lkml.org 
[lkml]   [2007]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: select(0, ..) is valid ?
    On Tue, 15 May 2007, Christoph Lameter wrote:
    > On Tue, 15 May 2007, Andrew Morton wrote:
    >
    > > I _think_ we can just do
    > >
    > > --- a/fs/compat.c~a
    > > +++ a/fs/compat.c
    > > @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
    > > */
    > > ret = -ENOMEM;
    > > size = FDS_BYTES(n);
    > > - bits = kmalloc(6 * size, GFP_KERNEL);
    > > - if (!bits)
    > > - goto out_nofds;
    > > + if (likely(size)) {
    > > + bits = kmalloc(6 * size, GFP_KERNEL);
    > > + if (!bits)
    > > + goto out_nofds;
    > > + } else {
    > > + bits = NULL;
    > > + }

    It's interesting that compat_core_sys_select() shows this kmalloc(0)
    failure but core_sys_select() does not. That's because core_sys_select()
    avoids kmalloc by using a buffer on the stack for small allocations (and
    0 sure is small). Shouldn't compat_core_sys_select() do just the same?
    Or is SLUB going to be so efficient that doing so is a waste of time?

    > > fds.in = (unsigned long *) bits;
    > > fds.out = (unsigned long *) (bits + size);
    > > fds.ex = (unsigned long *) (bits + 2*size);
    > > _
    > >
    > > I mean, if that oopses then I'd be very interested in finding out why.
    > >
    > > But I'm starting to suspect that it would be better to permit kmalloc(0) in
    > > slub. It depends on how many more of these things need fixing.
    > >
    > > otoh, a kmalloc(0) could be a sign of some buggy/inefficient/weird code, so
    > > there's some value in forcing us to go look at all the callsites.
    >
    > Hmmm... We could have kmalloc(0) return a pointer to the zero page? That
    > would catch any writers?

    I don't think using the zero page that way would be at all safe:
    there's probably configurations/architectures in which it is write
    protected, but I don't believe that's a given at all.

    But the principle is good: ERR_PTR(-MAX_ERRNO) should work,
    that area up the top should always give a fault.
    Hmm, but perhaps there are architectures on which it does not?

    Hugh
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-15 23:25    [W:0.024 / U:31.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site