Prev: [PATCH -next] platform/x86: msi-laptop depends on SERIO_I8042
Next: [PATCH -next] nouveau: fix acpi_lid_open undefined
From: Eric Paris on 23 May 2010 19:50 On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote: > On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis(a)redhat.com> wrote: > > I'm feeling like this is a udev bug, but the only fix is going to be to > > revert and paper over anything else that has problems with > > (mode & S_IFMNT) == 0 > > > > -Eric > [root(a)duff ~]# cat udevd.proc.pid.fd.out > lr-x------. 1 root root 64 2010-05-23 22:15 6 -> anon_inode:inotify > lrwx------. 1 root root 64 2010-05-23 22:15 7 -> anon_inode:[signalfd] > [root(a)duff ~]# head -30 udevd.strace.log > Process 1734 attached - interrupt to quit > poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) > ioctl(6, FIONREAD, [0]) = 0 Well at least I see what is wrong. Before the change ioctl(FIONREAD) would go down this code path: sys_ioctl() do_vfs_ioctl() vfs_ioctl() filp->f_ops->ioctl() inotify_ioctl() returns the answer. After the change we instead get: sys_ioctl() do_vfs_ioctl() file_ioctl() which would return put_user(i_size_read(inode) - filp->f_pos, p) If there is no rule that all inodes must be of a known S_IFMNT then I guess the best fix is to just revert and I'll fix up the symptoms. If there is such an unwritten rule (which seems perfectly reasonable) we can either special case the anon_inode to push FIONREAD down to vfs_ioctl or move FIONREAD down to vfs_ioctl and force everyone else to implement it. Al? Maybe you have better ideas? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |