public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Schmidt <lkml@digadd.de>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Andries Brouwer <Andries.Brouwer@cwi.nl>,
	Andrew Morton <akpm@osdl.org>,
	mikem@beardog.cca.cpqcorp.net, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH] make kernel ignore bogus partitions
Date: Mon, 30 Oct 2006 22:48:07 +0100	[thread overview]
Message-ID: <45467317.10005@digadd.de> (raw)
In-Reply-To: <45465648.3060608@cfl.rr.com>

Phillip Susi wrote:
> It looks like this patch got merged in to only warn about partitions
> going beyond the end of the device.  What still concerns me is that I (
> and others ) get a lot of IO error kernel messages during boot because
> we boot from a raid0 and the first disk in the set appears to contain a
> valid partition table that lists partitions larger than the single disk
> ( since the partitions span both disks ).  This causes the kernel to
> complain when it probes the partitions as it tries to read beyond the
> end of the device.
> 
> The arguments in this thread for not discarding such partitions out of
> hand make sense to me, but I wonder: why does the kernel complain about
> IO errors to the disk when it KNOWS it is making an invalid request ( to
> sectors beyond the end of the device )?  Attempting the IO anyhow makes
> sense in a way if sometimes the kernel can detect the size wrongly, but
> if the IO fails, maybe the error message should be suppressed if it is
> beyond the detected end of device?

I wonder if this at some time can be abused by someone plugging in a
purposely mispartitioned device into a machine. The software RAID (raid
0 at least; others probably) drivers at least can be driven into null
pointer dereferences this way; see my earlier mail to the list for
details. In summary: The block layer allows a request beyond the end to
come through to the software RAID driver, which doesn't check if the
access is beyond the end of its device and tries to read some data
structures which don't span that far.

> Jan Engelhardt wrote:
>>> Perhaps the kernel should try reading beyond the ends of disks when
>>> it detects them, so that it can determine if there's actually
>>> available storage there, and automatically increase the size if there
>>> is? Or, at least, it could check whether the medium actually goes out
>>> to the point the partition table implies, and suppress the I/O error
>>> if the disk actually ends where it claims to.
>>>
>> Sounds like a good idea. In fact, I had miscreated a sun disklabel on
>> a disk because it has a slightly different notion of cylinders that I
>> am used to from x86; IOW:
>>
>> dmesg:
>> SCSI device sdb: 35378533 512-byte hdwr sectors (18114 MB)
>>
>> fdisk:
>> Disk /dev/sdb (Sun disk label): 19 heads, 248 sectors, 7200 rpm
>> 7508 cylinders, 2 alternate cylinders, 7510 physical cylinders
>> 0 extra sects/cyl, interleave 1:1
>> (should have been 7506 cyl, 2 alt, 7508 phys)
>>
>> And Solaris rightfully barfs about it when scanning disks,
>> because 7510*19*248 > 35378533. Linux keeps silent,
>> and I am not sure if I have a silent data corruption there (currently
>> not as it seems).
>> (Since it's just a test box ATM, it's not critical.)
>>
>>
>> Jan Engelhardt
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2006-10-30 21:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-03 21:00 [PATCH] make kernel ignore bogus partitions Mike Miller (OS Dev)
2006-05-08  7:27 ` Andries Brouwer
2006-05-08 15:00   ` Douglas Gilbert
2006-05-08 15:33   ` David Greaves
2006-05-08 20:20     ` Jan Engelhardt
2006-05-08 20:46       ` reiser4 bug [was Re: 2.6.17-rc3-mm1] Alexander Gran
2006-05-08 23:21         ` Joe Feise
2006-05-09  0:13           ` Alexander Gran
2006-05-09 19:41 ` [PATCH] make kernel ignore bogus partitions Andrew Morton
2006-05-09 22:48   ` Andries Brouwer
2006-05-11 11:00     ` Andrew Morton
2006-05-11 11:51       ` Andries Brouwer
2006-05-11 16:04         ` Mike Miller (OS Dev)
2006-05-11 23:08         ` Daniel Barkalow
2006-05-12 10:32           ` Jan Engelhardt
2006-10-30 19:45             ` Phillip Susi
2006-10-30 21:48               ` Christian Schmidt [this message]
2006-05-11 21:47       ` Mike Miller (OS Dev)
2006-05-11 16:17   ` Mike Miller (OS Dev)
2006-05-11 16:27     ` Andrew Morton
2006-05-11 17:09       ` Alan Cox

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=45467317.10005@digadd.de \
    --to=lkml@digadd.de \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=akpm@osdl.org \
    --cc=barkalow@iabervon.org \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mikem@beardog.cca.cpqcorp.net \
    --cc=psusi@cfl.rr.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