On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote: > On 14 September 2014 21:47, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > double iput() on failure exit in lustre, racy removal of spliced dentries > > from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU pathwalk > > fixes. Please, pull from the usual place - > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus > > > > Shortlog: > > Al Viro (5): > > [fix] lustre: d_make_root() does iput() on dentry allocation failure > > move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon) > > fix bogus read_seqretry() checks introduced in b37199e > > don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu() > > be careful with nd->inode in path_init() and follow_dotdot_rcu() > > Hi, > > Commit 4023bfc9f351a7994 "be careful with nd->inode in path_init() and > follow_dotdot_rcu(), seem to hang my ARM no-MMU platform when mounting > the ramdisk. > > 3.17-rc4 - works > 3.17-rc5 - works with 4023bfc9f351a7994 reverted. > > Boot log with from rc5: > [ 5.810000] TCP: cubic registered > [ 5.820000] NET: Registered protocol family 17 > [ 5.860000] lpc2k-rtc 40046000.rtc: hctosys: unable to read the hardware clock > [ 5.910000] mmc_host mmc0: Bus speed (slot 0) = 12000000Hz (slot req > 25000000Hz, actual 12000000HZ div = 0) > [ 5.930000] mmc0: new SDHC card at address 0007 > [ 5.950000] mmcblk0: mmc0:0007 SD08G 7.42 GiB > [ 6.150000] clk: Not disabling unused clocks > [ 81.240000] random: nonblocking pool is initialized > > And there it just hangs it seems. > > > With patch reverted > [ 5.810000] TCP: cubic registered > [ 5.820000] NET: Registered protocol family 17 > [ 5.850000] lpc2k-rtc 40046000.rtc: hctosys: unable to read the hardware clock > [ 6.100000] clk: Not disabling unused clocks > [ 6.110000] RAMDISK: gzip image found at block 0 > [ 9.590000] VFS: Mounted root (ext2 filesystem) readonly on device 1:0. > [ 9.600000] devtmpfs: mounted > [ 9.610000] Freeing unused kernel memory: 68K (281e5000 - 281f6000) > > And then user space starts. *blink* What happens to mmc-related messages on successful boot? And what in that commit could've possibly lead to those not being produced? Another question: what happens if you revert a half of that commit? There are two separate parts, easy to isolate - one in follow_dotdot_rcu(), another in path_init(). They deal with similar problems, but they are independent from each other; which one is triggering that crap? Al, really mystified... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
