All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Parag Warudkar <parag.lkml@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"James.Bottomley@hansenpartnership.com" 
	<James.Bottomley@hansenpartnership.com>,
	<akpm@linux-foundation.org>, <torvalds@linux-foundation.org>,
	Linux SCSI List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS]
Date: Wed, 25 May 2011 09:37:44 +0200	[thread overview]
Message-ID: <4DDCB1C8.7040708@fusionio.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1105242127340.3472@ubuntu-natty>

On 2011-05-25 03:41, Parag Warudkar wrote:
> 
> 
> On Tue, 24 May 2011, Jens Axboe wrote:
> 
>> On 2011-05-24 06:29, Parag Warudkar wrote:
>>>
>>> External DVD drive - connected when suspended, removed before resume.
>>> Results in NULL pointer dereference in __blk_add_request on resume.
>>>
>>> *ffffffff811d6503:      48 89 58 08             mov    %rbx,0x8(%rax) |
>>> %ebx = ffff880131559020 <--- faulting instruction
>>>
>>> 48 89 58 08 appears only in list_add :
>>>
>>> static inline void list_add(struct list_head *new, struct list_head *head)
>>> {
>>>         __list_add(new, head, head->next);
>>> ffffffff81ac012c:       49 8b 04 24             mov    (%r12),%rax
>>> #ifndef CONFIG_DEBUG_LIST
>>> static inline void __list_add(struct list_head *new,
>>>                               struct list_head *prev,
>>>                               struct list_head *next)
>>> {
>>>         next->prev = new;
>>> ffffffff81ac0130:       48 89 58 08             mov    %rbx,0x8(%rax)
>>>
>>> AFAICS list_add is only called from one place in __elv_add_request :
>>>
>>>        switch (where) {
>>>         case ELEVATOR_INSERT_REQUEUE:
>>>         case ELEVATOR_INSERT_FRONT:
>>>                 rq->cmd_flags |= REQ_SOFTBARRIER;
>>>               **  list_add(&rq->queuelist, &q->queue_head);
>>>                 break;
>>>
>>> Now, where is the patch? :)
>>
>> You forgot to attach it?
>>
>> This is clearly q == NULL [snip]
> 
> OK, I think this patch should do the trick.
> 
> Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
> Reported-and-tested-by: Parag Warudkar <parag.lkml@gmail.com>
>  
> Check for device deletion before sending it a scsi command. This fixes an 
> OOPS I was seeing during resume when the external dvd drive was removed 
> while suspended.
> 
> diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c
> index d9564fb..cc4edbf 100644
> --- a/drivers/scsi/scsi_ioctl.c
> +++ b/drivers/scsi/scsi_ioctl.c
> @@ -136,7 +136,7 @@ int scsi_set_medium_removal(struct scsi_device *sdev, char state)
>  	char scsi_cmd[MAX_COMMAND_SIZE];
>  	int ret;
>  
> -	if (!sdev->removable || !sdev->lockable)
> +	if (!sdev->removable || !sdev->lockable || sdev->sdev_state == SDEV_DEL)
>  	       return 0;
>  
>  	scsi_cmd[0] = ALLOW_MEDIUM_REMOVAL;

While this will fix your particular oops, I don't think it's quite
right. It's fixing one particular piece of fall out from attempting to
talk to a removed device, it's not necessarily fixing the full class of
them. The other checks in scsi_set_medium_removal() aren't related to a
changing state of the device, they are capability checks.

-- 
Jens Axboe


WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jaxboe@fusionio.com>
To: Parag Warudkar <parag.lkml@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"James.Bottomley@hansenpartnership.com"
	<James.Bottomley@hansenpartnership.com>,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	Linux SCSI List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS]
Date: Wed, 25 May 2011 09:37:44 +0200	[thread overview]
Message-ID: <4DDCB1C8.7040708@fusionio.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1105242127340.3472@ubuntu-natty>

On 2011-05-25 03:41, Parag Warudkar wrote:
> 
> 
> On Tue, 24 May 2011, Jens Axboe wrote:
> 
>> On 2011-05-24 06:29, Parag Warudkar wrote:
>>>
>>> External DVD drive - connected when suspended, removed before resume.
>>> Results in NULL pointer dereference in __blk_add_request on resume.
>>>
>>> *ffffffff811d6503:      48 89 58 08             mov    %rbx,0x8(%rax) |
>>> %ebx = ffff880131559020 <--- faulting instruction
>>>
>>> 48 89 58 08 appears only in list_add :
>>>
>>> static inline void list_add(struct list_head *new, struct list_head *head)
>>> {
>>>         __list_add(new, head, head->next);
>>> ffffffff81ac012c:       49 8b 04 24             mov    (%r12),%rax
>>> #ifndef CONFIG_DEBUG_LIST
>>> static inline void __list_add(struct list_head *new,
>>>                               struct list_head *prev,
>>>                               struct list_head *next)
>>> {
>>>         next->prev = new;
>>> ffffffff81ac0130:       48 89 58 08             mov    %rbx,0x8(%rax)
>>>
>>> AFAICS list_add is only called from one place in __elv_add_request :
>>>
>>>        switch (where) {
>>>         case ELEVATOR_INSERT_REQUEUE:
>>>         case ELEVATOR_INSERT_FRONT:
>>>                 rq->cmd_flags |= REQ_SOFTBARRIER;
>>>               **  list_add(&rq->queuelist, &q->queue_head);
>>>                 break;
>>>
>>> Now, where is the patch? :)
>>
>> You forgot to attach it?
>>
>> This is clearly q == NULL [snip]
> 
> OK, I think this patch should do the trick.
> 
> Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
> Reported-and-tested-by: Parag Warudkar <parag.lkml@gmail.com>
>  
> Check for device deletion before sending it a scsi command. This fixes an 
> OOPS I was seeing during resume when the external dvd drive was removed 
> while suspended.
> 
> diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c
> index d9564fb..cc4edbf 100644
> --- a/drivers/scsi/scsi_ioctl.c
> +++ b/drivers/scsi/scsi_ioctl.c
> @@ -136,7 +136,7 @@ int scsi_set_medium_removal(struct scsi_device *sdev, char state)
>  	char scsi_cmd[MAX_COMMAND_SIZE];
>  	int ret;
>  
> -	if (!sdev->removable || !sdev->lockable)
> +	if (!sdev->removable || !sdev->lockable || sdev->sdev_state == SDEV_DEL)
>  	       return 0;
>  
>  	scsi_cmd[0] = ALLOW_MEDIUM_REMOVAL;

While this will fix your particular oops, I don't think it's quite
right. It's fixing one particular piece of fall out from attempting to
talk to a removed device, it's not necessarily fixing the full class of
them. The other checks in scsi_set_medium_removal() aren't related to a
changing state of the device, they are capability checks.

-- 
Jens Axboe

  reply	other threads:[~2011-05-25  7:37 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24  4:29 __elv_add_request OOPS Parag Warudkar
2011-05-24 10:44 ` Jens Axboe
2011-05-24 10:44   ` Jens Axboe
2011-05-25  1:41   ` [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS] Parag Warudkar
2011-05-25  1:41     ` Parag Warudkar
2011-05-25  7:37     ` Jens Axboe [this message]
2011-05-25  7:37       ` Jens Axboe
2011-05-25 18:44       ` Parag Warudkar
2011-05-25 18:44         ` Parag Warudkar
2011-05-25 18:55         ` Linus Torvalds
2011-05-25 18:55           ` Linus Torvalds
2011-05-25 19:02           ` Jens Axboe
2011-05-25 19:02             ` Jens Axboe
2011-05-25 19:13             ` Linus Torvalds
2011-05-25 19:13               ` Linus Torvalds
2011-05-25 19:17               ` Jens Axboe
2011-05-25 19:17                 ` Jens Axboe
2011-05-25 19:52                 ` Parag Warudkar
2011-05-25 19:52                   ` Parag Warudkar
2011-05-25 20:03                   ` Linus Torvalds
2011-05-25 20:03                     ` Linus Torvalds
2011-05-25 20:18                     ` Parag Warudkar
2011-05-25 20:18                       ` Parag Warudkar
2011-05-25 20:26                       ` Linus Torvalds
2011-05-25 20:26                         ` Linus Torvalds
2011-05-25 20:42                         ` Parag Warudkar
2011-05-25 20:42                           ` Parag Warudkar
2011-05-25 20:52                           ` James Bottomley
2011-05-25 23:00                             ` Parag Warudkar
2011-05-25 23:14                               ` Linus Torvalds
2011-05-25 23:45                                 ` Parag Warudkar
2011-05-25 23:52                                   ` Linus Torvalds
     [not found]                               ` <1306370123.1641.76.camel@mulgrave.site>
2011-05-26  1:01                                 ` Linus Torvalds
2011-05-26  1:06                                   ` James Bottomley
2011-05-26  1:43                                 ` Parag Warudkar
2011-05-27  3:53                             ` James Bottomley
2011-05-27  5:43                               ` Jens Axboe
2011-05-27 20:21                                 ` James Bottomley
2011-05-27 20:21                                   ` James Bottomley
2011-05-28 12:42                                   ` Jens Axboe
2011-05-28 12:42                                     ` Jens Axboe
2011-06-08  6:50                                   ` Torsten Hilbrich
2011-06-08  6:50                                     ` Torsten Hilbrich
2011-05-25 20:20                     ` James Bottomley
2011-05-25 20:22                       ` Parag Warudkar
2011-05-25 20:29                         ` James Bottomley
2011-05-25 20:26   ` __elv_add_request OOPS 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=4DDCB1C8.7040708@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=parag.lkml@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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.