From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Doug Thompson <dthompson@lnxi.com>
Subject: Re: PATCH: EDAC - clean up atomic stuff
Date: Tue, 01 Nov 2005 05:38:07 -0700 [thread overview]
Message-ID: <m1zmoo7dcg.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1130849199.9145.94.camel@localhost.localdomain> (Alan Cox's message of "Tue, 01 Nov 2005 12:46:39 +0000")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> There is a much more serious bug there as well. The code as it
>> exists is flatly impossible on x86_64 and some other architectures
>> as they do not support kmap. It is also broken on x86 as grain can
>
> All platforms have kmap. On systems without "highmem" the kmap functions
> simply return the page address of the existing permanent physical
> mapping for the page. See include/linux/highmem.h
Duh, I just looked again. I knew we had kmap, I had thought kmap_atomic
was special enough that it wasn't always there. I'm wrong.
> So it's all fine and larger than page sized scrubs can be added to the
> core code when they are needed.
The set of memory controllers where software scrubbing is interesting
and the set of memory controllers that need larger than page sized scrubs
intersect quite strongly. Although I don't think any of those
memory controllers ever migrated over from the old ecc.c code base.
We should at least have a BUG_ON((offset+size) > PAGE_SIZE) so we
don't forget to fix it.
Eric
next prev parent reply other threads:[~2005-11-01 12:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-21 13:40 Alan Cox
2005-10-28 16:33 ` Eric W. Biederman
2005-10-31 15:30 ` Alan Cox
2005-10-31 16:34 ` Eric W. Biederman
2005-10-31 20:02 ` Andrew Morton
2005-11-01 12:03 ` Eric W. Biederman
2005-11-01 12:46 ` Alan Cox
2005-11-01 12:38 ` Eric W. Biederman [this message]
2005-11-02 5:26 ` Andrew Morton
2005-11-02 16:02 ` Alan Cox
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=m1zmoo7dcg.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dthompson@lnxi.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®