I got Al's patches merged with Martin's patches and only one pretty simple conflict to fix. In testing, most things seem to work right, but at least one important thing is busted: umount... unmounting the filesystem just gets the kernel into a forever loop, "ERROR: fs_mount_pending 147936488" just goes on forever until I interrupt the umount command: Mar 25 23:42:00 be1 kernel: [ 156.990737] Releasing OP (ffff8800189a0000: 103) Mar 25 23:42:00 be1 kernel: [ 156.991366] orangefs_kill_sb: called Mar 25 23:42:00 be1 kernel: [ 156.991401] orangefs_destroy_inode: deallocated ffff880018998000 destroying inode 00001000-0000-0000-0000-000000000000 Mar 25 23:42:00 be1 kernel: [ 156.991414] orangefs_unmount_sb called on sb ffff880018810000 Mar 25 23:42:00 be1 kernel: [ 156.991416] Alloced OP (ffff8800189a0000: 104 OP_FS_UMOUNT) Mar 25 23:42:00 be1 kernel: [ 156.991417] Attempting ORANGEFS Unmount via host tcp://be1:3334/orangefs Mar 25 23:42:00 be1 kernel: [ 156.991418] service_operation: orangefs_fs_umount op:ffff8800189a0000: process:umount: pid:1124: Mar 25 23:42:00 be1 kernel: [ 156.991419] service_operation: op:OP_FS_UMOUNT: op_state:1: process:umount: Mar 25 23:42:00 be1 kernel: [ 156.991435] orangefs: skipping op tag 104 OP_FS_UMOUNT Mar 25 23:42:00 be1 kernel: [ 156.991435] orangefs: ERROR: fs_mount_pending 147936488 Mar 25 23:42:00 be1 kernel: [ 156.991440] orangefs: skipping op tag 104 OP_FS_UMOUNT The github repo has all the patches, I didn't think I should push it to the orangefs for-next branch like this. https://github.com/hubcapsc/linux/tree/current I'll look to see if I can see it, I guess it has something to do with Al's superblock re-do... -Mike On Fri, Mar 25, 2016 at 9:11 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mar 25, 2016 18:01, "Al Viro" <viro@xxxxxxxxxxxxxxxxxx> wrote: >> >> Umm... IIRC, there had been precedents when self-contained driver got >> merged >> later than -rc1. > > I do it if there is some reason for it, yes. > > In particular, for things like consumer hardware that has not had a driver > for it, I'll merge new drivers later, because missing one release nasty be a > big deal if some average-Joe machine just doesn't work. But even then it's > not just "random driver", but something that keeps that machine from working > entirely - disk or network or GPU or USB or something core like that. > > So it's not just "new driver that cannot cause a regression". It's also > about the driver being important to people who can't reasonably be expected > to compile their own kernel.. > > There is little reason to do an expedited out-of-the-merge-window merge for > something like orangefs, though. > > Linus -- 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
