lkml.org 
[lkml]   [2009]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86/pci: make pci_mem_start to be aligned only -v3

    * Yinghai Lu <yinghai@kernel.org> wrote:

    > Ingo Molnar wrote:
    > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
    > >
    > >> On Thu, 16 Apr 2009, Jesse Barnes wrote:
    > >>> Any comments on this one, Linus? Should I include your ack?
    > >> I'm not ready to ack it, no. I don't think the suggested patch is very
    > >> clean or necessarily sensible as-is. It seems very ad-hoc.
    > >>
    > >> I was literally thinking of something like
    > >> "round up from the last RAM by X"
    > >> "round up from the last reserved region by Y"
    > >> "pick the bigger of the two"
    > >>
    > >> with helper functions for the two cases and comments along the
    > >> lines of why we do it. Something that was a bit more obvious about
    > >> what it's doing and why.
    > >
    > > That's sensible - but i'd also like to inject hpa's add-on idea: if
    > > we do that then we should do it _explicitly_ and _visibly_, by
    > > injecting an artificial e820 reservation range to all expected
    > > "vulnerable" holes we cannot fully trust.
    > >
    > > We'd do that after all the fixed resources are allocated, but before
    > > dynamic PCI allocations.
    > >
    > > That prevents the PCI layer from dynamically allocating anything
    > > into that protective zone, and documents it as well (and makes it
    > > visible in boot logs, etc.) - instead of just a silent rule
    > > somewhere that no-one will really see if it breaks.
    >
    > that need to do done much earlier, and much simple, just need to
    > make that range to be reserved in e820. and later e820_setup_gap
    > even don't need to be aligned again.

    Well, an alignment _check_ could still be added with a
    WARN_ONCE(), to make sure these assumptions hold true in
    future as well.

    This kind of stuff is generally not testable and wont break on many
    systems - but it can easily cripple a random 0.5% of systems,
    creating a lot of unhappy users.

    So pretty much the only solution is to be careful, robust and
    redundant all along.

    Ingo


    \
     
     \ /
      Last update: 2009-04-16 19:31    [W:0.026 / U:1.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site