From: Sasha Levin <levinsasha928@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-mtd@lists.infradead.org, Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
dwmw2@infradead.org
Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!
Date: Mon, 10 Sep 2012 07:17:04 +0200 [thread overview]
Message-ID: <504D77D0.70705@gmail.com> (raw)
In-Reply-To: <504CCA31.2000003@zytor.com>
On 09/09/2012 06:56 PM, H. Peter Anvin wrote:
>>
>> Anyway, that means that the BUG_ON() is likely bogus, but so is the
>> whole calling convention.
>>
>> The 4kB range starting at 0xfffffffffffff000 sounds like a *valid*
>> range, but that requires that we fix the calling convention to not
>> have that "end" (exclusive) thing. It should either be "end"
>> (inclusive), or just "len".
>>
>
> On x86, it is definitely NOT a valid range. There is no physical addresses
> there, and there will never be any.
This reminds me a similar issue: If you try to mmap /dev/kmem at an offset which
is not kernel owned (such as 0), you'll get all the way to __pa() before getting
a BUG() about addresses not making sense.
How come there's no arch-specific validation of attempts to access
virtual/physical addresses? In the kmem example I'd assume that something very
early on should be yelling at me about doing something like that, but for some
reason I get all the way to __pa() before getting a BUG() (!).
Thanks,
Sasha
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <levinsasha928@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
dwmw2@infradead.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mtd@lists.infradead.org, linux-mm <linux-mm@kvack.org>,
Dave Jones <davej@redhat.com>
Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!
Date: Mon, 10 Sep 2012 07:17:04 +0200 [thread overview]
Message-ID: <504D77D0.70705@gmail.com> (raw)
In-Reply-To: <504CCA31.2000003@zytor.com>
On 09/09/2012 06:56 PM, H. Peter Anvin wrote:
>>
>> Anyway, that means that the BUG_ON() is likely bogus, but so is the
>> whole calling convention.
>>
>> The 4kB range starting at 0xfffffffffffff000 sounds like a *valid*
>> range, but that requires that we fix the calling convention to not
>> have that "end" (exclusive) thing. It should either be "end"
>> (inclusive), or just "len".
>>
>
> On x86, it is definitely NOT a valid range. There is no physical addresses
> there, and there will never be any.
This reminds me a similar issue: If you try to mmap /dev/kmem at an offset which
is not kernel owned (such as 0), you'll get all the way to __pa() before getting
a BUG() about addresses not making sense.
How come there's no arch-specific validation of attempts to access
virtual/physical addresses? In the kmem example I'd assume that something very
early on should be yelling at me about doing something like that, but for some
reason I get all the way to __pa() before getting a BUG() (!).
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <levinsasha928@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
dwmw2@infradead.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mtd@lists.infradead.org, linux-mm <linux-mm@kvack.org>,
Dave Jones <davej@redhat.com>
Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!
Date: Mon, 10 Sep 2012 07:17:04 +0200 [thread overview]
Message-ID: <504D77D0.70705@gmail.com> (raw)
In-Reply-To: <504CCA31.2000003@zytor.com>
On 09/09/2012 06:56 PM, H. Peter Anvin wrote:
>>
>> Anyway, that means that the BUG_ON() is likely bogus, but so is the
>> whole calling convention.
>>
>> The 4kB range starting at 0xfffffffffffff000 sounds like a *valid*
>> range, but that requires that we fix the calling convention to not
>> have that "end" (exclusive) thing. It should either be "end"
>> (inclusive), or just "len".
>>
>
> On x86, it is definitely NOT a valid range. There is no physical addresses
> there, and there will never be any.
This reminds me a similar issue: If you try to mmap /dev/kmem at an offset which
is not kernel owned (such as 0), you'll get all the way to __pa() before getting
a BUG() about addresses not making sense.
How come there's no arch-specific validation of attempts to access
virtual/physical addresses? In the kmem example I'd assume that something very
early on should be yelling at me about doing something like that, but for some
reason I get all the way to __pa() before getting a BUG() (!).
Thanks,
Sasha
next prev parent reply other threads:[~2012-09-10 5:16 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 8:48 mtd: kernel BUG at arch/x86/mm/pat.c:279! Sasha Levin
2012-06-29 8:48 ` Sasha Levin
2012-07-30 11:00 ` Sasha Levin
2012-07-30 11:00 ` Sasha Levin
2012-07-30 11:00 ` Sasha Levin
2012-09-07 16:55 ` Sasha Levin
2012-09-07 16:55 ` Sasha Levin
2012-09-07 16:55 ` Sasha Levin
2012-09-07 18:14 ` Linus Torvalds
2012-09-07 18:14 ` Linus Torvalds
2012-09-07 18:14 ` Linus Torvalds
2012-09-07 22:42 ` Suresh Siddha
2012-09-07 22:42 ` Suresh Siddha
2012-09-07 22:42 ` Suresh Siddha
2012-09-07 23:09 ` Linus Torvalds
2012-09-07 23:09 ` Linus Torvalds
2012-09-07 23:09 ` Linus Torvalds
2012-09-07 23:54 ` Suresh Siddha
2012-09-07 23:54 ` Suresh Siddha
2012-09-07 23:54 ` Suresh Siddha
2012-09-08 19:57 ` Linus Torvalds
2012-09-08 19:57 ` Linus Torvalds
2012-09-09 14:56 ` Suresh Siddha
2012-09-09 14:56 ` Suresh Siddha
2012-09-09 14:56 ` Suresh Siddha
2012-09-09 15:31 ` Linus Torvalds
2012-09-09 15:31 ` Linus Torvalds
2012-09-09 15:31 ` Linus Torvalds
2012-09-09 17:01 ` H. Peter Anvin
2012-09-09 17:01 ` H. Peter Anvin
2012-09-09 17:01 ` H. Peter Anvin
2012-09-12 10:50 ` Sasha Levin
2012-09-12 10:50 ` Sasha Levin
2012-09-12 10:50 ` Sasha Levin
2012-09-12 10:56 ` Sasha Levin
2012-09-12 10:56 ` Sasha Levin
2012-09-12 10:56 ` Sasha Levin
2012-09-28 9:00 ` Sasha Levin
2012-09-28 9:00 ` Sasha Levin
2012-09-28 9:00 ` Sasha Levin
2012-09-28 16:44 ` Linus Torvalds
2012-09-28 16:44 ` Linus Torvalds
2012-09-28 16:44 ` Linus Torvalds
2012-09-28 18:05 ` Artem Bityutskiy
2012-09-28 18:05 ` Artem Bityutskiy
2012-09-28 19:13 ` Linus Torvalds
2012-09-28 19:13 ` Linus Torvalds
2012-09-28 19:13 ` Linus Torvalds
2012-09-28 19:44 ` Sasha Levin
2012-09-28 19:44 ` Sasha Levin
2012-09-28 19:44 ` Sasha Levin
2012-09-28 19:04 ` David Woodhouse
2012-09-28 19:04 ` David Woodhouse
2012-09-28 19:15 ` richard -rw- weinberger
2012-09-28 19:15 ` richard -rw- weinberger
2012-09-28 19:15 ` richard -rw- weinberger
2012-09-28 19:18 ` richard -rw- weinberger
2012-09-28 19:18 ` richard -rw- weinberger
2012-09-28 19:18 ` richard -rw- weinberger
2012-09-29 16:11 ` David Woodhouse
2012-09-29 16:11 ` David Woodhouse
2012-09-29 16:34 ` David Woodhouse
2012-09-29 16:34 ` David Woodhouse
2012-09-09 16:56 ` H. Peter Anvin
2012-09-09 16:56 ` H. Peter Anvin
2012-09-09 16:56 ` H. Peter Anvin
2012-09-09 19:04 ` David Woodhouse
2012-09-09 19:04 ` David Woodhouse
2012-09-09 20:33 ` H. Peter Anvin
2012-09-09 20:33 ` H. Peter Anvin
2012-09-09 20:33 ` H. Peter Anvin
2012-09-10 5:17 ` Sasha Levin [this message]
2012-09-10 5:17 ` Sasha Levin
2012-09-10 5:17 ` Sasha Levin
2012-09-08 8:10 ` Sasha Levin
2012-09-08 8:10 ` Sasha Levin
2012-09-08 8:10 ` Sasha Levin
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=504D77D0.70705@gmail.com \
--to=levinsasha928@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.