On Mon, Jul 07, 2014 at 08:51:08AM -0500, Christoph Lameter wrote:
>On Thu, 3 Jul 2014, Wei Yang wrote:
>
>> Here is my refined version, hope this is more friendly to the audience.
>
>Acked-by: Christoph Lameter
Thanks. I am glad to work with you.
--
Richard Yang
Help you, Help me
--
To unsubs
On Thu, 3 Jul 2014, Wei Yang wrote:
> Here is my refined version, hope this is more friendly to the audience.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
On Wed, Jul 02, 2014 at 09:20:20AM -0500, Christoph Lameter wrote:
>On Wed, 2 Jul 2014, Wei Yang wrote:
>
>> My patch is somewhat convoluted since I wanted to preserve the original logic
>> and make minimal change. And yes, it looks not that nice to audience.
>
>Well I was the author of the initial
On Tue, Jul 01, 2014 at 02:49:47PM -0700, Andrew Morton wrote:
>On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter
>wrote:
>
>> On Mon, 30 Jun 2014, David Rientjes wrote:
>>
>> > It's not at all clear to me that that patch is correct. Wei?
>>
>> Looks ok to me. But I do not like the con
On Tue, 1 Jul 2014, Andrew Morton wrote:
> I can copy that text over and add the reported-by etc (ho hum) but I
> have a tiny feeling that this patch hasn't been rigorously tested?
The testing so far was to verify that a kernel successfully builds with
the patch and then booted upo in a kvm inst
On Tue, 1 Jul 2014, Sasha Levin wrote:
> Is there a better way to stress test slub?
The typical way to test is by stressing the network subsystem
with small packets that require small allocations. Or do a filesystem
test that requires lots of metadata (file creations, removal, renames
etc).
But
On Wed, 2 Jul 2014, Wei Yang wrote:
> My patch is somewhat convoluted since I wanted to preserve the original logic
> and make minimal change. And yes, it looks not that nice to audience.
Well I was the author of the initial "convoluted" logic.
> I feel a little hurt by this patch. What I found
On Tue, Jul 01, 2014 at 02:49:47PM -0700, Andrew Morton wrote:
>On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter
>wrote:
>
>> On Mon, 30 Jun 2014, David Rientjes wrote:
>>
>> > It's not at all clear to me that that patch is correct. Wei?
>>
>> Looks ok to me. But I do not like the con
On Tue, Jul 01, 2014 at 09:58:52AM -0500, Christoph Lameter wrote:
>On Mon, 30 Jun 2014, David Rientjes wrote:
>
>> It's not at all clear to me that that patch is correct. Wei?
>
>Looks ok to me. But I do not like the convoluted code in new_slab() which
>Wei's patch does not make easier to read. M
On 07/01/2014 05:49 PM, Andrew Morton wrote:
> On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter
> wrote:
>
>> On Mon, 30 Jun 2014, David Rientjes wrote:
>>
>>> It's not at all clear to me that that patch is correct. Wei?
>>
>> Looks ok to me. But I do not like the convoluted code in ne
On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter
wrote:
> On Mon, 30 Jun 2014, David Rientjes wrote:
>
> > It's not at all clear to me that that patch is correct. Wei?
>
> Looks ok to me. But I do not like the convoluted code in new_slab() which
> Wei's patch does not make easier to
On Mon, 30 Jun 2014, David Rientjes wrote:
> It's not at all clear to me that that patch is correct. Wei?
Looks ok to me. But I do not like the convoluted code in new_slab() which
Wei's patch does not make easier to read. Makes it difficult for the
reader to see whats going on.
Lets drop the us
On Mon, Jun 30, 2014 at 03:03:21PM -0700, David Rientjes wrote:
>On Wed, 25 Jun 2014, Christoph Lameter wrote:
>
>> On Wed, 25 Jun 2014, Sasha Levin wrote:
>>
>> > [ 791.669480] ? init_object (mm/slub.c:665)
>> > [ 791.669480] setup_object.isra.34 (mm/slub.c:1008 mm/slub.c:1373)
>> > [ 791.6694
On Wed, 25 Jun 2014, Christoph Lameter wrote:
> On Wed, 25 Jun 2014, Sasha Levin wrote:
>
> > [ 791.669480] ? init_object (mm/slub.c:665)
> > [ 791.669480] setup_object.isra.34 (mm/slub.c:1008 mm/slub.c:1373)
> > [ 791.669480] new_slab (mm/slub.c:278 mm/slub.c:1412)
>
> So we just got a new p
On Wed, 25 Jun 2014, Sasha Levin wrote:
> [ 791.669480] ? init_object (mm/slub.c:665)
> [ 791.669480] setup_object.isra.34 (mm/slub.c:1008 mm/slub.c:1373)
> [ 791.669480] new_slab (mm/slub.c:278 mm/slub.c:1412)
So we just got a new page from the page allocator but somehow cannot
write to it. T
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 791.659908] BUG: unable to handle kernel paging request at 880302e12000
[ 791.661580] IP: memset (arch/x86/lib/memset_64.S:83)
[ 791.661580] PGD 17b7d067 PUD 7
16 matches
Mail list logo
