diff options
author | Jeff Moyer <jmoyer@redhat.com> | 2017-12-13 16:33:09 -0500 |
---|---|---|
committer | Dan Williams <dan.j.williams@intel.com> | 2018-01-19 17:01:29 -0800 |
commit | d08cd5e0eb632eef7819ba911c09d89a767f2d0c (patch) | |
tree | c68a2d91c3265b0b3752618db864180c4f0bcc17 /drivers/dax/device.c | |
parent | ed07c4338dd5ceadb5ffed0a5be03488ac54f5d2 (diff) | |
download | lwn-d08cd5e0eb632eef7819ba911c09d89a767f2d0c.tar.gz lwn-d08cd5e0eb632eef7819ba911c09d89a767f2d0c.zip |
libnvdimm, btt: fix uninitialized err_lock
When a sector mode namespace is initially created, the arena's err_lock
is not initialized. If, on the other hand, the namespace already
exists, the mutex is initialized. To fix the issue, I moved the mutex
initialization into the arena_alloc, which is called by both
discover_arenas and create_arenas.
This was discovered on an older kernel where mutex_trylock checks the
count to determine whether the lock is held. Because the data structure
is kzalloc-d, that count was 0 (held), and I/O to the device would hang
forever waiting for the lock to be released (see btt_write_pg, for
example). Current kernels have a different mutex implementation that
checks for a non-null owner, and so this doesn't show up as a problem.
If that lock were ever contended, it might cause issues, but you'd have
to be really unlucky, I think.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'drivers/dax/device.c')
0 files changed, 0 insertions, 0 deletions