The error handling path at label 'accept_err' already performs these
'sock_release()' and 'mutex_unlock()' calls. The order is reversed, but
it is not important.
So avoid code duplication and 'goto accept_err'.
While at it, add some missing spaces around a '='.
Signed-off-by: Christophe JAILLET
Return all fallcoate modes supported by gfs2 file system.
Cc: cluster-devel@redhat.com
Signed-off-by: Lukas Czerner
---
fs/gfs2/file.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 33a0cb5..12e1de5 100644
--- a/fs/g
The lockdep code had reported the following unsafe locking scenario:
CPU0CPU1
lock(s_active#228);
lock(&bdev->bd_mutex/1);
lock(s_active#228);
lock(&bdev->bd_mutex);
*
v6:
- Add a second patch to rename the bd_fsfreeze_mutex to
bd_fsfreeze_blktrace_mutex.
v5:
- Overload the bd_fsfreeze_mutex in block_device structure for
blktrace protection.
v4:
- Use blktrace_mutex in blk_trace_ioctl() as well.
v3:
- Use a global blktrace_mutex to serializ
The patches are now here for testing
https://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git/log/?h=next
Dave
As the bd_fsfreeze_mutex is used by the blktrace subsystem as well,
it is now renamed to bd_fsfreeze_blktrace_mutex to better reflect
its purpose.
Signed-off-by: Waiman Long
---
fs/block_dev.c | 14 +++---
fs/gfs2/ops_fstype.c| 6 +++---
fs/nilfs2/super.c | 6 +++---
Acked-by: Steven Rostedt (VMware)
for the series.
Jens, feel free to take this in your tree.
-- Steve
On Mon, 18 Sep 2017 14:53:49 -0400
Waiman Long wrote:
> v6:
> - Add a second patch to rename the bd_fsfreeze_mutex to
> bd_fsfreeze_blktrace_mutex.
>
> v5:
> - Overload the bd_f
Don't rename it to a way to long name. Either add a separate mutex
for your purpose (unless there is interaction between freezing and
blktrace, which I doubt), or properly comment the usage.
Taking a look at this it seems like using a lock in struct block_device
isn't the right thing to do anyway - all the action is on fields in
struct blk_trace, so having a lock inside that would make a lot more
sense.
It would also help to document what exactly we're actually protecting.
