Hello,
On Mon, Jul 30, 2018 at 05:50:02PM +, Bart Van Assche wrote:
> On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> > On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > > It's not clear to me how the sysfs_break_active_protection() should obtain
> > > the
On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > It's not clear to me how the sysfs_break_active_protection() should obtain
> > the struct kernfs_node pointer to the attribute. Calling that function
> > before
> >
Hello, Bart.
On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> It's not clear to me how the sysfs_break_active_protection() should obtain
> the struct kernfs_node pointer to the attribute. Calling that function before
> device_remove_file_self() causes a double call to
>
On Mon, 2018-07-30 at 07:13 -0700, t...@kernel.org wrote:
> Also, wouldn't it be better to just expose sysfs_break/unbreak and
> then do sth like the following from scsi?
>
> kobject_get();
> sysfs_break_active_protection();
> do normal sysfs removal;
>
On Sun, Jul 29, 2018 at 04:03:41AM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
>
> Hello Tejun,
>
> How could this change
Hello, Bart.
On Thu, Jul 26, 2018 at 09:57:40PM +, Bart Van Assche wrote:
...
> @@ -440,11 +445,21 @@ bool sysfs_remove_file_self(struct kobject *kobj, const
> struct attribute *attr)
> return false;
>
> ret = kernfs_remove_self(kn);
> + if (ret && cb) {
> +
On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> Making removal asynchronous this way sometimes causes issues because
> whether the user sees the device released or not is racy.
Hello Tejun,
How could this change cause any user-visible changes? My understanding is
that any work queued with
On Thu, 2018-07-26 at 07:14 -0700, t...@kernel.org wrote:
> Hello,
>
> On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> > On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > > Making removal asynchronous this way sometimes causes issues because
> > > whether the user sees
Hello,
On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
> > kernfs/sysfs have mechanisms to
On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> Making removal asynchronous this way sometimes causes issues because
> whether the user sees the device released or not is racy.
> kernfs/sysfs have mechanisms to deal with these cases - remove_self
> and kernfs_break_active_protection(). Have
Hello,
ISTR giving the same feedback before.
On Wed, Jul 25, 2018 at 10:38:28AM -0700, Bart Van Assche wrote:
> +struct remove_dev_work {
> + struct callback_headhead;
> + struct scsi_device *sdev;
> +};
> +
> +static void delete_sdev(struct callback_head *head)
> +{
> +
Bart Van Assche 于2018年7月25日周三 下午7:39写道：
>
> This patch avoids that self-removal triggers the following deadlock:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc2-dbg+ #5 Not tainted
>
>From my limited insight into this:
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane
Bart,
> This patch avoids that self-removal triggers the following deadlock:
Somebody please review this so we can get it merged.
--
Martin K. Petersen Oracle Linux Engineering
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
15 matches
Mail list logo
