mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Peter Osterlund <petero2@telia.com>,
	Matthew Wilcox <matthew@wil.cx>, Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
Date: Sun, 6 Jan 2008 10:14:19 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.1.00.0801060954010.2811@woody.linux-foundation.org> (raw)
In-Reply-To: <1199630574.5205.14.camel@localhost.localdomain>



On Sun, 6 Jan 2008, James Bottomley wrote:
> > index 993f78c..6a20da9 100644
> > --- a/fs/block_dev.c
> > +++ b/fs/block_dev.c
> > @@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct file *file, int for_part)
> >  			}
> >  			if (bdev->bd_invalidated)
> >  				rescan_partitions(bdev->bd_disk, bdev);
> > +			bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
> >  		}
> >  	}
> >  	bdev->bd_openers++;
> 
> Actually, I think that code is fine ... the block size shouldn't change
> across positive values of bd_openers.

The block size should indeed not change, and that's why we must *not* do 
bd_set_size() there (because that changes the block size too, not just the 
size of the device).

But I would argue that if we have had a device invalidation event (ie 
media change), then we should indeed change the actual *size* of the block 
device as seen by anybody who opens the file again.

And yes, it will affect old openers of the same inode too (since the size 
is in the inode, not the file descriptor), but considering that this 
really should only happen for media change events, I think that's better 
than what we used to have.

Now, we could have made it even more clear by moving the "i_size" setting 
into the same "if (dbev->bd_invalidated)" conditional, but the thing is, 
we only set bd_invalidated for devices that have minors, so things like 
floppies etc that don't have partition support also don't have 
bd_invalidated set (in effect, bd_invalidated really *is* just a flag for 
the partitioning code, not for disk change in general).

That said:

> pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...

I'm not sure if it should be mucking with the size or not, but it 
definitely shouldn't be mucking with the block-size, because that can 
indeed cause huge problems. 

So removing the  bd_set_size() is almost certainly the right thing to do 
(because it's always incorrect to do at an "inner" open), and the real 
size should have already been set by the regular open.

But this should be tested by somebody who uses the dang thing. My personal 
favourite for a real fix would actually be to always make the capacity of 
the pktcdvd device match the capacity of the underlying device, ie the 
diff would look something like the appended (untested as usual), but that 
may be a bit too extensive a change.

But regardless, I think the i_size change makes sense - at least in some 
form. It doesn't necessarily have to be the explicit i_size setting: I 
also considered just changing the block_dev.c do_open() make bd_set_size() 
_unconditionally_, and then move the "if (!bdev->bd_openers)" test into 
bd_set_size(), so that people couldn't even change the blocksize by 
mistake!

I'd still like to hear comments from Al in particular, if he has something 
to say. 

			Linus
---
 drivers/block/pktcdvd.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 3535ef8..1b23681 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2342,9 +2342,7 @@ static int pkt_open_dev(struct pktcdvd_device *pd, int write)
 		goto out_unclaim;
 	}
 
-	set_capacity(pd->disk, lba << 2);
-	set_capacity(pd->bdev->bd_disk, lba << 2);
-	bd_set_size(pd->bdev, (loff_t)lba << 11);
+	set_capacity(pd->disk, get_capacity(pd->bdev->bd_disk));
 
 	q = bdev_get_queue(pd->bdev);
 	if (write) {

  parent reply	other threads:[~2008-01-06 18:23 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-02 16:25 Ingo Molnar
2008-01-02 16:46 ` James Bottomley
2008-01-02 19:19   ` Linus Torvalds
2008-01-02 19:40     ` Matthew Wilcox
2008-01-02 19:57       ` Linus Torvalds
2008-01-02 20:17         ` Christoph Hellwig
2008-01-02 20:49           ` Linus Torvalds
2008-01-02 20:53             ` Matthew Wilcox
2008-01-02 20:18         ` Matthew Wilcox
2008-01-02 20:12       ` James Bottomley
2008-01-02 20:45         ` Linus Torvalds
2008-01-02 23:33           ` James Bottomley
2008-01-03  1:58             ` Linus Torvalds
2008-01-06  2:55               ` Peter Osterlund
2008-01-06  3:43                 ` Linus Torvalds
2008-01-06 10:17                   ` Peter Osterlund
2008-01-06 14:04                   ` James Bottomley
2008-01-06 14:42                   ` James Bottomley
2008-01-06 15:01                     ` Peter Osterlund
2008-01-06 18:14                     ` Linus Torvalds [this message]
2008-01-06 18:44                       ` Linus Torvalds
2008-01-06 18:54                         ` James Bottomley
2008-01-06 16:19                   ` Boaz Harrosh
2008-01-06 16:47                     ` James Bottomley
2008-01-06 13:57                 ` James Bottomley
2008-01-06 14:47                   ` Ingo Molnar
2008-01-06 15:20                     ` James Bottomley
2008-01-06 15:45                       ` Adrian Bunk
2008-01-06 16:00                         ` James Bottomley
2008-01-06 16:12                       ` Ingo Molnar
2008-01-06 17:10                         ` James Bottomley
2008-01-08 16:55                           ` Ingo Molnar
2008-01-06 17:11                       ` Matthew Wilcox
2008-01-06 17:36                         ` James Bottomley
2008-01-06 18:34                           ` Willy Tarreau
2008-01-06 18:56                             ` Adrian Bunk
2008-01-06 19:10                               ` Willy Tarreau
2008-01-06 19:58                                 ` Adrian Bunk
2008-01-06 21:08                                   ` Willy Tarreau
2008-01-06 22:25                                     ` Adrian Bunk
2008-01-07 20:50                                     ` Valdis.Kletnieks
2008-01-07 21:31                                       ` Alan Cox
2008-01-07 21:37                                       ` Matthew Wilcox
2008-01-07 23:04                                         ` Valdis.Kletnieks
2008-01-07 23:19                                           ` Matthew Wilcox
2008-01-08 16:47                                             ` Stefan Richter
2008-01-08 17:11                                               ` Linus Torvalds
2008-01-08 20:01                                                 ` Ingo Molnar
2008-01-09  4:01                                             ` Valdis.Kletnieks
2008-01-09  4:10                                               ` Andrew Morton
2008-01-09  6:03                                                 ` Willy Tarreau
2008-01-09  4:03                                             ` Valdis.Kletnieks
2008-01-07 15:25                                 ` John Stoffel
2008-01-07 19:04                                   ` Stefan Richter
2008-01-07 19:59                                     ` John Stoffel
2008-01-06 17:29                     ` Stefan Richter
2008-01-06 20:26                       ` Ingo Molnar
2008-01-06 13:55 Thomas Meyer
2008-01-06 16:56 ` Matthew Wilcox

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=alpine.LFD.1.00.0801060954010.2811@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=petero2@telia.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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

all inboxes | Powered by JetHome®