Re: linux-next: build failure after merge of the rtc tree

[Alexandre Belloni]

On 11/04/2017 at 10:22:38 +1000, Stephen Rothwell wrote:
> Hi Hans,
> 
> On Mon, 10 Apr 2017 09:45:45 +0200 Hans de Goede  wrote:
> >
> > On 10-04-17 08:04, Stephen Rothwell wrote:
> > >
> > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > ERROR: "legacy_pic" [drivers/rtc/rtc-cmos.ko] undefined!
> > >
> > > Caused by commit
> > >
> > >   d3e3a65c6a96 ("rtc: cmos: Do not assume irq 8 for rtc when there are no 
> > > legacy irqs")
> > >
> > > "legacy_pic" is not exported to modules.
> > >
> > > I have used the rtc tree from next-20170407 for today.  
> > 
> > I already send out a patch to fix this yesterday. I've attached a copy.
> 
> I will add that to linux-next today and will drop it when Alexandre
> adds it (or some other fix).
> 

I think the x86 maintainers will take it as it is fairly independent.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: linux-next: build failure after merge of the rtc tree

[Alexandre Belloni]

On 11/04/2017 at 10:22:38 +1000, Stephen Rothwell wrote:
> Hi Hans,
> 
> On Mon, 10 Apr 2017 09:45:45 +0200 Hans de Goede  wrote:
> >
> > On 10-04-17 08:04, Stephen Rothwell wrote:
> > >
> > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > ERROR: "legacy_pic" [drivers/rtc/rtc-cmos.ko] undefined!
> > >
> > > Caused by commit
> > >
> > >   d3e3a65c6a96 ("rtc: cmos: Do not assume irq 8 for rtc when there are no 
> > > legacy irqs")
> > >
> > > "legacy_pic" is not exported to modules.
> > >
> > > I have used the rtc tree from next-20170407 for today.  
> > 
> > I already send out a patch to fix this yesterday. I've attached a copy.
> 
> I will add that to linux-next today and will drop it when Alexandre
> adds it (or some other fix).
> 

I think the x86 maintainers will take it as it is fairly independent.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

[Xunlei Pang]

On 04/11/2017 at 04:47 AM, Daniel Bristot de Oliveira wrote:
> On 04/10/2017 11:22 AM, Xunlei Pang wrote:
>> I was testing Daniel's changes with his test case in the commit
>> df8eac8cafce ("sched/deadline: Throttle a constrained deadline
>> task activated after the deadline"), and tweaked it a little.
>>
>> Instead of having the runtime equal to the deadline, I tweaked
>> runtime, deadline and sleep value to ensure every time it calls
>> dl_check_constrained_dl() with "dl_se->deadline > rq_clock(rq)"
>> as well as true dl_entity_overflow(), so it does replenishing
>> every wake up in update_dl_entity(), and break its bandwidth.
>>
>> Daniel's test case had:
>> attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */
>> attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms*/
>> attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */
>> ts.tv_sec = 0;
>> ts.tv_nsec = 2000 * 1000; /* 2 ms */
>>
>> I changed it to:
>> attr.sched_runtime = 5 * 1000 * 1000; /* 5 ms */
>> attr.sched_deadline = 7 * 1000 * 1000; /* 7 ms */
>> attr.sched_period = 1 * 1000 * 1000 * 1000; /* 1 s */
>> ts.tv_sec = 0;
>> ts.tv_nsec = 1000 * 1000; /* 1 ms */
>>
>> The change above can result in over 25% of the CPU on my machine.
>>
>> In order to avoid the beakage, we improve dl_check_constrained_dl()
>> to prevent dl tasks from being activated until the next period if it
>> runs out of bandwidth of the current period.
> The problem now is that, with your patch, we will throttle the task
> with some possible runtime. Moreover, the task did not brake any
> rule, like being awakened after the deadline - the user-space is not
> misbehaving.
>
> That is +- what the reproducer is doing when using your patch,
> (I put some trace_printk when noticing the overflow in the wakeup).
>
>   -0 [007] d.h.  1505.066439: enqueue_task_dl: my current 
> runtime is 3657361 and the deadline is 4613027 from now 
>   -0 [007] d.h.  1505.066439: enqueue_task_dl:  my 
> dl_runtime is 500
>
> and so the task will be throttled with 3657361 ns runtime available.
>
> As we can see, it is really breaking the density:
>
> 5ms / 7ms (.714285) < 3657361 / 4613027 (.792833)
>
> Well, it is not breaking that much. Trying to be less pessimist, we can
> compute a new runtime with following equation:
>
> runtime = (dl_runtime / dl_deadline) * (deadline - now)
>
> That is, a runtime which fits in the task's density.

This is a good point, to make the best use of remaining deadline, let me think 
more.

Regards,
Xunlei

>
> In code:
>
> dl_se->runtime = (div64_u64(dl_se->dl_runtime << 20, dl_se->dl_deadline) * 
> (dl_se->deadline - rq_clock(rq))) >> 20;
>
> For example (a trace_printk) showing the adjusted runtime for the
> previous task:
>   -0 [007] d.h.  1505.066440: enqueue_task_dl:  I can 
> still run for 3294208 (it is not that bad)
>
> With the adjusted runtime, we have the following density:
>
> 3294208 / 4613027 = .714109
>
> as .714109  < .714285
>
> Voilà. We can still use 3.2 ms of runtime! Not bad at all.
>
> However, even this result is, somehow, controversial. Because we are
> reducing the task's reservation (Q/P). But that is very close to the
> implicit deadline behavior: when it "overflows", the runtime is truncated
> (a replenishment...) and the deadline is postponed. In this case, we do
> not need to postpone the deadline, just to "truncate" the runtime to fit
> in the density... it is not that bad.
>
> Another possibility is not to replenish a constrained deadline
> task twice in a period. In this case, the task would run further
> the deadline, potentially causing problems for implicit deadline tasks.
> But! even implicit deadline would do it in a overloaded system. The
> problem is that, by using the density the system easily becomes
> overloaded (too pessimistic).
>
> Resuming (so far):
>
> 1) We can be pessimistic to the constrained deadline task,
>with Xunlei's patch;
> 2) Compute a new runtime to fit in the density - somehow pessimistic.
> 3) Avoid replenishing a constrained deadline before the next period.
>but the system will become overload very easily (density).
>
> I think the option 2 is the mid-term.
> I am showing a _proof of concept_ patch bellow. I is based in the
> Xunlei's changes in the verification. I need to polish it... but...
> you guys can read the idea in C.
>
> I have the 3) too, but I am not sure if it is as good as 2.
>
> We still need to think more about the solution test more... I will
> continue working on this tomorrow, discussing with luca and tommaso
> as well.
>
> Thoughts? Am I missing something (probably, I am tired :-) )?
>
> ---
>  kernel/sched/deadline.c | 53 
> -
>  1 file changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 7508129..6fa4887 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -696,34 +696,38 @@ void 

Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow

[Xunlei Pang]

On 04/11/2017 at 04:47 AM, Daniel Bristot de Oliveira wrote:
> On 04/10/2017 11:22 AM, Xunlei Pang wrote:
>> I was testing Daniel's changes with his test case in the commit
>> df8eac8cafce ("sched/deadline: Throttle a constrained deadline
>> task activated after the deadline"), and tweaked it a little.
>>
>> Instead of having the runtime equal to the deadline, I tweaked
>> runtime, deadline and sleep value to ensure every time it calls
>> dl_check_constrained_dl() with "dl_se->deadline > rq_clock(rq)"
>> as well as true dl_entity_overflow(), so it does replenishing
>> every wake up in update_dl_entity(), and break its bandwidth.
>>
>> Daniel's test case had:
>> attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */
>> attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms*/
>> attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */
>> ts.tv_sec = 0;
>> ts.tv_nsec = 2000 * 1000; /* 2 ms */
>>
>> I changed it to:
>> attr.sched_runtime = 5 * 1000 * 1000; /* 5 ms */
>> attr.sched_deadline = 7 * 1000 * 1000; /* 7 ms */
>> attr.sched_period = 1 * 1000 * 1000 * 1000; /* 1 s */
>> ts.tv_sec = 0;
>> ts.tv_nsec = 1000 * 1000; /* 1 ms */
>>
>> The change above can result in over 25% of the CPU on my machine.
>>
>> In order to avoid the beakage, we improve dl_check_constrained_dl()
>> to prevent dl tasks from being activated until the next period if it
>> runs out of bandwidth of the current period.
> The problem now is that, with your patch, we will throttle the task
> with some possible runtime. Moreover, the task did not brake any
> rule, like being awakened after the deadline - the user-space is not
> misbehaving.
>
> That is +- what the reproducer is doing when using your patch,
> (I put some trace_printk when noticing the overflow in the wakeup).
>
>   -0 [007] d.h.  1505.066439: enqueue_task_dl: my current 
> runtime is 3657361 and the deadline is 4613027 from now 
>   -0 [007] d.h.  1505.066439: enqueue_task_dl:  my 
> dl_runtime is 500
>
> and so the task will be throttled with 3657361 ns runtime available.
>
> As we can see, it is really breaking the density:
>
> 5ms / 7ms (.714285) < 3657361 / 4613027 (.792833)
>
> Well, it is not breaking that much. Trying to be less pessimist, we can
> compute a new runtime with following equation:
>
> runtime = (dl_runtime / dl_deadline) * (deadline - now)
>
> That is, a runtime which fits in the task's density.

This is a good point, to make the best use of remaining deadline, let me think 
more.

Regards,
Xunlei

>
> In code:
>
> dl_se->runtime = (div64_u64(dl_se->dl_runtime << 20, dl_se->dl_deadline) * 
> (dl_se->deadline - rq_clock(rq))) >> 20;
>
> For example (a trace_printk) showing the adjusted runtime for the
> previous task:
>   -0 [007] d.h.  1505.066440: enqueue_task_dl:  I can 
> still run for 3294208 (it is not that bad)
>
> With the adjusted runtime, we have the following density:
>
> 3294208 / 4613027 = .714109
>
> as .714109  < .714285
>
> Voilà. We can still use 3.2 ms of runtime! Not bad at all.
>
> However, even this result is, somehow, controversial. Because we are
> reducing the task's reservation (Q/P). But that is very close to the
> implicit deadline behavior: when it "overflows", the runtime is truncated
> (a replenishment...) and the deadline is postponed. In this case, we do
> not need to postpone the deadline, just to "truncate" the runtime to fit
> in the density... it is not that bad.
>
> Another possibility is not to replenish a constrained deadline
> task twice in a period. In this case, the task would run further
> the deadline, potentially causing problems for implicit deadline tasks.
> But! even implicit deadline would do it in a overloaded system. The
> problem is that, by using the density the system easily becomes
> overloaded (too pessimistic).
>
> Resuming (so far):
>
> 1) We can be pessimistic to the constrained deadline task,
>with Xunlei's patch;
> 2) Compute a new runtime to fit in the density - somehow pessimistic.
> 3) Avoid replenishing a constrained deadline before the next period.
>but the system will become overload very easily (density).
>
> I think the option 2 is the mid-term.
> I am showing a _proof of concept_ patch bellow. I is based in the
> Xunlei's changes in the verification. I need to polish it... but...
> you guys can read the idea in C.
>
> I have the 3) too, but I am not sure if it is as good as 2.
>
> We still need to think more about the solution test more... I will
> continue working on this tomorrow, discussing with luca and tommaso
> as well.
>
> Thoughts? Am I missing something (probably, I am tired :-) )?
>
> ---
>  kernel/sched/deadline.c | 53 
> -
>  1 file changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 7508129..6fa4887 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -696,34 +696,38 @@ void 

Re: linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

On Tue, 11 Apr 2017 07:38:32 +0200 Greg KH  wrote:
>
> I should have this fixed now, sorry for taking so long.

Thanks and no worries.
-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

On Tue, 11 Apr 2017 07:38:32 +0200 Greg KH  wrote:
>
> I should have this fixed now, sorry for taking so long.

Thanks and no worries.
-- 
Cheers,
Stephen Rothwell

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Changes since 20170410:

The crypto tree gained a conflict against the kbuild tree.

The drm tree gained a conflict against the v4l-dvb tree.

The mfd tree lost its build failure.

The kvm-ppc tree still had its build failure for which I reverted 4 commits.

The staging tree gained conflicts against the v4l-dvb tree and still
had its build failure for which I applied a supplied patch. I gained
another build failure for which I disabled a driver.

The rtc tree still had its build failure for which I applied a supplied
patch.

The akpm-current tree lost its build failure.

The akpm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8639
 8597 files changed, 1063053 insertions(+), 174220 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 256 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c08e611b7d01 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (83c67bb382fb ARC: [plat-eznps] Fix build error)
Merging arm-current/fixes (3872fe83a2fb Merge branch 'kprobe-fixes' of 
https://git.linaro.org/people/tixy/kernel into fixes)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (4749228f0228 powerpc/crypto/crc32c-vpmsum: Fix 
missing preempt_disable())
Merging sparc/master (78d91a75b40f Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (17c3060b1701 tcp: clear saved_syn in tcp_disconnect())
Merging ipsec/master (89e357d83c06 af_key: Add lock to key dump)
Merging netfilter/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO 
check)
Merging ipvs/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO 
check)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (75514b665485 net: ethernet: ti: cpsw: wake tx queues 
on ndo_tx_timeout)
Merging sound-current/for-linus (3d016d57fdc5 ALSA: oxfw: fix regression to 
handle Stanton SCS.1m/1d)
Merging pci-current/for-linus (794a8604fe6e PCI: dwc: Fix dw_pcie_ops NULL 
pointer dereference)
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (5659495a7a14 uapi: add missing install of 
userio.h)
Merging crypto-current/master (e6534aeb

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Changes since 20170410:

The crypto tree gained a conflict against the kbuild tree.

The drm tree gained a conflict against the v4l-dvb tree.

The mfd tree lost its build failure.

The kvm-ppc tree still had its build failure for which I reverted 4 commits.

The staging tree gained conflicts against the v4l-dvb tree and still
had its build failure for which I applied a supplied patch. I gained
another build failure for which I disabled a driver.

The rtc tree still had its build failure for which I applied a supplied
patch.

The akpm-current tree lost its build failure.

The akpm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8639
 8597 files changed, 1063053 insertions(+), 174220 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 256 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c08e611b7d01 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (83c67bb382fb ARC: [plat-eznps] Fix build error)
Merging arm-current/fixes (3872fe83a2fb Merge branch 'kprobe-fixes' of 
https://git.linaro.org/people/tixy/kernel into fixes)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (4749228f0228 powerpc/crypto/crc32c-vpmsum: Fix 
missing preempt_disable())
Merging sparc/master (78d91a75b40f Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (17c3060b1701 tcp: clear saved_syn in tcp_disconnect())
Merging ipsec/master (89e357d83c06 af_key: Add lock to key dump)
Merging netfilter/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO 
check)
Merging ipvs/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO 
check)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (75514b665485 net: ethernet: ti: cpsw: wake tx queues 
on ndo_tx_timeout)
Merging sound-current/for-linus (3d016d57fdc5 ALSA: oxfw: fix regression to 
handle Stanton SCS.1m/1d)
Merging pci-current/for-linus (794a8604fe6e PCI: dwc: Fix dw_pcie_ops NULL 
pointer dereference)
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (5659495a7a14 uapi: add missing install of 
userio.h)
Merging crypto-current/master (e6534aeb

Re: [RFC PATCH tip/master V3 0/8] kprobes/x86: Make kprobes instruction buffers read-only

[Masami Hiramatsu]

Ping?

On Wed, 29 Mar 2017 13:55:44 +0900
Masami Hiramatsu  wrote:

> Hi,
> 
> This is the 3rd version of the series. I just updated 4/8 according
> to Ingo's comment.
> 
> This series tries to make kprobes instruction buffers read-only
> pages. Since those buffers are used for trampoline code, those
> are a part of "text area" and it should be marked as ro for
> avoiding unexpected modification. And this actually fix a warning
> rodata sanity check reported by lkp-robot.
> 
> https://lkml.org/lkml/2017/2/27/161
> 
> This change requires changing the kprobe-booster at first
> because it can modify the instruction buffer to add a jump while
> resuming from single-stepping. Of course after we make the buffer
> readonly, we may not be able to modify it while probing.
> 
> So, at first this series checks the current bootable instructions
> and fixes a missed instruction (call far), modifies can_boost to
> use x86 instruction decoder, and inserts "booster" jump while
> preparing instruction buffer instead of resuming from single-stepping.
> At last, it makes the buffers for kprobes and optprobe readonly.
> 
> This series also has some cleanup patches related to above 
> changes.
> 
> Changes from V2:
>  - [4/8]: Fix imbalanced curly braces and remove unneeded
>(void *) cast.
> 
> ---
> 
> Masami Hiramatsu (8):
>   kprobes/x86: Fix not to boost call far instruction
>   kprobes/x86: Fix the description of __copy_instruction()
>   kprobes/x86: Use instruction decoder for booster
>   kprobes/x86: Do not modify singlestep buffer while resuming
>   kprobes/x86: Make boostable flag boolean
>   kprobes/x86: Set kprobes pages readonly
>   kprobes/x86: Use probe_kernel_read instead of memcpy
>   kprobes/x86: Consolidate insn decoder users for copying code
> 
> 
>  arch/x86/include/asm/kprobes.h   |7 +-
>  arch/x86/kernel/kprobes/common.h |4 +
>  arch/x86/kernel/kprobes/core.c   |  149 
> +++---
>  arch/x86/kernel/kprobes/ftrace.c |2 -
>  arch/x86/kernel/kprobes/opt.c|   13 +++
>  5 files changed, 90 insertions(+), 85 deletions(-)
> 
> --
> Masami Hiramatsu (Linaro) 


-- 
Masami Hiramatsu 

Re: [RFC PATCH tip/master V3 0/8] kprobes/x86: Make kprobes instruction buffers read-only

[Masami Hiramatsu]

Ping?

On Wed, 29 Mar 2017 13:55:44 +0900
Masami Hiramatsu  wrote:

> Hi,
> 
> This is the 3rd version of the series. I just updated 4/8 according
> to Ingo's comment.
> 
> This series tries to make kprobes instruction buffers read-only
> pages. Since those buffers are used for trampoline code, those
> are a part of "text area" and it should be marked as ro for
> avoiding unexpected modification. And this actually fix a warning
> rodata sanity check reported by lkp-robot.
> 
> https://lkml.org/lkml/2017/2/27/161
> 
> This change requires changing the kprobe-booster at first
> because it can modify the instruction buffer to add a jump while
> resuming from single-stepping. Of course after we make the buffer
> readonly, we may not be able to modify it while probing.
> 
> So, at first this series checks the current bootable instructions
> and fixes a missed instruction (call far), modifies can_boost to
> use x86 instruction decoder, and inserts "booster" jump while
> preparing instruction buffer instead of resuming from single-stepping.
> At last, it makes the buffers for kprobes and optprobe readonly.
> 
> This series also has some cleanup patches related to above 
> changes.
> 
> Changes from V2:
>  - [4/8]: Fix imbalanced curly braces and remove unneeded
>(void *) cast.
> 
> ---
> 
> Masami Hiramatsu (8):
>   kprobes/x86: Fix not to boost call far instruction
>   kprobes/x86: Fix the description of __copy_instruction()
>   kprobes/x86: Use instruction decoder for booster
>   kprobes/x86: Do not modify singlestep buffer while resuming
>   kprobes/x86: Make boostable flag boolean
>   kprobes/x86: Set kprobes pages readonly
>   kprobes/x86: Use probe_kernel_read instead of memcpy
>   kprobes/x86: Consolidate insn decoder users for copying code
> 
> 
>  arch/x86/include/asm/kprobes.h   |7 +-
>  arch/x86/kernel/kprobes/common.h |4 +
>  arch/x86/kernel/kprobes/core.c   |  149 
> +++---
>  arch/x86/kernel/kprobes/ftrace.c |2 -
>  arch/x86/kernel/kprobes/opt.c|   13 +++
>  5 files changed, 90 insertions(+), 85 deletions(-)
> 
> --
> Masami Hiramatsu (Linaro) 


-- 
Masami Hiramatsu 

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

[Giuseppe CAVALLARO]

Hi Niklas

patch looks ok for me, Alex any feedback?

peppe

On 4/10/2017 8:33 PM, Niklas Cassel wrote:

From: Niklas Cassel 

Field FL/TPL in register TDES3 is not correctly set on GMAC4.
TX appears to be functional on GMAC 4.10a even if this field is not set,
however, to avoid relying on undefined behavior, set the length in TDES3.

The field has a different meaning depending on if the TSE bit in TDES3
is set or not (TSO). However, regardless of the TSE bit, the field is
not optional. The field is already set correctly when the TSE bit is set.

Since there is no limit for the number of descriptors that can be
used for a single packet, the field should be set to the sum of
the buffers contained in:
[ ...  ...
], which should be equal to skb->len.

Signed-off-by: Niklas Cassel 
---
  drivers/net/ethernet/stmicro/stmmac/chain_mode.c   | 6 +++---
  drivers/net/ethernet/stmicro/stmmac/common.h   | 2 +-
  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 3 ++-
  drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
  drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 2 +-
  drivers/net/ethernet/stmicro/stmmac/ring_mode.c| 9 ++---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 5 +++--
  7 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 37881f81319e..e93c40b4631e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -52,7 +52,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
tx_q->tx_skbuff_dma[entry].len = bmax;
/* do not close the descriptor and do not set own bit */
priv->hw->desc->prepare_tx_desc(desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
-   0, false);
+   0, false, skb->len);
  
  	while (len != 0) {

tx_q->tx_skbuff[entry] = NULL;
@@ -70,7 +70,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
tx_q->tx_skbuff_dma[entry].len = bmax;
priv->hw->desc->prepare_tx_desc(desc, 0, bmax, csum,
STMMAC_CHAIN_MODE, 1,
-   false);
+   false, skb->len);
len -= bmax;
i++;
} else {
@@ -85,7 +85,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
/* last descriptor can be set now */
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum,
STMMAC_CHAIN_MODE, 1,
-   true);
+   true, skb->len);
len = 0;
}
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 90d28bcad880..b7ce3fbb5375 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -373,7 +373,7 @@ struct stmmac_desc_ops {
/* Invoked by the xmit function to prepare the tx descriptor */
void (*prepare_tx_desc) (struct dma_desc *p, int is_fs, int len,
 bool csum_flag, int mode, bool tx_own,
-bool ls);
+bool ls, unsigned int tot_pkt_len);
void (*prepare_tso_tx_desc)(struct dma_desc *p, int is_fs, int len1,
int len2, bool tx_own, bool ls,
unsigned int tcphdrlen,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 843ec69222ea..aa6476439aee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -304,12 +304,13 @@ static void dwmac4_rd_init_tx_desc(struct dma_desc *p, 
int mode, int end)
  
  static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,

  bool csum_flag, int mode, bool tx_own,
- bool ls)
+ bool ls, unsigned int tot_pkt_len)
  {
unsigned int tdes3 = le32_to_cpu(p->des3);
  
  	p->des2 |= cpu_to_le32(len & TDES2_BUFFER1_SIZE_MASK);
  
+	tdes3 |= tot_pkt_len & TDES3_PACKET_SIZE_MASK;

if (is_fs)
tdes3 |= TDES3_FIRST_DESCRIPTOR;
else
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 323b59ec74a3..7546b3664113 100644
--- 

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

[Giuseppe CAVALLARO]

Hi Niklas

patch looks ok for me, Alex any feedback?

peppe

On 4/10/2017 8:33 PM, Niklas Cassel wrote:

From: Niklas Cassel 

Field FL/TPL in register TDES3 is not correctly set on GMAC4.
TX appears to be functional on GMAC 4.10a even if this field is not set,
however, to avoid relying on undefined behavior, set the length in TDES3.

The field has a different meaning depending on if the TSE bit in TDES3
is set or not (TSO). However, regardless of the TSE bit, the field is
not optional. The field is already set correctly when the TSE bit is set.

Since there is no limit for the number of descriptors that can be
used for a single packet, the field should be set to the sum of
the buffers contained in:
[ ...  ...
], which should be equal to skb->len.

Signed-off-by: Niklas Cassel 
---
  drivers/net/ethernet/stmicro/stmmac/chain_mode.c   | 6 +++---
  drivers/net/ethernet/stmicro/stmmac/common.h   | 2 +-
  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 3 ++-
  drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
  drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 2 +-
  drivers/net/ethernet/stmicro/stmmac/ring_mode.c| 9 ++---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 5 +++--
  7 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 37881f81319e..e93c40b4631e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -52,7 +52,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
tx_q->tx_skbuff_dma[entry].len = bmax;
/* do not close the descriptor and do not set own bit */
priv->hw->desc->prepare_tx_desc(desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
-   0, false);
+   0, false, skb->len);
  
  	while (len != 0) {

tx_q->tx_skbuff[entry] = NULL;
@@ -70,7 +70,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
tx_q->tx_skbuff_dma[entry].len = bmax;
priv->hw->desc->prepare_tx_desc(desc, 0, bmax, csum,
STMMAC_CHAIN_MODE, 1,
-   false);
+   false, skb->len);
len -= bmax;
i++;
} else {
@@ -85,7 +85,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
/* last descriptor can be set now */
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum,
STMMAC_CHAIN_MODE, 1,
-   true);
+   true, skb->len);
len = 0;
}
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 90d28bcad880..b7ce3fbb5375 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -373,7 +373,7 @@ struct stmmac_desc_ops {
/* Invoked by the xmit function to prepare the tx descriptor */
void (*prepare_tx_desc) (struct dma_desc *p, int is_fs, int len,
 bool csum_flag, int mode, bool tx_own,
-bool ls);
+bool ls, unsigned int tot_pkt_len);
void (*prepare_tso_tx_desc)(struct dma_desc *p, int is_fs, int len1,
int len2, bool tx_own, bool ls,
unsigned int tcphdrlen,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 843ec69222ea..aa6476439aee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -304,12 +304,13 @@ static void dwmac4_rd_init_tx_desc(struct dma_desc *p, 
int mode, int end)
  
  static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,

  bool csum_flag, int mode, bool tx_own,
- bool ls)
+ bool ls, unsigned int tot_pkt_len)
  {
unsigned int tdes3 = le32_to_cpu(p->des3);
  
  	p->des2 |= cpu_to_le32(len & TDES2_BUFFER1_SIZE_MASK);
  
+	tdes3 |= tot_pkt_len & TDES3_PACKET_SIZE_MASK;

if (is_fs)
tdes3 |= TDES3_FIRST_DESCRIPTOR;
else
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c 
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 323b59ec74a3..7546b3664113 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ 

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 11, 2017 at 07:15:42AM +0200, Greg KH wrote:
> On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig - I presume that an x86_64 allyesconfig will fail the
> > same way) failed like this:
> > 
> > drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function 
> > `.rtw_get_oper_ch':
> > (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> > drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined 
> > here
> > 
> > and many, many more ...
> > 
> > Presumably caused by commit
> > 
> >   554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> > 
> > I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> > point and modified (or they have the same ancestor) since they share a
> > large number of global symbols.
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 11 Apr 2017 14:53:55 +1000
> > Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  drivers/staging/rtl8723bs/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/staging/rtl8723bs/Kconfig 
> > b/drivers/staging/rtl8723bs/Kconfig
> > index 71450eee3b28..04706d3148d6 100644
> > --- a/drivers/staging/rtl8723bs/Kconfig
> > +++ b/drivers/staging/rtl8723bs/Kconfig
> > @@ -1,6 +1,7 @@
> >  config RTL8723BS
> > tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
> > depends on WLAN && MMC && CFG80211
> > +   depends on BROKEN
> > select WIRELESS_EXT
> > select WEXT_PRIV
> > ---help---
> 
> Yes, thanks, we are going to force this to be built as a module which
> should resolve the issues...

I should have this fixed now, sorry for taking so long.

greg k-h

Re: [PATCH 0/5] zram clean up

[Minchan Kim]

Hi Andrew,

Could you drop this patchset?

I will send updated version based on Sergey with some bug fixes.

zram-handle-multiple-pages-attached-bios-bvec.patch
zram-partial-io-refactoring.patch
zram-use-zram_slot_lock-instead-of-raw-bit_spin_lock-op.patch
zram-remove-zram_meta-structure.patch
zram-introduce-zram-data-accessor.patch

Thanks!

On Mon, Apr 03, 2017 at 02:17:28PM +0900, Minchan Kim wrote:
> This patchset aims zram clean-up.
> 
> [1] clean up multiple pages's bvec handling.
> [2] clean up partial IO handling
> [3-5] clean up zram via using accessor and removing pointless structure.
> 
> With [2-5] applied, we can get a few hundred bytes as well as huge
> readibility enhance.
> 
> This patchset is based on v4.11-rc4-mmotm-2017-03-30-16-31 and
> *drop* zram-factor-out-partial-io-routine.patch.
> 
> x86: 708 byte save
> 
> add/remove: 1/1 grow/shrink: 0/11 up/down: 478/-1186 (-708)
> function old new   delta
> zram_special_page_read - 478+478
> zram_reset_device317 314  -3
> mem_used_max_store   131 128  -3
> compact_store 96  93  -3
> mm_stat_show 203 197  -6
> zram_add 719 712  -7
> zram_slot_free_notify229 214 -15
> zram_make_request819 803 -16
> zram_meta_free   128 111 -17
> zram_free_page   180 151 -29
> disksize_store   432 361 -71
> zram_decompress_page.isra504   --504
> zram_bvec_rw25922080-512
> Total: Before=25350773, After=25350065, chg -0.00%
> 
> ppc64: 231 byte save
> 
> add/remove: 2/0 grow/shrink: 1/9 up/down: 681/-912 (-231)
> function old new   delta
> zram_special_page_read - 480+480
> zram_slot_lock - 200+200
> vermagic  39  40  +1
> mm_stat_show 256 248  -8
> zram_meta_free   200 184 -16
> zram_add 944 912 -32
> zram_free_page   348 308 -40
> disksize_store   572 492 -80
> zram_decompress_page 664 564-100
> zram_slot_free_notify292 160-132
> zram_make_request   11321000-132
> zram_bvec_rw27682396-372
> Total: Before=17565825, After=17565594, chg -0.00%
> 
> Minchan Kim (5):
>   [1] zram: handle multiple pages attached bio's bvec
>   [2] zram: partial IO refactoring
>   [3] zram: use zram_slot_lock instead of raw bit_spin_lock op
>   [4] zram: remove zram_meta structure
>   [5] zram: introduce zram data accessor
> 
>  drivers/block/zram/zram_drv.c | 532 
> +-
>  drivers/block/zram/zram_drv.h |   6 +-
>  2 files changed, 270 insertions(+), 268 deletions(-)
> 
> -- 
> 2.7.4
> 

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 11, 2017 at 07:15:42AM +0200, Greg KH wrote:
> On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig - I presume that an x86_64 allyesconfig will fail the
> > same way) failed like this:
> > 
> > drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function 
> > `.rtw_get_oper_ch':
> > (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> > drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined 
> > here
> > 
> > and many, many more ...
> > 
> > Presumably caused by commit
> > 
> >   554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> > 
> > I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> > point and modified (or they have the same ancestor) since they share a
> > large number of global symbols.
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 11 Apr 2017 14:53:55 +1000
> > Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  drivers/staging/rtl8723bs/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/staging/rtl8723bs/Kconfig 
> > b/drivers/staging/rtl8723bs/Kconfig
> > index 71450eee3b28..04706d3148d6 100644
> > --- a/drivers/staging/rtl8723bs/Kconfig
> > +++ b/drivers/staging/rtl8723bs/Kconfig
> > @@ -1,6 +1,7 @@
> >  config RTL8723BS
> > tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
> > depends on WLAN && MMC && CFG80211
> > +   depends on BROKEN
> > select WIRELESS_EXT
> > select WEXT_PRIV
> > ---help---
> 
> Yes, thanks, we are going to force this to be built as a module which
> should resolve the issues...

I should have this fixed now, sorry for taking so long.

greg k-h

Re: [PATCH 0/5] zram clean up

[Minchan Kim]

Hi Andrew,

Could you drop this patchset?

I will send updated version based on Sergey with some bug fixes.

zram-handle-multiple-pages-attached-bios-bvec.patch
zram-partial-io-refactoring.patch
zram-use-zram_slot_lock-instead-of-raw-bit_spin_lock-op.patch
zram-remove-zram_meta-structure.patch
zram-introduce-zram-data-accessor.patch

Thanks!

On Mon, Apr 03, 2017 at 02:17:28PM +0900, Minchan Kim wrote:
> This patchset aims zram clean-up.
> 
> [1] clean up multiple pages's bvec handling.
> [2] clean up partial IO handling
> [3-5] clean up zram via using accessor and removing pointless structure.
> 
> With [2-5] applied, we can get a few hundred bytes as well as huge
> readibility enhance.
> 
> This patchset is based on v4.11-rc4-mmotm-2017-03-30-16-31 and
> *drop* zram-factor-out-partial-io-routine.patch.
> 
> x86: 708 byte save
> 
> add/remove: 1/1 grow/shrink: 0/11 up/down: 478/-1186 (-708)
> function old new   delta
> zram_special_page_read - 478+478
> zram_reset_device317 314  -3
> mem_used_max_store   131 128  -3
> compact_store 96  93  -3
> mm_stat_show 203 197  -6
> zram_add 719 712  -7
> zram_slot_free_notify229 214 -15
> zram_make_request819 803 -16
> zram_meta_free   128 111 -17
> zram_free_page   180 151 -29
> disksize_store   432 361 -71
> zram_decompress_page.isra504   --504
> zram_bvec_rw25922080-512
> Total: Before=25350773, After=25350065, chg -0.00%
> 
> ppc64: 231 byte save
> 
> add/remove: 2/0 grow/shrink: 1/9 up/down: 681/-912 (-231)
> function old new   delta
> zram_special_page_read - 480+480
> zram_slot_lock - 200+200
> vermagic  39  40  +1
> mm_stat_show 256 248  -8
> zram_meta_free   200 184 -16
> zram_add 944 912 -32
> zram_free_page   348 308 -40
> disksize_store   572 492 -80
> zram_decompress_page 664 564-100
> zram_slot_free_notify292 160-132
> zram_make_request   11321000-132
> zram_bvec_rw27682396-372
> Total: Before=17565825, After=17565594, chg -0.00%
> 
> Minchan Kim (5):
>   [1] zram: handle multiple pages attached bio's bvec
>   [2] zram: partial IO refactoring
>   [3] zram: use zram_slot_lock instead of raw bit_spin_lock op
>   [4] zram: remove zram_meta structure
>   [5] zram: introduce zram data accessor
> 
>  drivers/block/zram/zram_drv.c | 532 
> +-
>  drivers/block/zram/zram_drv.h |   6 +-
>  2 files changed, 270 insertions(+), 268 deletions(-)
> 
> -- 
> 2.7.4
> 

6f58284e66: BUG: kernel hang in boot stage

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

commit 6f58284e666261162b2c95fdd8608f5e247e9a38
Merge: 7fd97bca bf74b20
Author: Stephen Rothwell <s...@canb.auug.org.au>
AuthorDate: Mon Apr 10 10:06:42 2017 +1000
Commit: Stephen Rothwell <s...@canb.auug.org.au>
CommitDate: Mon Apr 10 10:06:42 2017 +1000

Merge remote-tracking branch 'net-next/master'

7fd97bca68  Merge remote-tracking branch 'dlm/next'
bf74b20d00  Revert "rtnl: Add support for netdev event to link messages"
6f58284e66  Merge remote-tracking branch 'net-next/master'
f8c97bdb49  Add linux-next specific files for 20170410
+-++++---+
| | 7fd97bca68 | bf74b20d00 | 
6f58284e66 | next-20170410 |
+-++++---+
| boot_successes  | 42 | 38 | 0 
 | 0 |
| boot_failures   | 0  | 0  | 
17 | 17|
| BUG:kernel_hang_in_boot_stage   | 0  | 0  | 
17 | 11|
| BUG:kernel_reboot-without-warning_in_boot_stage | 0  | 0  | 0 
 | 6 |
+-++++---+

[0.00] ACPI: RSDP 0x000F6930 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x1FFE1936 30 (v01 BOCHS  BXPCRSDT 
0001 BXPC 0001)
[0.00] ACPI: FACP 0x1FFE180A 74 (v01 BOCHS  BXPCFACP 
0001 BXPC 0001)


  # HH:MM RESULT GOOD 
BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start f8c97bdb49832d2b0edaa0c05db873aa2f6101ff 
39da7c509acff13fc8cb12ec1bb20337c988ed36 --
git bisect  bad af6d4e29c13fd47ef3d1b4d96b7f781aa7534413  # 05:19  B  0 
3   14   0  Merge remote-tracking branch 'drm-panel/drm/panel/for-next'
git bisect good 8a41837405da3919179983b830eb648b65954797  # 05:40  G 13 
00   0  Merge remote-tracking branch 'xtensa/xtensa-for-next'
git bisect good 1635d3d77b290e99090a4e7f613009cc68531bb8  # 06:04  G 13 
00   0  Merge remote-tracking branch 'v4l-dvb/master'
git bisect  bad 89c15a058190c83af2d029fad4de33f542bcfb42  # 06:28  B  0 
2   13   0  Merge remote-tracking branch 'ipsec-next/master'
git bisect good 3d5657773c2ccdbeff13e2db374a1fd3b3e36722  # 07:06  G 12 
00   0  Merge remote-tracking branch 'thermal/next'
git bisect good 3700d2a55af503f43ae0e4595c92557bcb89046e  # 07:24  G 13 
00   0  Merge remote-tracking branch 'ieee1394/for-next'
git bisect good 7fd97bca680b4ceedebf194f8316ae6c2b60ce01  # 08:32  G 13 
00   0  Merge remote-tracking branch 'dlm/next'
git bisect  bad 6f58284e666261162b2c95fdd8608f5e247e9a38  # 08:55  B  0 
1   12   0  Merge remote-tracking branch 'net-next/master'
git bisect good 00ecfb3b34b69dd702dee1bd6de6fc100be384db  # 09:12  G 12 
00   0  netvsc: remove unnecessary lock on shutdown
git bisect good df1c631648c55bfb247339279f9bc573c7f283f4  # 09:54  G 12 
00   0  net: mpls: Limit memory allocation for mpls_route
git bisect good b404127879471c38ad13a246ce5dec156f60f828  # 10:14  G 12 
00   0  Merge branch '100GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect good 15ed8a47ff0571dd268e37002511993b47e996bd  # 10:34  G 12 
00   0  qede: Add support for ingress headroom
git bisect good e8c5f7231cc03153fee1b5fcb173585354c08ee8  # 10:53  G 12 
00   0  i40e: Swap use of pf->flags and pf->hw_disabled_flags for ATR 
Eviction
git bisect good 0c264588b5de50353e4a1ce0c2521576426dd89d  # 11:15  G 13 
00   0  liquidio: fix VF incorrectly indicating that it successfully set 
its VLAN
git bisect good ca9ec0888d631c446040a7fab9985afdeb4f73f3  # 11:39  G 13 
00   0  i40e/i40evf: Add support for padding start of frames
git bisect good 417d978fa532b61b89f0c3ccbd9cdb51090ea032  # 11:59  G 13 
00   0  Merge branch 'dsa-receive-path-simplifications'
git bisect good 0492b71c42f76b6019ef5fe686a7cb253dded09c  # 12:29  G 13 
00   0  Merge branch '40GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect good bf74b20d00b13919db7ae5d1015636e76f56f6ae  # 12:45  G 13 
00   0  Revert "rtnl: Add support for netdev event to link messages"
# first bad commit: [6f58284e666261162b2c95fdd8608f5e247e9a38] Merge 
remote-tracking branch 'net-next/master'
git bisect good 7fd97bca680b4ceedebf194f8316ae6c2b60ce01  # 12:50  G 38 
00   0  Merge

6f58284e66: BUG: kernel hang in boot stage

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

commit 6f58284e666261162b2c95fdd8608f5e247e9a38
Merge: 7fd97bca bf74b20
Author: Stephen Rothwell 
AuthorDate: Mon Apr 10 10:06:42 2017 +1000
Commit: Stephen Rothwell 
CommitDate: Mon Apr 10 10:06:42 2017 +1000

Merge remote-tracking branch 'net-next/master'

7fd97bca68  Merge remote-tracking branch 'dlm/next'
bf74b20d00  Revert "rtnl: Add support for netdev event to link messages"
6f58284e66  Merge remote-tracking branch 'net-next/master'
f8c97bdb49  Add linux-next specific files for 20170410
+-++++---+
| | 7fd97bca68 | bf74b20d00 | 
6f58284e66 | next-20170410 |
+-++++---+
| boot_successes  | 42 | 38 | 0 
 | 0 |
| boot_failures   | 0  | 0  | 
17 | 17|
| BUG:kernel_hang_in_boot_stage   | 0  | 0  | 
17 | 11|
| BUG:kernel_reboot-without-warning_in_boot_stage | 0  | 0  | 0 
 | 6 |
+-++++---+

[0.00] ACPI: RSDP 0x000F6930 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x1FFE1936 30 (v01 BOCHS  BXPCRSDT 
0001 BXPC 0001)
[0.00] ACPI: FACP 0x1FFE180A 74 (v01 BOCHS  BXPCFACP 
0001 BXPC 0001)


  # HH:MM RESULT GOOD 
BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start f8c97bdb49832d2b0edaa0c05db873aa2f6101ff 
39da7c509acff13fc8cb12ec1bb20337c988ed36 --
git bisect  bad af6d4e29c13fd47ef3d1b4d96b7f781aa7534413  # 05:19  B  0 
3   14   0  Merge remote-tracking branch 'drm-panel/drm/panel/for-next'
git bisect good 8a41837405da3919179983b830eb648b65954797  # 05:40  G 13 
00   0  Merge remote-tracking branch 'xtensa/xtensa-for-next'
git bisect good 1635d3d77b290e99090a4e7f613009cc68531bb8  # 06:04  G 13 
00   0  Merge remote-tracking branch 'v4l-dvb/master'
git bisect  bad 89c15a058190c83af2d029fad4de33f542bcfb42  # 06:28  B  0 
2   13   0  Merge remote-tracking branch 'ipsec-next/master'
git bisect good 3d5657773c2ccdbeff13e2db374a1fd3b3e36722  # 07:06  G 12 
00   0  Merge remote-tracking branch 'thermal/next'
git bisect good 3700d2a55af503f43ae0e4595c92557bcb89046e  # 07:24  G 13 
00   0  Merge remote-tracking branch 'ieee1394/for-next'
git bisect good 7fd97bca680b4ceedebf194f8316ae6c2b60ce01  # 08:32  G 13 
00   0  Merge remote-tracking branch 'dlm/next'
git bisect  bad 6f58284e666261162b2c95fdd8608f5e247e9a38  # 08:55  B  0 
1   12   0  Merge remote-tracking branch 'net-next/master'
git bisect good 00ecfb3b34b69dd702dee1bd6de6fc100be384db  # 09:12  G 12 
00   0  netvsc: remove unnecessary lock on shutdown
git bisect good df1c631648c55bfb247339279f9bc573c7f283f4  # 09:54  G 12 
00   0  net: mpls: Limit memory allocation for mpls_route
git bisect good b404127879471c38ad13a246ce5dec156f60f828  # 10:14  G 12 
00   0  Merge branch '100GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect good 15ed8a47ff0571dd268e37002511993b47e996bd  # 10:34  G 12 
00   0  qede: Add support for ingress headroom
git bisect good e8c5f7231cc03153fee1b5fcb173585354c08ee8  # 10:53  G 12 
00   0  i40e: Swap use of pf->flags and pf->hw_disabled_flags for ATR 
Eviction
git bisect good 0c264588b5de50353e4a1ce0c2521576426dd89d  # 11:15  G 13 
00   0  liquidio: fix VF incorrectly indicating that it successfully set 
its VLAN
git bisect good ca9ec0888d631c446040a7fab9985afdeb4f73f3  # 11:39  G 13 
00   0  i40e/i40evf: Add support for padding start of frames
git bisect good 417d978fa532b61b89f0c3ccbd9cdb51090ea032  # 11:59  G 13 
00   0  Merge branch 'dsa-receive-path-simplifications'
git bisect good 0492b71c42f76b6019ef5fe686a7cb253dded09c  # 12:29  G 13 
00   0  Merge branch '40GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect good bf74b20d00b13919db7ae5d1015636e76f56f6ae  # 12:45  G 13 
00   0  Revert "rtnl: Add support for netdev event to link messages"
# first bad commit: [6f58284e666261162b2c95fdd8608f5e247e9a38] Merge 
remote-tracking branch 'net-next/master'
git bisect good 7fd97bca680b4ceedebf194f8316ae6c2b60ce01  # 12:50  G 38 
00   0  Merge remote-tracking branch 

[PATCH v2 2/3] ARM: dts: imx6qdl.dtsi: add "fsl,imx6q-snvs-lpgpr" node

[Oleksij Rempel]

This node is for Low Power General Purpose Register which can
be used as Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Shawn Guo 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf6496117..8e90014705c3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -768,6 +768,12 @@
mask = <0x60>;
status = "disabled";
};
+
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;
+   };
};
 
epit1: epit@020d { /* EPIT1 */
-- 
2.11.0

[PATCH v2 2/3] ARM: dts: imx6qdl.dtsi: add "fsl,imx6q-snvs-lpgpr" node

[Oleksij Rempel]

This node is for Low Power General Purpose Register which can
be used as Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Shawn Guo 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf6496117..8e90014705c3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -768,6 +768,12 @@
mask = <0x60>;
status = "disabled";
};
+
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;
+   };
};
 
epit1: epit@020d { /* EPIT1 */
-- 
2.11.0

Re: [PATCH v4 5/7] dt-bindings: display/panel: Add common rotation property

[Laurent Pinchart]

Hi Noralf,

On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote:
> Display panels can be oriented many ways, especially in the embedded
> world. The rotation property is a way to describe this orientation.
> The counter clockwise direction is chosen because that's what fbdev
> and drm use.
> 
> Signed-off-by: Noralf Trønnes 
> Acked-by: Thierry Reding 
> ---
> 
> Changes since version 3:
> - Changed display/display.txt -> display/panel/panel.txt
> 
>  Documentation/devicetree/bindings/display/panel/panel.txt | 4 

We now have both Documentation/devicetree/bindings/display/panel/panel.txt and 
Documentation/devicetree/bindings/display/panel/panel-common.txt as they have 
been merged concurrently without being aware of each other. Would you mind if 
I moved this property to panel-common.txt ?

I would also like to document the property in a bit more details to avoid 
confusion about the rotation direction, as "display rotation" could be 
interpreted as the angle by which the display output has to be rotated to 
obtain an upside-up image. What would you think of the following, am I 
overdoing it, or is it even more confusing ?

- rotation: Panels are commonly mounted rotated, with their native orientation 
not aligned with the device's orientation. The rotation property specifies the 
angle in degrees between the panel's orientation and the device's orientation 
(corresponding to a counter-clockwise rotation of the panel). Valid values are 
0, 90, 180 and 270.


>  1 file changed, 4 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/panel/panel.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt
> b/Documentation/devicetree/bindings/display/panel/panel.txt new file mode
> 100644
> index 000..e2e6867
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel.txt
> @@ -0,0 +1,4 @@
> +Common display properties
> +-
> +
> +- rotation:  Display rotation in degrees counter clockwise (0,90,180,270)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 5/7] dt-bindings: display/panel: Add common rotation property

[Laurent Pinchart]

Hi Noralf,

On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote:
> Display panels can be oriented many ways, especially in the embedded
> world. The rotation property is a way to describe this orientation.
> The counter clockwise direction is chosen because that's what fbdev
> and drm use.
> 
> Signed-off-by: Noralf Trønnes 
> Acked-by: Thierry Reding 
> ---
> 
> Changes since version 3:
> - Changed display/display.txt -> display/panel/panel.txt
> 
>  Documentation/devicetree/bindings/display/panel/panel.txt | 4 

We now have both Documentation/devicetree/bindings/display/panel/panel.txt and 
Documentation/devicetree/bindings/display/panel/panel-common.txt as they have 
been merged concurrently without being aware of each other. Would you mind if 
I moved this property to panel-common.txt ?

I would also like to document the property in a bit more details to avoid 
confusion about the rotation direction, as "display rotation" could be 
interpreted as the angle by which the display output has to be rotated to 
obtain an upside-up image. What would you think of the following, am I 
overdoing it, or is it even more confusing ?

- rotation: Panels are commonly mounted rotated, with their native orientation 
not aligned with the device's orientation. The rotation property specifies the 
angle in degrees between the panel's orientation and the device's orientation 
(corresponding to a counter-clockwise rotation of the panel). Valid values are 
0, 90, 180 and 270.


>  1 file changed, 4 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/panel/panel.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt
> b/Documentation/devicetree/bindings/display/panel/panel.txt new file mode
> 100644
> index 000..e2e6867
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel.txt
> @@ -0,0 +1,4 @@
> +Common display properties
> +-
> +
> +- rotation:  Display rotation in degrees counter clockwise (0,90,180,270)

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

Sent out another patch to correct return value.

On Tue, Apr 11, 2017 at 10:25 AM, Dan Williams  wrote:
> On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar
>  wrote:
>> dax_dev_huge_fault returning without releasing lock. Making code change to 
>> avoid this situation
>>
>> Signed-off-by: Pushkar Jambhlekar 
>> ---
>>  drivers/dax/dax.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
>> index 0d1ca24..fd9c4db 100644
>> --- a/drivers/dax/dax.c
>> +++ b/drivers/dax/dax.c
>> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>> rc = __dax_dev_pud_fault(dax_dev, vmf);
>> break;
>> default:
>> -   return VM_FAULT_FALLBACK;
>> +   rc = VM_FAULT_FALLBACK;
>
> Thanks for the fix! Luckily we never take that branch, but we should
> fix it so we don't trip over it in some future where there are more
> fault sizes than pte, pmd, and pud. However, it should be setting rc
> to VM_FAULT_SIGBUS on an unknown / unsupported fault size.



-- 
Jambhlekar Pushkar Arun

[PATCH v2 1/3] nvmem: add snvs_lpgpr driver

[Oleksij Rempel]

This is a driver for Low Power General Purpose Register (LPGPR)
available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS)
of this chip.

It is a 32-bit read/write register located in the low power domain.
Since LPGPR is located in the battery-backed power domain, LPGPR can
be used by any application for retaining data during an SoC power-down
mode.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: linux-kernel@vger.kernel.org
---
 drivers/nvmem/Kconfig  |  13 +
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 132 +
 3 files changed, 147 insertions(+)
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 650f1b1797ad..52cdfd4275d7 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -133,4 +133,17 @@ config MESON_EFUSE
  This driver can also be built as a module. If so, the module
  will be called nvmem_meson_efuse.
 
+config NVMEM_SNVS_LPGPR
+   tristate "Support for Low Power General Purpose Register"
+   depends on HAS_IOMEM
+   depends on OF
+   select REGMAP_MMIO
+   select MFD_SYSCON
+   help
+ This is a driver for Low Power General Purpose Register (LPGPR) 
available on
+ i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-snvs-lpgpr.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 86e45995fdad..4ba7685e36ff 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -28,3 +28,5 @@ obj-$(CONFIG_NVMEM_VF610_OCOTP)   += nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
 nvmem_meson_efuse-y:= meson-efuse.o
+obj-$(CONFIG_NVMEM_SNVS_LPGPR) += nvmem_snvs_lpgpr.o
+nvmem_snvs_lpgpr-y := snvs_lpgpr.o
diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
new file mode 100644
index ..fea72b424426
--- /dev/null
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Steffen Trumtrar 
+ * Copyright (c) 2017 Pengutronix, Oleksij Rempel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct snvs_lpgpr_priv {
+   struct device_d *dev;
+   struct regmap   *regmap;
+   int offset;
+   struct nvmem_config cfg;
+};
+
+static int snvs_lpgpr_write(void *context, unsigned int offset, void *_val,
+   size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   const u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   regmap_write(priv->regmap, priv->offset + offset + (i++ * 4),
+*val++);
+
+   return 0;
+}
+
+static int snvs_lpgpr_read(void *context, unsigned int offset, void *_val,
+  size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   regmap_read(priv->regmap, priv->offset + offset + (i++ * 4),
+   val++);
+
+   return 0;
+}
+
+static int snvs_lpgpr_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *node = dev->of_node;
+   struct device_node *syscon_node;
+   struct snvs_lpgpr_priv *priv;
+   struct nvmem_config *cfg;
+   struct nvmem_device *nvmem;
+   int err;
+
+   if (!node)
+   return -ENOENT;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+syscon_node = of_get_parent(node);
+   if (!syscon_node)
+   return -ENODEV;
+
+   priv->regmap = syscon_node_to_regmap(syscon_node);
+   of_node_put(syscon_node);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+
+   err = of_property_read_u32(node, "offset", >offset);
+   if (err)
+   return err;
+
+   cfg = >cfg;
+   cfg->priv = priv;
+   cfg->name = dev_name(dev);
+   cfg->dev = dev;
+   cfg->stride = 4,
+   cfg->word_size = 4,
+   cfg->size = 4,
+   cfg->owner = THIS_MODULE,
+   cfg->reg_read  = snvs_lpgpr_read,
+   cfg->reg_write = snvs_lpgpr_write,
+
+   nvmem = nvmem_register(cfg);
+   if (IS_ERR(nvmem))
+ 

Re: [PATCH] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

Sent out another patch to correct return value.

On Tue, Apr 11, 2017 at 10:25 AM, Dan Williams  wrote:
> On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar
>  wrote:
>> dax_dev_huge_fault returning without releasing lock. Making code change to 
>> avoid this situation
>>
>> Signed-off-by: Pushkar Jambhlekar 
>> ---
>>  drivers/dax/dax.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
>> index 0d1ca24..fd9c4db 100644
>> --- a/drivers/dax/dax.c
>> +++ b/drivers/dax/dax.c
>> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>> rc = __dax_dev_pud_fault(dax_dev, vmf);
>> break;
>> default:
>> -   return VM_FAULT_FALLBACK;
>> +   rc = VM_FAULT_FALLBACK;
>
> Thanks for the fix! Luckily we never take that branch, but we should
> fix it so we don't trip over it in some future where there are more
> fault sizes than pte, pmd, and pud. However, it should be setting rc
> to VM_FAULT_SIGBUS on an unknown / unsupported fault size.



-- 
Jambhlekar Pushkar Arun

[PATCH v2 1/3] nvmem: add snvs_lpgpr driver

[Oleksij Rempel]

This is a driver for Low Power General Purpose Register (LPGPR)
available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS)
of this chip.

It is a 32-bit read/write register located in the low power domain.
Since LPGPR is located in the battery-backed power domain, LPGPR can
be used by any application for retaining data during an SoC power-down
mode.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: linux-kernel@vger.kernel.org
---
 drivers/nvmem/Kconfig  |  13 +
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 132 +
 3 files changed, 147 insertions(+)
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 650f1b1797ad..52cdfd4275d7 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -133,4 +133,17 @@ config MESON_EFUSE
  This driver can also be built as a module. If so, the module
  will be called nvmem_meson_efuse.
 
+config NVMEM_SNVS_LPGPR
+   tristate "Support for Low Power General Purpose Register"
+   depends on HAS_IOMEM
+   depends on OF
+   select REGMAP_MMIO
+   select MFD_SYSCON
+   help
+ This is a driver for Low Power General Purpose Register (LPGPR) 
available on
+ i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-snvs-lpgpr.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 86e45995fdad..4ba7685e36ff 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -28,3 +28,5 @@ obj-$(CONFIG_NVMEM_VF610_OCOTP)   += nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
 nvmem_meson_efuse-y:= meson-efuse.o
+obj-$(CONFIG_NVMEM_SNVS_LPGPR) += nvmem_snvs_lpgpr.o
+nvmem_snvs_lpgpr-y := snvs_lpgpr.o
diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
new file mode 100644
index ..fea72b424426
--- /dev/null
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Steffen Trumtrar 
+ * Copyright (c) 2017 Pengutronix, Oleksij Rempel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct snvs_lpgpr_priv {
+   struct device_d *dev;
+   struct regmap   *regmap;
+   int offset;
+   struct nvmem_config cfg;
+};
+
+static int snvs_lpgpr_write(void *context, unsigned int offset, void *_val,
+   size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   const u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   regmap_write(priv->regmap, priv->offset + offset + (i++ * 4),
+*val++);
+
+   return 0;
+}
+
+static int snvs_lpgpr_read(void *context, unsigned int offset, void *_val,
+  size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   regmap_read(priv->regmap, priv->offset + offset + (i++ * 4),
+   val++);
+
+   return 0;
+}
+
+static int snvs_lpgpr_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *node = dev->of_node;
+   struct device_node *syscon_node;
+   struct snvs_lpgpr_priv *priv;
+   struct nvmem_config *cfg;
+   struct nvmem_device *nvmem;
+   int err;
+
+   if (!node)
+   return -ENOENT;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+syscon_node = of_get_parent(node);
+   if (!syscon_node)
+   return -ENODEV;
+
+   priv->regmap = syscon_node_to_regmap(syscon_node);
+   of_node_put(syscon_node);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+
+   err = of_property_read_u32(node, "offset", >offset);
+   if (err)
+   return err;
+
+   cfg = >cfg;
+   cfg->priv = priv;
+   cfg->name = dev_name(dev);
+   cfg->dev = dev;
+   cfg->stride = 4,
+   cfg->word_size = 4,
+   cfg->size = 4,
+   cfg->owner = THIS_MODULE,
+   cfg->reg_read  = snvs_lpgpr_read,
+   cfg->reg_write = snvs_lpgpr_write,
+
+   nvmem = nvmem_register(cfg);
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static int snvs_lpgpr_remove(struct 

[PATCH v2 3/3] nvmem: dt: document SNVS LPGPR binding

[Oleksij Rempel]

Documentation bindings for the Low Power General Purpose Register
available on i.MX6 SoCs in the Secure Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt

diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt 
b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
new file mode 100644
index ..5399087a76d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -0,0 +1,15 @@
+Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D
+Secure Non-Volatile Storage.
+
+Required properties:
+- compatible: should be one of
+   "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
+- offset: Should contain the offset relative to syscon parent node.
+- regmap: Should contain a phandle pointing to syscon.
+
+Example:
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;
+   };
-- 
2.11.0

[PATCH 2/2] drivers/dax: Changing RC value

[Pushkar Jambhlekar]

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / 
unsupported fault size.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index fd9c4db..6156fdc 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   rc = VM_FAULT_FALLBACK;
+   rc = VM_FAULT_SIGBUS;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 2/2] drivers/dax: Changing RC value

[Pushkar Jambhlekar]

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / 
unsupported fault size.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index fd9c4db..6156fdc 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   rc = VM_FAULT_FALLBACK;
+   rc = VM_FAULT_SIGBUS;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH v2 3/3] nvmem: dt: document SNVS LPGPR binding

[Oleksij Rempel]

Documentation bindings for the Low Power General Purpose Register
available on i.MX6 SoCs in the Secure Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt

diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt 
b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
new file mode 100644
index ..5399087a76d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -0,0 +1,15 @@
+Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D
+Secure Non-Volatile Storage.
+
+Required properties:
+- compatible: should be one of
+   "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
+- offset: Should contain the offset relative to syscon parent node.
+- regmap: Should contain a phandle pointing to syscon.
+
+Example:
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;
+   };
-- 
2.11.0

[PATCH] mtd: nand: NULL terminate a of_device_id table

[Christophe JAILLET]

of_device_id tables should be NULL terminated.

Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/mtd/nand/atmel/nand-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
b/drivers/mtd/nand/atmel/nand-controller.c
index 27301603f394..af9dd0e04261 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1636,6 +1636,7 @@ static const struct of_device_id atmel_matrix_of_ids[] = {
.compatible = "atmel,at91sam9x5-matrix",
.data = (void *)AT91SAM9X5_MATRIX_EBICSA,
},
+   { /* sentinel */ },
 };
 
 static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
-- 
2.11.0

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH] mtd: nand: NULL terminate a of_device_id table

[Christophe JAILLET]

of_device_id tables should be NULL terminated.

Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/mtd/nand/atmel/nand-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
b/drivers/mtd/nand/atmel/nand-controller.c
index 27301603f394..af9dd0e04261 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1636,6 +1636,7 @@ static const struct of_device_id atmel_matrix_of_ids[] = {
.compatible = "atmel,at91sam9x5-matrix",
.data = (void *)AT91SAM9X5_MATRIX_EBICSA,
},
+   { /* sentinel */ },
 };
 
 static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
-- 
2.11.0

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 2/2] drivers/dax: Changing RC value

[Pushkar Jambhlekar]

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / 
unsupported fault size.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index fd9c4db..6156fdc 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   rc = VM_FAULT_FALLBACK;
+   rc = VM_FAULT_SIGBUS;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 2/2] drivers/dax: Changing RC value

[Pushkar Jambhlekar]

Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / 
unsupported fault size.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index fd9c4db..6156fdc 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   rc = VM_FAULT_FALLBACK;
+   rc = VM_FAULT_SIGBUS;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

Re: [PATCH v2] cfg80211: Fix array-bounds warning in fragment copy

[Johannes Berg]

On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote:
> Ping, any feedback on this patch?

You didn't cc linux-wireless, so it fell through the cracks ... I'll
try to remember it when I merge later.

johannes

Re: [PATCH v2] cfg80211: Fix array-bounds warning in fragment copy

[Johannes Berg]

On Mon, 2017-04-10 at 14:36 -0700, Matthias Kaehlcke wrote:
> Ping, any feedback on this patch?

You didn't cc linux-wireless, so it fell through the cracks ... I'll
try to remember it when I merge later.

johannes

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig - I presume that an x86_64 allyesconfig will fail the
> same way) failed like this:
> 
> drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function 
> `.rtw_get_oper_ch':
> (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined 
> here
> 
> and many, many more ...
> 
> Presumably caused by commit
> 
>   554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> 
> I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> point and modified (or they have the same ancestor) since they share a
> large number of global symbols.
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell 
> Date: Tue, 11 Apr 2017 14:53:55 +1000
> Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/staging/rtl8723bs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/rtl8723bs/Kconfig 
> b/drivers/staging/rtl8723bs/Kconfig
> index 71450eee3b28..04706d3148d6 100644
> --- a/drivers/staging/rtl8723bs/Kconfig
> +++ b/drivers/staging/rtl8723bs/Kconfig
> @@ -1,6 +1,7 @@
>  config RTL8723BS
>   tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
>   depends on WLAN && MMC && CFG80211
> + depends on BROKEN
>   select WIRELESS_EXT
>   select WEXT_PRIV
>   ---help---

Yes, thanks, we are going to force this to be built as a module which
should resolve the issues...

thanks,

greg k-h

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig - I presume that an x86_64 allyesconfig will fail the
> same way) failed like this:
> 
> drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function 
> `.rtw_get_oper_ch':
> (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined 
> here
> 
> and many, many more ...
> 
> Presumably caused by commit
> 
>   554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> 
> I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> point and modified (or they have the same ancestor) since they share a
> large number of global symbols.
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell 
> Date: Tue, 11 Apr 2017 14:53:55 +1000
> Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/staging/rtl8723bs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/rtl8723bs/Kconfig 
> b/drivers/staging/rtl8723bs/Kconfig
> index 71450eee3b28..04706d3148d6 100644
> --- a/drivers/staging/rtl8723bs/Kconfig
> +++ b/drivers/staging/rtl8723bs/Kconfig
> @@ -1,6 +1,7 @@
>  config RTL8723BS
>   tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
>   depends on WLAN && MMC && CFG80211
> + depends on BROKEN
>   select WIRELESS_EXT
>   select WEXT_PRIV
>   ---help---

Yes, thanks, we are going to force this to be built as a module which
should resolve the issues...

thanks,

greg k-h

Re: [For Linux v1 0/4] PV protocol headers for Linux Kernel

[Juergen Gross]

On 10/04/17 08:25, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Hi, all!
> 
> This patch series adds/updates para-virtual device
> protocols for Linux Kernel (headers):
>  o kbdif (updated/multitouch support added)
>  o sndif - sound (new)
>  o displif - display (new)
> 
> Changes since v0:
>  * removed editor blocks
>  * XENDISPL_EVENT_PAGE_SIZE -> XEN_PAGE_SIZE, not 4096
>  * removed Reviewed-by from Xen's review
> 
> Thank you,
> Oleksandr
> 
> Oleksandr Andrushchenko (4):
>   xen/kbdif: update protocol description
>   xen/kbdif: add multi-touch support
>   xen/sndif: add sound-device ABI
>   xen/displif: add ABI for para-virtual display
> 
>  include/xen/interface/io/displif.h | 854 
> +
>  include/xen/interface/io/kbdif.h   | 458 ++--
>  include/xen/interface/io/sndif.h   | 793 ++
>  3 files changed, 2078 insertions(+), 27 deletions(-)
>  create mode 100644 include/xen/interface/io/displif.h
>  create mode 100644 include/xen/interface/io/sndif.h
> 

One note regarding the tags (S-o-b, Acked-by, etc.): please add those in
their logical order in future. So an Acked-by should be below the
Signed-off-by. I've fixed that up for this series.

Series applied to xen/tip for-linus-4.12


Thanks,

Juergen

Re: [For Linux v1 0/4] PV protocol headers for Linux Kernel

[Juergen Gross]

On 10/04/17 08:25, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Hi, all!
> 
> This patch series adds/updates para-virtual device
> protocols for Linux Kernel (headers):
>  o kbdif (updated/multitouch support added)
>  o sndif - sound (new)
>  o displif - display (new)
> 
> Changes since v0:
>  * removed editor blocks
>  * XENDISPL_EVENT_PAGE_SIZE -> XEN_PAGE_SIZE, not 4096
>  * removed Reviewed-by from Xen's review
> 
> Thank you,
> Oleksandr
> 
> Oleksandr Andrushchenko (4):
>   xen/kbdif: update protocol description
>   xen/kbdif: add multi-touch support
>   xen/sndif: add sound-device ABI
>   xen/displif: add ABI for para-virtual display
> 
>  include/xen/interface/io/displif.h | 854 
> +
>  include/xen/interface/io/kbdif.h   | 458 ++--
>  include/xen/interface/io/sndif.h   | 793 ++
>  3 files changed, 2078 insertions(+), 27 deletions(-)
>  create mode 100644 include/xen/interface/io/displif.h
>  create mode 100644 include/xen/interface/io/sndif.h
> 

One note regarding the tags (S-o-b, Acked-by, etc.): please add those in
their logical order in future. So an Acked-by should be below the
Signed-off-by. I've fixed that up for this series.

Series applied to xen/tip for-linus-4.12


Thanks,

Juergen

Re: linux-next: manual merge of the crypto tree with the kbuild tree

[Herbert Xu]

On Tue, Apr 11, 2017 at 03:02:50PM +1000, Stephen Rothwell wrote:
>
> So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
> header but 128 in the kernel header?  In which case the kbuild patch
> needs to be changed not removed.  Or the merge resolution needs to be
> cleverer.

Actually the kbuild patch just needs to be reverted.  We should
not export CRYPTO_MAX_ALG_NAME at all.  Each user-space interface
that uses it already has its own limit and should not refer to the
in-kernel value.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the crypto tree with the kbuild tree

[Herbert Xu]

On Tue, Apr 11, 2017 at 03:02:50PM +1000, Stephen Rothwell wrote:
>
> So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
> header but 128 in the kernel header?  In which case the kbuild patch
> needs to be changed not removed.  Or the merge resolution needs to be
> cleverer.

Actually the kbuild patch just needs to be reverted.  We should
not export CRYPTO_MAX_ALG_NAME at all.  Each user-space interface
that uses it already has its own limit and should not refer to the
in-kernel value.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

[Juergen Gross]

On 30/03/17 22:06, Nicolai Stange wrote:
> In preparation for making the clockevents core NTP correction aware,
> all clockevent device drivers must set ->min_delta_ticks and
> ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
> clockevent device's rate is going to change dynamically and thus, the
> ratio of ns to ticks ceases to stay invariant.
> 
> Make the x86 arch's xen clockevent driver initialize these fields properly.
> 
> This patch alone doesn't introduce any change in functionality as the
> clockevents core still looks exclusively at the (untouched) ->min_delta_ns
> and ->max_delta_ns. As soon as this has changed, a followup patch will
> purge the initialization of ->min_delta_ns and ->max_delta_ns from this
> driver.
> 
> Signed-off-by: Nicolai Stange 

Applied to xen/tip for-linus-4.12


Thanks,

Juergen

Re: [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

[Juergen Gross]

On 30/03/17 22:06, Nicolai Stange wrote:
> In preparation for making the clockevents core NTP correction aware,
> all clockevent device drivers must set ->min_delta_ticks and
> ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
> clockevent device's rate is going to change dynamically and thus, the
> ratio of ns to ticks ceases to stay invariant.
> 
> Make the x86 arch's xen clockevent driver initialize these fields properly.
> 
> This patch alone doesn't introduce any change in functionality as the
> clockevents core still looks exclusively at the (untouched) ->min_delta_ns
> and ->max_delta_ns. As soon as this has changed, a followup patch will
> purge the initialization of ->min_delta_ns and ->max_delta_ns from this
> driver.
> 
> Signed-off-by: Nicolai Stange 

Applied to xen/tip for-linus-4.12


Thanks,

Juergen

Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support

[Archit Taneja]

Hi,

On 04/04/2017 12:27 AM, Laura Abbott wrote:

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.


We could get rid of the ION_FLAG_CACHED_NEEDS_SYNC flag in this patch
too.

Thanks,
Archit



Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 drivers/staging/android/ion/ion.c   | 40 -
 drivers/staging/android/ion/ion_carveout_heap.c |  6 
 drivers/staging/android/ion/ion_chunk_heap.c|  6 
 drivers/staging/android/ion/ion_page_pool.c |  3 --
 drivers/staging/android/ion/ion_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }

-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-  size_t size, enum dma_data_direction dir)
-{
-   struct scatterlist sg;
-
-   sg_init_table(, 1);
-   sg_set_page(, page, size, 0);
-   /*
-* This is not correct - sg_dma_address needs a dma_addr_t that is valid
-* for the targeted device, but this works on the currently targeted
-* hardware.
-*/
-   sg_dma_address() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);

-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_buffer *buffer;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   /* if this memory came from ion */
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not sync dmabuf from another exporter\n",
-  __func__);
-   dma_buf_put(dmabuf);
-   return -EINVAL;
-   }
-   buffer = dmabuf->priv;
-
-   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-   dma_buf_put(dmabuf);
-   return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
*buffer)

ion_heap_buffer_zero(buffer);

-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, 

Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support

[Archit Taneja]

Hi,

On 04/04/2017 12:27 AM, Laura Abbott wrote:

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.


We could get rid of the ION_FLAG_CACHED_NEEDS_SYNC flag in this patch
too.

Thanks,
Archit



Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 drivers/staging/android/ion/ion.c   | 40 -
 drivers/staging/android/ion/ion_carveout_heap.c |  6 
 drivers/staging/android/ion/ion_chunk_heap.c|  6 
 drivers/staging/android/ion/ion_page_pool.c |  3 --
 drivers/staging/android/ion/ion_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }

-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-  size_t size, enum dma_data_direction dir)
-{
-   struct scatterlist sg;
-
-   sg_init_table(, 1);
-   sg_set_page(, page, size, 0);
-   /*
-* This is not correct - sg_dma_address needs a dma_addr_t that is valid
-* for the targeted device, but this works on the currently targeted
-* hardware.
-*/
-   sg_dma_address() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);

-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_buffer *buffer;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   /* if this memory came from ion */
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not sync dmabuf from another exporter\n",
-  __func__);
-   dma_buf_put(dmabuf);
-   return -EINVAL;
-   }
-   buffer = dmabuf->priv;
-
-   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-   dma_buf_put(dmabuf);
-   return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
*buffer)

ion_heap_buffer_zero(buffer);

-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, table->sgl, 

[PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

[Ravi Bangoria]

If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel 
OOPS:

  [ 1275.165932] Bad kernel stack pointer cd93c840 at c0009868
  [ 1275.166378] Oops: Bad kernel stack pointer, sig: 6 [#1]
  ...
  GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840
  ...
  [ 1275.178305] NIP [c0009868] resume_kernel+0x2c/0x58
  [ 1275.178594] LR [c0006208] program_check_common+0x108/0x180

Basically, on 64 bit system, when user probes on 'stdu' instruction,
kernel does not emulate actual store in emulate_step itself because it
may corrupt exception frame. So kernel does actual store operation in
exception return code i.e. resume_kernel().

resume_kernel() loads the saved stack pointer from memory using lwz,
effectively loading a corrupt (32bit) address, causing the kernel crash.

Fix this by loading the 64bit value instead.

Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of 
emulate_step()") 
Signed-off-by: Ravi Bangoria 
Reviewed-by: Naveen N. Rao  
---
History:
  Commit 8e9f69371536 ("powerpc/kprobe: Don't emulate store when kprobe
  stwu r1") fixed exception frame corruption for 32 bit system which uses
  'stwu' instruction for stack frame allocation. This commit also added
  code for 64 bit system but did not enabled it for 'stdu' instruction.
  So 'stdu' instruction on 64 bit machine was emulating actual store in
  emulate_step() itself until...

  Commit be96f63375a1 ("powerpc: Split out instruction analysis part of
  emulate_step()"), enabled it for 'stdu' instruction on 64 bit machine.

  So kprobe on 'stdu' has always been broken on powerpc64.  We haven't
  noticed since most stdu operations were probably landing in the red
  zone so the exception frame never got corrupted. In that sense, this
  fix is needed for BE ever since load/store emulation was added.

  For LE, this is only getting exposed now due to my recent patch to
  enable load/store emulation on LE, which got merged as commit
  e148bd17f48b ("powerpc: Emulation support for load/store instructions
  on LE").

  Please mark this for stable as well.

Changes in v2:
  - Replace 'stwu' with 'stdu' in the comment.

 arch/powerpc/kernel/entry_64.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6432d4b..767ef6d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -689,7 +689,7 @@ resume_kernel:
 
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
 
-   lwz r3,GPR1(r1)
+   ld  r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception 
frame */
mr  r4,r1   /* src:  current exception frame */
mr  r1,r3   /* Reroute the trampoline frame to r1 */
@@ -703,8 +703,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
 
-   /* Do real store operation to complete stwu */
-   lwz r5,GPR1(r1)
+   /* Do real store operation to complete stdu */
+   ld  r5,GPR1(r1)
std r8,0(r5)
 
/* Clear _TIF_EMULATE_STACK_STORE flag */
-- 
1.9.3

[PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

[Ravi Bangoria]

If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel 
OOPS:

  [ 1275.165932] Bad kernel stack pointer cd93c840 at c0009868
  [ 1275.166378] Oops: Bad kernel stack pointer, sig: 6 [#1]
  ...
  GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840
  ...
  [ 1275.178305] NIP [c0009868] resume_kernel+0x2c/0x58
  [ 1275.178594] LR [c0006208] program_check_common+0x108/0x180

Basically, on 64 bit system, when user probes on 'stdu' instruction,
kernel does not emulate actual store in emulate_step itself because it
may corrupt exception frame. So kernel does actual store operation in
exception return code i.e. resume_kernel().

resume_kernel() loads the saved stack pointer from memory using lwz,
effectively loading a corrupt (32bit) address, causing the kernel crash.

Fix this by loading the 64bit value instead.

Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of 
emulate_step()") 
Signed-off-by: Ravi Bangoria 
Reviewed-by: Naveen N. Rao  
---
History:
  Commit 8e9f69371536 ("powerpc/kprobe: Don't emulate store when kprobe
  stwu r1") fixed exception frame corruption for 32 bit system which uses
  'stwu' instruction for stack frame allocation. This commit also added
  code for 64 bit system but did not enabled it for 'stdu' instruction.
  So 'stdu' instruction on 64 bit machine was emulating actual store in
  emulate_step() itself until...

  Commit be96f63375a1 ("powerpc: Split out instruction analysis part of
  emulate_step()"), enabled it for 'stdu' instruction on 64 bit machine.

  So kprobe on 'stdu' has always been broken on powerpc64.  We haven't
  noticed since most stdu operations were probably landing in the red
  zone so the exception frame never got corrupted. In that sense, this
  fix is needed for BE ever since load/store emulation was added.

  For LE, this is only getting exposed now due to my recent patch to
  enable load/store emulation on LE, which got merged as commit
  e148bd17f48b ("powerpc: Emulation support for load/store instructions
  on LE").

  Please mark this for stable as well.

Changes in v2:
  - Replace 'stwu' with 'stdu' in the comment.

 arch/powerpc/kernel/entry_64.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6432d4b..767ef6d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -689,7 +689,7 @@ resume_kernel:
 
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
 
-   lwz r3,GPR1(r1)
+   ld  r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception 
frame */
mr  r4,r1   /* src:  current exception frame */
mr  r1,r3   /* Reroute the trampoline frame to r1 */
@@ -703,8 +703,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
 
-   /* Do real store operation to complete stwu */
-   lwz r5,GPR1(r1)
+   /* Do real store operation to complete stdu */
+   ld  r5,GPR1(r1)
std r8,0(r5)
 
/* Clear _TIF_EMULATE_STACK_STORE flag */
-- 
1.9.3

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Guenter Roeck]

On 04/10/2017 09:48 PM, Greg Kroah-Hartman wrote:

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote:

On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.10.10 release.
There are 110 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 149 pass: 146 fail: 3
Failed builds:
arm:allmodconfig
arm:omap2plus_defconfig
arm:davinci_all_defconfig

Qemu test results:
total: 122 pass: 107 fail: 15
Failed tests:
arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi
arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
arm:midway:multi_v7_defconfig:ecx-2000
arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
arm:beagle:omap2plus_defconfig:omap3-beagle
arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
arm:overo:omap2plus_defconfig:omap3-overo-tobi

For arm, same problem as with v4.9.

Building arm:allmodconfig ... failed
--
Error log:
In file included from 
/opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:15:0:
/opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:536:49:
 error: 'rx51_ir_data' undeclared here (not in a function)
  OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),


Now dropped, thanks.


but also:

Building arm:davinci_all_defconfig ... failed
--
Error log:
/opt/buildbot/slave/stable-queue-4.10/build/drivers/usb/musb/da8xx.c:461:31: 
error: 'MUSB_PRESERVE_SESSION' undeclared here (not in a function)
  .quirks  = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
   ^
make[4]: *** [drivers/usb/musb/da8xx.o] Error 1

This is due to
8425a79bcbfe usb: musb: da8xx: Fix host mode suspend

which does not apply to 4.10 since MUSB_PRESERVE_SESSION is indeed not 
available in 4.10.
The flag was introduced with
a926ed11e7b4 usb: musb: Add a quirk to preserve the session during 
suspend

so it is either both patches or none of them.


I'll drop it as well.  Odd that this isn't showing up as a 4.9 build
error, it should, and I'll go drop it there too.



I don't build with -i, so maybe the build didn't get to that point.


Ugh, what a mess...


:-)



thanks for the help, much appreciated.



My pleasure. I'll let you know when I have new results.

Guenter

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Guenter Roeck]

On 04/10/2017 09:48 PM, Greg Kroah-Hartman wrote:

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote:

On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.10.10 release.
There are 110 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 149 pass: 146 fail: 3
Failed builds:
arm:allmodconfig
arm:omap2plus_defconfig
arm:davinci_all_defconfig

Qemu test results:
total: 122 pass: 107 fail: 15
Failed tests:
arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi
arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
arm:midway:multi_v7_defconfig:ecx-2000
arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
arm:beagle:omap2plus_defconfig:omap3-beagle
arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
arm:overo:omap2plus_defconfig:omap3-overo-tobi

For arm, same problem as with v4.9.

Building arm:allmodconfig ... failed
--
Error log:
In file included from 
/opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:15:0:
/opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:536:49:
 error: 'rx51_ir_data' undeclared here (not in a function)
  OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),


Now dropped, thanks.


but also:

Building arm:davinci_all_defconfig ... failed
--
Error log:
/opt/buildbot/slave/stable-queue-4.10/build/drivers/usb/musb/da8xx.c:461:31: 
error: 'MUSB_PRESERVE_SESSION' undeclared here (not in a function)
  .quirks  = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
   ^
make[4]: *** [drivers/usb/musb/da8xx.o] Error 1

This is due to
8425a79bcbfe usb: musb: da8xx: Fix host mode suspend

which does not apply to 4.10 since MUSB_PRESERVE_SESSION is indeed not 
available in 4.10.
The flag was introduced with
a926ed11e7b4 usb: musb: Add a quirk to preserve the session during 
suspend

so it is either both patches or none of them.


I'll drop it as well.  Odd that this isn't showing up as a 4.9 build
error, it should, and I'll go drop it there too.



I don't build with -i, so maybe the build didn't get to that point.


Ugh, what a mess...


:-)



thanks for the help, much appreciated.



My pleasure. I'll let you know when I have new results.

Guenter

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (powerpc
allyesconfig - I presume that an x86_64 allyesconfig will fail the
same way) failed like this:

drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch':
(.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined here

and many, many more ...

Presumably caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

I guess this driver was copied from drivers/staging/rtl8188eu/ at some
point and modified (or they have the same ancestor) since they share a
large number of global symbols.

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Tue, 11 Apr 2017 14:53:55 +1000
Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/rtl8723bs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8723bs/Kconfig 
b/drivers/staging/rtl8723bs/Kconfig
index 71450eee3b28..04706d3148d6 100644
--- a/drivers/staging/rtl8723bs/Kconfig
+++ b/drivers/staging/rtl8723bs/Kconfig
@@ -1,6 +1,7 @@
 config RTL8723BS
tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
depends on WLAN && MMC && CFG80211
+   depends on BROKEN
select WIRELESS_EXT
select WEXT_PRIV
---help---
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (powerpc
allyesconfig - I presume that an x86_64 allyesconfig will fail the
same way) failed like this:

drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch':
(.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined here

and many, many more ...

Presumably caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

I guess this driver was copied from drivers/staging/rtl8188eu/ at some
point and modified (or they have the same ancestor) since they share a
large number of global symbols.

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Tue, 11 Apr 2017 14:53:55 +1000
Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/rtl8723bs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8723bs/Kconfig 
b/drivers/staging/rtl8723bs/Kconfig
index 71450eee3b28..04706d3148d6 100644
--- a/drivers/staging/rtl8723bs/Kconfig
+++ b/drivers/staging/rtl8723bs/Kconfig
@@ -1,6 +1,7 @@
 config RTL8723BS
tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
depends on WLAN && MMC && CFG80211
+   depends on BROKEN
select WIRELESS_EXT
select WEXT_PRIV
---help---
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 06:40:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.22 release.
> There are 152 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.22-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

And I made a -rc2 here as well, due to the build issues:

kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.22-rc2.gz
or:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y

thanks,

greg k-h

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 06:40:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.22 release.
> There are 152 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.22-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

And I made a -rc2 here as well, due to the build issues:

kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.22-rc2.gz
or:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y

thanks,

greg k-h

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 06:41:51PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.10.10 release.
> There are 110 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.10.y
> and the diffstat can be found below.

Ok, that blew up into lots of tiny pieces :(

Let's try this again...

I've released a -rc2 now:

kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc2.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.10.y

Hopefully this should be a lot better, sorry about that.

greg k-h

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 06:41:51PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.10.10 release.
> There are 110 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.10.y
> and the diffstat can be found below.

Ok, that blew up into lots of tiny pieces :(

Let's try this again...

I've released a -rc2 now:

kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc2.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.10.y

Hopefully this should be a lot better, sorry about that.

greg k-h

Re: linux-next: manual merge of the crypto tree with the kbuild tree

[Stephen Rothwell]

Hi Herbert,

On Tue, 11 Apr 2017 10:42:15 +0800 Herbert Xu  
wrote:
>
> Actually the patch in the kbuild tree should be reverted because
> we have now increased the in-kernel length limit and this must not
> be directly exposed to user-space or it'll break compatibility.

So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
header but 128 in the kernel header?  In which case the kbuild patch
needs to be changed not removed.  Or the merge resolution needs to be
cleverer.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the crypto tree with the kbuild tree

[Stephen Rothwell]

Hi Herbert,

On Tue, 11 Apr 2017 10:42:15 +0800 Herbert Xu  
wrote:
>
> Actually the patch in the kbuild tree should be reverted because
> we have now increased the in-kernel length limit and this must not
> be directly exposed to user-space or it'll break compatibility.

So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
header but 128 in the kernel header?  In which case the kbuild patch
needs to be changed not removed.  Or the merge resolution needs to be
cleverer.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 02:39:37PM -0600, Shuah Khan wrote:
> On 04/10/2017 10:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.10 release.
> > There are 110 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 02:39:37PM -0600, Shuah Khan wrote:
> On 04/10/2017 10:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.10 release.
> > There are 110 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.10-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH] mm: Add additional consistency check

[Kees Cook]

On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko  wrote:
> On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
>> On Tue, 4 Apr 2017, Michal Hocko wrote:
>>
>> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
>> > > On Tue, 4 Apr 2017, Michal Hocko wrote:
>> > >
>> > > > Yes, but we do not have to blow the kernel, right? Why cannot we simply
>> > > > leak that memory?
>> > >
>> > > Because it is a serious bug to attempt to free a non slab object using
>> > > slab operations. This is often the result of memory corruption, coding
>> > > errs etc. The system needs to stop right there.
>> >
>> > Why when an alternative is a memory leak?
>>
>> Because the slab allocators fail also in case you free an object multiple
>> times etc etc. Continuation is supported by enabling a special resiliency
>> feature via the kernel command line. The alternative is selectable but not
>> the default.
>
> I disagree! We should try to continue as long as we _know_ that the
> internal state of the allocator is still consistent and a further
> operation will not spread the corruption even more. This is clearly not
> the case for an invalid pointer to kfree.
>
> I can see why checking for an early allocator corruption is not always
> feasible and you can only detect after-the-fact but this is not the case
> here and putting your system down just because some buggy code is trying
> to free something it hasn't allocated is not really useful. I completely
> agree with Linus that we overuse BUG way too much and this is just
> another example of it.

Instead of the proposed BUG here, what's the correct "safe" return value?

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] mm: Add additional consistency check

[Kees Cook]

On Tue, Apr 4, 2017 at 1:13 PM, Michal Hocko  wrote:
> On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
>> On Tue, 4 Apr 2017, Michal Hocko wrote:
>>
>> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
>> > > On Tue, 4 Apr 2017, Michal Hocko wrote:
>> > >
>> > > > Yes, but we do not have to blow the kernel, right? Why cannot we simply
>> > > > leak that memory?
>> > >
>> > > Because it is a serious bug to attempt to free a non slab object using
>> > > slab operations. This is often the result of memory corruption, coding
>> > > errs etc. The system needs to stop right there.
>> >
>> > Why when an alternative is a memory leak?
>>
>> Because the slab allocators fail also in case you free an object multiple
>> times etc etc. Continuation is supported by enabling a special resiliency
>> feature via the kernel command line. The alternative is selectable but not
>> the default.
>
> I disagree! We should try to continue as long as we _know_ that the
> internal state of the allocator is still consistent and a further
> operation will not spread the corruption even more. This is clearly not
> the case for an invalid pointer to kfree.
>
> I can see why checking for an early allocator corruption is not always
> feasible and you can only detect after-the-fact but this is not the case
> here and putting your system down just because some buggy code is trying
> to free something it hasn't allocated is not really useful. I completely
> agree with Linus that we overuse BUG way too much and this is just
> another example of it.

Instead of the proposed BUG here, what's the correct "safe" return value?

-Kees

-- 
Kees Cook
Pixel Security

[PATCH] drm: i915: Avoid format string expansion from engine names

[Kees Cook]

While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index f05971f5586f..be3550cec8e4 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -407,7 +407,7 @@ static void hangcheck_declare_hang(struct drm_i915_private 
*i915,
 "%s, ", engine->name);
msg[len-2] = '\0';
 
-   return i915_handle_error(i915, hung, msg);
+   return i915_handle_error(i915, hung, "%s", msg);
 }
 
 /*
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] drm: i915: Avoid format string expansion from engine names

[Kees Cook]

While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index f05971f5586f..be3550cec8e4 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -407,7 +407,7 @@ static void hangcheck_declare_hang(struct drm_i915_private 
*i915,
 "%s, ", engine->name);
msg[len-2] = '\0';
 
-   return i915_handle_error(i915, hung, msg);
+   return i915_handle_error(i915, hung, "%s", msg);
 }
 
 /*
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: [PATCH] drivers/dax: Avoiding potential deadlock

[Dan Williams]

On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar
 wrote:
> dax_dev_huge_fault returning without releasing lock. Making code change to 
> avoid this situation
>
> Signed-off-by: Pushkar Jambhlekar 
> ---
>  drivers/dax/dax.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
> index 0d1ca24..fd9c4db 100644
> --- a/drivers/dax/dax.c
> +++ b/drivers/dax/dax.c
> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
> rc = __dax_dev_pud_fault(dax_dev, vmf);
> break;
> default:
> -   return VM_FAULT_FALLBACK;
> +   rc = VM_FAULT_FALLBACK;

Thanks for the fix! Luckily we never take that branch, but we should
fix it so we don't trip over it in some future where there are more
fault sizes than pte, pmd, and pud. However, it should be setting rc
to VM_FAULT_SIGBUS on an unknown / unsupported fault size.

Re: [PATCH] drivers/dax: Avoiding potential deadlock

[Dan Williams]

On Mon, Apr 10, 2017 at 9:45 PM, Pushkar Jambhlekar
 wrote:
> dax_dev_huge_fault returning without releasing lock. Making code change to 
> avoid this situation
>
> Signed-off-by: Pushkar Jambhlekar 
> ---
>  drivers/dax/dax.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
> index 0d1ca24..fd9c4db 100644
> --- a/drivers/dax/dax.c
> +++ b/drivers/dax/dax.c
> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
> rc = __dax_dev_pud_fault(dax_dev, vmf);
> break;
> default:
> -   return VM_FAULT_FALLBACK;
> +   rc = VM_FAULT_FALLBACK;

Thanks for the fix! Luckily we never take that branch, but we should
fix it so we don't trip over it in some future where there are more
fault sizes than pte, pmd, and pud. However, it should be setting rc
to VM_FAULT_SIGBUS on an unknown / unsupported fault size.

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

[Kees Cook]

On Thu, Apr 6, 2017 at 7:25 AM, Tommi Rantala  wrote:
> On 06.04.2017 03:00, Kees Cook wrote:
>>
>> This changes the x86 exception for the low 1MB by reading back zeros for
>> RAM areas instead of blindly allowing them. (It may be possible for heap
>> to end up getting allocated in low 1MB RAM, and then read out, possibly
>> tripping hardened usercopy.)
>>
>> Unfinished: this still needs mmap support.
>>
>> Reported-by: Tommi Rantala 
>> Signed-off-by: Kees Cook 
>> ---
>> Tommi, can you check and see if this fixes what you're seeing? I want to
>> make sure this actually works first. (x86info uses seek/read not mmap.)
>
>
> Hi, I can confirm that it works (after adding CONFIG_STRICT_DEVMEM), no more
> kernel bugs when running x86info.

Great, thanks for testing!

Linus, given that this fixes the problem, are you okay with this patch
as at least the first step? It doesn't solve the mmap exposure case,
but I'm struggling to figure out how to construct zero-page holes in
the mmap vma, and strictly speaking hardened usercopy doesn't trip
over the mmap since it's not using copy_to_user...

-Kees

>
>
> open("/dev/mem", O_RDONLY)  = 3
> lseek(3, 1038, SEEK_SET)= 1038
> read(3, "\300\235", 2)  = 2
> lseek(3, 646144, SEEK_SET)  = 646144
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 1043, SEEK_SET)= 1043
> read(3, "w\2", 2)   = 2
> lseek(3, 645120, SEEK_SET)  = 645120
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 654336, SEEK_SET)  = 654336
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 983040, SEEK_SET)  = 983040
> read(3,
> "IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"...,
> 65536) = 65536
> lseek(3, 917504, SEEK_SET)  = 917504
> read(3,
> "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"...,
> 65536) = 65536
> lseek(3, 524288, SEEK_SET)  = 524288
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 65536) = 65536
> lseek(3, 589824, SEEK_SET)  = 589824
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 65536) = 65536
>
>
> dd works too:
>
> # LANG=C dd if=/dev/mem of=/dev/null bs=4096 count=256
> 256+0 records in
> 256+0 records out
> 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0874073 s, 12.0 MB/s
>
>
>
>> ---
>>
>>  arch/x86/mm/init.c | 41 +++
>>  drivers/char/mem.c | 82
>> ++
>>  2 files changed, 82 insertions(+), 41 deletions(-)



-- 
Kees Cook
Pixel Security

Re: [RFC][PATCH] mm: Tighten x86 /dev/mem with zeroing

[Kees Cook]

On Thu, Apr 6, 2017 at 7:25 AM, Tommi Rantala  wrote:
> On 06.04.2017 03:00, Kees Cook wrote:
>>
>> This changes the x86 exception for the low 1MB by reading back zeros for
>> RAM areas instead of blindly allowing them. (It may be possible for heap
>> to end up getting allocated in low 1MB RAM, and then read out, possibly
>> tripping hardened usercopy.)
>>
>> Unfinished: this still needs mmap support.
>>
>> Reported-by: Tommi Rantala 
>> Signed-off-by: Kees Cook 
>> ---
>> Tommi, can you check and see if this fixes what you're seeing? I want to
>> make sure this actually works first. (x86info uses seek/read not mmap.)
>
>
> Hi, I can confirm that it works (after adding CONFIG_STRICT_DEVMEM), no more
> kernel bugs when running x86info.

Great, thanks for testing!

Linus, given that this fixes the problem, are you okay with this patch
as at least the first step? It doesn't solve the mmap exposure case,
but I'm struggling to figure out how to construct zero-page holes in
the mmap vma, and strictly speaking hardened usercopy doesn't trip
over the mmap since it's not using copy_to_user...

-Kees

>
>
> open("/dev/mem", O_RDONLY)  = 3
> lseek(3, 1038, SEEK_SET)= 1038
> read(3, "\300\235", 2)  = 2
> lseek(3, 646144, SEEK_SET)  = 646144
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 1043, SEEK_SET)= 1043
> read(3, "w\2", 2)   = 2
> lseek(3, 645120, SEEK_SET)  = 645120
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 654336, SEEK_SET)  = 654336
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024)
> = 1024
> lseek(3, 983040, SEEK_SET)  = 983040
> read(3,
> "IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\\276\17\0"...,
> 65536) = 65536
> lseek(3, 917504, SEEK_SET)  = 917504
> read(3,
> "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"...,
> 65536) = 65536
> lseek(3, 524288, SEEK_SET)  = 524288
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 65536) = 65536
> lseek(3, 589824, SEEK_SET)  = 589824
> read(3,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 65536) = 65536
>
>
> dd works too:
>
> # LANG=C dd if=/dev/mem of=/dev/null bs=4096 count=256
> 256+0 records in
> 256+0 records out
> 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0874073 s, 12.0 MB/s
>
>
>
>> ---
>>
>>  arch/x86/mm/init.c | 41 +++
>>  drivers/char/mem.c | 82
>> ++
>>  2 files changed, 82 insertions(+), 41 deletions(-)



-- 
Kees Cook
Pixel Security

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.10 release.
> > There are 110 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 146 fail: 3
> Failed builds:
>   arm:allmodconfig
>   arm:omap2plus_defconfig
>   arm:davinci_all_defconfig
> 
> Qemu test results:
>   total: 122 pass: 107 fail: 15
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:midway:multi_v7_defconfig:ecx-2000
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>   arm:beagle:omap2plus_defconfig:omap3-beagle
>   arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
>   arm:overo:omap2plus_defconfig:omap3-overo-tobi
> 
> For arm, same problem as with v4.9.
> 
> Building arm:allmodconfig ... failed
> --
> Error log:
> In file included from 
> /opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:15:0:
> /opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:536:49:
>  error: 'rx51_ir_data' undeclared here (not in a function)
>   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),

Now dropped, thanks.

> but also:
> 
> Building arm:davinci_all_defconfig ... failed
> --
> Error log:
> /opt/buildbot/slave/stable-queue-4.10/build/drivers/usb/musb/da8xx.c:461:31: 
> error: 'MUSB_PRESERVE_SESSION' undeclared here (not in a function)
>   .quirks  = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
>^
> make[4]: *** [drivers/usb/musb/da8xx.o] Error 1
> 
> This is due to
>   8425a79bcbfe usb: musb: da8xx: Fix host mode suspend
> 
> which does not apply to 4.10 since MUSB_PRESERVE_SESSION is indeed not 
> available in 4.10.
> The flag was introduced with
>   a926ed11e7b4 usb: musb: Add a quirk to preserve the session during 
> suspend
> 
> so it is either both patches or none of them.

I'll drop it as well.  Odd that this isn't showing up as a 4.9 build
error, it should, and I'll go drop it there too.

Ugh, what a mess...

thanks for the help, much appreciated.

greg k-h

Re: [PATCH 4.10 000/110] 4.10.10-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 08:17:16PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.10 release.
> > There are 110 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:40 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 146 fail: 3
> Failed builds:
>   arm:allmodconfig
>   arm:omap2plus_defconfig
>   arm:davinci_all_defconfig
> 
> Qemu test results:
>   total: 122 pass: 107 fail: 15
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:midway:multi_v7_defconfig:ecx-2000
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>   arm:beagle:omap2plus_defconfig:omap3-beagle
>   arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
>   arm:overo:omap2plus_defconfig:omap3-overo-tobi
> 
> For arm, same problem as with v4.9.
> 
> Building arm:allmodconfig ... failed
> --
> Error log:
> In file included from 
> /opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:15:0:
> /opt/buildbot/slave/stable-queue-4.10/build/arch/arm/mach-omap2/pdata-quirks.c:536:49:
>  error: 'rx51_ir_data' undeclared here (not in a function)
>   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),

Now dropped, thanks.

> but also:
> 
> Building arm:davinci_all_defconfig ... failed
> --
> Error log:
> /opt/buildbot/slave/stable-queue-4.10/build/drivers/usb/musb/da8xx.c:461:31: 
> error: 'MUSB_PRESERVE_SESSION' undeclared here (not in a function)
>   .quirks  = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
>^
> make[4]: *** [drivers/usb/musb/da8xx.o] Error 1
> 
> This is due to
>   8425a79bcbfe usb: musb: da8xx: Fix host mode suspend
> 
> which does not apply to 4.10 since MUSB_PRESERVE_SESSION is indeed not 
> available in 4.10.
> The flag was introduced with
>   a926ed11e7b4 usb: musb: Add a quirk to preserve the session during 
> suspend
> 
> so it is either both patches or none of them.

I'll drop it as well.  Odd that this isn't showing up as a 4.9 build
error, it should, and I'll go drop it there too.

Ugh, what a mess...

thanks for the help, much appreciated.

greg k-h

[PATCH] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

[PATCH] drivers/dax: Avoiding potential deadlock

[Pushkar Jambhlekar]

dax_dev_huge_fault returning without releasing lock. Making code change to 
avoid this situation

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
rc = __dax_dev_pud_fault(dax_dev, vmf);
break;
default:
-   return VM_FAULT_FALLBACK;
+   rc = VM_FAULT_FALLBACK;
}
rcu_read_unlock();
 
-- 
2.7.4

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

[Kees Cook]

On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni  wrote:
> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler  
> wrote:
>> I think that would be the prudent approach. There is still
>> the possibility that blob sharing (or full stacking, if you
>> prefer) won't be accepted any time soon.
>
> Ok Casey! I will wait for more feedback, and if other maintainers do
> not object, I will convert it back to rhashtables in next iterations
> making sure that it should be simple to convert later to a blob
> sharing mechanism.

Would it be possible just to add a single field to task_struct if this
LSM is built in? I feel like rhashtables is a huge overhead when a
single field is all that's needed.

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

[Kees Cook]

On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni  wrote:
> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler  
> wrote:
>> I think that would be the prudent approach. There is still
>> the possibility that blob sharing (or full stacking, if you
>> prefer) won't be accepted any time soon.
>
> Ok Casey! I will wait for more feedback, and if other maintainers do
> not object, I will convert it back to rhashtables in next iterations
> making sure that it should be simple to convert later to a blob
> sharing mechanism.

Would it be possible just to add a single field to task_struct if this
LSM is built in? I feel like rhashtables is a huge overhead when a
single field is all that's needed.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 08:07:17PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.22 release.
> > There are 152 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 146 fail: 3
> Failed builds:
>   arm:allmodconfig
>   arm:omap2plus_defconfig
>   arm64:allmodconfig
> 
> Qemu test results:
>   total: 122 pass: 103 fail: 19
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:midway:multi_v7_defconfig:ecx-2000
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>   arm:beagle:omap2plus_defconfig:omap3-beagle
>   arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
>   arm:overo:omap2plus_defconfig:omap3-overo-tobi
>   arm64:virt:smp:defconfig
>   arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
>   arm64:virt:nosmp:defconfig
>   arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
> 
> As reported earlier, the arm64 builds fail with
> 
> Building arm64:virt:nosmp:defconfig ... failed
> 
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel 
> may be susceptible to erratum
> arch/arm64/kernel/pci.c: In function ‘pci_acpi_setup_ecam_mapping’:
> arch/arm64/kernel/pci.c:139:9: error: implicit declaration of function 
> ‘acpi_resource_consumer’
>   adev = acpi_resource_consumer();
> ...
> drivers/pci/host/pcie-hisi.c: In function ‘hisi_pcie_init’:
> drivers/pci/host/pcie-hisi.c:94:8: error: implicit declaration of function 
> ‘acpi_get_rc_resources’
> 
> ---
> 
> The arm builds fail as follows.
> 
> Building arm:overo:omap2plus_defconfig:omap3-overo-tobi ... failed
> 
> Error log:
> In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
> arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared 
> here (not in a function)
>   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),
>  ^
> ./include/linux/of_platform.h:52:21: note: in definition of macro 
> 'OF_DEV_AUXDATA'
> .platform_data = _pdata }
>  ^
> make[1]: *** [arch/arm/mach-omap2/pdata-quirks.o] Error 1
> 
> I am a bit lost here. Reverting
> 
> f2ea7a5c3730 rx51: broken build
> 
> fixes the problem, but is supposed to accomplish the opposite. You'll need to 
> drop
> that patch, or maybe even better drop
> 
> 375a81645446 ARM: OMAP2+: Fix init for multiple quirks for the same SoC
> 
> as well and let the authors [copied] sort this out.

Good idea, both now dropped, thanks.

greg k-h

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 08:07:17PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.22 release.
> > There are 152 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 146 fail: 3
> Failed builds:
>   arm:allmodconfig
>   arm:omap2plus_defconfig
>   arm64:allmodconfig
> 
> Qemu test results:
>   total: 122 pass: 103 fail: 19
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:midway:multi_v7_defconfig:ecx-2000
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>   arm:beagle:omap2plus_defconfig:omap3-beagle
>   arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
>   arm:overo:omap2plus_defconfig:omap3-overo-tobi
>   arm64:virt:smp:defconfig
>   arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
>   arm64:virt:nosmp:defconfig
>   arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
> 
> As reported earlier, the arm64 builds fail with
> 
> Building arm64:virt:nosmp:defconfig ... failed
> 
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel 
> may be susceptible to erratum
> arch/arm64/kernel/pci.c: In function ‘pci_acpi_setup_ecam_mapping’:
> arch/arm64/kernel/pci.c:139:9: error: implicit declaration of function 
> ‘acpi_resource_consumer’
>   adev = acpi_resource_consumer();
> ...
> drivers/pci/host/pcie-hisi.c: In function ‘hisi_pcie_init’:
> drivers/pci/host/pcie-hisi.c:94:8: error: implicit declaration of function 
> ‘acpi_get_rc_resources’
> 
> ---
> 
> The arm builds fail as follows.
> 
> Building arm:overo:omap2plus_defconfig:omap3-overo-tobi ... failed
> 
> Error log:
> In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
> arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared 
> here (not in a function)
>   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),
>  ^
> ./include/linux/of_platform.h:52:21: note: in definition of macro 
> 'OF_DEV_AUXDATA'
> .platform_data = _pdata }
>  ^
> make[1]: *** [arch/arm/mach-omap2/pdata-quirks.o] Error 1
> 
> I am a bit lost here. Reverting
> 
> f2ea7a5c3730 rx51: broken build
> 
> fixes the problem, but is supposed to accomplish the opposite. You'll need to 
> drop
> that patch, or maybe even better drop
> 
> 375a81645446 ARM: OMAP2+: Fix init for multiple quirks for the same SoC
> 
> as well and let the authors [copied] sort this out.

Good idea, both now dropped, thanks.

greg k-h

Re: [PATCH] pci/quirks: ITE 8893 needs quirk_use_pcie_bridge_dma_alias

[Alex Williamson]

On Mon, 10 Apr 2017 21:01:27 -0400
Jarod Wilson  wrote:

> This bridge has the same problems as the ITE 8892, which were resulting in
> crippling an older PCI 1Gbps NIC down to 45Mbps throughput with IOMMU and
> VT-d enabled. With the patch, this old e1000 goes back up to ~900Mbps.
> 
> Suggested-by: Alex Williamson 
> CC: linux-...@vger.kernel.org
> CC: Alex Williamson 
> CC: Bjorn Helgaas 
> Signed-off-by: Jarod Wilson 
> ---
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 9236e40ac055..c95fbf2431f8 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3914,6 +3914,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1080,
>  DECLARE_PCI_FIXUP_HEADER(0x10e3, 0x8113, quirk_use_pcie_bridge_dma_alias);
>  /* ITE 8892, https://bugzilla.kernel.org/show_bug.cgi?id=73551 */
>  DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892, quirk_use_pcie_bridge_dma_alias);
> +/* ITE 8893 has the same problem as the 8892 */
> +DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8893, quirk_use_pcie_bridge_dma_alias);
>  /* Intel 82801, https://bugzilla.kernel.org/show_bug.cgi?id=44881#c49 */
>  DECLARE_PCI_FIXUP_HEADER(0x8086, 0x244e, quirk_use_pcie_bridge_dma_alias);


Reviewed-by: Alex Williamson 

Re: [PATCH] pci/quirks: ITE 8893 needs quirk_use_pcie_bridge_dma_alias

[Alex Williamson]

On Mon, 10 Apr 2017 21:01:27 -0400
Jarod Wilson  wrote:

> This bridge has the same problems as the ITE 8892, which were resulting in
> crippling an older PCI 1Gbps NIC down to 45Mbps throughput with IOMMU and
> VT-d enabled. With the patch, this old e1000 goes back up to ~900Mbps.
> 
> Suggested-by: Alex Williamson 
> CC: linux-...@vger.kernel.org
> CC: Alex Williamson 
> CC: Bjorn Helgaas 
> Signed-off-by: Jarod Wilson 
> ---
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 9236e40ac055..c95fbf2431f8 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3914,6 +3914,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1080,
>  DECLARE_PCI_FIXUP_HEADER(0x10e3, 0x8113, quirk_use_pcie_bridge_dma_alias);
>  /* ITE 8892, https://bugzilla.kernel.org/show_bug.cgi?id=73551 */
>  DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892, quirk_use_pcie_bridge_dma_alias);
> +/* ITE 8893 has the same problem as the 8892 */
> +DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8893, quirk_use_pcie_bridge_dma_alias);
>  /* Intel 82801, https://bugzilla.kernel.org/show_bug.cgi?id=44881#c49 */
>  DECLARE_PCI_FIXUP_HEADER(0x8086, 0x244e, quirk_use_pcie_bridge_dma_alias);


Reviewed-by: Alex Williamson 

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Jon Masters]

On 04/06/2017 11:58 AM, Catalin Marinas wrote:

> The Cavium guys haven't shown any numbers (IIUC) to back the
> L1_CACHE_BYTES performance improvement but I would not revert the
> original commit since ARCH_DMA_MINALIGN definitely needs to cover the
> maximum available cache line size, which is 128 for them.

I am pinging them via other channels to ensure they've seen this.

Jon.

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Jon Masters]

On 04/06/2017 11:58 AM, Catalin Marinas wrote:

> The Cavium guys haven't shown any numbers (IIUC) to back the
> L1_CACHE_BYTES performance improvement but I would not revert the
> original commit since ARCH_DMA_MINALIGN definitely needs to cover the
> maximum available cache line size, which is 128 for them.

I am pinging them via other channels to ensure they've seen this.

Jon.

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 03:55:12PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.22 release.
> > There are 152 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Early feedback:
> 
> 
> Building arm64:allmodconfig ... failed
> --
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel 
> may be susceptible to erratum
> arch/arm64/Makefile:36: LSE atomics not supported by binutils
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c: In 
> function ‘pci_acpi_setup_ecam_mapping’:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c:139:9: 
> error: implicit declaration of function ‘acpi_resource_consumer’ 
> [-Werror=implicit-function-declaration]
>   adev = acpi_resource_consumer();
>  ^
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c:139:7: 
> warning: assignment makes pointer from integer without a cast 
> [-Wint-conversion]
>   adev = acpi_resource_consumer();
>^
> cc1: some warnings being treated as errors
> make[2]: *** [arch/arm64/kernel/pci.o] Error 1
> make[1]: *** [arch/arm64/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs
> /opt/buildbot/slave/stable-queue-4.9/build/drivers/pci/host/pcie-hisi.c: In 
> function ‘hisi_pcie_init’:
> /opt/buildbot/slave/stable-queue-4.9/build/drivers/pci/host/pcie-hisi.c:94:8: 
> error: implicit declaration of function ‘acpi_get_rc_resources’ 
> [-Werror=implicit-function-declaration]
>   ret = acpi_get_rc_resources(dev, "HISI0081", root->segment, res);
> ^
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/pci/host/pcie-hisi.o] Error 1
> 
> Culprits:
> 
> 166fba287313 PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller
> 575fdb4e21ec arm64: PCI: Search ACPI namespace to ensure ECAM space is 
> reserved
> 6fe2dc79c28d PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllers
> 
> You will also need
> 
> 00710984eac5 ACPI: Add acpi_resource_consumer() to find device that claims a 
> resource
> 169de969c018 PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform
> 
> to fix the errors.

No, that's a mess, I'm dropping those original patches, and others that
depended on them.  Thanks for letting me know.

greg k-h

Re: [PATCH 4.9 000/152] 4.9.22-stable review

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 03:55:12PM -0700, Guenter Roeck wrote:
> On 04/10/2017 09:40 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.22 release.
> > There are 152 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 12 16:41:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Early feedback:
> 
> 
> Building arm64:allmodconfig ... failed
> --
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel 
> may be susceptible to erratum
> arch/arm64/Makefile:36: LSE atomics not supported by binutils
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c: In 
> function ‘pci_acpi_setup_ecam_mapping’:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c:139:9: 
> error: implicit declaration of function ‘acpi_resource_consumer’ 
> [-Werror=implicit-function-declaration]
>   adev = acpi_resource_consumer();
>  ^
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kernel/pci.c:139:7: 
> warning: assignment makes pointer from integer without a cast 
> [-Wint-conversion]
>   adev = acpi_resource_consumer();
>^
> cc1: some warnings being treated as errors
> make[2]: *** [arch/arm64/kernel/pci.o] Error 1
> make[1]: *** [arch/arm64/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs
> /opt/buildbot/slave/stable-queue-4.9/build/drivers/pci/host/pcie-hisi.c: In 
> function ‘hisi_pcie_init’:
> /opt/buildbot/slave/stable-queue-4.9/build/drivers/pci/host/pcie-hisi.c:94:8: 
> error: implicit declaration of function ‘acpi_get_rc_resources’ 
> [-Werror=implicit-function-declaration]
>   ret = acpi_get_rc_resources(dev, "HISI0081", root->segment, res);
> ^
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/pci/host/pcie-hisi.o] Error 1
> 
> Culprits:
> 
> 166fba287313 PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller
> 575fdb4e21ec arm64: PCI: Search ACPI namespace to ensure ECAM space is 
> reserved
> 6fe2dc79c28d PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllers
> 
> You will also need
> 
> 00710984eac5 ACPI: Add acpi_resource_consumer() to find device that claims a 
> resource
> 169de969c018 PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform
> 
> to fix the errors.

No, that's a mess, I'm dropping those original patches, and others that
depended on them.  Thanks for letting me know.

greg k-h

Re: [PATCH] switchtec: Fix an error handling

[Logan Gunthorpe]

Nice catch. Thanks.

Reviewed-by: Logan Gunthorpe 

Logan

On 10/04/17 10:32 PM, Christophe JAILLET wrote:
> 'stuser_create' returns an error pointer in case of error, not NULL.
> So test its return value with IS_ERR.
> 
> Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver")
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/pci/switch/switchtec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index fcde98161d9a..cc6e085008fb 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -608,7 +608,7 @@ static int switchtec_dev_open(struct inode *inode, struct 
> file *filp)
>   stdev = container_of(inode->i_cdev, struct switchtec_dev, cdev);
>  
>   stuser = stuser_create(stdev);
> - if (!stuser)
> + if (IS_ERR(stuser))
>   return PTR_ERR(stuser);
>  
>   filp->private_data = stuser;
> 

Re: [PATCH] switchtec: Fix an error handling

[Logan Gunthorpe]

Nice catch. Thanks.

Reviewed-by: Logan Gunthorpe 

Logan

On 10/04/17 10:32 PM, Christophe JAILLET wrote:
> 'stuser_create' returns an error pointer in case of error, not NULL.
> So test its return value with IS_ERR.
> 
> Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver")
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/pci/switch/switchtec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index fcde98161d9a..cc6e085008fb 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -608,7 +608,7 @@ static int switchtec_dev_open(struct inode *inode, struct 
> file *filp)
>   stdev = container_of(inode->i_cdev, struct switchtec_dev, cdev);
>  
>   stuser = stuser_create(stdev);
> - if (!stuser)
> + if (IS_ERR(stuser))
>   return PTR_ERR(stuser);
>  
>   filp->private_data = stuser;
> 

Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding

[Oleksij Rempel]

Hi,

On 04/10/2017 08:22 PM, Rob Herring wrote:

On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote:

Documenation bindings for the Low Power General Purpose Registe


s/Registe/Register/


available on i.MX6 SoCs in the Secure Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt

diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt 
b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
new file mode 100644
index ..9a8be1a2d12e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -0,0 +1,15 @@
+Device tree bindings for Low Power General Purpose Registe found in i.MX6Q/D
+Secure Non-Volatile Storage.
+
+Required properties:
+- compatible: should be one of
+   "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
+- offset: Should contain the offset relative to syscon parrent node.


typo


ok.


 +- regmap: Should contain a phandle pointing to syscon.

+
+Example:
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;


Why does this need to be in DT? Is something going to refer to this
node? If not, the  node should be enough information for the OS.


Jes, it is refereed by other driver.

Thank you.

Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding

[Oleksij Rempel]

Hi,

On 04/10/2017 08:22 PM, Rob Herring wrote:

On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote:

Documenation bindings for the Low Power General Purpose Registe


s/Registe/Register/


available on i.MX6 SoCs in the Secure Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
Cc: Srinivas Kandagatla 
Cc: Maxime Ripard 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt

diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt 
b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
new file mode 100644
index ..9a8be1a2d12e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -0,0 +1,15 @@
+Device tree bindings for Low Power General Purpose Registe found in i.MX6Q/D
+Secure Non-Volatile Storage.
+
+Required properties:
+- compatible: should be one of
+   "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
+- offset: Should contain the offset relative to syscon parrent node.


typo


ok.


 +- regmap: Should contain a phandle pointing to syscon.

+
+Example:
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   regmap = <>;
+   offset = <0x68>;


Why does this need to be in DT? Is something going to refer to this
node? If not, the  node should be enough information for the OS.


Jes, it is refereed by other driver.

Thank you.

[PATCH] switchtec: Fix an error handling

[Christophe JAILLET]

'stuser_create' returns an error pointer in case of error, not NULL.
So test its return value with IS_ERR.

Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/pci/switch/switchtec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index fcde98161d9a..cc6e085008fb 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -608,7 +608,7 @@ static int switchtec_dev_open(struct inode *inode, struct 
file *filp)
stdev = container_of(inode->i_cdev, struct switchtec_dev, cdev);
 
stuser = stuser_create(stdev);
-   if (!stuser)
+   if (IS_ERR(stuser))
return PTR_ERR(stuser);
 
filp->private_data = stuser;
-- 
2.11.0

[PATCH] switchtec: Fix an error handling

[Christophe JAILLET]

'stuser_create' returns an error pointer in case of error, not NULL.
So test its return value with IS_ERR.

Fixes: 74004262f329 ("MicroSemi Switchtec management interface driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/pci/switch/switchtec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index fcde98161d9a..cc6e085008fb 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -608,7 +608,7 @@ static int switchtec_dev_open(struct inode *inode, struct 
file *filp)
stdev = container_of(inode->i_cdev, struct switchtec_dev, cdev);
 
stuser = stuser_create(stdev);
-   if (!stuser)
+   if (IS_ERR(stuser))
return PTR_ERR(stuser);
 
filp->private_data = stuser;
-- 
2.11.0

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Kees Cook]

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
> Hi List,
>
> This is RFC v2 of the Module auto-loading restriction feature. The
> module has been renamed ModAutoRestrict LSM.
>
> This RFC is a work in progress update.
>
> There are still minor things to fix which are listed in the TODO
> section. Also I used Tetsuo approach of stacking task->security, since
> now that the task_security_alloc() hook is in linux-security/next I took
> advantage of it and switched to use that hook and applied Tetsuo
> task->security per LSM blob on top of it. I can also switch to Casey
> approach. However, since these are internal implementation details which
> are not exposed, I do not think that this is a big issue. Thanks for the
> work now it is clear that we are able to easily stack new LSMs.
>
> Patches are against linux-security/next HEAD 622f6e3265707eb
>
> ==
>
> ModAutoRestrict is a Linux Security Module that applies restrictions on
> automatic module loading operations. This is selectable at build-time
> with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
> through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
> per-process setting via a prctl() interface.
>
> A userspace request to use a kernel feature that is implemented by modules
> that are not loaded may trigger the module auto-load feature to load
> these modules in order to satisfy userspace. However as today's Linux use
> cases cover embedded systems to containers where applications are running
> in their own separate environments, reducing or preventing operations
> that may affect external environments is an important constraint.
> Therefore, we need a way to control if automatic module loading is
> allowed or which applications are allowed to trigger the module
> auto-load feature.

It might be worth looking through the last several years of kernel
CVEs to find all the ones that would have been stopped with a feature
like this. There are many examples lately: both DCCP (CVE-2017-6074)
and n_hldc (CVE-2017-2636) come to mind this year alone.

> The ModAutoRestrict LSM allows system administrators or sandbox
> mechanisms to control the module auto-load feature and prevent loading
> unneeded modules or abuse the interface.
>
> The settings can be applied globally using a sysctl interface which
> completes the core kernel interface "modules_disable".

Typo: complements

Perhaps mention why this is a complement (i.e. modules_disable is ALL
modules, and modautorestrict is just auto-loaded, not explicitly
loaded).

>
> The feature is also available as a prctl() interface. This allows to
> apply restrictions when sandboxing processes. On embedded Linux systems,
> or containers where only some containers/processes should have the
> right privileges to load modules, this allows to restrict those
> processes from inserting modules. Only privileged processes can be
> allowed to perform so. A more restrictive access can be applied where
> the module autoload feature is completely disabled.
> In this schema the access rules are per-process and inherited by
> children created by fork(2) and clone(2), and preserved across execve(2).
>
> Interface:
>
> *) The per-process prctl() settings are:
>
>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>
>  Where value means:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - The current process must have CAP_SYS_MODULE to be able to
>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>  modules with a 'netdev-%s' alias.
>
>  2 - Current process can not auto-load modules. Once set, this prctl
>  value can not be changed.
>
>  The per-process value may only be increased, never decreased, thus ensuring
>  that once applied, processes can never relaxe their setting.

Typo: relax

> *) The global sysctl setting can be set by writting an integer value to
>'/proc/sys/kernel/modautorestrict/autoload'

I wonder if this should just be named
/proc/sys/kernel/modules_autoload (to look more like
modules_disabled)?

>  The valid values are:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>  alias.
>
>  2 - Processes can not auto-load modules. Once set, this sysctl value
>  can not be changed.
>
> *) Access rules:
>First the prctl() settings are checked, if the access is not denied
>then the global sysctl settings are checked.
>
> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>
>
> The sample code here can be used to test the feature:
> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>
> # TODO list:
> *) Confirm the struct task_struct->security stacking mechanism.

If we can't settle on a way to 

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Kees Cook]

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
> Hi List,
>
> This is RFC v2 of the Module auto-loading restriction feature. The
> module has been renamed ModAutoRestrict LSM.
>
> This RFC is a work in progress update.
>
> There are still minor things to fix which are listed in the TODO
> section. Also I used Tetsuo approach of stacking task->security, since
> now that the task_security_alloc() hook is in linux-security/next I took
> advantage of it and switched to use that hook and applied Tetsuo
> task->security per LSM blob on top of it. I can also switch to Casey
> approach. However, since these are internal implementation details which
> are not exposed, I do not think that this is a big issue. Thanks for the
> work now it is clear that we are able to easily stack new LSMs.
>
> Patches are against linux-security/next HEAD 622f6e3265707eb
>
> ==
>
> ModAutoRestrict is a Linux Security Module that applies restrictions on
> automatic module loading operations. This is selectable at build-time
> with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
> through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
> per-process setting via a prctl() interface.
>
> A userspace request to use a kernel feature that is implemented by modules
> that are not loaded may trigger the module auto-load feature to load
> these modules in order to satisfy userspace. However as today's Linux use
> cases cover embedded systems to containers where applications are running
> in their own separate environments, reducing or preventing operations
> that may affect external environments is an important constraint.
> Therefore, we need a way to control if automatic module loading is
> allowed or which applications are allowed to trigger the module
> auto-load feature.

It might be worth looking through the last several years of kernel
CVEs to find all the ones that would have been stopped with a feature
like this. There are many examples lately: both DCCP (CVE-2017-6074)
and n_hldc (CVE-2017-2636) come to mind this year alone.

> The ModAutoRestrict LSM allows system administrators or sandbox
> mechanisms to control the module auto-load feature and prevent loading
> unneeded modules or abuse the interface.
>
> The settings can be applied globally using a sysctl interface which
> completes the core kernel interface "modules_disable".

Typo: complements

Perhaps mention why this is a complement (i.e. modules_disable is ALL
modules, and modautorestrict is just auto-loaded, not explicitly
loaded).

>
> The feature is also available as a prctl() interface. This allows to
> apply restrictions when sandboxing processes. On embedded Linux systems,
> or containers where only some containers/processes should have the
> right privileges to load modules, this allows to restrict those
> processes from inserting modules. Only privileged processes can be
> allowed to perform so. A more restrictive access can be applied where
> the module autoload feature is completely disabled.
> In this schema the access rules are per-process and inherited by
> children created by fork(2) and clone(2), and preserved across execve(2).
>
> Interface:
>
> *) The per-process prctl() settings are:
>
>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>
>  Where value means:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - The current process must have CAP_SYS_MODULE to be able to
>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>  modules with a 'netdev-%s' alias.
>
>  2 - Current process can not auto-load modules. Once set, this prctl
>  value can not be changed.
>
>  The per-process value may only be increased, never decreased, thus ensuring
>  that once applied, processes can never relaxe their setting.

Typo: relax

> *) The global sysctl setting can be set by writting an integer value to
>'/proc/sys/kernel/modautorestrict/autoload'

I wonder if this should just be named
/proc/sys/kernel/modules_autoload (to look more like
modules_disabled)?

>  The valid values are:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>  alias.
>
>  2 - Processes can not auto-load modules. Once set, this sysctl value
>  can not be changed.
>
> *) Access rules:
>First the prctl() settings are checked, if the access is not denied
>then the global sysctl settings are checked.
>
> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>
>
> The sample code here can be used to test the feature:
> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>
> # TODO list:
> *) Confirm the struct task_struct->security stacking mechanism.

If we can't settle on a way to do this, perhaps 

Re: [PATCH] ibmveth: Support to enable LSO/CSO for Trunk VEA.

[Sivakumar Krishnasamy]

Re-sending as my earlier response had some HTML subparts.

Let me give some background before I answer your queries.

In IBM PowerVM environment, ibmveth driver supports largesend and 
checksum offload today, but only for virtual ethernet adapters (VEA) 
which are not configured in "Trunk mode".  In trunk mode, one cannot 
enable checksum and largesend offload capabilities. Without these 
offloads enabled, the performance numbers are not good. This patch is to 
enable these offloads for "Trunk" VEAs.


The following shows a typical configuration for network packet flow, 
when VMs in the PowerVM server have their network virtualized and 
communicate to external world.


VM (ibmveth) <=> PowerVM Hypervisor <=>  PowerVM I/O Server VM 
( ibmveth in "Trunk mode" <=> OVS <=> Physical NIC ) <=>  External Network


As you can see the packets originating in VM will travel through local 
ibmveth driver and then to PowerVM Hypervisor, then it gets delivered to 
ibmveth driver configured in "Trunk" mode in I/O Server, which is then 
bridged by OVS to external network via Physical NIC.  To have largesend 
and checksum offload enabled end to end, from VM up to Physical NIC, 
ibmveth needs to support these offload capabilities when configured in 
"Trunk" mode too.


Before this patch, when a VM communicates with external network (in a 
configuration similar to above), throughput numbers were not so good 
(~1.5 Gbps) and with the patch, I see ~9.4 Gbps throughput for a 10G NIC 
(iperf used for measurements).


On 4/9/2017 12:15 AM, David Miller wrote:

From: Sivakumar Krishnasamy 
Date: Fri,  7 Apr 2017 05:57:59 -0400


Enable largesend and checksum offload for ibmveth configured in trunk mode.
Added support to SKB frag_list in TX path by skb_linearize'ing such SKBs.

Signed-off-by: Sivakumar Krishnasamy 


Why is linearization necessary?

It would seem that the gains you get from GRO are nullified by
linearizing the SKB and thus copying all the data around and
allocating buffers.

When Physical NIC has GRO enabled and when OVS bridges these packets, 
OVS vport send code will end up calling dev_queue_xmit, which in turn 
calls validate_xmit_skb.


validate_xmit_skb has the below code snippet,

if (netif_needs_gso(skb, features)) {
struct sk_buff *segs;

segs = skb_gso_segment(skb, features); <=== Segments the 
GSO packet into MTU sized segments.


When the OVS outbound vport is ibmveth, netif_needs_gso returns 
positively if the SKB has a frag_list and if the driver doesn't support 
the same (NETIF_F_FRAGLIST feature).  So all the packets received by 
ibmveth are of MSS size (or lesser) due to the above code.


On a 10G physical NIC, the maximum throughput achieved was 2.2 Gbps due 
to the above segmentation in validate_xmit_skb. With the patch to 
linearize the SKB, the throughput increased to 9 Gbps (and ibmveth 
received packets without being segmented). This is ~4X improvement even 
though we end up allocating buffers and copying data.



Finally, all of that new checksumming stuff looks extremely
suspicious.  You have to explain why that is happening and why it
isn't because this driver is doing something incorrectly.

Thanks.

We are now enabling support for OVS and improving bridging performance 
in IBM's PowerVM environment, which brings in these new offload 
requirements for ibmveth driver configured in Trunk mode.


Please let me know if you need more details.

Regards,
Siva K

Re: [PATCH] ibmveth: Support to enable LSO/CSO for Trunk VEA.

[Sivakumar Krishnasamy]

Re-sending as my earlier response had some HTML subparts.

Let me give some background before I answer your queries.

In IBM PowerVM environment, ibmveth driver supports largesend and 
checksum offload today, but only for virtual ethernet adapters (VEA) 
which are not configured in "Trunk mode".  In trunk mode, one cannot 
enable checksum and largesend offload capabilities. Without these 
offloads enabled, the performance numbers are not good. This patch is to 
enable these offloads for "Trunk" VEAs.


The following shows a typical configuration for network packet flow, 
when VMs in the PowerVM server have their network virtualized and 
communicate to external world.


VM (ibmveth) <=> PowerVM Hypervisor <=>  PowerVM I/O Server VM 
( ibmveth in "Trunk mode" <=> OVS <=> Physical NIC ) <=>  External Network


As you can see the packets originating in VM will travel through local 
ibmveth driver and then to PowerVM Hypervisor, then it gets delivered to 
ibmveth driver configured in "Trunk" mode in I/O Server, which is then 
bridged by OVS to external network via Physical NIC.  To have largesend 
and checksum offload enabled end to end, from VM up to Physical NIC, 
ibmveth needs to support these offload capabilities when configured in 
"Trunk" mode too.


Before this patch, when a VM communicates with external network (in a 
configuration similar to above), throughput numbers were not so good 
(~1.5 Gbps) and with the patch, I see ~9.4 Gbps throughput for a 10G NIC 
(iperf used for measurements).


On 4/9/2017 12:15 AM, David Miller wrote:

From: Sivakumar Krishnasamy 
Date: Fri,  7 Apr 2017 05:57:59 -0400


Enable largesend and checksum offload for ibmveth configured in trunk mode.
Added support to SKB frag_list in TX path by skb_linearize'ing such SKBs.

Signed-off-by: Sivakumar Krishnasamy 


Why is linearization necessary?

It would seem that the gains you get from GRO are nullified by
linearizing the SKB and thus copying all the data around and
allocating buffers.

When Physical NIC has GRO enabled and when OVS bridges these packets, 
OVS vport send code will end up calling dev_queue_xmit, which in turn 
calls validate_xmit_skb.


validate_xmit_skb has the below code snippet,

if (netif_needs_gso(skb, features)) {
struct sk_buff *segs;

segs = skb_gso_segment(skb, features); <=== Segments the 
GSO packet into MTU sized segments.


When the OVS outbound vport is ibmveth, netif_needs_gso returns 
positively if the SKB has a frag_list and if the driver doesn't support 
the same (NETIF_F_FRAGLIST feature).  So all the packets received by 
ibmveth are of MSS size (or lesser) due to the above code.


On a 10G physical NIC, the maximum throughput achieved was 2.2 Gbps due 
to the above segmentation in validate_xmit_skb. With the patch to 
linearize the SKB, the throughput increased to 9 Gbps (and ibmveth 
received packets without being segmented). This is ~4X improvement even 
though we end up allocating buffers and copying data.



Finally, all of that new checksumming stuff looks extremely
suspicious.  You have to explain why that is happening and why it
isn't because this driver is doing something incorrectly.

Thanks.

We are now enabling support for OVS and improving bridging performance 
in IBM's PowerVM environment, which brings in these new offload 
requirements for ibmveth driver configured in Trunk mode.


Please let me know if you need more details.

Regards,
Siva K

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Tue, 2017-04-11 at 00:23 +0300, Michael S. Tsirkin wrote:
> On Sat, Apr 08, 2017 at 07:01:34AM +0200, Mike Galbraith wrote:
> > On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote:
> > 
> > > OK. test3 and test4 are now pushed: test3 should fix your hang,
> > > test4 is trying to fix a crash reported independently.
> > 
> > test3 does not fix the post hibernate hang business that I can easily
> > reproduce, those are NFS, and at least as old as 4.4.  Host/guest,
> > dunno, put 4.4 on both, guest hangs intermittently.
> 
> OK so IIUC you agree it's a good idea to send test4 to Linus, right?

Well, my box agrees that that is a viable option.

> Hybernation's still broken but that's not a regression.

Yup.

> > [] __rpc_wait_for_completion_task+0x30/0x30 [sunrpc]
> > [] rpc_wait_bit_killable+0x1e/0xb0 [sunrpc]
> > [] __rpc_wait_for_completion_task+0x30/0x30 [sunrpc]
> > [] autoremove_wake_function+0x50/0x50
> > [] call_decode+0x850/0x850 [sunrpc]
> > [] call_decode+0x850/0x850 [sunrpc]
> > [] __rpc_execute+0x14e/0x440 [sunrpc]
> > [] ktime_get+0x35/0xa0
> > [] rpc_run_task+0x120/0x170 [sunrpc]
> > [] nfs4_call_sync_sequence+0x56/0x80 [nfsv4]
> > [] _nfs4_proc_getattr+0xb0/0xc0 [nfsv4]
> > [] path_lookupat+0xd2/0x100
> > [] nfs4_proc_getattr+0x5c/0xe0 [nfsv4]
> > [] __nfs_revalidate_inode+0xa0/0x300 [nfs]
> > [] nfs_getattr+0x95/0x250 [nfs]
> > [] vfs_statx+0x7b/0xc0
> > [] SYSC_newstat+0x20/0x40
> > [] entry_SYSCALL_64_fastpath+0x1a/0xa9
> > [] 0x
> > 
> > I noted no _other_ misbehavior in either kernel, w/wo threadirqs.
> > 
> > > > -Mike
> 
> Interesting. I would guess virtio net does not complete some
> packets. So you were unable to find an old guest where this
> works fine?

I just tried my opensuse 13.2 clone.  It works markedly less fine,
turns into a brick either on the way down or back up in short order.

-Mike

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Tue, 2017-04-11 at 00:23 +0300, Michael S. Tsirkin wrote:
> On Sat, Apr 08, 2017 at 07:01:34AM +0200, Mike Galbraith wrote:
> > On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote:
> > 
> > > OK. test3 and test4 are now pushed: test3 should fix your hang,
> > > test4 is trying to fix a crash reported independently.
> > 
> > test3 does not fix the post hibernate hang business that I can easily
> > reproduce, those are NFS, and at least as old as 4.4.  Host/guest,
> > dunno, put 4.4 on both, guest hangs intermittently.
> 
> OK so IIUC you agree it's a good idea to send test4 to Linus, right?

Well, my box agrees that that is a viable option.

> Hybernation's still broken but that's not a regression.

Yup.

> > [] __rpc_wait_for_completion_task+0x30/0x30 [sunrpc]
> > [] rpc_wait_bit_killable+0x1e/0xb0 [sunrpc]
> > [] __rpc_wait_for_completion_task+0x30/0x30 [sunrpc]
> > [] autoremove_wake_function+0x50/0x50
> > [] call_decode+0x850/0x850 [sunrpc]
> > [] call_decode+0x850/0x850 [sunrpc]
> > [] __rpc_execute+0x14e/0x440 [sunrpc]
> > [] ktime_get+0x35/0xa0
> > [] rpc_run_task+0x120/0x170 [sunrpc]
> > [] nfs4_call_sync_sequence+0x56/0x80 [nfsv4]
> > [] _nfs4_proc_getattr+0xb0/0xc0 [nfsv4]
> > [] path_lookupat+0xd2/0x100
> > [] nfs4_proc_getattr+0x5c/0xe0 [nfsv4]
> > [] __nfs_revalidate_inode+0xa0/0x300 [nfs]
> > [] nfs_getattr+0x95/0x250 [nfs]
> > [] vfs_statx+0x7b/0xc0
> > [] SYSC_newstat+0x20/0x40
> > [] entry_SYSCALL_64_fastpath+0x1a/0xa9
> > [] 0x
> > 
> > I noted no _other_ misbehavior in either kernel, w/wo threadirqs.
> > 
> > > > -Mike
> 
> Interesting. I would guess virtio net does not complete some
> packets. So you were unable to find an old guest where this
> works fine?

I just tried my opensuse 13.2 clone.  It works markedly less fine,
turns into a brick either on the way down or back up in short order.

-Mike