* Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 24 Nov, at 09:23:23AM, Ingo Molnar wrote:
> >
> > Didn't we want to do the _end alignment linker script fix instead?
>
> I think we should do both. This patch is tagged for stable because it
> fixes a bug in the existing code. It's obvious and it's explicit and
> it's much easier to know when someone might want to backport it.
>
> Changing the linker script which indirectly fixes the above bug is a
> much more subtle solution, with much larger potential for fallout
> because it affects multiple chunks of kernel code.
>
> > Alignment assumptions are easy to make when symbols are well aligned typically (as
> > in this case), so we should guarantee the alignment property instead of
> > complicating the code.
>
> I don't agree that sprinkling PFN_ALIGN() complicates the code, it's a
> minimal change with a well known kernel idiom. But yes, aligning these
> symbols in the linker script is generally a good idea.
>
> The two patches are worthwhile, for different reasons; let's do both.
I disagree, this form:
npages = (_end - _text) >> PAGE_SHIFT;
is a lot clearer to read than:
npages = (PFN_ALIGN(_end) - PFN_ALIGN(_text)) >> PAGE_SHIFT;
especially once we ensure that _end and _text are page aligned. The latter form
will only result in cargo-cult carrying over of unnecessary PFN_ALIGN()
operations.
Section boundaries of the kernel should generally be page aligned, this is useful
for a number of other reasons as well.
As far as backporting goes, it would generally be _safer_ to backport the linker
script fix, in case there are other unrealized alignment bugs in the kernel.
Especially if upstream does the same.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html