public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: emist <emistz@gmail.com>
To: Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	Linux <linux-kernel@vger.kernel.org>,
	cornelia.huck@de.ibm.com
Subject: Re: [PATCH] Bug fix for the s390 dcssblk driver
Date: Tue, 23 Oct 2007 18:03:49 -0400	[thread overview]
Message-ID: <471E6FC5.6070301@gmail.com> (raw)
In-Reply-To: <1193145774.5325.27.camel@localhost.localdomain>

Gerald Schaefer wrote:
> On Mon, 2007-10-22 at 13:37 +0200, Cornelia Huck wrote:
>> On Sun, 21 Oct 2007 23:46:49 -0400,
>> emist <emistz@gmail.com> wrote:
>>
>>> # This patch fixes a memory corruption bug in the s390 dcssblk driver.
>>> # The bug occurs when an attempt to change the type of a segment
>>> # returns an error. At this point the driver tries to remove the segment in
>>> # question while some of the device's attributes are in use. This causes the
>>> # driver to hang.
>> Hm, seems we missed another of those device attributes exhibiting
>> suicidal tendencies...
>>
>> Tejun has a patchset allowing device attributes to commit suicide (see
>> http://marc.info/?l=linux-kernel&m=119027371416452&w=2), although I'm
>> not sure what its current status is. Until then, you would need to use
>> device_schedule_callback() to commit suicide.
>>
>> This all of course only applies if killing the segment is better than
>> leaving it in its current state, but others can make a better judgement
>> on that :)
> 
> Hi,
> 
> thanks for reporting this bug, seems like we forgot to consider the
> suicidal behavior of this driver when the device_unregister() stuff was
> changed.
> 
> The best solution for now would be to use the scheduled callback
> function, like Cornelia described. If segment_modify_shared() should
> fail, the DCSS segment will be unloaded. Calling the function again
> with the old "shared" flag will not help because it will not reload
> the segment. So we need to remove/unregister the device in this error
> path, and for now this should be done with device_schedule_callback().
> 
> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
> ---
> 
>  dcssblk.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.23/drivers/s390/block/dcssblk.c
> ===================================================================
> --- linux-2.6.23.orig/drivers/s390/block/dcssblk.c
> +++ linux-2.6.23/drivers/s390/block/dcssblk.c
> @@ -193,6 +193,12 @@ dcssblk_segment_warn(int rc, char* seg_n
>         }
>  }
> 
> +static void dcssblk_unregister_callback(struct device *dev)
> +{
> +       device_unregister(dev);
> +       put_device(dev);
> +}
> +
>  /*
>   * device attribute for switching shared/nonshared (exclusive)
>   * operation (show + store)
> @@ -276,8 +282,7 @@ removeseg:
>         blk_cleanup_queue(dev_info->dcssblk_queue);
>         dev_info->gd->queue = NULL;
>         put_disk(dev_info->gd);
> -       device_unregister(dev);
> -       put_device(dev);
> +       rc = device_schedule_callback(dev, dcssblk_unregister_callback);
>  out:
>         up_write(&dcssblk_devices_sem);
>         return rc;
> 
> 
Hey,

That makes sense. I no longer have access to an s390 system so I will
not be able to provide a tested patch for this bug. I will however
attempt to fix this issue and submit a patch using the scheduled
callback function and maybe someone could make sure that it works properly.

Have a good one,

Igor H.

  reply	other threads:[~2007-10-23 22:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200710201451.57138.elendil@planet.nl>
2007-10-20 17:24 ` [PATCH] Bug fix for the s390 dcssblk driver emist
2007-10-21 10:09   ` Heiko Carstens
2007-10-22  3:46     ` emist
2007-10-22 11:37       ` Cornelia Huck
2007-10-23 13:22         ` Gerald Schaefer
2007-10-23 22:03           ` emist [this message]
2007-10-20  5:07 emist

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=471E6FC5.6070301@gmail.com \
    --to=emistz@gmail.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox