On 19.07.2007 [09:58:50 -0700], Andrew Morton wrote:
> On Thu, 19 Jul 2007 08:51:49 -0700 Badari Pulavarty <[email protected]> wrote:
>
> > > > + }
> > > > +
> > > > + offset += ret;
> > > > + retval += ret;
> > > > + len -= ret;
> > > > + index += offset >> HPAGE_SHIFT;
> > > > + offset &= ~HPAGE_MASK;
> > > > +
> > > > + page_cache_release(page);
> > > > + if (ret == nr && len)
> > > > + continue;
> > > > + goto out;
> > > > + }
> > > > +out:
> > > > + return retval;
> > > > +}
> > >
> > > This code doesn't have all the ghastly tricks which we deploy to
> > > handle concurrent truncate.
> >
> > Do I need to ? Baaahh!! I don't want to deal with them.
>
> Nick, can you think of any serious consequences of a read/truncate
> race in there? I can't..
>
> > All I want is a simple read() to get my oprofile working. Please
> > advise.
>
> Did you consider changing oprofile userspace to read the executable
> with mmap?
It's not actually oprofile's code, though, it's libbfd (used by
oprofile). And it works fine (presumably) for other binaries. Just not
for libhugetlbfs-relinked binaries because hugetlbfs doesn't behave like
a normal ramfs (perhaps it shouldn't, but that's a different argument).
But I do think a second reason to do this is to make hugetlbfs behave
like a normal fs -- that is read(), write(), etc. work on files in the
mountpoint. But that is simply my opinion.
Thanks,
Nish
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
