All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Frans Pop <elendil@planet.nl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] ide: add "ignore_hpa" module parameter
Date: Tue, 26 May 2009 14:23:39 +0200	[thread overview]
Message-ID: <200905261423.40117.bzolnier@gmail.com> (raw)
In-Reply-To: <200905260106.13705.elendil@planet.nl>

On Tuesday 26 May 2009 01:06:12 Frans Pop wrote:
> On Tuesday 26 May 2009, Alan Cox wrote:
> > > It's also not obvious (at least not to a dumb user like me) that
> > > "ignore HPA limit" is equivalent to "preserving the Host Protected
> > > Area" as the commit commit says.
> >
> > It isn't - its the exact reverse.
> 
> Right.
> 
> > Ignoring the HPA limit tells the kernel to ignore the system BIOS and
> > firmware set defaults and to stomp the whole disk regardless. On a
> > modern system thats almost always a really bad idea. Unfortunately on
> > ancient boxes with disk jumpers set to lie about the disk size (32GB
> > clipping etc) its the right thing.
> >
> > Having the same parameter in both stacks seems a good idea but really
> > we need Tejun's patch exposing the values and then to propogate the hpa
> > ignore into sysfs and trigger a revalidate of the disk if you change
> > it. Libata has all the framework for that ready just needing the final
> > bits. I don't see anything problematic in old IDE also having that
> > interface.
> 
> That also sounds as if it would better protect (or at least inform) 
> existing users who have file systems on disks where the HPA is currently 
> being ignored.
> 
> Seems to me this whole issue would also be worth an LWN (BCCed) article to 
> raise awareness, explain the issue, maybe give practical info how to test 
> whether you're affected, and maybe add some advice to distributions how 
> to handle it. Seems to me like it's something that should be mentioned in 
> distribution release notes.

Ironically, some distributions were a well aware of the problem, yet they
chose to ignore it *twice* over the last few years.

First time with the introduction of the default IDE HPA behavior of always
giving the access to the full capacity of a disk and leaving decisions about
HPA preservation/removal up to the installer & user.

Second time when said distributions switched from IDE to libata (which uses
the different default behavior as it limits the capacity to non-HPA part).

Please note that no fancy sysfs support was needed to prevent the problem:
both stacks (ide & libata) support HDIO_DRIVE_TASK ioctl which can be used
to execute commands needed to retrieve/change HPA setting.

Moreover the (much needed) work from Tejun doesn't help a tiny bit in case
of people migrating their *working* setups from IDE to libata (at least
in distro upgrade case this could have been handled by distro installer but
see above) and hitting the compatibility issue mentioned in bug #13365.

Anyway I'm putting all HPA fixes on hold as I have enough (thanks for your
feedback on patches - all points are valid and I will address them if I ever
take patches out of freezer).

Thanks.
Bart

  reply	other threads:[~2009-05-26 12:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-25 21:44 [PATCH 1/3] ide: add "ignore_hpa" module parameter Bartlomiej Zolnierkiewicz
2009-05-25 22:27 ` Frans Pop
2009-05-25 22:36   ` Alan Cox
2009-05-25 23:06     ` Frans Pop
2009-05-26 12:23       ` Bartlomiej Zolnierkiewicz [this message]
2009-05-26 12:53         ` Frans Pop
2009-05-26 13:01           ` Alan Cox
2009-05-26 18:08             ` Andries E. Brouwer
2009-05-27  9:49               ` Alan Cox
2009-05-26 17:32           ` Bartlomiej Zolnierkiewicz
2009-05-26 23:49           ` Robert Hancock
2009-05-26 12:53         ` Alan Cox
2009-05-26 17:15           ` Bartlomiej Zolnierkiewicz
2009-05-27 10:38             ` Alan Cox
2009-05-27 11:41               ` Bartlomiej Zolnierkiewicz

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=200905261423.40117.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=elendil@planet.nl \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.