All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: SCSI development list <linux-scsi@vger.kernel.org>,
	James Bottomley <james.bottomley@hansenpartnership.com>
Cc: vaughan <vaughan.cao@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	Hannes Reinecke <hare@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] sg: O_EXCL and other lock handling
Date: Thu, 14 Nov 2013 11:17:19 -0500	[thread overview]
Message-ID: <5284F78F.6010600@interlog.com> (raw)
In-Reply-To: <5282CEB4.4050708@interlog.com>

On 13-11-12 07:58 PM, Douglas Gilbert wrote:
> After feedback on version 2 and a new report of a failure
> in the vicinity of sg_remove() [remove device] during
> a shutdown on a large machine, the locking has been
> revised again.

The shutdown problem in the vicinity of sg_remove() has
been traced to the st driver and a patch to fix st has
been sent to this list. So there are now no reported
problems against this patch.

Doug Gilbert

> ChangeLog v3:
>    - change Sg_device::exclude and detached (renamed to
>      detaching) to atomic_t
>    - introduce atomic_t Sg_device::open_cnt and use for
>      open(O_EXCL) logic. Hence stop using list_empty(sfds)
>      which decouples the open/release logic from
>      sg_remove_device() and other post-release cleanup
>      functions
>    - use a mutex to stop races between sg_open() and
>      sg_release() on the same device
>    - reduce the use of driver wide sg_index_lock so now
>      it only protects sg_index_idr (the device array)
>    - expand cleanups requested by checkpatch.pl to the
>      remaining code in the driver
>
> ChangeLog v2:
>    - favour non O_EXCL open()s over open(dev, O_EXCL)s
>    - wake all open(dev)s if dev is removed (detached)
>    - wake all read(dev_fd)s that are waiting for a response
>      if dev is removed (detached)
>    - other cleanups requested by checkpatch.pl
>
> ChangeLog v1:
>    - introduce a finer grain (per device) lock to protect
>      access and changes to the file descriptor objects
>    - introduce a semaphore for mutual exclusion of co-incident
>      open and release calls to the same device
>    - improve the O_EXCL handling of sg_open() when multiple
>      callers are waiting for an O_EXCL condition to clear
>    - change some seq_printf()s to seq_puts()s as requested
>      by checkpatch.pl
>    - update copyright notice, version number and date
>
>
> The patch is against lk 3.12.0 (and should work on lk 3.10
> and lk 3.11 as the sg driver hasn't changed).
>
> Testing is ongoing (see the v2 post) with focus on host
> removal and shutdown. The driver survives bombarding 4 LUs
> with queued requests spread across 6000 scsi_debug LUs.
> Some log noise is generated, but it is not from the sg
> driver:
>    scsi 9:0:33:3: rejecting I/O to offline device
>    scsi 9:0:33:3: [sg1000] killing request
> <multiple times>
>
> This is not seen when there are only 600 LUs.
>
>
> Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>


      reply	other threads:[~2013-11-14 16:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13  0:58 [PATCH v3] sg: O_EXCL and other lock handling Douglas Gilbert
2013-11-14 16:17 ` Douglas Gilbert [this message]

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=5284F78F.6010600@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=vaughan.cao@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.