public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarod Wilson <jwilson@redhat.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net,
	"Kristian Høgsberg" <krh@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH update] firewire: fix "kobject_add failed for fw* with -EEXIST"
Date: Mon, 28 Jan 2008 11:48:53 -0500	[thread overview]
Message-ID: <200801281148.54017.jwilson@redhat.com> (raw)
In-Reply-To: <tkrat.a4603d89e4c2fde1@s5r6.in-berlin.de>

On Sunday 27 January 2008 12:20:40 pm Stefan Richter wrote:
> There is a race between shutdown and creation of devices:  fw-core may
> attempt to add a device with the same name of an already existing
> device.  http://bugzilla.kernel.org/show_bug.cgi?id=9828
>
> Impact of the bug:  Happens rarely, forces the user to unplug and replug
> the new device to get it working.

If you're crazy enough to set up a software raid array on two firewire drives 
that end up contending for the fwX device, its much worse than simply having 
to unplug and replug though, since all hell breaks loose at the fs level and 
the array level.

We may have another issue there though, as when this happened to me, the md 
layer apparently never noticed (after ~6 hours) that one of the array members 
had disappeared -- not sure if that's firewire's fault or md's though... This 
will presumably avoid this situation entirely, but worth noting that there 
may still be somewhere we need to better communicate status to an upper 
layer.

> The fix moves deregistration of the minor number and device_unregister()
> into a common rw_sem protected section.
>
> We also move the ref count increment from fw_device_op_open into an
> rw_sem protected section with the lookup of the device, so that the
> device pointer can't become invalid between lookup and usage.
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Looks straight-forward enough, and I'll give these a spin shortly and see if I 
can reproduce the situation I was hitting with my raid array...


-- 
Jarod Wilson
jwilson@redhat.com

  parent reply	other threads:[~2008-01-28 16:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-27  0:05 [PATCH] firewire: fix "kobject_add failed for fw* with -EEXIST" Stefan Richter
2008-01-27 17:20 ` [PATCH update] " Stefan Richter
2008-01-27 17:21   ` [PATCH] firewire: fail open() quickly if the node doesn't exist anymore Stefan Richter
2008-01-28 22:32     ` Jarod Wilson
2008-01-28 23:50       ` Stefan Richter
2008-01-28 16:48   ` Jarod Wilson [this message]
2008-01-28 18:54     ` [PATCH update] firewire: fix "kobject_add failed for fw* with -EEXIST" Stefan Richter
2008-01-28 22:24       ` Jarod Wilson
2008-01-28 19:16     ` Stefan Richter
2008-01-28 23:31       ` Stefan Richter
2008-02-02 14:01         ` [PATCH update 2] " Stefan Richter
2008-01-28 22:30   ` [PATCH update] " Jarod Wilson

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=200801281148.54017.jwilson@redhat.com \
    --to=jwilson@redhat.com \
    --cc=krh@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /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