Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-13 Thread J. Bruce Fields
On Wed, Aug 13, 2014 at 08:28:27AM +1000, Stephen Rothwell wrote: > This s reinforced by the lack of Acked-by, Reviewed-by and Tested-by > tags ... (the addition of which would presumably require the rebase > (or rewrite) of a published git tree.) By the way, I reshuffled my branches recently so

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-13 Thread J. Bruce Fields
On Wed, Aug 13, 2014 at 08:28:27AM +1000, Stephen Rothwell wrote: This s reinforced by the lack of Acked-by, Reviewed-by and Tested-by tags ... (the addition of which would presumably require the rebase (or rewrite) of a published git tree.) By the way, I reshuffled my branches recently so the

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Stephen Rothwell
Hi Jeff, On Tue, 12 Aug 2014 19:47:36 -0400 Jeff Layton wrote: > > On Wed, 13 Aug 2014 08:28:27 +1000 > Stephen Rothwell wrote: > > > On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton > > wrote: > > > > > > Absent any objections, I'll plan to merge these for 3.18. > > > > This means that this

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Wed, 13 Aug 2014 08:28:27 +1000 Stephen Rothwell wrote: > Hi Jeff, > > On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton > wrote: > > > > Absent any objections, I'll plan to merge these for 3.18. > > This means that this patch set should *not* be in linux-next until after > (at least)

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Stephen Rothwell
Hi Jeff, On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton wrote: > > Absent any objections, I'll plan to merge these for 3.18. This means that this patch set should *not* be in linux-next until after (at least) v3.17-rc1 is released ... This s reinforced by the lack of Acked-by, Reviewed-by and

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread J. Bruce Fields
On Tue, Aug 12, 2014 at 01:43:13PM -0400, Jeff Layton wrote: > On Tue, 12 Aug 2014 10:48:08 -0400 > Jeff Layton wrote: > > > In the days of yore, the file locking code was primarily protected by > > the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks > > into a spinlock), at

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton wrote: > In the days of yore, the file locking code was primarily protected by > the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks > into a spinlock), at which point the code was changed to be protected > by a conventional

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Tue, 12 Aug 2014 08:32:29 -0700 Christoph Hellwig wrote: > Btw, I might be missing something here, but wouldn't it be better > to reference count the file_lock structure and grab a reference to > it where we currently call (__)locks_copy_lock? > It's not really possible with the way this

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Christoph Hellwig
Btw, I might be missing something here, but wouldn't it be better to reference count the file_lock structure and grab a reference to it where we currently call (__)locks_copy_lock? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

[PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
In the days of yore, the file locking code was primarily protected by the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks into a spinlock), at which point the code was changed to be protected by a conventional spinlock (mostly due to a push to finally eliminate the BKL). Since

[PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
In the days of yore, the file locking code was primarily protected by the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks into a spinlock), at which point the code was changed to be protected by a conventional spinlock (mostly due to a push to finally eliminate the BKL). Since

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Christoph Hellwig
Btw, I might be missing something here, but wouldn't it be better to reference count the file_lock structure and grab a reference to it where we currently call (__)locks_copy_lock? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Tue, 12 Aug 2014 08:32:29 -0700 Christoph Hellwig h...@infradead.org wrote: Btw, I might be missing something here, but wouldn't it be better to reference count the file_lock structure and grab a reference to it where we currently call (__)locks_copy_lock? It's not really possible with

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton jlay...@primarydata.com wrote: In the days of yore, the file locking code was primarily protected by the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks into a spinlock), at which point the code was changed to be protected by a

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread J. Bruce Fields
On Tue, Aug 12, 2014 at 01:43:13PM -0400, Jeff Layton wrote: On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton jlay...@primarydata.com wrote: In the days of yore, the file locking code was primarily protected by the BKL. That changed in commit 72f98e72551fa (locks: turn lock_flocks into a

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Stephen Rothwell
Hi Jeff, On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton jlay...@primarydata.com wrote: Absent any objections, I'll plan to merge these for 3.18. This means that this patch set should *not* be in linux-next until after (at least) v3.17-rc1 is released ... This s reinforced by the lack of

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Jeff Layton
On Wed, 13 Aug 2014 08:28:27 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Jeff, On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton jlay...@primarydata.com wrote: Absent any objections, I'll plan to merge these for 3.18. This means that this patch set should *not* be in

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

2014-08-12 Thread Stephen Rothwell
Hi Jeff, On Tue, 12 Aug 2014 19:47:36 -0400 Jeff Layton jeff.lay...@primarydata.com wrote: On Wed, 13 Aug 2014 08:28:27 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton jlay...@primarydata.com wrote: Absent any objections, I'll