From: Ewan Milne <emilne@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
gregkh@linuxfoundation.org, martin.petersen@oracle.com,
hare@suse.com
Subject: Re: [PATCH 0/2] avoid crashing when reading /proc/scsi/scsi and simultaneously removing devices
Date: Mon, 11 Jan 2016 16:32:59 -0500 [thread overview]
Message-ID: <1452547979.22112.42.camel@localhost.localdomain> (raw)
In-Reply-To: <1452539718.2363.12.camel@HansenPartnership.com>
On Mon, 2016-01-11 at 11:15 -0800, James Bottomley wrote:
> On Mon, 2016-01-11 at 12:28 -0500, Ewan D. Milne wrote:
> > From: "Ewan D. Milne" <emilne@redhat.com>
> >
> > The klist traversal used by the reading of /proc/scsi/scsi is not
> > interlocked
> > against device removal. It takes a reference on the containing
> > object, but
> > this does not prevent the device from being removed from the list.
> > Thus, we
> > get errors and eventually panic, as shown in the traces below. Fix
> > this by
> > keeping a klist iterator in the seq_file private data.
> >
> > The problem can be easily reproduced by repeatedly increasing
> > scsi_debug's
> > max_luns to 30 and then deleting the devices via sysfs, while
> > simulatenously
> > accessing /proc/scsi/scsi.
> >
> > From a patch originally developed by David Jeffery <
> > djeffery@redhat.com>
>
> OK, so it looks like this is a bug in the klist system. When a
> starting point is used, there should be a check to see if it's still
> active otherwise the whole thing is racy. If it's fixed in klist, the
> fix works for everyone, not just SCSI.
>
> How about this? It causes the iterator to start at the beginning if
> the node has been deleted. That will produce double output during some
> of your test, but I think that's OK given that this is a rare race.
>
> James
I'm running with your change now, it does appear to fix the problem.
I guess the question is whether this behavior would trip up any other
klist users, for /proc/scsi/scsi it is probably not a problem. The
worst that might happen is that userspace tools that parse the output
would get duplicate entries.
-Ewan
> ---
>
> diff --git a/lib/klist.c b/lib/klist.c
> index d74cf7a..0507fa5 100644
> --- a/lib/klist.c
> +++ b/lib/klist.c
> @@ -282,9 +282,9 @@ void klist_iter_init_node(struct klist *k, struct klist_iter *i,
> struct klist_node *n)
> {
> i->i_klist = k;
> - i->i_cur = n;
> - if (n)
> - kref_get(&n->n_ref);
> + i->i_cur = NULL;
> + if (n && kref_get_unless_zero(&n->n_ref))
> + i->i_cur = n;
> }
> EXPORT_SYMBOL_GPL(klist_iter_init_node);
>
next prev parent reply other threads:[~2016-01-11 21:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-11 17:28 [PATCH 0/2] avoid crashing when reading /proc/scsi/scsi and simultaneously removing devices Ewan D. Milne
2016-01-11 17:28 ` [PATCH 1/2] drivers/base: add bus_device_iter_init, bus_device_iter_next, bus_device_iter_exit Ewan D. Milne
2016-01-11 17:28 ` [PATCH 2/2] scsi_proc: Change /proc/scsi/scsi to use bus device iterator Ewan D. Milne
2016-01-11 19:15 ` [PATCH 0/2] avoid crashing when reading /proc/scsi/scsi and simultaneously removing devices James Bottomley
2016-01-11 21:32 ` Ewan Milne [this message]
2016-01-12 2:35 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1452547979.22112.42.camel@localhost.localdomain \
--to=emilne@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox