Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-27 Thread Hannes Reinecke
On 3/25/19 4:32 PM, Bart Van Assche wrote: On Mon, 2019-03-25 at 10:26 +0100, Hannes Reinecke wrote: The original issue leading to this patchset was this crash: [159135.508116] Pid: 2638, comm: ssea Tainted: GWX 3.0.101-0.40-default #1 HP ProLiant BL460c Gen9 [159135.508119] RIP: 0

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-25 Thread Bart Van Assche
On Mon, 2019-03-25 at 10:26 +0100, Hannes Reinecke wrote: > The original issue leading to this patchset was this crash: > > > [159135.508116] Pid: 2638, comm: ssea Tainted: GWX > 3.0.101-0.40-default #1 HP ProLiant BL460c Gen9 > [159135.508119] RIP: 0010:[] [] > scsi_device_get+0x1

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-25 Thread Hannes Reinecke
On 3/22/19 12:33 AM, Bart Van Assche wrote: On Thu, 2019-03-21 at 19:11 -0400, Douglas Gilbert wrote: That doesn't sound right. If it was correct then sg_open() and sg_release() have mutex overkill (and I don't think that is caused by the complexity of adding O_EXCL which is damn hard to impleme

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-21 Thread Douglas Gilbert
On 2019-03-21 7:33 p.m., Bart Van Assche wrote: On Thu, 2019-03-21 at 19:11 -0400, Douglas Gilbert wrote: That doesn't sound right. If it was correct then sg_open() and sg_release() have mutex overkill (and I don't think that is caused by the complexity of adding O_EXCL which is damn hard to imp

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-21 Thread Bart Van Assche
On Thu, 2019-03-21 at 19:11 -0400, Douglas Gilbert wrote: > That doesn't sound right. If it was correct then sg_open() and sg_release() > have mutex overkill (and I don't think that is caused by the complexity of > adding O_EXCL which is damn hard to implement correctly). > > Example with existing

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-21 Thread Douglas Gilbert
On 2019-03-21 7:11 p.m., Douglas Gilbert wrote: On 2019-03-21 5:36 p.m., Bart Van Assche wrote: On Wed, 2019-03-20 at 12:39 +0100, Hannes Reinecke wrote: The 'ch_mutex" is meant to guard against modifications of file->private_data, so we need to take in in ch_release() as well as in ch_open().

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-21 Thread Douglas Gilbert
On 2019-03-21 5:36 p.m., Bart Van Assche wrote: On Wed, 2019-03-20 at 12:39 +0100, Hannes Reinecke wrote: The 'ch_mutex" is meant to guard against modifications of file->private_data, so we need to take in in ch_release() as well as in ch_open(). Signed-off-by: Hannes Reinecke --- drivers/sc

Re: [PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-21 Thread Bart Van Assche
On Wed, 2019-03-20 at 12:39 +0100, Hannes Reinecke wrote: > The 'ch_mutex" is meant to guard against modifications of > file->private_data, so we need to take in in ch_release() as > well as in ch_open(). > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/ch.c | 2 ﭗ橸ṷ梧뇪觬() > > diff --gi

[PATCH 1/2] ch: add missing mutex_lock()/mutex_unlock() in ch_release()

2019-03-20 Thread Hannes Reinecke
The 'ch_mutex" is meant to guard against modifications of file->private_data, so we need to take in in ch_release() as well as in ch_open(). Signed-off-by: Hannes Reinecke --- drivers/scsi/ch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c index 1c50