* Re: [Xen-changelog] [linux-2.6.18-xen] scsifront: avoid acquiring same lock twice if ring is full
[not found] <E1YBL5P-00011p-DI@xenbits.xen.org>
@ 2015-01-14 10:36 ` Jürgen Groß
2015-01-14 11:02 ` Jan Beulich
0 siblings, 1 reply; 2+ messages in thread
From: Jürgen Groß @ 2015-01-14 10:36 UTC (permalink / raw)
To: xen-devel, Jan Beulich
On 01/14/2015 11:22 AM, Xen patchbot-linux-2.6.18-xen wrote:
> # HG changeset patch
> # User Juergen Gross <jgross@suse.com>
> # Date 1421228828 -3600
> # Node ID 3015a92b2b53825d00dc81c2dd131fc77ce8ab00
> # Parent 078f1bb69ea5e3772f3df4b4ee21f3c52e381e51
> scsifront: avoid acquiring same lock twice if ring is full
>
> The locking in scsifront_dev_reset_handler() as introduced by c/s
> 1209:4d1471ca031e is obviously wrong. In case of a full ring the host
> lock is acquired twice.
>
> Fixing this issue enables to get rid of the endless fo loop with an
> explicit break statement.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> Also add a missing version check.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Committed-by: Jan Beulich <jbeulich@suse.com>
> ---
>
>
> diff -r 078f1bb69ea5 -r 3015a92b2b53 drivers/xen/scsifront/scsifront.c
> --- a/drivers/xen/scsifront/scsifront.c Wed Dec 10 10:22:39 2014 +0100
> +++ b/drivers/xen/scsifront/scsifront.c Wed Jan 14 10:47:08 2015 +0100
> @@ -447,12 +447,10 @@ static int scsifront_dev_reset_handler(s
> uint16_t rqid;
> int err = 0;
>
> - for (;;) {
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
> - spin_lock_irq(host->host_lock);
> + spin_lock_irq(host->host_lock);
> #endif
> - if (!RING_FULL(&info->ring))
> - break;
> + while (RING_FULL(&info->ring)) {
> if (err) {
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
> spin_unlock_irq(host->host_lock);
> @@ -463,7 +461,9 @@ static int scsifront_dev_reset_handler(s
> spin_unlock_irq(host->host_lock);
> err = wait_event_interruptible(info->wq_sync,
> !info->waiting_sync);
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
Is this correct? I didn't check, but thought up to 2.6.12 the reset
handler would be called with the lock already held.
In any case: either this test must be removed again or two lines above
another test should be added for the unlock.
Juergen
> spin_lock_irq(host->host_lock);
> +#endif
> }
>
> ring_req = scsifront_pre_request(info);
>
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@lists.xen.org
> http://lists.xensource.com/xen-changelog
>
^ permalink raw reply [flat|nested] 2+ messages in thread