On Thu, 1 May 2014 06:28:44 -0400 Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > Hi Trond, > This set is basically unchanged from the last one, aside from a bit > more cleanup of unneeded arguments in patch #1. > > I know that you basically NAKed this set earlier this week. The issue > you saw was that the generic locking codepaths never set the fl_owner > value for flock locks. That's true, but nfs_flock does set this for any > file_lock request that comes through it, so patch #1 is safe to apply > now if you see no other issue with it. > > I have a patch queued for v3.16 that makes the generic flock codepaths > set the fl_owner, but that's just cleanup and won't really affect how > this works. > > The main problem that I think we need to fix soon though is the one that > patch #2 fixes. An unprivileged user can trigger that BUG() and if > panic_on_oops is set, then that's an unprivileged DoS at least. > > Jeff Layton (3): > nfs4: treat lock owners as opaque values > nfs4: queue free_lock_state job submission to nfsiod > nfs4: turn free_lock_state into a void return operation > > fs/nfs/nfs4_fs.h | 26 +++++++------------- > fs/nfs/nfs4proc.c | 14 +++++------ > fs/nfs/nfs4state.c | 69 +++++++++++++++++++++--------------------------------- > 3 files changed, 42 insertions(+), 67 deletions(-) > Hi Trond, The patch that moves the setting of fl_owner for flock locks into the generic locking code was merged for v3.16. Are you willing to rescind your earlier NACK now that that's done? Thanks, -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
