mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, philipp.marek@bmlv.gv.at
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/partitions/msdos.c Guard against negative sizes
Date: Mon, 27 Jan 2003 17:48:12 +0100 (MET)	[thread overview]
Message-ID: <UTC200301271648.h0RGmCh27353.aeb@smtp.cwi.nl> (raw)

    u32 start = START_SECT(p)*sector_size;
    u32 size = NR_SECTS(p)*sector_size;
    And this looks as if it was calculated in bytes

But it is not. It converts hardware sector size units
to 512-byte units. For example, some MO disks use
2048-byte sectors, and also have the partition tables
in that unit.

    What about overflow?

More detailed checking of the table is certainly possible.

[But then, weird tables only occur when people fiddle with
the partition table themselves. Or when an accident happened.
I am not sure inhibiting access to partitions that look strange
is useful. It might make rescue operations difficult or impossible.]

    And btw, when can a partition that extends beyond the end
    be "allowed or even necessary"?

One reason is that "the end" is not well-defined. E.g.,
disk manufacturers invent jumpers that make the disk appear
smaller than it is in reality in order to avoid BIOS bugs.
See http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html#ss11.3

In many cases the kernel option CONFIG_IDEDISK_STROKE will tell
the kernel to automatically fix up fake lengths. If that doesn't
work, a user mode utility may be needed to give the disk full size.
Since that utility is run after the kernel does the partition detection,
it is often easiest to let the last logical partition start just before
the fake end.

Andries

             reply	other threads:[~2003-01-27 16:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-27 16:48 Andries.Brouwer [this message]
     [not found] <UTC200301271203.h0RC3Sb19647.aeb@smtp.cwi.nl>
2003-01-27 15:38 ` Ph. Marek
  -- strict thread matches above, loose matches on Subject: below --
2003-01-27 11:30 Ph. Marek
2003-01-27 14:03 ` Andries Brouwer

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=UTC200301271648.h0RGmCh27353.aeb@smtp.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=philipp.marek@bmlv.gv.at \
    /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®