[lkml]   [2007]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
    On Thu, 04 Jan 2007 11:51:10 -0600
    Eric Sandeen <> wrote:

    > Andrew Morton wrote:
    > > Al is correct, of course. But the patch takes bad_inode.o from 280 up to 703
    > > bytes, which is a bit sad for some cosmetic thing which nobody ever looks
    > > at or modifies.
    > >
    > > Perhaps you can do
    > >
    > > static int return_EIO_int(void)
    > > {
    > > return -EIO;
    > > }
    > >
    > > static int bad_file_release(struct inode * inode, struct file * filp)
    > > __attribute__((alias("return_EIO_int")));
    > > static int bad_file_fsync(struct inode * inode, struct file * filp)
    > > __attribute__((alias("return_EIO_int")));
    > >
    > > etcetera?
    > Ok, try this on for size. Even though the gcc manual says alias doesn't work
    > on all target machines, I assume linux arches are ok since alias is used
    > in the core module init & exit code...
    > Also - is it ok to alias a function with one signature to a function with
    > another signature?

    Ordinarily I'd say no wucking fay, but that's effectively what we've been
    doing in there for ages, and it seems to work.

    I'd be a bit worried if any of these functions were returning pointers,
    because one could certainly conceive of an arch+compiler combo which
    returns pointers in a different register from integers (680x0?) but that's
    not happening here.

    > Note... I also realized that there are a couple of file ops which expect unsigned
    > returns... poll and get_unmapped_area. The latter seems to be handled just fine by
    > the caller, which does IS_ERR gyrations to check for errnos.
    > I'm not so sure about poll; some callers put the return in a signed int, others
    > unsigned, not sure anyone is really checking for -EIO... I think this op should
    > probably be returning POLLERR, so that's what I've got in this version.

    Yeah, that should all be OK.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-04 19:29    [W:0.021 / U:49.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site