This patch avoids that self-removal triggers the following deadlock:
==
WARNING: possible circular locking dependency detected
4.18.0-rc2-dbg+ #5 Not tainted
--
modprobe/6539 is trying to acquir
James Bottomley writes:
> On Tue, 2016-11-08 at 20:10 -0600, Eric W. Biederman wrote:
>> James Bottomley writes:
>>
>> > On Tue, 2016-11-08 at 18:57 -0600, Eric W. Biederman wrote:
> [...]
>> > > I am pretty certain that if you are going to make
>> > > kernfs_remove_self and kernfs_remove_by_n
On Tue, 2016-11-08 at 20:10 -0600, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > On Tue, 2016-11-08 at 18:57 -0600, Eric W. Biederman wrote:
[...]
> > > I am pretty certain that if you are going to make
> > > kernfs_remove_self and kernfs_remove_by_name_ns to be safe to
> > > race ag
James Bottomley writes:
> On Tue, 2016-11-08 at 18:57 -0600, Eric W. Biederman wrote:
>> James Bottomley writes:
>>
>> > On Tue, 2016-11-08 at 13:13 -0600, Eric W. Biederman wrote:
> [...]
>> > > Is it really the dropping of the lock that is causing this?
>> > > I don't see that when I read tho
On Tue, 2016-11-08 at 18:57 -0600, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > On Tue, 2016-11-08 at 13:13 -0600, Eric W. Biederman wrote:
[...]
> > > Is it really the dropping of the lock that is causing this?
> > > I don't see that when I read those traces.
> >
> > No, it's an ABB
Bart Van Assche writes:
> On 11/08/2016 11:15 AM, Eric W. Biederman wrote:
>> James Bottomley writes:
>>
>>> On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
On 11/08/2016 07:28 AM, James Bottomley wrote:
> On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
>> diff -
James Bottomley writes:
> On Tue, 2016-11-08 at 13:13 -0600, Eric W. Biederman wrote:
>> James Bottomley writes:
>>
>> > On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
>> > > On 11/08/2016 07:28 AM, James Bottomley wrote:
>> > > > On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wr
On Tue, 2016-11-08 at 13:13 -0600, Eric W. Biederman wrote:
> James Bottomley writes:
>
> > On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
> > > On 11/08/2016 07:28 AM, James Bottomley wrote:
> > > > On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
> > > > > diff --git a/fs/ke
On 11/08/2016 11:15 AM, Eric W. Biederman wrote:
James Bottomley writes:
On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
On 11/08/2016 07:28 AM, James Bottomley wrote:
On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index cf
James Bottomley writes:
> On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
>> On 11/08/2016 07:28 AM, James Bottomley wrote:
>> > On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
>> > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
>> > > index cf4c636..44ec536 100644
>> > > --
On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
> On 11/08/2016 07:28 AM, James Bottomley wrote:
> > On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
> > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> > > index cf4c636..44ec536 100644
> > > --- a/fs/kernfs/dir.c
> > > +++ b/f
On 11/08/2016 07:28 AM, James Bottomley wrote:
On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index cf4c636..44ec536 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1410,7 +1410,7 @@ int kernfs_remove_by_name_ns(struct kernfs_node
On Tue, 2016-11-08 at 08:01 +0100, Greg KH wrote:
> On Mon, Nov 07, 2016 at 04:32:18PM -0800, Bart Van Assche wrote:
> > The SCSI core holds scan_mutex around SCSI device addition and
> > removal operations. sysfs serializes attribute read and write
> > operations against attribute removal through
On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
> The SCSI core holds scan_mutex around SCSI device addition and
> removal operations. sysfs serializes attribute read and write
> operations against attribute removal through s_active. Avoid that
> grabbing scan_mutex during self-removal of
On Mon, Nov 07, 2016 at 04:32:18PM -0800, Bart Van Assche wrote:
> The SCSI core holds scan_mutex around SCSI device addition and
> removal operations. sysfs serializes attribute read and write
> operations against attribute removal through s_active. Avoid that
> grabbing scan_mutex during self-rem
The SCSI core holds scan_mutex around SCSI device addition and
removal operations. sysfs serializes attribute read and write
operations against attribute removal through s_active. Avoid that
grabbing scan_mutex during self-removal of a SCSI device triggers
a deadlock by not calling __kernfs_remove(
On Fri, 2016-11-04 at 12:17 -0600, Bart Van Assche wrote:
> On 11/04/2016 07:47 AM, James Bottomley wrote:
> > You know after
> >
> > if (device_remove_file_self(dev, attr))
> >
> > returns true that s_active is held and also that KERNFS_SUICIDAL is
> > set on the node, so the non-self remove pa
On 11/04/2016 07:47 AM, James Bottomley wrote:
You know after
if (device_remove_file_self(dev, attr))
returns true that s_active is held and also that KERNFS_SUICIDAL is set
on the node, so the non-self remove paths can simply check for this
flag and return without descending into __kernfs_remo
On Thu, 2016-11-03 at 16:27 -0600, Bart Van Assche wrote:
> On 10/28/2016 08:08 PM, James Bottomley wrote:
> > This is a deadlock caused by an inversion issue in kernfs (suicide
> > vs
> > non-suicide removes); so fixing it in SCSI alone really isn't
> > appropriate. I count at least five other su
On 10/28/2016 08:08 PM, James Bottomley wrote:
> This is a deadlock caused by an inversion issue in kernfs (suicide vs
> non-suicide removes); so fixing it in SCSI alone really isn't
> appropriate. I count at least five other subsystems all using this
> mechanism, so they'll all be similarly affec
On Sun, 2016-10-30 at 19:22 +, Bart Van Assche wrote:
> On 10/28/16 19:08, James Bottomley wrote:
> > This is a deadlock caused by an inversion issue in kernfs (suicide
> > vs
> > non-suicide removes); so fixing it in SCSI alone really isn't
> > appropriate. I count at least five other subsyst
On 10/28/16 19:08, James Bottomley wrote:
> This is a deadlock caused by an inversion issue in kernfs (suicide vs
> non-suicide removes); so fixing it in SCSI alone really isn't
> appropriate. I count at least five other subsystems all using this
> mechanism, so they'll all be similarly affected.
On Wed, 2016-10-26 at 11:44 -0700, Bart Van Assche wrote:
> The solution I prefer is to modify the SCSI scanning code such that
> the scan_mutex is only held while performing the actual LUN scanning
> and while ensuring that no SCSI device has been created yet for a
> certain LUN number but not whi
On Thu, Oct 27, 2016 at 08:38:03AM -0700, Bart Van Assche wrote:
> On 10/27/2016 02:46 AM, Johannes Thumshirn wrote:
> > On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote:
> > > +static void scsi_remove_device_async(struct scsi_device *sdev)
> > > +{
> > > + if (scsi_device_get(sdev)
On 10/27/2016 02:36 AM, Sagi Grimberg wrote:
The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device
On 10/27/2016 02:46 AM, Johannes Thumshirn wrote:
On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote:
+static void scsi_remove_device_async(struct scsi_device *sdev)
+{
+ if (scsi_device_get(sdev) < 0)
Nit: the < 0 could be dropped, scsi_device_get returns either -ENXIO or
0
Hey Bart,
The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device and its sysfs
attributes are crea
Hi Bart,
On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote:
> The solution I prefer is to modify the SCSI scanning code such that
> the scan_mutex is only held while performing the actual LUN scanning
> and while ensuring that no SCSI device has been created yet for a
> certain LUN n
The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device and its sysfs
attributes are created. Since th
29 matches
Mail list logo