On Sat, 2012-09-29 at 17:11 +0100, David Woodhouse wrote:
>
> That check seems to have been missing from David's commit 402d3265 in
> which he introduced the mtd_mmap() operation, and wasn't fixed in commit
> dd02b67d5 where Anatolij fixed things to actually *work* in the MMU code
> path. This sho
On Fri, 2012-09-28 at 20:04 +0100, David Woodhouse wrote:
> > I was really hoping it would go through the regular channels and come
> > back to me that way, since I can't really test it, and it's bigger
> > than the trivial obvious one-liners that I'm happy to commit.
>
> I can't test it on real h
On 09/28/2012 09:13 PM, Linus Torvalds wrote:
> On Fri, Sep 28, 2012 at 11:05 AM, Artem Bityutskiy
> wrote:
>>
>> I am not the maintainer, but please, go ahead an push your fix. I do not
>> have time to test it myself and it does not look like anyone else in the
>> small mtd community does.
>
>
On Fri, 2012-09-28 at 09:44 -0700, Linus Torvalds wrote:
> On Fri, Sep 28, 2012 at 2:00 AM, Sasha Levin wrote:
> >
> > Is anyone planning on picking up Linus' patch? This is still not in -next
> > even.
>
> I was really hoping it would go through the regular channels and come
> back to me that w
On Fri, Sep 28, 2012 at 9:15 PM, richard -rw- weinberger
wrote:
> On Fri, Sep 28, 2012 at 9:04 PM, David Woodhouse wrote:
>> On Fri, 2012-09-28 at 09:44 -0700, Linus Torvalds wrote:
>>> On Fri, Sep 28, 2012 at 2:00 AM, Sasha Levin
>>> wrote:
>>> >
>>> > Is anyone planning on picking up Linus' p
On Fri, Sep 28, 2012 at 9:04 PM, David Woodhouse wrote:
> On Fri, 2012-09-28 at 09:44 -0700, Linus Torvalds wrote:
>> On Fri, Sep 28, 2012 at 2:00 AM, Sasha Levin wrote:
>> >
>> > Is anyone planning on picking up Linus' patch? This is still not in -next
>> > even.
>>
>> I was really hoping it wo
On Fri, Sep 28, 2012 at 11:05 AM, Artem Bityutskiy wrote:
>
> I am not the maintainer, but please, go ahead an push your fix. I do not
> have time to test it myself and it does not look like anyone else in the
> small mtd community does.
Grr. I told people that patch wasn't tested. I hadn't even
On Fri, 2012-09-28 at 09:44 -0700, Linus Torvalds wrote:
> On Fri, Sep 28, 2012 at 2:00 AM, Sasha Levin wrote:
> >
> > Is anyone planning on picking up Linus' patch? This is still not in -next
> > even.
>
> I was really hoping it would go through the regular channels and come
> back to me that w
On Fri, Sep 28, 2012 at 2:00 AM, Sasha Levin wrote:
>
> Is anyone planning on picking up Linus' patch? This is still not in -next
> even.
I was really hoping it would go through the regular channels and come
back to me that way, since I can't really test it, and it's bigger
than the trivial obvi
On 09/12/2012 12:56 PM, Sasha Levin wrote:
> On 09/12/2012 12:50 PM, Sasha Levin wrote:
>> On 09/09/2012 04:56 PM, Suresh Siddha wrote:
>>> On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote:
> Whatever. Something like this (TOTALLY UNTESTED) attached patch should
> get the mtdchar ove
On 09/12/2012 12:50 PM, Sasha Levin wrote:
> On 09/09/2012 04:56 PM, Suresh Siddha wrote:
>> On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote:
Whatever. Something like this (TOTALLY UNTESTED) attached patch should
get the mtdchar overflows to go away,
>> It looks good to me. Acked
On 09/09/2012 04:56 PM, Suresh Siddha wrote:
> On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote:
>> > Whatever. Something like this (TOTALLY UNTESTED) attached patch should
>> > get the mtdchar overflows to go away,
> It looks good to me. Acked-by: Suresh Siddha
>
> Sasha, can you please
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 0xf000 sounds like a *valid*
>> range, but that requires that we fix the calling convention to not
>> have
On 09/09/2012 12:04 PM, David Woodhouse wrote:
On Sun, 2012-09-09 at 09:56 -0700, H. Peter Anvin wrote:
So it should either be start=0xf000 end=0x
or it should be start=0xf000 len=0x1000.
I would strongly object to the former; that kind of inclusive ra
On Sun, 2012-09-09 at 09:56 -0700, H. Peter Anvin wrote:
>
> > So it should either be start=0xf000 end=0x
> > or it should be start=0xf000 len=0x1000.
>
> I would strongly object to the former; that kind of inclusive ranges
> breed a whole class of bugs by
On 09/09/2012 08:31 AM, Linus Torvalds wrote:
On Sun, Sep 9, 2012 at 7:56 AM, Suresh Siddha wrote:
yes but that is not a valid range I think because of the supported
physical address bit limits of the processor and also the max
architecture limit of 52 address bits.
But how could the caller
On 09/08/2012 12:57 PM, Linus Torvalds wrote:
Ack.
Anyway, that means that the BUG_ON() is likely bogus, but so is the
whole calling convention.
The 4kB range starting at 0xf000 sounds like a *valid*
range, but that requires that we fix the calling convention to not
have that "end"
On Sun, Sep 9, 2012 at 7:56 AM, Suresh Siddha wrote:
>
> yes but that is not a valid range I think because of the supported
> physical address bit limits of the processor and also the max
> architecture limit of 52 address bits.
But how could the caller possibly know that? None of those internal
On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote:
> Whatever. Something like this (TOTALLY UNTESTED) attached patch should
> get the mtdchar overflows to go away,
It looks good to me. Acked-by: Suresh Siddha
Sasha, can you please give this a try?
> but it does *not* fix the fact
> that
On Fri, Sep 7, 2012 at 4:54 PM, Suresh Siddha wrote:
>
> Essentially the user is trying to mmap at a very large offset (from the
> oops it appears "vma->vm_pgoff << PAGE_SHIFT + start" ends up to
> "0xf000").
Ok, Sasha confirmed that.
> So it appears that the condition "(vma->vm_end
On 09/08/2012 01:09 AM, Linus Torvalds wrote:
> Sasha, since you can apparently reproduce it, can you replace the
> "BUG_ON()" with just a
>
> if (start >= end) {
> printf("bogus range %llx - %llx\n", start, end);
> return -EINVAL;
> }
Replacing it gives me the following:
[ 36.23173
On Fri, 2012-09-07 at 16:09 -0700, Linus Torvalds wrote:
> The "u32 len" -> "unsigned long len" thing *might* make a difference, though.
This I believe doesn't fix the reported BUG. I was trying to address
your previous comment about broken types.
>
> I also think your patch is incomplete even o
On Fri, Sep 7, 2012 at 3:42 PM, Suresh Siddha wrote:
> - unsigned long start;
> - unsigned long off;
> - u32 len;
> + resource_size_t start, off;
> + unsigned long len;
So since the oops is on x86-64, I don't think it's the "unsigned long"
-> "resource_size_t" part (
On Fri, 2012-09-07 at 11:14 -0700, Linus Torvalds wrote:
> Guys, this looks like a MTD and/or io_remap_pfn_range() bug, and it's
> not getting any traction.
>
> What the f*ck is mtd_mmap() doing, and why? The problem seems to be an
> overflow condition, because reserve_pfn_range() does
>
> re
Guys, this looks like a MTD and/or io_remap_pfn_range() bug, and it's
not getting any traction.
What the f*ck is mtd_mmap() doing, and why? The problem seems to be an
overflow condition, because reserve_pfn_range() does
reserve_memtype(paddr, paddr + size, want_flags, &flags);
and then the B
Ping? Still seeing this with latest master...
On Fri, Jun 29, 2012 at 10:48 AM, Sasha Levin wrote:
> Hi all,
>
> I've stumbled on the following while fuzzing with trinity in a KVM tools
> guest using latest linux-next:
>
> [ 3299.675163] [ cut here ]
> [ 3299.676027] kern
Ping?
On Fri, Jun 29, 2012 at 10:48 AM, Sasha Levin wrote:
> Hi all,
>
> I've stumbled on the following while fuzzing with trinity in a KVM tools
> guest using latest linux-next:
>
> [ 3299.675163] [ cut here ]
> [ 3299.676027] kernel BUG at arch/x86/mm/pat.c:279!
> [ 329
27 matches
Mail list logo
