linux-next: build failure after merge of the driver-core tree
in [Kernel]
|
Prev: [ !! PROPOSAL !! ] NMI & register handling infrastructure
Next: v4l: Pushdown bkl to drivers that implement their own ioctl
From: Stephen Rothwell on 18 May 2010 02:50 Hi Greg, After merging the driver-core tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: cc1: warnings being treated as errors In file included from include/linux/kobject.h:21, from include/linux/device.h:17, from arch/powerpc/lib/devres.c:10: include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list and many more (arch/powerpc is built with -Werror (as do some other architectures)) and lots of similar warnings ... Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add struct file* to bin_attr callbacks"). See Rule 1 in Documentation/SubmitChecklist. The header file probably just needs "struct file;" added in the right place. I have reverted that commit for today (and commit 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs file open to read device dependent config space") that depends on it). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Eric W. Biederman on 18 May 2010 03:10 Stephen Rothwell <sfr(a)canb.auug.org.au> writes: > Hi Greg, > > After merging the driver-core tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > fs/sysfs/mount.c: In function 'sysfs_exit_ns': > fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function) > > Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs: > Implement sysfs tagged directory support") from the driver-core tree > interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get > rid of S_BIAS") from the vfs tree. > > I don't know how to fix this, so I just commented the code out for now > (see below). Please someone supply a correct fix. > > [Al, I notice that the "get rid of S_BIAS" patch has an author date of > March 22 - it would have been nice if it had been in linux-next during > the last two months so that we could have had a fix for this some time > ago.] Stephen what is the easiest way to get a copy of Al's tree so I can take a look to see what needs to happen? 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/
From: Al Viro on 18 May 2010 03:50 On Tue, May 18, 2010 at 12:00:01AM -0700, Eric W. Biederman wrote: > Stephen Rothwell <sfr(a)canb.auug.org.au> writes: > > > Hi Greg, > > > > After merging the driver-core tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > fs/sysfs/mount.c: In function 'sysfs_exit_ns': > > fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function) > > > > Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs: > > Implement sysfs tagged directory support") from the driver-core tree > > interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get > > rid of S_BIAS") from the vfs tree. > > > > I don't know how to fix this, so I just commented the code out for now > > (see below). Please someone supply a correct fix. > > > > [Al, I notice that the "get rid of S_BIAS" patch has an author date of > > March 22 - it would have been nice if it had been in linux-next during > > the last two months so that we could have had a fix for this some time > > ago.] > > Stephen what is the easiest way to get a copy of Al's tree so I can take > a look to see what needs to happen? What needs to happen is the end of s_instances abuse in there. If you do something to all your sysfs_super_info instances, put those into a list of its own. What seems to be done there is blind "slap NULL at that member in all those structures, no matter what might be going on". Since the only thing you apparently care about is that sb->s_fs_info won't disappear under you... I really wonder what you intend to happen with readdir/sysfs_exit_ns races, but that's a separate question. Note that there you drop all locks many times (and don't get me started on the amount of contention in sysfs), you have no protection against old info->ns[...] contents getting stale, AFAICS. -- 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/
From: Stephen Rothwell on 18 May 2010 04:00 Hi Eric, On Tue, 18 May 2010 00:00:01 -0700 ebiederm(a)xmission.com (Eric W. Biederman) wrote: > > Stephen what is the easiest way to get a copy of Al's tree so I can take > a look to see what needs to happen? It is here: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next [The latest list of trees included in linux-next can always be found here: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees] -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Eric W. Biederman on 18 May 2010 06:40
Stephen Rothwell <sfr(a)canb.auug.org.au> writes: > Hi Eric, > > On Tue, 18 May 2010 00:00:01 -0700 ebiederm(a)xmission.com (Eric W. Biederman) wrote: >> >> Stephen what is the easiest way to get a copy of Al's tree so I can take >> a look to see what needs to happen? > > It is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next > > [The latest list of trees included in linux-next can always be found here: > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees] Thanks. I will cook up a proper incremental patch after I get some sleep. Stephen it appears those two lines you have commented out are actually unnecessary. We have deactivate_super kill_sb aka sysfs_kill_sb kill_anon_super generic_shutdown_super sb_lock list_del(sb->s_instances) sb_unlock kfree(info) Nothing generic stomps on s_fs_info. Which means that if I find a superblock on sb->s_instances sb->s_fs_info still points to a valid sysfs_super_info. As as for the race Al mentions between sysfs_exit_ns and sysfs_readdir, I looked and a small race has crept in. The primary prevention of problems is that all matching sysfs_dirents for that namespace are required to be removed before sysfs_exit_ns is called. What remains is the tiniest of races where a namespace structure is freed and a new namespace structure of the same type is allocated at the same address and sysfs_dirents for it are created, all during the a single kernel readdir operation. Possible with slabs, and copy_to_user triggering a page fault. Still the worst case is that we tell userspace some name that it wasn't supposed to see on that mount point. From a userspace point of view this seems to fall under a readdir implementations license to return some odd things if the directory is changing during the readdir call. Overall we do preserve the property of returning everything that is in the directory between opendir and the time readdir his the end of file. 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/ |