Re: [PATCH 0/3] /proc/kmem cleanups and hwpoison bits

[Hugh Dickins]

On Wed, 16 Sep 2009, Geert Uytterhoeven wrote:
> On Tue, Sep 15, 2009 at 12:16, Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx> wrote:
> > Warning: it may be rubbish, it may just be a hack which appeared to
> > work for me the last time I tried, on a particular address range of a
> > particular set of configurations of a particular set of architectures
> > (x86_32, x86_64, powerpc64). ÂI've never thought it through enough to
> > consider submitting, but it _might_ contain something useful for you
> > to factor into your own efforts.
> >
> > Sorry for chucking it over the wall to you in this way, but I guess
> > that's better than just sitting quietly on it for a few more years.
> >
> > Certainly-Not-Signed-off-by: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>

I think that gives a good idea of the status of this patch:
I'm not making any policy decisions here or submitting to any tree.

> > --- 2.6.31/drivers/char/mem.c  2009-09-09 23:13:59.000000000 +0100
> > +++ 2.6.31d/drivers/char/mem.c Â2009-09-10 09:38:30.000000000 +0100
> 
> > -#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
> > - Â Â Â Â Â Â Â /* we don't have page 0 mapped on sparc and m68k.. */
> 
> Is this `feature' removed?

The feature that some arches don't have page zero mapped?
No, I could hardly change that from drivers/char/mem.c,
and wouldn't wish to.

The feature that reading from one unmapped page gave zeroes
and writing to it threw away what you wrote?  Yes, in making
that patch, I was thinking that if we cope with unmapped areas
elsewhere by returning -ENXIO, it made little sense to have
special code to do something different for page zero.

But of course there might be userspace compatibility reasons
why that couldn't change e.g. a body of /dev/kmem users who
would be surprised by an error right at the "start" (though
in kmem's case, they've already had to seek to get anywhere).

Take the patch as saying "hmm, I wonder if we could do it this way".

Hugh