From: Patrick Mansfield <patmans@us.ibm.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: 76306.1226@compuserve.com, linux-kernel@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net,
linux-scsi@vger.kernel.org
Subject: Re: [2.6.13-rc6-latest] SCSI disk registration msgs repeat themselves
Date: Wed, 17 Aug 2005 14:01:43 -0700 [thread overview]
Message-ID: <20050817210143.GA11364@us.ibm.com> (raw)
In-Reply-To: <20050816225113.1c3677c2.zaitcev@redhat.com>
On Tue, Aug 16, 2005 at 10:51:13PM -0700, Pete Zaitcev wrote:
> On Tue, 16 Aug 2005 21:39:33 -0700, Patrick Mansfield <patmans@us.ibm.com> wrote:
> > On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote:
>
> > > I just added some usb-storage devices to my system and got the below.
>
> > > Why do the first four lines repeat for each device? (Not sure if
> > > this is a SCSI or USB problem.)
> >
> > It is in the partition code. I posted twice before about this with no
> > response.
>
> It's not an important problem, presumably. I observe dual revalidations
> as well, but they are not that bothersome. Add to it that your patch
Yes.
Does this *only* happens for sd (scsi) devices?
> appears wrong (see below). If you offered an acceptable solution, I would
> expect a warmer welcome... But even then getting a reply from linux-scsi
> folks is like pulling a tooth (if my own little CD-ROM sizing patch is
> any indication). So, steel yourself for challenges of this life, Patrick!
;-)
> Here's what it was in 2.6.9, as documented in drivers/block/ub.c:
>
> + /*
> + * This is a workaround for a specific problem in our block layer.
> + * In 2.6.9, register_disk duplicates the code from rescan_partitions.
> + * However, if we do add_disk with a device which persistently reports
> + * a changed media, add_disk calls register_disk, which does do_open,
> + * which will call rescan_paritions for changed media. After that,
> + * register_disk attempts to do it all again and causes double kobject
> + * registration and a eventually an oops on module removal.
> + *
> + * The bottom line is, Al Viro says that we should not allow
> + * bdev->bd_invalidated to be set when doing add_disk no matter what.
> + */
> + if (sc->first_open) {
> + if (sc->changed) {
> + sc->first_open = 0;
> + rc = -ENOMEDIUM;
> + goto err_open;
> + }
> + }
>
> Users were hitting it with oopses like these:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0011.html
>
> The ub alone was not suffient to motivate Al for the fix, so I added
> this silly "first_open" thingie, which papered over it. It was thought
> that sd was miraclously immune.
>
> However, over time users hit it with usb-storage and sd, like this:
> http://lkml.org/lkml/2004/2/21/19
> This prompted Al's action. He simply dropped all the extra code like
> this:
>
> --- linux-2.6.9-11.5.EL/fs/partitions/check.c 2004-10-18 14:55:07.000000000 -0700
> +++ linux-2.6.12/fs/partitions/check.c 2005-06-17 12:48:29.000000000 -0700
> @@ -358,24 +357,9 @@ void register_disk(struct gendisk *disk)
> if (!bdev)
> return;
>
> + bdev->bd_invalidated = 1;
> if (blkdev_get(bdev, FMODE_READ, 0) < 0)
> return;
> - state = check_partition(disk, bdev);
> - if (state) {
> - for (j = 1; j < state->limit; j++) {
> - sector_t size = state->parts[j].size;
> - sector_t from = state->parts[j].from;
> - if (!size)
> - continue;
> - add_partition(disk, j, from, size);
> -#ifdef CONFIG_BLK_DEV_MD
> - if (!state->parts[j].flags)
> - continue;
> - md_autodetect_dev(bdev->bd_dev+j);
> -#endif
> - }
> - kfree(state);
> - }
> blkdev_put(bdev);
> }
OK, thanks for posting those links and information.
> > --- linux-2.6.11-rc1/fs/partitions/check.c Fri Dec 24 13:35:28 2004
> > +++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21 11:19:00 2005
> > @@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
> > bdev->bd_invalidated = 0;
> > for (p = 1; p < disk->minors; p++)
> > delete_partition(disk, p);
> > - if (disk->fops->revalidate_disk)
> > - disk->fops->revalidate_disk(disk);
>
> As for your proposed fix, it may be problematic. The ->revalidate
> method has to be called at least once for a new device, because
> that's when drivers fetch the capacities. But ->open only calls
> check_disk_change() for removable devices. Who is going to call
> ->revalidate inside add_disk() for non-removable devices?
sd.c always calls its revalidate_disk method (sd_revalidate_disk) when the
device is attached, so for scsi, we definitely do not miss anything.
I thought revalidate_disk was not called prior to Al's patch, so why do we
need to call it on the first open now?
You already have to call set_capacity() before add_disk(), else
register_disk thinks there is no media present, and won't set
bd_invalidated. So drivers must already get the capacity (or fake it)
prior to calling add_disk.
-- Patrick Mansfield
prev parent reply other threads:[~2005-08-17 21:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 3:01 [2.6.13-rc6-latest] SCSI disk registration msgs repeat themselves Chuck Ebbert
2005-08-17 4:39 ` Patrick Mansfield
2005-08-17 5:51 ` Pete Zaitcev
2005-08-17 21:01 ` Patrick Mansfield [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=20050817210143.GA11364@us.ibm.com \
--to=patmans@us.ibm.com \
--cc=76306.1226@compuserve.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=zaitcev@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox