[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: check_mntent_file() (was: Re: Resizing root partition)

From: Theodore Ts'o
Subject: Re: check_mntent_file() (was: Re: Resizing root partition)
Date: Sun, 10 Aug 2003 13:20:37 -0400
User-agent: Mutt/1.5.4i

On Sun, Aug 10, 2003 at 10:16:05AM +1000, Andrew Clausen wrote:
> Wrt "heuristic": why have two ways of checking?  Shouldn't the st_rdev
> comparison always be sufficient?  Or is it something special for
> loopback devices?

Exactly, it's specifically for loopback devices.  If you look at the
code, how we decide which scheme to use is by checking to see if the
pathname is block device or not.

So it is not a hueristic; it is a separate code path for a separate
case which is required for correct behaviour.

> > 1) If you're using devfs, devfs is so full of races and other bugs
> > that you're basically inviting yourself to lose.  One more way of
> > losing isn't all that interesting to me.  As of Linux 2.6, devfs is
> > deprecated, and many kernel developers have never thought it was a
> > good idea in the first place.
> This problem isn't related to any devfs-isms... just the way some
> people seem to be using it in the wild.

People do many stupid things.... including using devfs.  We can't
necessarily protect all stupid people from their own sillyness...  


> > 2) check_mntent_file is using stat to deal with aliased device nodes,
> > which is about as much as it can handle.  If the partition doesn't
> > exist, then obviously it can't be mounted; so what's the problem?
> Consider the following:
> in /proc/mounts:
> /dev/hda1
> /dev/hda3
> in /dev:
> /dev/hda /dev/hda1 /dev/hda2 /dev/something
> Suppose /dev/something is an alias to /dev/hda.
> Now, if the user invokes "parted /dev/something" in order to resize
> the first partition therein, Parted needs to decide if "/dev/something1"
> is mounted.  What if the device entry /dev/something1 doesn't exist?
> Perhaps Parted should keep a database of device major/minors.
> (Presumebly, the dev_t of /dev/something is available, and an
> appropriate dev_t for /dev/something1 could be made available) Adding
> "n" should never get false negatives, but perhaps false positives?
> Worth worrying about?

Adding 'n' will always be accurate, unless there are more partitions
than a particular device supports.  The sure-fire way if you want to
be completely accurate is to check /proc/partitions, and read out the
major/minor number from there.

> Another issue that just occured to me is: when you remove
> logical partitions, partition numbering will change.  Suppose
> /dev/hda6 is mounted, and /dev/hda5 is deleted at the request of
> the user.  Now, partitioning tools will see /dev/hda6 as /dev/hda5.
> So, when the user goes to resize /dev/hda6 (which they will now
> see as /dev/hda5), they won't get any warnings.  Unpleasant.

Remember that the kernel will only change the renumbering on reboot or
when it is explicitly told to reread the partition table.  (And in the
latter case, the attempt to reread the partition table may fail if any
partitions on the hard drive are mounted or in-use when the kernel is
requested to re-read the partition table on that disk.)

So the one thing you *do* need to make sure about is to use the
partition numbering scheme that is currently in use by the kernel.
The best way to do that is by referring to /proc/partitions and/or
using the appropriate ioctl's to read out the current starting sector
and size of a particular partition.  

If you use the partition table on the disk when you started the parted
program, you could lose if the user had previously used parted,
modified the partition table, but when the partition table was written
out, the kernel could have refused to re-read the partition table
because some partitions were in use.  In that case, whatever the
partition table was before the user ran parted the first time would
still be in effect.  

There is a real question about whether or not it's worthwhile to worry
about such cases.  If a user is stupid enough to run parted on a
currently mounted filesystem, they deserve everything they get.  We
can put in some failsafes to protect against some levels of user
idiocy, but ultimately, it is impossible to 100% foolproof any
software program, because fools are so ingenious.  

If you're really paranoid, about protecting against stupid users' own
stupidity, perhaps the right thing to do is to refuse to let parted
run at all if any partitions are in use on the hard disk at all,
unless the user uses the

Remember the grand old Unix tradition is to not bother prompting
before the user wipes out a hard drive using mkfs, and we don't
protect against someone trashing their system by running dd
if=/dev/zero of=/dev/mem, either.

                                                - Ted

reply via email to

[Prev in Thread] Current Thread [Next in Thread]