linux-kernel - Re: [PATCH -mm -v4 1/3] i386/x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1191920123.9719.71.camel@caritas-dev.intel.com>
Date:	Tue, 09 Oct 2007 16:55:23 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	linux-mm@...ck.org, "H. Peter Anvin" <hpa@...or.com>,
	Andi Kleen <ak@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	akpm@...ux-foundation.org, Yinghai Lu <yhlu.kernel@...il.com>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm -v4 1/3] i386/x86_64 boot: setup data

On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
> On Tuesday 09 October 2007 18:22, Huang, Ying wrote:
> > On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
> > > On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
> > > > +unsigned long copy_from_phys(void *to, unsigned long from_phys,
> > > > +			     unsigned long n)
> 
> > > I suppose that's not unreasonable to put in mm/memory.c, although
> > > it's not really considered a problem to do this kind of stuff in
> > > a low level arch file...
> > >
> > > You have no kernel virtual mapping for the source data?
> >
> > On 32-bit platform such as i386. Some memory zones have no kernel
> > virtual mapping (highmem region etc).
> 
> I'm just wondering whether you really need to access highmem in
> boot code...

Because the zero page (boot_parameters) of i386 boot protocol has 4k
limitation, a linked list style boot parameter passing mechanism (struct
setup_data) is proposed by Peter Anvin. The linked list is provided by
bootloader, so it is possible to be in highmem region.

> 
> > So I think this may be useful as a 
> > universal way to access physical memory. But it can be more efficient to
> > implement it in arch file for some arch. Should this implementation be
> > used as a fall back implementation with attribute "weak"?
> 
> Definitely on most architectures it would just amount to
> memcpy(dst, __va(phys), n);, right? However I don't know if

Yes.

> it's worth the trouble of overriding it unless there is some
> non-__init user of it.

To support debugging and kexec, the boot parameters include the linked
list above are exported into sysfs. This function is used there too. The
patch is the No. 2 of the series.

Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/