Hi all,
News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.
Changes since 20200806:
My fixes tree contains:
dbf24e30ce2e ("device_cgroup: Fix RCU list debugging warning")
Non-merge
Hi Michael,
On 8/8/19 12:13 AM, Michael Ellerman wrote:
>
> This is still popping a few implicit fallthrough warnings, from various
> configs:
>
> arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
>
Stephen Rothwell writes:
> Hi all,
>
> Changes since 20190806:
>
> The arm64 tree introduced a patch that stopped the powerpc ppc64_defconfig
> build from completing so I reverted that commit.
>
> The mips tree gained a conflict against Linus' tree.
>
> The crypto tree still had its build failure
Hi Song,
On Wed, 7 Aug 2019 22:11:28 + Song Liu wrote:
>
> From: Song Liu
> Date: Wed, 7 Aug 2019 14:57:38 -0700
> Subject: [PATCH] khugepaged: fix build without CONFIG_SHMEM
>
> khugepaged_scan_file() should be fully bypassed without CONFIG_SHMEM.
>
> Fixes: f57286140d96 ("mm,thp: add
Hi Andrew,
On Wed, 7 Aug 2019 14:27:55 -0700 Andrew Morton
wrote:
>
> It's all a bit confusing. I'll drop
>
> mm-move-memcmp_pages-and-pages_identical.patch
> uprobe-use-original-page-when-all-uprobes-are-removed.patch
> uprobe-use-original-page-when-all-uprobes-are-removed-v2.patch
>
> On Aug 7, 2019, at 2:27 PM, Andrew Morton wrote:
>
> On Wed, 7 Aug 2019 21:00:04 + Song Liu wrote:
>
Shall I resend the patch, or shall I send fix on top of current patch?
>>>
>>> Either is OK. If the difference is small I will turn it into an
>>> incremental patch so
> On Aug 7, 2019, at 2:30 PM, Randy Dunlap wrote:
>
> On 8/7/19 2:27 PM, Andrew Morton wrote:
>> On Wed, 7 Aug 2019 21:00:04 + Song Liu wrote:
>>
>
> Shall I resend the patch, or shall I send fix on top of current patch?
Either is OK. If the difference is small I
On 8/7/19 2:27 PM, Andrew Morton wrote:
> On Wed, 7 Aug 2019 21:00:04 + Song Liu wrote:
>
Shall I resend the patch, or shall I send fix on top of current patch?
>>>
>>> Either is OK. If the difference is small I will turn it into an
>>> incremental patch so that I (and others) can
On Wed, 7 Aug 2019 21:00:04 + Song Liu wrote:
> >>
> >> Shall I resend the patch, or shall I send fix on top of current patch?
> >
> > Either is OK. If the difference is small I will turn it into an
> > incremental patch so that I (and others) can see what changed.
>
> Please find the
Hi Andrew,
> On Aug 7, 2019, at 1:10 PM, Andrew Morton wrote:
>
> On Wed, 7 Aug 2019 16:59:14 + Song Liu wrote:
>
>> Hi Randy,
>>
>>> On Aug 7, 2019, at 8:11 AM, Randy Dunlap wrote:
>>>
>>> On 8/7/19 1:36 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20190806:
On Wed, 7 Aug 2019 16:59:14 + Song Liu wrote:
> Hi Randy,
>
> > On Aug 7, 2019, at 8:11 AM, Randy Dunlap wrote:
> >
> > On 8/7/19 1:36 AM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Changes since 20190806:
> >>
> >
> > on i386:
> >
> > when CONFIG_SHMEM is not set/enabled:
> >
>
Hi Randy,
> On Aug 7, 2019, at 8:11 AM, Randy Dunlap wrote:
>
> On 8/7/19 1:36 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20190806:
>>
>
> on i386:
>
> when CONFIG_SHMEM is not set/enabled:
>
> ../mm/khugepaged.c: In function ‘khugepaged_scan_mm_slot’:
>
On 8/7/19 1:36 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190806:
>
on i386:
when CONFIG_SHMEM is not set/enabled:
../mm/khugepaged.c: In function ‘khugepaged_scan_mm_slot’:
../mm/khugepaged.c:1874:2: error: implicit declaration of function
Hi all,
Changes since 20190806:
The arm64 tree introduced a patch that stopped the powerpc ppc64_defconfig
build from completing so I reverted that commit.
The mips tree gained a conflict against Linus' tree.
The crypto tree still had its build failure for which I applied a patch.
The
Hi all,
Changes since 20180806:
The vfs tree still had its build failure but today I applied a suggested
patch. It then gained another build failure due to an interaction with
the kbuild tree for which I applied a merge fix patch. And then another
for which I disabled CONFIG_SAMPLE_STATX.
The
Hi all,
Changes since 20180806:
The vfs tree still had its build failure but today I applied a suggested
patch. It then gained another build failure due to an interaction with
the kbuild tree for which I applied a merge fix patch. And then another
for which I disabled CONFIG_SAMPLE_STATX.
The
Hi all,
Changes since 20170804:
The rockchip tree gained a conflict against Linus' tree.
The pm tree gained a conflict against the dmi tree.
The net-next tree gained a conflict against the net tree.
I again reverted a commit from the staging tree that was causing overnight
build failures.
Hi all,
Changes since 20170804:
The rockchip tree gained a conflict against Linus' tree.
The pm tree gained a conflict against the dmi tree.
The net-next tree gained a conflict against the net tree.
I again reverted a commit from the staging tree that was causing overnight
build failures.
Hi all,
Changes since 20150806:
The arm-soc tree gained a build failure so I used the version from
next-20150806.
The slave-dma tree lost its build failure.
The wireless-drivers-next tree gained a build failure so I used the
version from next-20150806.
The audit tree gained a conflict against
Hi all,
Changes since 20150806:
The arm-soc tree gained a build failure so I used the version from
next-20150806.
The slave-dma tree lost its build failure.
The wireless-drivers-next tree gained a build failure so I used the
version from next-20150806.
The audit tree gained a conflict against
Hi all,
Please do not add code intended for v3.18 until after v3.17-rc1 is
released.
Changes since 20140806:
The modules tree lost one build failure but gained another so I used
the version from next-20140725.
The mmc-uh tree still had its build failure so I used the version from
Hi all,
Please do not add code intended for v3.18 until after v3.17-rc1 is
released.
Changes since 20140806:
The modules tree lost one build failure but gained another so I used
the version from next-20140725.
The mmc-uh tree still had its build failure so I used the version from
On Wed, Aug 07, 2013 at 04:36:21PM -0700, David Miller wrote:
> From: David Miller
> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>
> > Look, I'm going to fix this myself, because I'm pretty tired of
> > waiting for the obvious fix.
>
> Someone please test this:
>
> diff --git
On Wed, Aug 07, 2013 at 04:36:21PM -0700, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
Look, I'm going to fix this myself, because I'm pretty tired of
waiting for the obvious fix.
Someone please test this:
diff --git
On Thu, Aug 8, 2013 at 10:46 AM, Sedat Dilek wrote:
> On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross wrote:
>> On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek wrote:
>>> On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross wrote:
On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek wrote:
> On Thu, Aug 8,
On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross wrote:
> On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek wrote:
>> On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross wrote:
>>> On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek wrote:
On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross wrote:
> Can you try add a
On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross ccr...@android.com wrote:
On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross ccr...@android.com wrote:
On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu,
On Thu, Aug 8, 2013 at 10:46 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross ccr...@android.com wrote:
On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross ccr...@android.com wrote:
On Wed,
On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek wrote:
> On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross wrote:
>> On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek wrote:
>>> On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross wrote:
Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
From: David Miller
Date: Wed, 07 Aug 2013 17:09:26 -0700 (PDT)
> Ok, I'm going to simply revert all of these changes, thanks for testing.
Here is what I just pushed to net-next:
>From 09effa67a18d893fc4e6f81a3659fc9efef1445e Mon Sep 17 00:00:00 2001
From: "David S. Miller"
On Wed, 2013-08-07 at 16:36 -0700, David Miller wrote:
> From: David Miller
> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>
> > Look, I'm going to fix this myself, because I'm pretty tired of
> > waiting for the obvious fix.
>
> Someone please test this:
>
> diff --git
From: Sedat Dilek
Date: Thu, 8 Aug 2013 02:02:48 +0200
> On Thu, Aug 8, 2013 at 1:36 AM, David Miller wrote:
>> From: David Miller
>> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>>
>>> Look, I'm going to fix this myself, because I'm pretty tired of
>>> waiting for the obvious fix.
>>
>>
On Thu, Aug 8, 2013 at 1:36 AM, David Miller wrote:
> From: David Miller
> Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
>
>> Look, I'm going to fix this myself, because I'm pretty tired of
>> waiting for the obvious fix.
>
> Someone please test this:
>
Your patch on top of next-20130807 does not
On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek wrote:
> On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross wrote:
>> Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
>> the error path of try_to_freeze_tasks(), where it prints the "refusing
>> to freeze" message? It will print the
From: David Miller
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
> Look, I'm going to fix this myself, because I'm pretty tired of
> waiting for the obvious fix.
Someone please test this:
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index c623861..afc02a6 100644
---
From: Phil Sutter
Date: Wed, 7 Aug 2013 20:37:58 +0200
> One could simply call skb_push(skb, ETH_HLEN) right after calling
> eth_type_trans(skb, dev) in order to undo the 'data' and 'len'
> adjustment. Not sure if this kind of hack is the right way to go here,
> or if the whole af_packet parses
On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross wrote:
> Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
> the error path of try_to_freeze_tasks(), where it prints the "refusing
> to freeze" message? It will print the stack trace of every thread
> since they are all in the
Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
the error path of try_to_freeze_tasks(), where it prints the "refusing
to freeze" message? It will print the stack trace of every thread
since they are all in the freezer, so the output will be very long.
On Wed, Aug 7, 2013 at
On Wednesday, August 07, 2013 04:25:14 PM Sedat Dilek wrote:
> On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Changes since 20130806:
> >
> > The ext4 tree lost its build failure.
> >
> > The mvebu tree gained a build failure so I used the version from
> >
On Wed, Aug 07, 2013 at 10:47:13AM -0700, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 07 Aug 2013 09:40:09 -0700
>
> > On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
> >
> >> Maybe. I haven't tested it, but I'm thinking that skb->data doesn't
> >> point to the start of the
From: Eric Dumazet
Date: Wed, 07 Aug 2013 09:40:09 -0700
> On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
>
>> Maybe. I haven't tested it, but I'm thinking that skb->data doesn't
>> point to the start of the data frame in this case, since we now call
>> eth_type_trans() which pulls the
On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
> Maybe. I haven't tested it, but I'm thinking that skb->data doesn't
> point to the start of the data frame in this case, since we now call
> eth_type_trans() which pulls the ethernet header. So if the device just
> transmits skb->len
On Wed, 2013-08-07 at 18:12 +0200, Johannes Berg wrote:
> On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
>
> > The idea behind this patch is that users setting the protocol to
> > something else probably do know better and so should be left alone.
>
> Regardless of that, I think that
On Wed, 2013-08-07 at 09:17 -0700, Eric Dumazet wrote:
> On Wed, 2013-08-07 at 18:12 +0200, Johannes Berg wrote:
> > On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
> >
> > > The idea behind this patch is that users setting the protocol to
> > > something else probably do know better and so
On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
> The idea behind this patch is that users setting the protocol to
> something else probably do know better and so should be left alone.
Regardless of that, I think that still the skb pointers would be changed
by this patch which would
On Wed, Aug 07, 2013 at 10:29:18AM +0200, Sedat Dilek wrote:
> On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Changes since 20130806:
> >
> > The ext4 tree lost its build failure.
> >
> > The mvebu tree gained a build failure so I used the version from
> >
On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130806:
>
> The ext4 tree lost its build failure.
>
> The mvebu tree gained a build failure so I used the version from
> next-20130806.
>
> The akpm tree gained conflicts against the ext4 tree.
>
>
On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi all,
Changes since 20130806:
The ext4 tree lost its build failure.
The mvebu tree gained a build failure so I used the version from
next-20130806.
The akpm tree gained conflicts against the ext4 tree.
On Wed, Aug 07, 2013 at 10:29:18AM +0200, Sedat Dilek wrote:
On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
Changes since 20130806:
The ext4 tree lost its build failure.
The mvebu tree gained a build failure so I used the version from
On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
The idea behind this patch is that users setting the protocol to
something else probably do know better and so should be left alone.
Regardless of that, I think that still the skb pointers would be changed
by this patch which would confuse
On Wed, 2013-08-07 at 09:17 -0700, Eric Dumazet wrote:
On Wed, 2013-08-07 at 18:12 +0200, Johannes Berg wrote:
On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
The idea behind this patch is that users setting the protocol to
something else probably do know better and so should be
On Wed, 2013-08-07 at 18:12 +0200, Johannes Berg wrote:
On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
The idea behind this patch is that users setting the protocol to
something else probably do know better and so should be left alone.
Regardless of that, I think that still the
On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
Maybe. I haven't tested it, but I'm thinking that skb-data doesn't
point to the start of the data frame in this case, since we now call
eth_type_trans() which pulls the ethernet header. So if the device just
transmits skb-len starting
From: Eric Dumazet eric.duma...@gmail.com
Date: Wed, 07 Aug 2013 09:40:09 -0700
On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
Maybe. I haven't tested it, but I'm thinking that skb-data doesn't
point to the start of the data frame in this case, since we now call
eth_type_trans()
On Wed, Aug 07, 2013 at 10:47:13AM -0700, David Miller wrote:
From: Eric Dumazet eric.duma...@gmail.com
Date: Wed, 07 Aug 2013 09:40:09 -0700
On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
Maybe. I haven't tested it, but I'm thinking that skb-data doesn't
point to the start
On Wednesday, August 07, 2013 04:25:14 PM Sedat Dilek wrote:
On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
Changes since 20130806:
The ext4 tree lost its build failure.
The mvebu tree gained a build failure so I used the version from
Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
the error path of try_to_freeze_tasks(), where it prints the refusing
to freeze message? It will print the stack trace of every thread
since they are all in the freezer, so the output will be very long.
On Wed, Aug 7, 2013 at
On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross ccr...@android.com wrote:
Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
the error path of try_to_freeze_tasks(), where it prints the refusing
to freeze message? It will print the stack trace of every thread
since they are all
From: Phil Sutter p...@nwl.cc
Date: Wed, 7 Aug 2013 20:37:58 +0200
One could simply call skb_push(skb, ETH_HLEN) right after calling
eth_type_trans(skb, dev) in order to undo the 'data' and 'len'
adjustment. Not sure if this kind of hack is the right way to go here,
or if the whole af_packet
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
Look, I'm going to fix this myself, because I'm pretty tired of
waiting for the obvious fix.
Someone please test this:
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index
On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross ccr...@android.com wrote:
Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
the error path of try_to_freeze_tasks(), where it prints the refusing
to freeze
On Thu, Aug 8, 2013 at 1:36 AM, David Miller da...@davemloft.net wrote:
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
Look, I'm going to fix this myself, because I'm pretty tired of
waiting for the obvious fix.
Someone please test this:
Your patch on
From: Sedat Dilek sedat.di...@gmail.com
Date: Thu, 8 Aug 2013 02:02:48 +0200
On Thu, Aug 8, 2013 at 1:36 AM, David Miller da...@davemloft.net wrote:
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
Look, I'm going to fix this myself, because I'm pretty tired
On Wed, 2013-08-07 at 16:36 -0700, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT)
Look, I'm going to fix this myself, because I'm pretty tired of
waiting for the obvious fix.
Someone please test this:
diff --git
From: David Miller da...@davemloft.net
Date: Wed, 07 Aug 2013 17:09:26 -0700 (PDT)
Ok, I'm going to simply revert all of these changes, thanks for testing.
Here is what I just pushed to net-next:
From 09effa67a18d893fc4e6f81a3659fc9efef1445e Mon Sep 17 00:00:00 2001
From:
On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross ccr...@android.com wrote:
On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross ccr...@android.com wrote:
Can you
Hi all,
Changes since 20130806:
The ext4 tree lost its build failure.
The mvebu tree gained a build failure so I used the version from
next-20130806.
The akpm tree gained conflicts against the ext4 tree.
I have
Hi all,
Changes since 20130806:
The ext4 tree lost its build failure.
The mvebu tree gained a build failure so I used the version from
next-20130806.
The akpm tree gained conflicts against the ext4 tree.
I have
Hi all,
OK, so the merge window is closed. Time to clean up your trees and then
start adding new stuff to them.
Changes since 20120806:
The cifs tree lost its build failure.
The spi-mb tree lost its build failure.
The tty tree still has its build failures for which I have disabled 2
staging
Hi all,
OK, so the merge window is closed. Time to clean up your trees and then
start adding new stuff to them.
Changes since 20120806:
The cifs tree lost its build failure.
The spi-mb tree lost its build failure.
The tty tree still has its build failures for which I have disabled 2
staging
70 matches
Mail list logo
