Re: [PATCH] nvme-loop: add configfs dependency

[J Freyensee]

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote:
> On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote:
> > Thanks Arnd, applied.
> 
> Actually I think we should replace the select with the depends.  In
> fact I though I had done that a while ago, but I must have messed it
> up.
> 
> Btw - do you plan to grab patches directly from the list now or
> do you want me to queue them up?  There are a few more pending on
> the list that should go in:
> 
> http://lists.infradead.org/pipermail/linux-nvme/2016-June/005150.html
> (whole series)
> 
> http://lists.infradead.org/pipermail/linux-nvme/2016-July/005290.html
> (needs the attribution fixed to be from Ming)

I can re-send the patch changing "Fix by: " to "From: " if that helps.

Jay

Re: [PATCH] nvme-loop: add configfs dependency

[J Freyensee]

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote:
> On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote:
> > Thanks Arnd, applied.
> 
> Actually I think we should replace the select with the depends.  In
> fact I though I had done that a while ago, but I must have messed it
> up.
> 
> Btw - do you plan to grab patches directly from the list now or
> do you want me to queue them up?  There are a few more pending on
> the list that should go in:
> 
> http://lists.infradead.org/pipermail/linux-nvme/2016-June/005150.html
> (whole series)
> 
> http://lists.infradead.org/pipermail/linux-nvme/2016-July/005290.html
> (needs the attribution fixed to be from Ming)

I can re-send the patch changing "Fix by: " to "From: " if that helps.

Jay

[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency

[Javier Martinez Canillas]

Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.

But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
not correct since Kconfig expressions are not boolean but tristate. So it
will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
to 'm' if VIDEO_SAMSUNG_S5P_G2D=m.

This means that both the V4L2 and DRM drivers can be enabled if the former
is enabled as a module, which is not what we want.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/gpu/drm/exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d814b3048ee5..ec2dcc5e4962 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -119,7 +119,7 @@ config DRM_EXYNOS_ROTATOR
 
 config DRM_EXYNOS_GSC
bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
+   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.
 
-- 
2.5.5

[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency

[Javier Martinez Canillas]

Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.

But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
not correct since Kconfig expressions are not boolean but tristate. So it
will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
to 'm' if VIDEO_SAMSUNG_S5P_G2D=m.

This means that both the V4L2 and DRM drivers can be enabled if the former
is enabled as a module, which is not what we want.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/gpu/drm/exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d814b3048ee5..ec2dcc5e4962 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -119,7 +119,7 @@ config DRM_EXYNOS_ROTATOR
 
 config DRM_EXYNOS_GSC
bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
+   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.
 
-- 
2.5.5

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

[Stephen Warren]

On 07/11/2016 08:14 AM, Rob Herring wrote:

On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote:

On 07/07/2016 12:13 PM, Sivaram Nair wrote:

On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:

Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is designed for the processors to share resources and communicate
together. It provides a set of hardware synchronization primitives for
interprocessor communication. So the interprocessor communication (IPC)
protocols can use hardware synchronization primitive, when operating
between two processors not in an SMP relationship.



diff --git a/include/dt-bindings/mailbox/tegra186-hsp.h 
b/include/dt-bindings/mailbox/tegra186-hsp.h



+#define HSP_MBOX_TYPE_DB 0x0
+#define HSP_MBOX_TYPE_SM 0x1
+#define HSP_MBOX_TYPE_SS 0x2
+#define HSP_MBOX_TYPE_AS 0x3
+
+#define HSP_DB_MASTER_CCPLEX 17
+#define HSP_DB_MASTER_BPMP 19
+
+#define HSP_MBOX_ID(type, ID) \
+   (HSP_MBOX_TYPE_##type << 16 | ID)


It will be nicer if you avoid the macro glue magic '##' for 'type'. I
would also suggest to use braces around 'type' and 'ID'.


This technique been used without issue in quite a few other places without
issue, and has the benefit of simplifying the text wherever the macro is
used. What issue do you foresee?


I'm not a fan of using the macros to begin with and less so anything
more complex than a single constant value. I'd rather see 2 cells here
with the first being the id and the 2nd being the type.

An issue with token pasting is grepping for DB, SM, etc. in kernel tree
is probably noisy. Not such a big deal here, but a major PIA when you
have more complex sets of includes.


Is that a NAK or simply a suggestion? Having a single cell makes DT 
parsing a bit simpler, since pretty much every SW stack provides a 
default "one-cell" of_xlate implementation, whereas >1 cell means custom 
code for of_xlate.

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

[Stephen Warren]

On 07/11/2016 08:14 AM, Rob Herring wrote:

On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote:

On 07/07/2016 12:13 PM, Sivaram Nair wrote:

On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:

Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is designed for the processors to share resources and communicate
together. It provides a set of hardware synchronization primitives for
interprocessor communication. So the interprocessor communication (IPC)
protocols can use hardware synchronization primitive, when operating
between two processors not in an SMP relationship.



diff --git a/include/dt-bindings/mailbox/tegra186-hsp.h 
b/include/dt-bindings/mailbox/tegra186-hsp.h



+#define HSP_MBOX_TYPE_DB 0x0
+#define HSP_MBOX_TYPE_SM 0x1
+#define HSP_MBOX_TYPE_SS 0x2
+#define HSP_MBOX_TYPE_AS 0x3
+
+#define HSP_DB_MASTER_CCPLEX 17
+#define HSP_DB_MASTER_BPMP 19
+
+#define HSP_MBOX_ID(type, ID) \
+   (HSP_MBOX_TYPE_##type << 16 | ID)


It will be nicer if you avoid the macro glue magic '##' for 'type'. I
would also suggest to use braces around 'type' and 'ID'.


This technique been used without issue in quite a few other places without
issue, and has the benefit of simplifying the text wherever the macro is
used. What issue do you foresee?


I'm not a fan of using the macros to begin with and less so anything
more complex than a single constant value. I'd rather see 2 cells here
with the first being the id and the 2nd being the type.

An issue with token pasting is grepping for DB, SM, etc. in kernel tree
is probably noisy. Not such a big deal here, but a major PIA when you
have more complex sets of includes.


Is that a NAK or simply a suggestion? Having a single cell makes DT 
parsing a bit simpler, since pretty much every SW stack provides a 
default "one-cell" of_xlate implementation, whereas >1 cell means custom 
code for of_xlate.

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Coelho, Luciano]

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote:
> Didn't get any feedback or review comments on this patch.  Resending
> ...
> 
> P.

Sorry, this got flooded down my inbox.


> ---8<---
> 
> The iwlwifi driver implements a thermal zone and hwmon device, but
> returns -EIO on temperature reads if the firmware isn't loaded.  This
> results in the error
> 
> iwlwifi-virtual-0
> Adapter: Virtual device
> ERROR: Can't get value of subfeature temp1_input: I/O error
> temp1:N/A
> 
> being output when using sensors from the lm-sensors package.  Since
> the temperature cannot be read unless the ucode is loaded there is no
> reason to add the interface only to have it return an error 100% of
> the time.
> 
> This patch moves the firmware check to
> iwl_mvm_thermal_zone_register() and
> stops the thermal zone from being created if the ucode hasn't been
> loaded.
> 
> Signed-off-by: Prarit Bhargava 
> Cc: Johannes Berg 
> Cc: Emmanuel Grumbach 
> Cc: Luca Coelho 
> Cc: Intel Linux Wireless 
> Cc: Kalle Valo 
> Cc: Chaya Rachel Ivgi 
> Cc: Sara Sharon 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> ---

I have now sent it for review on our internal tree.

--
Luca.

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Coelho, Luciano]

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote:
> Didn't get any feedback or review comments on this patch.  Resending
> ...
> 
> P.

Sorry, this got flooded down my inbox.


> ---8<---
> 
> The iwlwifi driver implements a thermal zone and hwmon device, but
> returns -EIO on temperature reads if the firmware isn't loaded.  This
> results in the error
> 
> iwlwifi-virtual-0
> Adapter: Virtual device
> ERROR: Can't get value of subfeature temp1_input: I/O error
> temp1:N/A
> 
> being output when using sensors from the lm-sensors package.  Since
> the temperature cannot be read unless the ucode is loaded there is no
> reason to add the interface only to have it return an error 100% of
> the time.
> 
> This patch moves the firmware check to
> iwl_mvm_thermal_zone_register() and
> stops the thermal zone from being created if the ucode hasn't been
> loaded.
> 
> Signed-off-by: Prarit Bhargava 
> Cc: Johannes Berg 
> Cc: Emmanuel Grumbach 
> Cc: Luca Coelho 
> Cc: Intel Linux Wireless 
> Cc: Kalle Valo 
> Cc: Chaya Rachel Ivgi 
> Cc: Sara Sharon 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> ---

I have now sent it for review on our internal tree.

--
Luca.

Re: [PATCH 2/2] bus: mvebu-mbus: make mvebu_mbus_syscore_ops static

[Gregory CLEMENT]

Hi Ben,
 
 On mar., juin 21 2016, Arnd Bergmann  wrote:

> On Tuesday, June 21, 2016 4:16:19 PM CEST Ben Dooks wrote:
>> 
>> -struct syscore_ops mvebu_mbus_syscore_ops = {
>> +static struct syscore_ops mvebu_mbus_syscore_ops = {
>> .suspend= mvebu_mbus_suspend,
>> .resume = mvebu_mbus_resume,
>>  };
>> 
>
>
> Looks good, but I immediately thought it should be "const" as well.
> Unfortunately there is a list_head in them, so that isn't easy,
> but if anyone has an idea for how to make these all const, that
> would be nice.
>
> Anyway, that shouldn't stop your patch from getting merged, so
>
> Acked-by: Arnd Bergmann 
>
> (also for patch 1/2).

So I applied both patch in mvebu/cleanup

Thanks,

Gregory

>
>   Arnd

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH 2/2] bus: mvebu-mbus: make mvebu_mbus_syscore_ops static

[Gregory CLEMENT]

Hi Ben,
 
 On mar., juin 21 2016, Arnd Bergmann  wrote:

> On Tuesday, June 21, 2016 4:16:19 PM CEST Ben Dooks wrote:
>> 
>> -struct syscore_ops mvebu_mbus_syscore_ops = {
>> +static struct syscore_ops mvebu_mbus_syscore_ops = {
>> .suspend= mvebu_mbus_suspend,
>> .resume = mvebu_mbus_resume,
>>  };
>> 
>
>
> Looks good, but I immediately thought it should be "const" as well.
> Unfortunately there is a list_head in them, so that isn't easy,
> but if anyone has an idea for how to make these all const, that
> would be nice.
>
> Anyway, that shouldn't stop your patch from getting merged, so
>
> Acked-by: Arnd Bergmann 
>
> (also for patch 1/2).

So I applied both patch in mvebu/cleanup

Thanks,

Gregory

>
>   Arnd

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

[Stephen Warren]

On 07/11/2016 08:22 AM, Rob Herring wrote:

On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote:

The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the CPU
and BPMP.



diff --git 
a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt 
b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt



+NVIDIA Tegra Boot and Power Management Processor (BPMP)
+
+The BPMP is a specific processor in Tegra chip, which is designed for
+booting process handling and offloading the power management, clock
+management, and reset control tasks from the CPU. The binding document
+defines the resources that would be used by the BPMP firmware driver,
+which can create the interprocessor communication (IPC) between the CPU
+and BPMP.
+
+Required properties:
+- name : Should be bpmp
+- compatible
+Array of strings
+One of:
+- "nvidia,tegra186-bpmp"
+- mboxes : The phandle of mailbox controller and the mailbox specifier.
+- shmem : List of the phandle of the TX and RX shared memory area that
+ the IPC between CPU and BPMP is based on.


I think you can use memory-region here.


Isn't memory-region intended for references into the /reserved-memory 
node. If so, that isn't appropriate in this case since this property 
typically points at on-chip SRAM that isn't included in the OS's view of 
"system RAM".


Or, should /reserved-memory be used even for (e.g. non-DRAM) memory 
regions that aren't represented by the /memory/reg property?



diff --git a/include/dt-bindings/clock/tegra186-clock.h 
b/include/dt-bindings/clock/tegra186-clock.h



+/** @file */
+
+#ifndef _MACH_T186_CLK_T186_H
+#define _MACH_T186_CLK_T186_H
+
+/**
+ * @defgroup clock_ids Clock Identifiers


Aren't these doxygen markup? Does that work with docbook? If not,
remove.


These headers are part of the BPMP FW release. It's preferable not to 
edit them when incorporating them into the Linux kernel (or any other SW 
stack) to simplify integration of any updated versions of the header, by 
removing the need to edit the file when doing so. Given that, do you 
still object?

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

[Stephen Warren]

On 07/11/2016 08:22 AM, Rob Herring wrote:

On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote:

The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the CPU
and BPMP.



diff --git 
a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt 
b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt



+NVIDIA Tegra Boot and Power Management Processor (BPMP)
+
+The BPMP is a specific processor in Tegra chip, which is designed for
+booting process handling and offloading the power management, clock
+management, and reset control tasks from the CPU. The binding document
+defines the resources that would be used by the BPMP firmware driver,
+which can create the interprocessor communication (IPC) between the CPU
+and BPMP.
+
+Required properties:
+- name : Should be bpmp
+- compatible
+Array of strings
+One of:
+- "nvidia,tegra186-bpmp"
+- mboxes : The phandle of mailbox controller and the mailbox specifier.
+- shmem : List of the phandle of the TX and RX shared memory area that
+ the IPC between CPU and BPMP is based on.


I think you can use memory-region here.


Isn't memory-region intended for references into the /reserved-memory 
node. If so, that isn't appropriate in this case since this property 
typically points at on-chip SRAM that isn't included in the OS's view of 
"system RAM".


Or, should /reserved-memory be used even for (e.g. non-DRAM) memory 
regions that aren't represented by the /memory/reg property?



diff --git a/include/dt-bindings/clock/tegra186-clock.h 
b/include/dt-bindings/clock/tegra186-clock.h



+/** @file */
+
+#ifndef _MACH_T186_CLK_T186_H
+#define _MACH_T186_CLK_T186_H
+
+/**
+ * @defgroup clock_ids Clock Identifiers


Aren't these doxygen markup? Does that work with docbook? If not,
remove.


These headers are part of the BPMP FW release. It's preferable not to 
edit them when incorporating them into the Linux kernel (or any other SW 
stack) to simplify integration of any updated versions of the header, by 
removing the need to edit the file when doing so. Given that, do you 
still object?

Re: [PATCH] capabilities: audit capability use

[Topi Miettinen]

On 07/11/16 15:25, Serge E. Hallyn wrote:
> Quoting Topi Miettinen (toiwo...@gmail.com):
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, except blind trial and error.
>>
>> Currently, there is no way to know which capabilities are actually used.
>> Even the source code is only implicit, in-depth knowledge of each
>> capability must be used when analyzing a program to judge which
>> capabilities the program will exercise.
>>
>> Generate an audit message at system call exit, when capabilities are used.
>> This can then be used to configure capability sets for services by a
>> software developer, maintainer or system administrator.
>>
>> Test case demonstrating basic capability monitoring with the new
>> message types 1330 and 1331 and how the cgroups are displayed (boot to
>> rdshell):
> 
> Thanks, Topi, I'll find time this week to look this over in detail.
> 
> How much chattier does this make the syslog/journald during a regular
> boot?  I was thinking "this is audit, we can choose what messages
> will show up", but I guess that' sonly what auditd actually listens to,
> not what kernel emits?  (sorry i've not looked at audit in a long
> time).  Drat, that makes it seem like tracepoints would be better
> after all.  But let's see how much it addes to the noise.

For example "loadkeys" causes thousands of entries. :-( I'm checking how
to avoid audit message rate limiting, now some messages are lost.

It's still too easy to drown the logs with noise. That could be limited
a lot by emitting a message only when the capability is used for the
first time. But the question is how to define where to start counting
(fork, exec, and/or setpcap?). I'm also not sure if that is the right
way to log, since the first use of a capability could be expected and an
innocent one, but then the 100th one could be malicious.

It's also very complex and error-prone to collect a capability mask from
audit logs, which was my original goal.

-Topi

> 
>> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
>> Enter 'help' for a list of built-in commands.
>>
>> (initramfs) cd /sys/fs
>> (initramfs) mount -t cgroup2 cgroup cgroup
>> [   12.343152] audit_printk_skb: 5886 callbacks suppressed
>> [   12.355214] audit: type=1300 audit(1468234317.100:518): arch=c03e 
>> syscall=165 success=yes exit=0 a0=7fffe1e9ae2d a1=7fffe1e9ae34 
>> a2=7fffe1e9ae25 a3=8000 items=0 ppid=469 pid=470 auid=4294967295 uid=0 gid=0 
>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 
>> comm="mount" exe="/bin/mount" key=(null)
>> [   12.414853] audit: type=1327 audit(1468234317.100:518): 
>> proctitle=6D6F756E74002D74006367726F757032006367726F7570006367726F7570
>> [   12.438338] audit: type=1330 audit(1468234317.100:518): 
>> cap_used=0020
>> [   12.453893] audit: type=1331 audit(1468234317.100:518): cgroups=:/;
>> (initramfs) cd cgroup
>> (initramfs) mkdir test; cd test
>> [   17.335625] audit: type=1300 audit(1468234322.092:519): arch=c03e 
>> syscall=83 success=yes exit=0 a0=7ffddfd75e29 a1=1ff a2=0 a3=1e2 items=0 
>> ppid=469 pid=471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mkdir" exe="/bin/mkdir" 
>> key=(null)
>> [   17.392686] audit: type=1327 audit(1468234322.092:519): 
>> proctitle=6D6B6469720074657374
>> [   17.409404] audit: type=1330 audit(1468234322.092:519): 
>> cap_used=0002
>> [   17.425404] audit: type=1331 audit(1468234322.092:519): cgroups=:/;
>> (initramfs) echo $$ >cgroup.procs
>> (initramfs) mknod /dev/z_$$ c 1 2
>> [   28.385681] audit: type=1300 audit(1468234333.144:520): arch=c03e 
>> syscall=133 success=yes exit=0 a0=7ffe16324e11 a1=21b6 a2=102 a3=5c9 items=0 
>> ppid=469 pid=472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mknod" exe="/bin/mknod" 
>> key=(null)
>> [   28.443674] audit: type=1327 audit(1468234333.144:520): 
>> proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032
>> [   28.465888] audit: type=1330 audit(1468234333.144:520): 
>> cap_used=0800
>> [   28.482080] audit: type=1331 audit(1468234333.144:520): cgroups=:/test;
>> (initramfs) chown 1234 /dev/z_*
>> [   34.772992] audit: type=1300 audit(1468234339.532:521): arch=c03e 
>> syscall=92 success=yes exit=0 a0=7ffd0b563e17 a1=4d2 a2=0 a3=60a items=0 
>> ppid=469 pid=473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="chown" exe="/bin/chown" 
>> key=(null)
>> [   34.828569] audit: type=1327 audit(1468234339.532:521): 
>> proctitle=63686F776E0031323334002F6465762F7A5F343639
>> [   34.848747] audit: type=1330 audit(1468234339.532:521): 
>> cap_used=0001
>> [   34.864404] audit: type=1331 audit(1468234339.532:521): cgroups=:/test;
>>
>> Signed-off-by: Topi 

Re: [PATCH] capabilities: audit capability use

[Topi Miettinen]

On 07/11/16 15:25, Serge E. Hallyn wrote:
> Quoting Topi Miettinen (toiwo...@gmail.com):
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, except blind trial and error.
>>
>> Currently, there is no way to know which capabilities are actually used.
>> Even the source code is only implicit, in-depth knowledge of each
>> capability must be used when analyzing a program to judge which
>> capabilities the program will exercise.
>>
>> Generate an audit message at system call exit, when capabilities are used.
>> This can then be used to configure capability sets for services by a
>> software developer, maintainer or system administrator.
>>
>> Test case demonstrating basic capability monitoring with the new
>> message types 1330 and 1331 and how the cgroups are displayed (boot to
>> rdshell):
> 
> Thanks, Topi, I'll find time this week to look this over in detail.
> 
> How much chattier does this make the syslog/journald during a regular
> boot?  I was thinking "this is audit, we can choose what messages
> will show up", but I guess that' sonly what auditd actually listens to,
> not what kernel emits?  (sorry i've not looked at audit in a long
> time).  Drat, that makes it seem like tracepoints would be better
> after all.  But let's see how much it addes to the noise.

For example "loadkeys" causes thousands of entries. :-( I'm checking how
to avoid audit message rate limiting, now some messages are lost.

It's still too easy to drown the logs with noise. That could be limited
a lot by emitting a message only when the capability is used for the
first time. But the question is how to define where to start counting
(fork, exec, and/or setpcap?). I'm also not sure if that is the right
way to log, since the first use of a capability could be expected and an
innocent one, but then the 100th one could be malicious.

It's also very complex and error-prone to collect a capability mask from
audit logs, which was my original goal.

-Topi

> 
>> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
>> Enter 'help' for a list of built-in commands.
>>
>> (initramfs) cd /sys/fs
>> (initramfs) mount -t cgroup2 cgroup cgroup
>> [   12.343152] audit_printk_skb: 5886 callbacks suppressed
>> [   12.355214] audit: type=1300 audit(1468234317.100:518): arch=c03e 
>> syscall=165 success=yes exit=0 a0=7fffe1e9ae2d a1=7fffe1e9ae34 
>> a2=7fffe1e9ae25 a3=8000 items=0 ppid=469 pid=470 auid=4294967295 uid=0 gid=0 
>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 
>> comm="mount" exe="/bin/mount" key=(null)
>> [   12.414853] audit: type=1327 audit(1468234317.100:518): 
>> proctitle=6D6F756E74002D74006367726F757032006367726F7570006367726F7570
>> [   12.438338] audit: type=1330 audit(1468234317.100:518): 
>> cap_used=0020
>> [   12.453893] audit: type=1331 audit(1468234317.100:518): cgroups=:/;
>> (initramfs) cd cgroup
>> (initramfs) mkdir test; cd test
>> [   17.335625] audit: type=1300 audit(1468234322.092:519): arch=c03e 
>> syscall=83 success=yes exit=0 a0=7ffddfd75e29 a1=1ff a2=0 a3=1e2 items=0 
>> ppid=469 pid=471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mkdir" exe="/bin/mkdir" 
>> key=(null)
>> [   17.392686] audit: type=1327 audit(1468234322.092:519): 
>> proctitle=6D6B6469720074657374
>> [   17.409404] audit: type=1330 audit(1468234322.092:519): 
>> cap_used=0002
>> [   17.425404] audit: type=1331 audit(1468234322.092:519): cgroups=:/;
>> (initramfs) echo $$ >cgroup.procs
>> (initramfs) mknod /dev/z_$$ c 1 2
>> [   28.385681] audit: type=1300 audit(1468234333.144:520): arch=c03e 
>> syscall=133 success=yes exit=0 a0=7ffe16324e11 a1=21b6 a2=102 a3=5c9 items=0 
>> ppid=469 pid=472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mknod" exe="/bin/mknod" 
>> key=(null)
>> [   28.443674] audit: type=1327 audit(1468234333.144:520): 
>> proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032
>> [   28.465888] audit: type=1330 audit(1468234333.144:520): 
>> cap_used=0800
>> [   28.482080] audit: type=1331 audit(1468234333.144:520): cgroups=:/test;
>> (initramfs) chown 1234 /dev/z_*
>> [   34.772992] audit: type=1300 audit(1468234339.532:521): arch=c03e 
>> syscall=92 success=yes exit=0 a0=7ffd0b563e17 a1=4d2 a2=0 a3=60a items=0 
>> ppid=469 pid=473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="chown" exe="/bin/chown" 
>> key=(null)
>> [   34.828569] audit: type=1327 audit(1468234339.532:521): 
>> proctitle=63686F776E0031323334002F6465762F7A5F343639
>> [   34.848747] audit: type=1330 audit(1468234339.532:521): 
>> cap_used=0001
>> [   34.864404] audit: type=1331 audit(1468234339.532:521): cgroups=:/test;
>>
>> Signed-off-by: Topi 

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Paolo Bonzini]

On 11/07/2016 17:52, Radim Krčmář wrote:
> 2016-07-11 16:14+0200, Paolo Bonzini:
>> On 11/07/2016 15:48, Radim Krčmář wrote:
> I guess the easiest solution is to replace kvm_apic_id with a field in
> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>>
>>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
>>>  x2apic id.  xapic id cannot be greater than 255 and all of those are
>>>  covered by the initial value of max_id.)
>>
>> Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
>> in kvm_apic_id?
> 
> APIC ID is writeable in xAPIC mode, which would make the implementation
> weird without an extra variable.  Always read-only APIC ID would be
> best, IMO.

You can do

if (x2apic mode)
return lapic->vcpu->vcpu_id;
else
return get_reg(APIC_ID) >> 24;

The point is to avoid returning a shifted APIC_ID without shifting it.

The alternative of course is just caching it, which at this point is not
particularly harder...

Paolo

>>> (What makes a bit wary is that it doesn't avoid the same problem if we
>>>  changed KVM to reset apic id to xapic id first when disabling apic.)
>>
>> Yes, this is why I prefer it fixed once and for all in kvm_apic_id...
> 
> Seems most reasonable.  We'll need to be careful to have a correct value
> in the apic page, but there shouldn't be any races there.
> 
>>> Races in recalculation and APIC ID changes also lead to invalid physical
>>> maps, which haven't been taken care of properly ...
>>
>> Hmm, true, but can be fixed separately.  Probably the mutex should be
>> renamed so that it can be taken outside recalculate_apic_map...
> 
> Good point, it'll make reasoning easier and shouldn't introduce any
> extra scalability issues.

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Paolo Bonzini]

On 11/07/2016 17:52, Radim Krčmář wrote:
> 2016-07-11 16:14+0200, Paolo Bonzini:
>> On 11/07/2016 15:48, Radim Krčmář wrote:
> I guess the easiest solution is to replace kvm_apic_id with a field in
> struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>>>
>>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
>>>  x2apic id.  xapic id cannot be greater than 255 and all of those are
>>>  covered by the initial value of max_id.)
>>
>> Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
>> in kvm_apic_id?
> 
> APIC ID is writeable in xAPIC mode, which would make the implementation
> weird without an extra variable.  Always read-only APIC ID would be
> best, IMO.

You can do

if (x2apic mode)
return lapic->vcpu->vcpu_id;
else
return get_reg(APIC_ID) >> 24;

The point is to avoid returning a shifted APIC_ID without shifting it.

The alternative of course is just caching it, which at this point is not
particularly harder...

Paolo

>>> (What makes a bit wary is that it doesn't avoid the same problem if we
>>>  changed KVM to reset apic id to xapic id first when disabling apic.)
>>
>> Yes, this is why I prefer it fixed once and for all in kvm_apic_id...
> 
> Seems most reasonable.  We'll need to be careful to have a correct value
> in the apic page, but there shouldn't be any races there.
> 
>>> Races in recalculation and APIC ID changes also lead to invalid physical
>>> maps, which haven't been taken care of properly ...
>>
>> Hmm, true, but can be fixed separately.  Probably the mutex should be
>> renamed so that it can be taken outside recalculate_apic_map...
> 
> Good point, it'll make reasoning easier and shouldn't introduce any
> extra scalability issues.

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:
> +ifeq ($(CONFIG_SOC_NUC970),)
>  obj-y  := irq.o time.o mfp.o gpio.o clock.o
>  obj-y  += clksel.o dev.o cpu.o
> +endif
>  # W90X900 CPU support files

When mfp.o is disabled like this, I get a link error in two drivers
using the exported interface:

ERROR: "mfp_set_groupg" [drivers/spi/spi-nuc900.ko] undefined!
ERROR: "mfp_set_groupi" [drivers/input/keyboard/w90p910_keypad.ko] undefined!

Any idea for a better migration strategy?

Arnd

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:
> +ifeq ($(CONFIG_SOC_NUC970),)
>  obj-y  := irq.o time.o mfp.o gpio.o clock.o
>  obj-y  += clksel.o dev.o cpu.o
> +endif
>  # W90X900 CPU support files

When mfp.o is disabled like this, I get a link error in two drivers
using the exported interface:

ERROR: "mfp_set_groupg" [drivers/spi/spi-nuc900.ko] undefined!
ERROR: "mfp_set_groupi" [drivers/input/keyboard/w90p910_keypad.ko] undefined!

Any idea for a better migration strategy?

Arnd

Re: [patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

[Ralf Baechle]

Thank, looks ok.  I assume you want to merge this with the remainder of
of the series, so:

Acked-by: Ralf Baechle 

  Ralf

Re: [patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

[Ralf Baechle]

Thank, looks ok.  I assume you want to merge this with the remainder of
of the series, so:

Acked-by: Ralf Baechle 

  Ralf

Re: [PATCH 10/10] perf script python: Fix string vs byte array resolving

[Steven Rostedt]

On Sun, 10 Jul 2016 13:08:02 +0200
Jiri Olsa  wrote:

> Jirka reported that python code returns all arrays as strings.
> This makes impossible to get all items for byte array tracepoint
> field containing 0x00 value item.
> 
> Fixing this by scanning full length of the array and returning
> it as PyByteArray object in case non printable byte is found.
> 
> Cc: Steven Rostedt (Red Hat) 
> Reported-and-tested-by: Jiri Pirko 
> Link: http://lkml.kernel.org/n/tip-22f4vhhz5uytegkggy1on...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  .../util/scripting-engines/trace-event-python.c| 34 
> ++
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index ff134700bf30..75e9790ebb96 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -386,6 +386,16 @@ exit:
>   return pylist;
>  }
>  
> +static int is_printable_array(char *p, unsigned int len)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < len; i++)
> + if (!isprint(p[i]) && !isspace(p[i]))
> + return 0;

I believe this will return the wrong result if you pass in a string
that has '\0' in it. Try it out:

char a[] = "hello";

printf("a=%s is %d\n", a, is_printable_array(a, sizeof(a)));

and see what you get?

-- Steve

> +
> + return 1;
> +}
>  
>  static void python_process_tracepoint(struct perf_sample *sample,
> struct perf_evsel *evsel,
> @@ -457,14 +467,26 @@ static void python_process_tracepoint(struct 
> perf_sample *sample,
>   pydict_set_item_string_decref(dict, "common_callchain", 
> callchain);
>   }
>   for (field = event->format.fields; field; field = field->next) {
> - if (field->flags & FIELD_IS_STRING) {
> - int offset;
> + unsigned int offset, len;
> + unsigned long long val;
> +
> + if (field->flags & FIELD_IS_ARRAY) {
> + offset = field->offset;
> + len= field->size;
>   if (field->flags & FIELD_IS_DYNAMIC) {
> - offset = *(int *)(data + field->offset);
> + val = 
> pevent_read_number(scripting_context->pevent,
> +  data + offset, 
> len);
> + offset  = val;
> + len = offset >> 16;
>   offset &= 0x;
> - } else
> - offset = field->offset;
> - obj = PyString_FromString((char *)data + offset);
> + }
> + if (field->flags & FIELD_IS_STRING &&
> + is_printable_array(data + offset, len)) {
> + obj = PyString_FromString((char *) data + 
> offset);
> + } else {
> + obj = PyByteArray_FromStringAndSize((const char 
> *) data + offset, len);
> + field->flags &= ~FIELD_IS_STRING;
> + }
>   } else { /* FIELD_IS_NUMERIC */
>   obj = get_field_numeric_entry(event, field, data);
>   }

Re: [PATCH 10/10] perf script python: Fix string vs byte array resolving

[Steven Rostedt]

On Sun, 10 Jul 2016 13:08:02 +0200
Jiri Olsa  wrote:

> Jirka reported that python code returns all arrays as strings.
> This makes impossible to get all items for byte array tracepoint
> field containing 0x00 value item.
> 
> Fixing this by scanning full length of the array and returning
> it as PyByteArray object in case non printable byte is found.
> 
> Cc: Steven Rostedt (Red Hat) 
> Reported-and-tested-by: Jiri Pirko 
> Link: http://lkml.kernel.org/n/tip-22f4vhhz5uytegkggy1on...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  .../util/scripting-engines/trace-event-python.c| 34 
> ++
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index ff134700bf30..75e9790ebb96 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -386,6 +386,16 @@ exit:
>   return pylist;
>  }
>  
> +static int is_printable_array(char *p, unsigned int len)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < len; i++)
> + if (!isprint(p[i]) && !isspace(p[i]))
> + return 0;

I believe this will return the wrong result if you pass in a string
that has '\0' in it. Try it out:

char a[] = "hello";

printf("a=%s is %d\n", a, is_printable_array(a, sizeof(a)));

and see what you get?

-- Steve

> +
> + return 1;
> +}
>  
>  static void python_process_tracepoint(struct perf_sample *sample,
> struct perf_evsel *evsel,
> @@ -457,14 +467,26 @@ static void python_process_tracepoint(struct 
> perf_sample *sample,
>   pydict_set_item_string_decref(dict, "common_callchain", 
> callchain);
>   }
>   for (field = event->format.fields; field; field = field->next) {
> - if (field->flags & FIELD_IS_STRING) {
> - int offset;
> + unsigned int offset, len;
> + unsigned long long val;
> +
> + if (field->flags & FIELD_IS_ARRAY) {
> + offset = field->offset;
> + len= field->size;
>   if (field->flags & FIELD_IS_DYNAMIC) {
> - offset = *(int *)(data + field->offset);
> + val = 
> pevent_read_number(scripting_context->pevent,
> +  data + offset, 
> len);
> + offset  = val;
> + len = offset >> 16;
>   offset &= 0x;
> - } else
> - offset = field->offset;
> - obj = PyString_FromString((char *)data + offset);
> + }
> + if (field->flags & FIELD_IS_STRING &&
> + is_printable_array(data + offset, len)) {
> + obj = PyString_FromString((char *) data + 
> offset);
> + } else {
> + obj = PyByteArray_FromStringAndSize((const char 
> *) data + offset, len);
> + field->flags &= ~FIELD_IS_STRING;
> + }
>   } else { /* FIELD_IS_NUMERIC */
>   obj = get_field_numeric_entry(event, field, data);
>   }

RE: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

[Breana, Tiberiu A]

> -Original Message-
> From: Alison Schofield [mailto:amsfiel...@gmail.com]
> Sent: Monday, July 11, 2016 6:25 PM
> To: ji...@kernel.org
> Cc: Breana, Tiberiu A ; mranos...@gmail.com;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux-
> i...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-
> zero values
> 
> Use the iio_pollfunc_store_time parameter during triggered buffer set-up to 
> get
> valid timestamps. 
> 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 

+1
Reviewed-By: Tiberiu Breana 

> ---
>  drivers/iio/accel/bma220_spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/bma220_spi.c b/drivers/iio/accel/bma220_spi.c
> index 1098d10..5099f29 100644
> --- a/drivers/iio/accel/bma220_spi.c
> +++ b/drivers/iio/accel/bma220_spi.c
> @@ -253,7 +253,7 @@ static int bma220_probe(struct spi_device *spi)
>   if (ret < 0)
>   return ret;
> 
> - ret = iio_triggered_buffer_setup(indio_dev, NULL,
> + ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
>bma220_trigger_handler, NULL);
>   if (ret < 0) {
>   dev_err(>dev, "iio triggered buffer setup failed\n");
> --
> 2.1.4

RE: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

[Breana, Tiberiu A]

> -Original Message-
> From: Alison Schofield [mailto:amsfiel...@gmail.com]
> Sent: Monday, July 11, 2016 6:25 PM
> To: ji...@kernel.org
> Cc: Breana, Tiberiu A ; mranos...@gmail.com;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux-
> i...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-
> zero values
> 
> Use the iio_pollfunc_store_time parameter during triggered buffer set-up to 
> get
> valid timestamps. 
> 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 

+1
Reviewed-By: Tiberiu Breana 

> ---
>  drivers/iio/accel/bma220_spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/bma220_spi.c b/drivers/iio/accel/bma220_spi.c
> index 1098d10..5099f29 100644
> --- a/drivers/iio/accel/bma220_spi.c
> +++ b/drivers/iio/accel/bma220_spi.c
> @@ -253,7 +253,7 @@ static int bma220_probe(struct spi_device *spi)
>   if (ret < 0)
>   return ret;
> 
> - ret = iio_triggered_buffer_setup(indio_dev, NULL,
> + ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
>bma220_trigger_handler, NULL);
>   if (ret < 0) {
>   dev_err(>dev, "iio triggered buffer setup failed\n");
> --
> 2.1.4

RE: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

[Breana, Tiberiu A]

> -Original Message-
> From: Alison Schofield [mailto:amsfiel...@gmail.com]
> Sent: Monday, July 11, 2016 6:26 PM
> To: ji...@kernel.org
> Cc: Breana, Tiberiu A ; mranos...@gmail.com;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux-
> i...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-
> zero values
> 
> Use the iio_pollfunc_store_time parameter during triggered buffer set-up to 
> get
> valid timestamps.
> 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---

+1
Reviewed-By: Tiberiu Breana 

>  drivers/iio/humidity/am2315.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> index 3e200f6..ff96b6d 100644
> --- a/drivers/iio/humidity/am2315.c
> +++ b/drivers/iio/humidity/am2315.c
> @@ -244,7 +244,7 @@ static int am2315_probe(struct i2c_client *client,
>   indio_dev->channels = am2315_channels;
>   indio_dev->num_channels = ARRAY_SIZE(am2315_channels);
> 
> - ret = iio_triggered_buffer_setup(indio_dev, NULL,
> + ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
>am2315_trigger_handler, NULL);
>   if (ret < 0) {
>   dev_err(>dev, "iio triggered buffer setup failed\n");
> --
> 2.1.4

RE: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

[Breana, Tiberiu A]

> -Original Message-
> From: Alison Schofield [mailto:amsfiel...@gmail.com]
> Sent: Monday, July 11, 2016 6:26 PM
> To: ji...@kernel.org
> Cc: Breana, Tiberiu A ; mranos...@gmail.com;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux-
> i...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-
> zero values
> 
> Use the iio_pollfunc_store_time parameter during triggered buffer set-up to 
> get
> valid timestamps.
> 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---

+1
Reviewed-By: Tiberiu Breana 

>  drivers/iio/humidity/am2315.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> index 3e200f6..ff96b6d 100644
> --- a/drivers/iio/humidity/am2315.c
> +++ b/drivers/iio/humidity/am2315.c
> @@ -244,7 +244,7 @@ static int am2315_probe(struct i2c_client *client,
>   indio_dev->channels = am2315_channels;
>   indio_dev->num_channels = ARRAY_SIZE(am2315_channels);
> 
> - ret = iio_triggered_buffer_setup(indio_dev, NULL,
> + ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
>am2315_trigger_handler, NULL);
>   if (ret < 0) {
>   dev_err(>dev, "iio triggered buffer setup failed\n");
> --
> 2.1.4

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Radim Krčmář]

2016-07-11 16:14+0200, Paolo Bonzini:
> On 11/07/2016 15:48, Radim Krčmář wrote:
 I guess the easiest solution is to replace kvm_apic_id with a field in
 struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>> 
>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
>>  x2apic id.  xapic id cannot be greater than 255 and all of those are
>>  covered by the initial value of max_id.)
> 
> Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
> in kvm_apic_id?

APIC ID is writeable in xAPIC mode, which would make the implementation
weird without an extra variable.  Always read-only APIC ID would be
best, IMO.

>>> Or we can just simply put the assignment of apic_base to the end.
>> 
>> Yes, this would work, I'd also remove recalculates from
>> kvm_apic_set_*apic_id() and add a compiler barrier with comment for good
>> measure, even though set_virtual_x2apic_mode() serves as one.
> 
> Why a compiler barrier?

True, it should be a proper pair of smp_wmb() and smp_rmb() in
recalculate ... and current kvm_apic_id() reads in a wrong order, so
changing the apic_base alone update wouldn't get rid of this race.

>> (What makes a bit wary is that it doesn't avoid the same problem if we
>>  changed KVM to reset apic id to xapic id first when disabling apic.)
> 
> Yes, this is why I prefer it fixed once and for all in kvm_apic_id...

Seems most reasonable.  We'll need to be careful to have a correct value
in the apic page, but there shouldn't be any races there.

>> Races in recalculation and APIC ID changes also lead to invalid physical
>> maps, which haven't been taken care of properly ...
> 
> Hmm, true, but can be fixed separately.  Probably the mutex should be
> renamed so that it can be taken outside recalculate_apic_map...

Good point, it'll make reasoning easier and shouldn't introduce any
extra scalability issues.

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Radim Krčmář]

2016-07-11 16:14+0200, Paolo Bonzini:
> On 11/07/2016 15:48, Radim Krčmář wrote:
 I guess the easiest solution is to replace kvm_apic_id with a field in
 struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.
>> 
>> (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
>>  x2apic id.  xapic id cannot be greater than 255 and all of those are
>>  covered by the initial value of max_id.)
> 
> Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
> in kvm_apic_id?

APIC ID is writeable in xAPIC mode, which would make the implementation
weird without an extra variable.  Always read-only APIC ID would be
best, IMO.

>>> Or we can just simply put the assignment of apic_base to the end.
>> 
>> Yes, this would work, I'd also remove recalculates from
>> kvm_apic_set_*apic_id() and add a compiler barrier with comment for good
>> measure, even though set_virtual_x2apic_mode() serves as one.
> 
> Why a compiler barrier?

True, it should be a proper pair of smp_wmb() and smp_rmb() in
recalculate ... and current kvm_apic_id() reads in a wrong order, so
changing the apic_base alone update wouldn't get rid of this race.

>> (What makes a bit wary is that it doesn't avoid the same problem if we
>>  changed KVM to reset apic id to xapic id first when disabling apic.)
> 
> Yes, this is why I prefer it fixed once and for all in kvm_apic_id...

Seems most reasonable.  We'll need to be careful to have a correct value
in the apic page, but there shouldn't be any races there.

>> Races in recalculation and APIC ID changes also lead to invalid physical
>> maps, which haven't been taken care of properly ...
> 
> Hmm, true, but can be fixed separately.  Probably the mutex should be
> renamed so that it can be taken outside recalculate_apic_map...

Good point, it'll make reasoning easier and shouldn't introduce any
extra scalability issues.

Re: PCIe MSI address is not written at pci_enable_msi_range call

[Marc Zyngier]

On 11/07/16 11:51, Bharat Kumar Gogada wrote:
>>> Hi Marc,
>>>
>>> Thanks for the reply.
>>>
>>> From PCIe Spec:
>>> MSI Enable Bit:
>>> If 1 and the MSI-X Enable bit in the MSI-X Message
>>> Control register (see Section 6.8.2.3) is 0, the
>>> function is permitted to use MSI to request service
>>> and is prohibited from using its INTx# pin.
>>>
>>> From Endpoint perspective, MSI Enable = 1 indicates MSI can be used
>> which means MSI address and data fields are available/programmed.
>>>
>>> In our SoC whenever MSI Enable goes from 0 --> 1 the hardware latches
>> onto MSI address and MSI data values.
>>>
>>> With current MSI implementation in kernel, our SoC is latching on to
>> incorrect address and data values, as address/data
>>> are updated much later than MSI Enable bit.
>>
>> Interesting. It looks like we're doing something wrong in the MSI flow.
>> Can you confirm that this is limited to MSI and doesn't affect MSI-X?
>>
> I think it's the same issue irrespective of MSI or MSI-X as we are
> enabling these interrupts before providing the  vectors.
> 
> So we always have a hole when MSI/MSI-X is 1, and software driver has
> not registered the irq, and End Point may raise an interrupt (may be
> due to error) in this point of time.

Looking at the MSI-X part of the code, there is this:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/msi.c#n764

which hints that it may not be possible to do otherwise. Damned if you
do, damned if you don't.

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v8 4/4] serial: pl011: add console matching function

[Matthias Brugger]

On 11/07/16 16:40, Matthias Brugger wrote:



I tried to apply these patches against linux-next. They needed some
changes to apply, which is quite normal after such a long time. Apart
from that the DBG2 subtype patch didn't end up in mainline, so this
patches do not compile.

I followed up on that on the corresponding thread. Please don't forget
to pin-point in the introduction mail to any other series which is
needed for your patches to compile/work.



Ok, I sorted out, that the DBG2 subtypes actually are part of mainline 
and that I screwed up my branches.


Sorry for the noise.
Matthias

Re: [PATCH v8 4/4] serial: pl011: add console matching function

[Matthias Brugger]

On 11/07/16 16:40, Matthias Brugger wrote:



I tried to apply these patches against linux-next. They needed some
changes to apply, which is quite normal after such a long time. Apart
from that the DBG2 subtype patch didn't end up in mainline, so this
patches do not compile.

I followed up on that on the corresponding thread. Please don't forget
to pin-point in the introduction mail to any other series which is
needed for your patches to compile/work.



Ok, I sorted out, that the DBG2 subtypes actually are part of mainline 
and that I screwed up my branches.


Sorry for the noise.
Matthias

Re: PCIe MSI address is not written at pci_enable_msi_range call

[Marc Zyngier]

On 11/07/16 11:51, Bharat Kumar Gogada wrote:
>>> Hi Marc,
>>>
>>> Thanks for the reply.
>>>
>>> From PCIe Spec:
>>> MSI Enable Bit:
>>> If 1 and the MSI-X Enable bit in the MSI-X Message
>>> Control register (see Section 6.8.2.3) is 0, the
>>> function is permitted to use MSI to request service
>>> and is prohibited from using its INTx# pin.
>>>
>>> From Endpoint perspective, MSI Enable = 1 indicates MSI can be used
>> which means MSI address and data fields are available/programmed.
>>>
>>> In our SoC whenever MSI Enable goes from 0 --> 1 the hardware latches
>> onto MSI address and MSI data values.
>>>
>>> With current MSI implementation in kernel, our SoC is latching on to
>> incorrect address and data values, as address/data
>>> are updated much later than MSI Enable bit.
>>
>> Interesting. It looks like we're doing something wrong in the MSI flow.
>> Can you confirm that this is limited to MSI and doesn't affect MSI-X?
>>
> I think it's the same issue irrespective of MSI or MSI-X as we are
> enabling these interrupts before providing the  vectors.
> 
> So we always have a hole when MSI/MSI-X is 1, and software driver has
> not registered the irq, and End Point may raise an interrupt (may be
> due to error) in this point of time.

Looking at the MSI-X part of the code, there is this:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/msi.c#n764

which hints that it may not be possible to do otherwise. Damned if you
do, damned if you don't.

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

[Dave Hansen]

On 07/11/2016 07:45 AM, Andy Lutomirski wrote:
> On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen  wrote:
>> Should we instead just recommend to userspace that they lock down access
>> to keys by default in all threads as a best practice?
> 
> Is that really better than doing it in-kernel?  My concern is that
> we'll find library code that creates a thread, and that code could run
> before the pkey-aware part of the program even starts running. 

Yeah, so let's assume we have some pkey-unaware thread.  The upside of a
scheme where the kernel preemptively (and transparently to the thread)
locks down PKRU is that the thread can't go corrupting any non-zero-pkey
structures that came from other threads.

But, the downside is that the thread can not access any non-zero-pkey
structures without taking some kind of action with PKRU.  That obviously
won't happen since the thread is pkeys-unaware to begin with.  Would
that break these libraries unless everything using pkeys knows to only
share pkey=0 data with those threads?

> So how is user code supposed lock down all of its threads?
> 
> seccomp has TSYNC for this, but I don't think that PKRU allows 
> something like that.

I'm not sure this is possible for PKRU.  Think of a simple PKRU
manipulation in userspace:

pkru = rdpkru();
pkru |= PKEY_DENY_ACCESS<

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

[Dave Hansen]

On 07/11/2016 07:45 AM, Andy Lutomirski wrote:
> On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen  wrote:
>> Should we instead just recommend to userspace that they lock down access
>> to keys by default in all threads as a best practice?
> 
> Is that really better than doing it in-kernel?  My concern is that
> we'll find library code that creates a thread, and that code could run
> before the pkey-aware part of the program even starts running. 

Yeah, so let's assume we have some pkey-unaware thread.  The upside of a
scheme where the kernel preemptively (and transparently to the thread)
locks down PKRU is that the thread can't go corrupting any non-zero-pkey
structures that came from other threads.

But, the downside is that the thread can not access any non-zero-pkey
structures without taking some kind of action with PKRU.  That obviously
won't happen since the thread is pkeys-unaware to begin with.  Would
that break these libraries unless everything using pkeys knows to only
share pkey=0 data with those threads?

> So how is user code supposed lock down all of its threads?
> 
> seccomp has TSYNC for this, but I don't think that PKRU allows 
> something like that.

I'm not sure this is possible for PKRU.  Think of a simple PKRU
manipulation in userspace:

pkru = rdpkru();
pkru |= PKEY_DENY_ACCESS<

Re: [Query] Preemption (hogging) of the work handler

[Sergey Senozhatsky]

Hello,

Thanks for Cc-ing.

I'm attending an internal 2-days training now, so I'm a bit
slow at answering emails, sorry.

On (07/11/16 12:26), Jan Kara wrote:
[..]
> > These print messages continue from 2994.918 to 2996.268 (1.35 seconds)
> > and they hog the work-handler for that long, which results in watchdog
> > reboot in our setup. The 3.10 kernel implementation of the printk
> > looks like this (if I am not wrong):
> > 
> > local_irq_save();
> > flush-console-buffer(); //console_unlock()
> > local_irq_restore();
> > 
> > So, the current CPU will try to print all the messages from the
> > buffer, before enabling the interrupts again on the local CPU and so I
> > don't see the hrtimer fire at all for almost a second.
> > 

right. apart from cases when the existing console_unlock() behaviour can
simply "block" a process to flush the log_buf to slow serial consoles
(regardless the  process execution context) and make the system less
responsive, I have around ~10 absolutely different scenarios on my list that
may cause soft/hard lockups, rcu stalls, oom-s, etc. and console_unlock() is
the root cause there. the simplest ones involve heavy printk() usage, the
trickier ones do not necessarily have anything that is abusing printk(): a
moderate printk() pressure coming from other CPUs on the system and more or
less active tty -> UART can do the trick, because uart interrupt service
routine and call_console_drivers()->write() have to compete for the same
uart port spin_lock. soft lockups are probably the most common problems,
though, it's not all that easy to catch, because watchdog does not ring
the bell straight after preempt_enable(), but from hrtimer interrupt, that
happens approx every 4 seconds. by this time CPU can be somewhere far away
from console_unlock(). I had an idea of doing watchdog soft lockup check
from preempt_enable(), when it brings preempt_count down to zero, but not
sure I can recall how well did it go.

> > I tried looking at if something related to this changed between 3.10
> > and mainline, and found few patches at least. One of the important
> > ones is:
> > 
> > commit 5874af2003b1 ("printk: enable interrupts before calling
> > console_trylock_for_printk()")
> > 
> > I wasn't able to backport it cleanly to 3.10 yet to see it makes thing
> > work better though. But it looks like it was targeting similar
> > problems.
> Yes. We have similar problems as you observe on machines when they do a lot
> of printing (usually due to device discovery or similar reasons). The
> problem is not fully solved even upstream as Andrew is reluctant to merge
> the patches. Sergey (added to CC) has the latest version of the series [1].
> If you are interested, I can send you the patches for 3.12 kernel which we
> carry in SLES kernels and which fixes the issue for us. It is significanly
> different from current upstream version but it works good enough for us.

yes, an alternative link /* lkml.org is pretty unreliable sometimes*/
is: http://marc.info/?l=linux-kernel=146314209118602

I don't have a backport to 3.10, sorry. I had it some time ago (not the
current version, tho), but I think I lost it by now, don't have to deal
with 3.10 anymore.

I'll re-spin the series in a day or two, I think. A rebased version
(against next-20160711), basically, has only that KERN_CONT patch as
part of 0001 now: http://marc.info/?l=linux-kernel=146717692431893

hopefully it will re-fresh the discussion and I'll be able to polish
the series so Andrew will be less sceptical about the whole thing.

-ss

Re: [Query] Preemption (hogging) of the work handler

[Sergey Senozhatsky]

Hello,

Thanks for Cc-ing.

I'm attending an internal 2-days training now, so I'm a bit
slow at answering emails, sorry.

On (07/11/16 12:26), Jan Kara wrote:
[..]
> > These print messages continue from 2994.918 to 2996.268 (1.35 seconds)
> > and they hog the work-handler for that long, which results in watchdog
> > reboot in our setup. The 3.10 kernel implementation of the printk
> > looks like this (if I am not wrong):
> > 
> > local_irq_save();
> > flush-console-buffer(); //console_unlock()
> > local_irq_restore();
> > 
> > So, the current CPU will try to print all the messages from the
> > buffer, before enabling the interrupts again on the local CPU and so I
> > don't see the hrtimer fire at all for almost a second.
> > 

right. apart from cases when the existing console_unlock() behaviour can
simply "block" a process to flush the log_buf to slow serial consoles
(regardless the  process execution context) and make the system less
responsive, I have around ~10 absolutely different scenarios on my list that
may cause soft/hard lockups, rcu stalls, oom-s, etc. and console_unlock() is
the root cause there. the simplest ones involve heavy printk() usage, the
trickier ones do not necessarily have anything that is abusing printk(): a
moderate printk() pressure coming from other CPUs on the system and more or
less active tty -> UART can do the trick, because uart interrupt service
routine and call_console_drivers()->write() have to compete for the same
uart port spin_lock. soft lockups are probably the most common problems,
though, it's not all that easy to catch, because watchdog does not ring
the bell straight after preempt_enable(), but from hrtimer interrupt, that
happens approx every 4 seconds. by this time CPU can be somewhere far away
from console_unlock(). I had an idea of doing watchdog soft lockup check
from preempt_enable(), when it brings preempt_count down to zero, but not
sure I can recall how well did it go.

> > I tried looking at if something related to this changed between 3.10
> > and mainline, and found few patches at least. One of the important
> > ones is:
> > 
> > commit 5874af2003b1 ("printk: enable interrupts before calling
> > console_trylock_for_printk()")
> > 
> > I wasn't able to backport it cleanly to 3.10 yet to see it makes thing
> > work better though. But it looks like it was targeting similar
> > problems.
> Yes. We have similar problems as you observe on machines when they do a lot
> of printing (usually due to device discovery or similar reasons). The
> problem is not fully solved even upstream as Andrew is reluctant to merge
> the patches. Sergey (added to CC) has the latest version of the series [1].
> If you are interested, I can send you the patches for 3.12 kernel which we
> carry in SLES kernels and which fixes the issue for us. It is significanly
> different from current upstream version but it works good enough for us.

yes, an alternative link /* lkml.org is pretty unreliable sometimes*/
is: http://marc.info/?l=linux-kernel=146314209118602

I don't have a backport to 3.10, sorry. I had it some time ago (not the
current version, tho), but I think I lost it by now, don't have to deal
with 3.10 anymore.

I'll re-spin the series in a day or two, I think. A rebased version
(against next-20160711), basically, has only that KERN_CONT patch as
part of 0001 now: http://marc.info/?l=linux-kernel=146717692431893

hopefully it will re-fresh the discussion and I'll be able to polish
the series so Andrew will be less sceptical about the whole thing.

-ss

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:22 PM CEST Wan Zongshun wrote:
> +
> +#if !defined(CONFIG_SOC_NUC900)
>  #define NR_IRQS(IRQ_ADC+1)
> +#else
> +#define NR_IRQS62
> +#endif
>  

The Kconfig symbols are a bit confusing here: CONFIG_SOC_NUC900
controls the compilation of the soc_device driver, but I guess
what you actually mean here is CONFIG_SOC_NUC970, which is the
support for the actual chip.

Maybe rename the former to something less confusing and change
this to CONFIG_SOC_NUC970?

Ideally, this should just go away once we use SPARSE_IRQ.

Arnd

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:22 PM CEST Wan Zongshun wrote:
> +
> +#if !defined(CONFIG_SOC_NUC900)
>  #define NR_IRQS(IRQ_ADC+1)
> +#else
> +#define NR_IRQS62
> +#endif
>  

The Kconfig symbols are a bit confusing here: CONFIG_SOC_NUC900
controls the compilation of the soc_device driver, but I guess
what you actually mean here is CONFIG_SOC_NUC970, which is the
support for the actual chip.

Maybe rename the former to something less confusing and change
this to CONFIG_SOC_NUC970?

Ideally, this should just go away once we use SPARSE_IRQ.

Arnd

Re: System freezes after OOM

[Mikulas Patocka]

On Mon, 11 Jul 2016, Ondrej Kozina wrote:

> On 07/11/2016 01:55 PM, Jerome Marchand wrote:
> > On 07/11/2016 01:03 PM, Stanislav Kozina wrote:
> > > Hi Jerome,
> > > 
> > > On upstream mailing lists there have been reports of freezing systems
> > > due to OOM. Ondra (on CC) managed to reproduce this inhouse, he'd like
> > > someone with mm skills to look at the problem since he doesn't
> > > understand why OOM comes into play when >90% of 2GB swap are still free.
> > > 
> > > Could you please take a look? It's following this email on upstream:
> > > https://lkml.org/lkml/2016/5/5/356
> > > 
> > > Thanks!
> > > -Stanislav
> > 
> > Hi Ondrej,
> > 
> > I can see [1] that there are several atomic memory allocation failures
> > before the OOM kill, several of them are in memory reclaim path, which
> > prevents it to free memory.
> > Normally the linux mm try to keep enough memory free at all time to
> > satisfy atomic allocation (cf. /proc/sys/vm/min_free_kbytes). Have you
> > try to increase that value?
> > It would be useful to understand why the reserve for atomic allocations
> > runs out. There might be a burst of atomic allocations that deplete the
> > reserve. What kind of workload is that?
> > 
> > Jerome
> > 
> > [1]:
> > https://okozina.fedorapeople.org/bugs/swap_on_dmcrypt/vmlog-1462458369-0/sample-00011/dmesg
> > 
> 
> Hi Jerome,
> 
> first let thank you for looking into it! About the workload it's nothing
> special. I've started gcc build of a project in C++ in 3-4 threads so that I'd
> waste all physical memory to trigger it. I can build some simple utility to
> allocate memory in predefined chunks in some loop if it'd of any help. It was
> really quite simple to trigger this.
> 
> On a /proc/sys/vm/min_free_kbytes value. Let me try it...
> 
> Thanks Ondra
> 
> PS: Adding Mikulas on CC'ed (dm-crypt upstream) in case he has anything to
> add.

That allocation warning in wb_start_writeback was already silenced by the 
commit 78ebc2f7146156f488083c9e5a7ded9d5c38c58b. The warning in 
drivers/virtio/virtio_ring.c:alloc_indirect could be silenced as well (the 
driver does fallback in case of allocation failure, so this failure can't 
result in loss of functionality).


The general problem is that the memory allocator does 16 retries to 
allocate a page and then triggers the OOM killer (and it doesn't take into 
account how much swap space is free or how many dirty pages were really 
swapped out while it waited).

So, it could prematurely trigger OOM killer on any slow swapping device 
(including dm-crypt). Michal Hocko reworked the OOM killer in the patch 
0a0337e0d1d134465778a16f5cbea95086e8e9e0, but it still has the flaw that 
it triggers OOM if there is plenty of free swap space free.

Michal, would you accept a change to the OOM killer, to prevent it from 
triggerring when there is free swap space?

Mikulas

Re: System freezes after OOM

[Mikulas Patocka]

On Mon, 11 Jul 2016, Ondrej Kozina wrote:

> On 07/11/2016 01:55 PM, Jerome Marchand wrote:
> > On 07/11/2016 01:03 PM, Stanislav Kozina wrote:
> > > Hi Jerome,
> > > 
> > > On upstream mailing lists there have been reports of freezing systems
> > > due to OOM. Ondra (on CC) managed to reproduce this inhouse, he'd like
> > > someone with mm skills to look at the problem since he doesn't
> > > understand why OOM comes into play when >90% of 2GB swap are still free.
> > > 
> > > Could you please take a look? It's following this email on upstream:
> > > https://lkml.org/lkml/2016/5/5/356
> > > 
> > > Thanks!
> > > -Stanislav
> > 
> > Hi Ondrej,
> > 
> > I can see [1] that there are several atomic memory allocation failures
> > before the OOM kill, several of them are in memory reclaim path, which
> > prevents it to free memory.
> > Normally the linux mm try to keep enough memory free at all time to
> > satisfy atomic allocation (cf. /proc/sys/vm/min_free_kbytes). Have you
> > try to increase that value?
> > It would be useful to understand why the reserve for atomic allocations
> > runs out. There might be a burst of atomic allocations that deplete the
> > reserve. What kind of workload is that?
> > 
> > Jerome
> > 
> > [1]:
> > https://okozina.fedorapeople.org/bugs/swap_on_dmcrypt/vmlog-1462458369-0/sample-00011/dmesg
> > 
> 
> Hi Jerome,
> 
> first let thank you for looking into it! About the workload it's nothing
> special. I've started gcc build of a project in C++ in 3-4 threads so that I'd
> waste all physical memory to trigger it. I can build some simple utility to
> allocate memory in predefined chunks in some loop if it'd of any help. It was
> really quite simple to trigger this.
> 
> On a /proc/sys/vm/min_free_kbytes value. Let me try it...
> 
> Thanks Ondra
> 
> PS: Adding Mikulas on CC'ed (dm-crypt upstream) in case he has anything to
> add.

That allocation warning in wb_start_writeback was already silenced by the 
commit 78ebc2f7146156f488083c9e5a7ded9d5c38c58b. The warning in 
drivers/virtio/virtio_ring.c:alloc_indirect could be silenced as well (the 
driver does fallback in case of allocation failure, so this failure can't 
result in loss of functionality).


The general problem is that the memory allocator does 16 retries to 
allocate a page and then triggers the OOM killer (and it doesn't take into 
account how much swap space is free or how many dirty pages were really 
swapped out while it waited).

So, it could prematurely trigger OOM killer on any slow swapping device 
(including dm-crypt). Michal Hocko reworked the OOM killer in the patch 
0a0337e0d1d134465778a16f5cbea95086e8e9e0, but it still has the flaw that 
it triggers OOM if there is plenty of free swap space free.

Michal, would you accept a change to the OOM killer, to prevent it from 
triggerring when there is free swap space?

Mikulas

Re: KASAN vs vmapped stacks

[Andrey Ryabinin]

On 07/11/2016 01:29 PM, Dmitry Vyukov wrote:
> On Mon, Jul 11, 2016 at 11:57 AM, Andrey Ryabinin
>  wrote:
>>
>>
>> On 07/10/2016 03:47 PM, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> I found two nasty issues with virtually mapped stacks if KASAN is
>>> enabled.  The first issue is a crash: the first non-init stack is
>>> allocated and accessed before KASAN initializes its zero shadow
>>> AFAICT, which means that we switch to that stack and then blow up when
>>> we start recursively faulting on failed accesses to the shadow.
>>>
>>
>> KASAN initialized quite early, before any non-init task exists. The crash 
>> happens
>> because non-init task writes to write-protected zero shadow.
>> Currently KASAN doesn't allocate shadow memory for vmalloc addresses, we 
>> just map single
>> zero page and write protect it.
>>
>>
>>> The second issue is that, even if we survive (we initialize the zero
>>> shadow on time), KASAN will fail to protect hte stack.
>>>
>>> For now, I just disabled use of virtually mapped stacks if KASAN is
>>> on.  Do you have any easy ideas to fix it?
>>>
>>
>> Allocate shadow memory which backs vmalloc/vmap allocations is the only way 
>> to fix this.
>> I can do this, and post the patches soon enough.
> 
> Do you want to allocate it eagerly? Won't it consume 1/8 of vmalloc
> range worth of physical memory?
> 

I have no idea what do you mean by eager allocation.
What we need is to allocate shadow per vmalloc()/vmap() call if such allocation 
requires non-zero shadow, like stacks or modules.
Sometimes we certainly know that the whole shadow page will contain only zeros. 
In such cases we can use zero page to not waste memory.

Re: KASAN vs vmapped stacks

[Andrey Ryabinin]

On 07/11/2016 01:29 PM, Dmitry Vyukov wrote:
> On Mon, Jul 11, 2016 at 11:57 AM, Andrey Ryabinin
>  wrote:
>>
>>
>> On 07/10/2016 03:47 PM, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> I found two nasty issues with virtually mapped stacks if KASAN is
>>> enabled.  The first issue is a crash: the first non-init stack is
>>> allocated and accessed before KASAN initializes its zero shadow
>>> AFAICT, which means that we switch to that stack and then blow up when
>>> we start recursively faulting on failed accesses to the shadow.
>>>
>>
>> KASAN initialized quite early, before any non-init task exists. The crash 
>> happens
>> because non-init task writes to write-protected zero shadow.
>> Currently KASAN doesn't allocate shadow memory for vmalloc addresses, we 
>> just map single
>> zero page and write protect it.
>>
>>
>>> The second issue is that, even if we survive (we initialize the zero
>>> shadow on time), KASAN will fail to protect hte stack.
>>>
>>> For now, I just disabled use of virtually mapped stacks if KASAN is
>>> on.  Do you have any easy ideas to fix it?
>>>
>>
>> Allocate shadow memory which backs vmalloc/vmap allocations is the only way 
>> to fix this.
>> I can do this, and post the patches soon enough.
> 
> Do you want to allocate it eagerly? Won't it consume 1/8 of vmalloc
> range worth of physical memory?
> 

I have no idea what do you mean by eager allocation.
What we need is to allocate shadow per vmalloc()/vmap() call if such allocation 
requires non-zero shadow, like stacks or modules.
Sometimes we certainly know that the whole shadow page will contain only zeros. 
In such cases we can use zero page to not waste memory.

Re: Hi, Ingo, would you please help drop the TSC MSR calibration patch

[Jacob Pan]

On Mon, 11 Jul 2016 07:59:19 -0700
"Chen, Yu C"  wrote:

> Currently it is in your x86/timer tree:
> 
> commit fc273eeef314cdaf0ac992b400d126f8184a4d1c
> Author: Len Brown 
> Date:   Fri Jun 17 01:22:49 2016 -0400
> 
> x86/tsc_msr: Extend to include Intel Core Architecture
> 
> 
> Previously we found this patch might decrease the performance on
> one of our servers, due to the small gap between using old PIT
> calibration and new MSR calibration method, so we currently would
> like to hold this patch for now, until we got a clear answer from our
> architect. Would you please help revert this patch (the other patches
> are safe and can be merged), sorry for the inconvenience.
> 
I modified the subject slightly to be more specific.
Adding lkml and x86 list, and a few more people.
This commit is also affected, won't compile if we revert the one above.

37c528e... x86/tsc_msr: Fix rdmsr(MSR_PLATFORM_INFO) unsafe warning in
KVM guest

> thanks,
> Yu
> 
> 

[Jacob Pan]

Re: Hi, Ingo, would you please help drop the TSC MSR calibration patch

[Jacob Pan]

On Mon, 11 Jul 2016 07:59:19 -0700
"Chen, Yu C"  wrote:

> Currently it is in your x86/timer tree:
> 
> commit fc273eeef314cdaf0ac992b400d126f8184a4d1c
> Author: Len Brown 
> Date:   Fri Jun 17 01:22:49 2016 -0400
> 
> x86/tsc_msr: Extend to include Intel Core Architecture
> 
> 
> Previously we found this patch might decrease the performance on
> one of our servers, due to the small gap between using old PIT
> calibration and new MSR calibration method, so we currently would
> like to hold this patch for now, until we got a clear answer from our
> architect. Would you please help revert this patch (the other patches
> are safe and can be merged), sorry for the inconvenience.
> 
I modified the subject slightly to be more specific.
Adding lkml and x86 list, and a few more people.
This commit is also affected, won't compile if we revert the one above.

37c528e... x86/tsc_msr: Fix rdmsr(MSR_PLATFORM_INFO) unsafe warning in
KVM guest

> thanks,
> Yu
> 
> 

[Jacob Pan]

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Tue, 5 Jul 2016, Mark Hounschell wrote:

> From: Jiri Kosina 
> 
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> this is being used setfdprm userspace for ioctl-only open().
> 
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
> modes, while still keeping the original O_NDELAY bug fixed.
> 
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt 
> Tested-by: Wim Osterholt 
> Signed-off-by: Jiri Kosina 
> ---
[ ... snip ... ]
> 
> But this does not completely fix all the problems induced by the original
> changes from 4.4 to 4.5. The following is what we use to open the floppy.
> 
> fd = open(device,  O_RDWR | O_NDELAY);
> 
> The FMODE_NDELAY check that was removed now prevents one from doing an open of
> the device with no media inserted. It also prevents one from doing an open of
> the device with media inserted that is not already formatted in a "standard"
> format.  I do both of these things a lot. I deal with a few very non-standard
> formats and this change prevents me from doing what I've been doing for YEARS.
> Could we please get the original behavior back in the floppy driver.

Hi Mark,

thanks for the regression report.

For my better understanding of your issue -- what behavior/semantics 
exactly does your userspace think it'll be getting from opening /dev/fd0 
with O_NDELAY?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Tue, 5 Jul 2016, Mark Hounschell wrote:

> From: Jiri Kosina 
> 
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> this is being used setfdprm userspace for ioctl-only open().
> 
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
> modes, while still keeping the original O_NDELAY bug fixed.
> 
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt 
> Tested-by: Wim Osterholt 
> Signed-off-by: Jiri Kosina 
> ---
[ ... snip ... ]
> 
> But this does not completely fix all the problems induced by the original
> changes from 4.4 to 4.5. The following is what we use to open the floppy.
> 
> fd = open(device,  O_RDWR | O_NDELAY);
> 
> The FMODE_NDELAY check that was removed now prevents one from doing an open of
> the device with no media inserted. It also prevents one from doing an open of
> the device with media inserted that is not already formatted in a "standard"
> format.  I do both of these things a lot. I deal with a few very non-standard
> formats and this change prevents me from doing what I've been doing for YEARS.
> Could we please get the original behavior back in the floppy driver.

Hi Mark,

thanks for the regression report.

For my better understanding of your issue -- what behavior/semantics 
exactly does your userspace think it'll be getting from opening /dev/fd0 
with O_NDELAY?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2 03/10] Clocksource: add nuc970 clocksource driver

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:23 PM CEST Wan Zongshun wrote:
> 
> +config NUC900_TIMER
> +bool "Clocksource timer for nuc900 platform" if COMPILE_TEST
> +depends on ARM
> +select CLKSRC_OF if OF
> +select CLKSRC_MMIO
> +help
> +  Enables the clocksource for the NUC900 platform.
> 

I have put this patch into my randconfig build system and found that
it lacks a dependency:



diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e18ef32776a3..59b9251eef37 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -523,7 +523,7 @@ config CLKSRC_ST_LPC
 
 config NUC900_TIMER
 bool "Clocksource timer for nuc900 platform" if COMPILE_TEST
-depends on ARM
+depends on ARM && GENERIC_CLOCKEVENTS
 select CLKSRC_OF if OF
 select CLKSRC_MMIO
 help


Also the init function has changed its return type in linux-next:

> +static void __init nuc970_timer_of_init(struct device_node *node)

This now needs to return an error code or we get:

../include/linux/of.h:1004:20: error: comparison of distinct pointer types 
lacks a cast [-Werror]
.data = (fn == (fn_type)NULL) ? fn : fn  }

Daniel Lezcano seems to have implemented a migration strategy, but I
can't see what you are supposed to do here, since the
CLOCKSOURCE_OF_DECLARE_RET macro is no longer part of linux-next.

Arnd

Re: [PATCH v2 03/10] Clocksource: add nuc970 clocksource driver

[Arnd Bergmann]

On Sunday, July 10, 2016 3:27:23 PM CEST Wan Zongshun wrote:
> 
> +config NUC900_TIMER
> +bool "Clocksource timer for nuc900 platform" if COMPILE_TEST
> +depends on ARM
> +select CLKSRC_OF if OF
> +select CLKSRC_MMIO
> +help
> +  Enables the clocksource for the NUC900 platform.
> 

I have put this patch into my randconfig build system and found that
it lacks a dependency:



diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e18ef32776a3..59b9251eef37 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -523,7 +523,7 @@ config CLKSRC_ST_LPC
 
 config NUC900_TIMER
 bool "Clocksource timer for nuc900 platform" if COMPILE_TEST
-depends on ARM
+depends on ARM && GENERIC_CLOCKEVENTS
 select CLKSRC_OF if OF
 select CLKSRC_MMIO
 help


Also the init function has changed its return type in linux-next:

> +static void __init nuc970_timer_of_init(struct device_node *node)

This now needs to return an error code or we get:

../include/linux/of.h:1004:20: error: comparison of distinct pointer types 
lacks a cast [-Werror]
.data = (fn == (fn_type)NULL) ? fn : fn  }

Daniel Lezcano seems to have implemented a migration strategy, but I
can't see what you are supposed to do here, since the
CLOCKSOURCE_OF_DECLARE_RET macro is no longer part of linux-next.

Arnd

Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd

[Kamal Dasu]

On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris
 wrote:
> On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote:
>> Change the BUG_ON() condition in brcmnand_send_cmd() which checks for
>> the interrupt status "controller ready" bit to a WARN_ON.
>>
>> There is no good reason to kill the system when this condition occur
>> because we could have systems which listed the NAND controller as
>> available (e.g: from Device Tree), but the NAND chip could be
>> malfunctioning and not responding.
>>
>> Signed-off-by: Florian Fainelli 
>
> Acked-by: Brian Norris 
>

Reviewed-by: Kamal Dasu 

>> ---
>> Note that I even hesitated to remove that completely, but there is
>> some value in knowing about this condition since it helps figuring
>> out what could be wrong.
>>
>>  drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
>> b/drivers/mtd/nand/brcmnand/brcmnand.c
>> index b6062a2f3dfd..72bdc283778d 100644
>> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
>> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
>> @@ -1165,7 +1165,7 @@ static void brcmnand_send_cmd(struct brcmnand_host 
>> *host, int cmd)
>>   ctrl->cmd_pending = cmd;
>>
>>   intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS);
>> - BUG_ON(!(intfc & INTFC_CTLR_READY));
>> + WARN_ON(!(intfc & INTFC_CTLR_READY));
>>
>>   mb(); /* flush previous writes */
>>   brcmnand_write_reg(ctrl, BRCMNAND_CMD_START,
>> --
>> 2.7.4
>>



-- 
Kamal Dasu
Principal Engineer | Broadcom Ltd. 200 Brickstone Sq Andover | 978-719-1405

Re: [PATCH] mtd: nand: brcmnand: Change BUG_ON in brcmnand_send_cmd

[Kamal Dasu]

On Sat, Jul 9, 2016 at 9:30 PM, Brian Norris
 wrote:
> On Fri, Jul 08, 2016 at 10:36:39AM -0700, Florian Fainelli wrote:
>> Change the BUG_ON() condition in brcmnand_send_cmd() which checks for
>> the interrupt status "controller ready" bit to a WARN_ON.
>>
>> There is no good reason to kill the system when this condition occur
>> because we could have systems which listed the NAND controller as
>> available (e.g: from Device Tree), but the NAND chip could be
>> malfunctioning and not responding.
>>
>> Signed-off-by: Florian Fainelli 
>
> Acked-by: Brian Norris 
>

Reviewed-by: Kamal Dasu 

>> ---
>> Note that I even hesitated to remove that completely, but there is
>> some value in knowing about this condition since it helps figuring
>> out what could be wrong.
>>
>>  drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
>> b/drivers/mtd/nand/brcmnand/brcmnand.c
>> index b6062a2f3dfd..72bdc283778d 100644
>> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
>> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
>> @@ -1165,7 +1165,7 @@ static void brcmnand_send_cmd(struct brcmnand_host 
>> *host, int cmd)
>>   ctrl->cmd_pending = cmd;
>>
>>   intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS);
>> - BUG_ON(!(intfc & INTFC_CTLR_READY));
>> + WARN_ON(!(intfc & INTFC_CTLR_READY));
>>
>>   mb(); /* flush previous writes */
>>   brcmnand_write_reg(ctrl, BRCMNAND_CMD_START,
>> --
>> 2.7.4
>>



-- 
Kamal Dasu
Principal Engineer | Broadcom Ltd. 200 Brickstone Sq Andover | 978-719-1405

Re: [PATCH 3/7] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

[Stephen Smalley]

On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook which is called when xattrs of a file are being
> copied up. This hook is called once for each xattr and LSM can return 0
> to access the xattr, 1 to reject xattr, -EOPNOTSUPP if none of the lsms
> claim to know xattr and a negative error code if something went terribly
> wrong.

0 if the security module wants the xattr to be copied up, 1 if the
security module wants the xattr to be discarded on the copy, -EOPNOTSUPP
if the security module does not handle/manage the xattr, or a -errno
upon an error.

> 
> If 0 or -EOPNOTSUPP is returned, xattr will be copied up, if 1 is returned,
> xattr will not be copied up and if negative error code is returned, copy up
> will be aborted.

Not sure I understand the benefit of the 0 vs -EOPNOTSUPP distinction.

> 
> Signed-off-by: David Howells 
> Signed-off-by: Vivek Goyal 
> ---
>  fs/overlayfs/copy_up.c|  7 +++
>  include/linux/lsm_hooks.h | 10 ++
>  include/linux/security.h  |  6 ++
>  security/security.c   |  8 
>  4 files changed, 31 insertions(+)
> 
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 8ebea18..68cefb2 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -103,6 +103,13 @@ retry:
>   goto retry;
>   }
>  
> + error = security_inode_copy_up_xattr(name);
> + if (error < 0 && error != -EOPNOTSUPP)
> + break;
> + if (error == 1) {
> + error = 0;
> + continue; /* Discard */
> + }
>   error = vfs_setxattr(new, name, value, size, 0);
>   if (error)
>   break;
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index c1f95be..84caead 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -410,6 +410,14 @@
>   *   @src indicates the union dentry of file that is being copied up.
>   *   @new pointer to pointer to return newly allocated creds.
>   *   Returns 0 on success or a negative error code on error.
> + * @inode_copy_up_xattr:
> + *   Filter the xattrs being copied up when a unioned file is copied
> + *   up from a lower layer to the union/overlay layer.
> + *   @name indicates the name of the xattr.
> + *   Returns 0 to accept the xattr, 1 to discard the xattr, -EOPNOTSUPP if
> + *   security module does not know about attribute or a negative error code
> + *   to abort the copy up. Note that the caller is responsible for reading
> + *   and writing the xattrs as this hook is merely a filter.
>   *
>   * Security hooks for file operations
>   *
> @@ -1435,6 +1443,7 @@ union security_list_options {
>   size_t buffer_size);
>   void (*inode_getsecid)(struct inode *inode, u32 *secid);
>   int (*inode_copy_up) (struct dentry *src, struct cred **new);
> + int (*inode_copy_up_xattr) (const char *name);
>  
>   int (*file_permission)(struct file *file, int mask);
>   int (*file_alloc_security)(struct file *file);
> @@ -1707,6 +1716,7 @@ struct security_hook_heads {
>   struct list_head inode_listsecurity;
>   struct list_head inode_getsecid;
>   struct list_head inode_copy_up;
> + struct list_head inode_copy_up_xattr;
>   struct list_head file_permission;
>   struct list_head file_alloc_security;
>   struct list_head file_free_security;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index c976d79..08d3191 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -283,6 +283,7 @@ int security_inode_setsecurity(struct inode *inode, const 
> char *name, const void
>  int security_inode_listsecurity(struct inode *inode, char *buffer, size_t 
> buffer_size);
>  void security_inode_getsecid(struct inode *inode, u32 *secid);
>  int security_inode_copy_up(struct dentry *src, struct cred **new);
> +int security_inode_copy_up_xattr(const char *name);
>  int security_file_permission(struct file *file, int mask);
>  int security_file_alloc(struct file *file);
>  void security_file_free(struct file *file);
> @@ -764,6 +765,11 @@ static inline int security_inode_copy_up(struct dentry 
> *src, struct cred **new)
>   return 0;
>  }
>  
> +static inline int security_inode_copy_up_xattr(const char *name)
> +{
> + -EOPNOTSUPP;

return?

> +}
> +
>  static inline int security_file_permission(struct file *file, int mask)
>  {
>   return 0;
> diff --git a/security/security.c b/security/security.c
> index 3d142aa..3321e31 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -733,6 +733,12 @@ int security_inode_copy_up(struct dentry *src, struct 
> cred **new)
>  }
>  EXPORT_SYMBOL(security_inode_copy_up);
>  
> +int security_inode_copy_up_xattr(const char *name)
> +{
> + return call_int_hook(inode_copy_up_xattr, -EOPNOTSUPP, 

Re: [PATCH 3/7] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

[Stephen Smalley]

On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook which is called when xattrs of a file are being
> copied up. This hook is called once for each xattr and LSM can return 0
> to access the xattr, 1 to reject xattr, -EOPNOTSUPP if none of the lsms
> claim to know xattr and a negative error code if something went terribly
> wrong.

0 if the security module wants the xattr to be copied up, 1 if the
security module wants the xattr to be discarded on the copy, -EOPNOTSUPP
if the security module does not handle/manage the xattr, or a -errno
upon an error.

> 
> If 0 or -EOPNOTSUPP is returned, xattr will be copied up, if 1 is returned,
> xattr will not be copied up and if negative error code is returned, copy up
> will be aborted.

Not sure I understand the benefit of the 0 vs -EOPNOTSUPP distinction.

> 
> Signed-off-by: David Howells 
> Signed-off-by: Vivek Goyal 
> ---
>  fs/overlayfs/copy_up.c|  7 +++
>  include/linux/lsm_hooks.h | 10 ++
>  include/linux/security.h  |  6 ++
>  security/security.c   |  8 
>  4 files changed, 31 insertions(+)
> 
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 8ebea18..68cefb2 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -103,6 +103,13 @@ retry:
>   goto retry;
>   }
>  
> + error = security_inode_copy_up_xattr(name);
> + if (error < 0 && error != -EOPNOTSUPP)
> + break;
> + if (error == 1) {
> + error = 0;
> + continue; /* Discard */
> + }
>   error = vfs_setxattr(new, name, value, size, 0);
>   if (error)
>   break;
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index c1f95be..84caead 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -410,6 +410,14 @@
>   *   @src indicates the union dentry of file that is being copied up.
>   *   @new pointer to pointer to return newly allocated creds.
>   *   Returns 0 on success or a negative error code on error.
> + * @inode_copy_up_xattr:
> + *   Filter the xattrs being copied up when a unioned file is copied
> + *   up from a lower layer to the union/overlay layer.
> + *   @name indicates the name of the xattr.
> + *   Returns 0 to accept the xattr, 1 to discard the xattr, -EOPNOTSUPP if
> + *   security module does not know about attribute or a negative error code
> + *   to abort the copy up. Note that the caller is responsible for reading
> + *   and writing the xattrs as this hook is merely a filter.
>   *
>   * Security hooks for file operations
>   *
> @@ -1435,6 +1443,7 @@ union security_list_options {
>   size_t buffer_size);
>   void (*inode_getsecid)(struct inode *inode, u32 *secid);
>   int (*inode_copy_up) (struct dentry *src, struct cred **new);
> + int (*inode_copy_up_xattr) (const char *name);
>  
>   int (*file_permission)(struct file *file, int mask);
>   int (*file_alloc_security)(struct file *file);
> @@ -1707,6 +1716,7 @@ struct security_hook_heads {
>   struct list_head inode_listsecurity;
>   struct list_head inode_getsecid;
>   struct list_head inode_copy_up;
> + struct list_head inode_copy_up_xattr;
>   struct list_head file_permission;
>   struct list_head file_alloc_security;
>   struct list_head file_free_security;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index c976d79..08d3191 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -283,6 +283,7 @@ int security_inode_setsecurity(struct inode *inode, const 
> char *name, const void
>  int security_inode_listsecurity(struct inode *inode, char *buffer, size_t 
> buffer_size);
>  void security_inode_getsecid(struct inode *inode, u32 *secid);
>  int security_inode_copy_up(struct dentry *src, struct cred **new);
> +int security_inode_copy_up_xattr(const char *name);
>  int security_file_permission(struct file *file, int mask);
>  int security_file_alloc(struct file *file);
>  void security_file_free(struct file *file);
> @@ -764,6 +765,11 @@ static inline int security_inode_copy_up(struct dentry 
> *src, struct cred **new)
>   return 0;
>  }
>  
> +static inline int security_inode_copy_up_xattr(const char *name)
> +{
> + -EOPNOTSUPP;

return?

> +}
> +
>  static inline int security_file_permission(struct file *file, int mask)
>  {
>   return 0;
> diff --git a/security/security.c b/security/security.c
> index 3d142aa..3321e31 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -733,6 +733,12 @@ int security_inode_copy_up(struct dentry *src, struct 
> cred **new)
>  }
>  EXPORT_SYMBOL(security_inode_copy_up);
>  
> +int security_inode_copy_up_xattr(const char *name)
> +{
> + return call_int_hook(inode_copy_up_xattr, -EOPNOTSUPP, name);
> +}
> 

[tip:irq/core] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

[tip-bot for Alexander Popov]

Commit-ID:  a1b7b1a57b9919a0abb6c93fca04ac9cf840c992
Gitweb: http://git.kernel.org/tip/a1b7b1a57b9919a0abb6c93fca04ac9cf840c992
Author: Alexander Popov 
AuthorDate: Sun, 3 Jul 2016 03:24:08 +0300
Committer:  Thomas Gleixner 
CommitDate: Mon, 11 Jul 2016 17:23:48 +0200

irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive()
for its parent has returned an error, then do return and avoid calling
irq_domain_free_irqs_recursive() uselessly, because:
- if domain->ops->alloc() had failed for an auto-recursive irq_domain,
   then irq_domain_free_irqs_recursive() had already been called;
- if domain->ops->alloc() had failed for a not auto-recursive irq_domain,
   then there is nothing to free at all.

Signed-off-by: Alexander Popov 
Acked-by: Marc Zyngier 
Link: 
http://lkml.kernel.org/r/1467505448-2850-1-git-send-email-alex.po...@linux.com
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/irqdomain.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index a828537..4752b43 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1192,8 +1192,10 @@ int irq_domain_alloc_irqs_recursive(struct irq_domain 
*domain,
if (recursive)
ret = irq_domain_alloc_irqs_recursive(parent, irq_base,
  nr_irqs, arg);
-   if (ret >= 0)
-   ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
+   if (ret < 0)
+   return ret;
+
+   ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
if (ret < 0 && recursive)
irq_domain_free_irqs_recursive(parent, irq_base, nr_irqs);
 

[tip:irq/core] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

[tip-bot for Alexander Popov]

Commit-ID:  a1b7b1a57b9919a0abb6c93fca04ac9cf840c992
Gitweb: http://git.kernel.org/tip/a1b7b1a57b9919a0abb6c93fca04ac9cf840c992
Author: Alexander Popov 
AuthorDate: Sun, 3 Jul 2016 03:24:08 +0300
Committer:  Thomas Gleixner 
CommitDate: Mon, 11 Jul 2016 17:23:48 +0200

irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive()
for its parent has returned an error, then do return and avoid calling
irq_domain_free_irqs_recursive() uselessly, because:
- if domain->ops->alloc() had failed for an auto-recursive irq_domain,
   then irq_domain_free_irqs_recursive() had already been called;
- if domain->ops->alloc() had failed for a not auto-recursive irq_domain,
   then there is nothing to free at all.

Signed-off-by: Alexander Popov 
Acked-by: Marc Zyngier 
Link: 
http://lkml.kernel.org/r/1467505448-2850-1-git-send-email-alex.po...@linux.com
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/irqdomain.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index a828537..4752b43 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1192,8 +1192,10 @@ int irq_domain_alloc_irqs_recursive(struct irq_domain 
*domain,
if (recursive)
ret = irq_domain_alloc_irqs_recursive(parent, irq_base,
  nr_irqs, arg);
-   if (ret >= 0)
-   ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
+   if (ret < 0)
+   return ret;
+
+   ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
if (ret < 0 && recursive)
irq_domain_free_irqs_recursive(parent, irq_base, nr_irqs);
 

[tip:timers/urgent] posix_cpu_timer: Exit early when process has been reaped

[tip-bot for Alexey Dobriyan]

Commit-ID:  2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307
Gitweb: http://git.kernel.org/tip/2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307
Author: Alexey Dobriyan 
AuthorDate: Fri, 8 Jul 2016 01:39:11 +0300
Committer:  Thomas Gleixner 
CommitDate: Mon, 11 Jul 2016 17:20:12 +0200

posix_cpu_timer: Exit early when process has been reaped

Variable "now" seems to be genuinely used unintialized
if branch

if (CPUCLOCK_PERTHREAD(timer->it_clock)) {

is not taken and branch

if (unlikely(sighand == NULL)) {

is taken. In this case the process has been reaped and the timer is marked as
disarmed anyway. So none of the postprocessing of the sample is
required. Return right away.

Signed-off-by: Alexey Dobriyan 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20160707223911.ga26...@p183.telecom.by
Signed-off-by: Thomas Gleixner 
---
 kernel/time/posix-cpu-timers.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 1cafba8..39008d7 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -777,6 +777,7 @@ static void posix_cpu_timer_get(struct k_itimer *timer, 
struct itimerspec *itp)
timer->it.cpu.expires = 0;
sample_to_timespec(timer->it_clock, 
timer->it.cpu.expires,
   >it_value);
+   return;
} else {
cpu_timer_sample_group(timer->it_clock, p, );
unlock_task_sighand(p, );

[tip:timers/urgent] posix_cpu_timer: Exit early when process has been reaped

[tip-bot for Alexey Dobriyan]

Commit-ID:  2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307
Gitweb: http://git.kernel.org/tip/2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307
Author: Alexey Dobriyan 
AuthorDate: Fri, 8 Jul 2016 01:39:11 +0300
Committer:  Thomas Gleixner 
CommitDate: Mon, 11 Jul 2016 17:20:12 +0200

posix_cpu_timer: Exit early when process has been reaped

Variable "now" seems to be genuinely used unintialized
if branch

if (CPUCLOCK_PERTHREAD(timer->it_clock)) {

is not taken and branch

if (unlikely(sighand == NULL)) {

is taken. In this case the process has been reaped and the timer is marked as
disarmed anyway. So none of the postprocessing of the sample is
required. Return right away.

Signed-off-by: Alexey Dobriyan 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20160707223911.ga26...@p183.telecom.by
Signed-off-by: Thomas Gleixner 
---
 kernel/time/posix-cpu-timers.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 1cafba8..39008d7 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -777,6 +777,7 @@ static void posix_cpu_timer_get(struct k_itimer *timer, 
struct itimerspec *itp)
timer->it.cpu.expires = 0;
sample_to_timespec(timer->it_clock, 
timer->it.cpu.expires,
   >it_value);
+   return;
} else {
cpu_timer_sample_group(timer->it_clock, p, );
unlock_task_sighand(p, );

[PATCH 3/3] iio: proximity: as3935: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/proximity/as3935.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
index 2e3a70e..5656deb 100644
--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -397,7 +397,7 @@ static int as3935_probe(struct spi_device *spi)
return ret;
}
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
_trigger_handler, NULL);
 
if (ret) {
-- 
2.1.4

[PATCH 3/3] iio: proximity: as3935: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/proximity/as3935.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
index 2e3a70e..5656deb 100644
--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -397,7 +397,7 @@ static int as3935_probe(struct spi_device *spi)
return ret;
}
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
_trigger_handler, NULL);
 
if (ret) {
-- 
2.1.4

[PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/am2315.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
index 3e200f6..ff96b6d 100644
--- a/drivers/iio/humidity/am2315.c
+++ b/drivers/iio/humidity/am2315.c
@@ -244,7 +244,7 @@ static int am2315_probe(struct i2c_client *client,
indio_dev->channels = am2315_channels;
indio_dev->num_channels = ARRAY_SIZE(am2315_channels);
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
 am2315_trigger_handler, NULL);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
-- 
2.1.4

[PATCH 2/3] iio: humidity: am2315: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/am2315.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
index 3e200f6..ff96b6d 100644
--- a/drivers/iio/humidity/am2315.c
+++ b/drivers/iio/humidity/am2315.c
@@ -244,7 +244,7 @@ static int am2315_probe(struct i2c_client *client,
indio_dev->channels = am2315_channels;
indio_dev->num_channels = ARRAY_SIZE(am2315_channels);
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
 am2315_trigger_handler, NULL);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
-- 
2.1.4

Re: [PATCH] ARM: dts: da850: Add new ECAP and EPWM bindings

[Franklin S Cooper Jr.]

On 07/04/2016 07:47 AM, Sekhar Nori wrote:
> On Monday 27 June 2016 07:44 PM, Franklin S Cooper Jr wrote:
>> From: "Cooper Jr., Franklin" 
>>
>> Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to
>> provide the various required clocks.
> 
> there is nothing called hwmod on da850, so this need rewording to make
> sense for that platform.

Sorry will fix.
> 
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> Acked-by: Rob Herring 
> 
> Also, documentation needs update as well since it says:
> 
> "
> for da850  - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm"
> "
> 

The original patch that Tony pulled in already includes this
documentation update for the new bindings. This patch just handles the
DA850 DT changes that didn't apply when Tony pulled in the original patch.

> Thanks,
> Sekhar
> 

[PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/accel/bma220_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/accel/bma220_spi.c b/drivers/iio/accel/bma220_spi.c
index 1098d10..5099f29 100644
--- a/drivers/iio/accel/bma220_spi.c
+++ b/drivers/iio/accel/bma220_spi.c
@@ -253,7 +253,7 @@ static int bma220_probe(struct spi_device *spi)
if (ret < 0)
return ret;
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
 bma220_trigger_handler, NULL);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
-- 
2.1.4

Re: [PATCH] ARM: dts: da850: Add new ECAP and EPWM bindings

[Franklin S Cooper Jr.]

On 07/04/2016 07:47 AM, Sekhar Nori wrote:
> On Monday 27 June 2016 07:44 PM, Franklin S Cooper Jr wrote:
>> From: "Cooper Jr., Franklin" 
>>
>> Switch to a new ECAP and EPWM bindings that doesn't depend on hwmod to
>> provide the various required clocks.
> 
> there is nothing called hwmod on da850, so this need rewording to make
> sense for that platform.

Sorry will fix.
> 
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> Acked-by: Rob Herring 
> 
> Also, documentation needs update as well since it says:
> 
> "
> for da850  - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm"
> "
> 

The original patch that Tony pulled in already includes this
documentation update for the new bindings. This patch just handles the
DA850 DT changes that didn't apply when Tony pulled in the original patch.

> Thanks,
> Sekhar
> 

[PATCH 1/3] iio: accel: bma220_spi: set up buffer timestamps for non-zero values

[Alison Schofield]

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/accel/bma220_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/accel/bma220_spi.c b/drivers/iio/accel/bma220_spi.c
index 1098d10..5099f29 100644
--- a/drivers/iio/accel/bma220_spi.c
+++ b/drivers/iio/accel/bma220_spi.c
@@ -253,7 +253,7 @@ static int bma220_probe(struct spi_device *spi)
if (ret < 0)
return ret;
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
 bma220_trigger_handler, NULL);
if (ret < 0) {
dev_err(>dev, "iio triggered buffer setup failed\n");
-- 
2.1.4

Re: [PATCH] capabilities: audit capability use

[Serge E. Hallyn]

Quoting Topi Miettinen (toiwo...@gmail.com):
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
> 
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
> 
> Generate an audit message at system call exit, when capabilities are used.
> This can then be used to configure capability sets for services by a
> software developer, maintainer or system administrator.
> 
> Test case demonstrating basic capability monitoring with the new
> message types 1330 and 1331 and how the cgroups are displayed (boot to
> rdshell):

Thanks, Topi, I'll find time this week to look this over in detail.

How much chattier does this make the syslog/journald during a regular
boot?  I was thinking "this is audit, we can choose what messages
will show up", but I guess that' sonly what auditd actually listens to,
not what kernel emits?  (sorry i've not looked at audit in a long
time).  Drat, that makes it seem like tracepoints would be better
after all.  But let's see how much it addes to the noise.

> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
> 
> (initramfs) cd /sys/fs
> (initramfs) mount -t cgroup2 cgroup cgroup
> [   12.343152] audit_printk_skb: 5886 callbacks suppressed
> [   12.355214] audit: type=1300 audit(1468234317.100:518): arch=c03e 
> syscall=165 success=yes exit=0 a0=7fffe1e9ae2d a1=7fffe1e9ae34 
> a2=7fffe1e9ae25 a3=8000 items=0 ppid=469 pid=470 auid=4294967295 uid=0 gid=0 
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 
> comm="mount" exe="/bin/mount" key=(null)
> [   12.414853] audit: type=1327 audit(1468234317.100:518): 
> proctitle=6D6F756E74002D74006367726F757032006367726F7570006367726F7570
> [   12.438338] audit: type=1330 audit(1468234317.100:518): 
> cap_used=0020
> [   12.453893] audit: type=1331 audit(1468234317.100:518): cgroups=:/;
> (initramfs) cd cgroup
> (initramfs) mkdir test; cd test
> [   17.335625] audit: type=1300 audit(1468234322.092:519): arch=c03e 
> syscall=83 success=yes exit=0 a0=7ffddfd75e29 a1=1ff a2=0 a3=1e2 items=0 
> ppid=469 pid=471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mkdir" exe="/bin/mkdir" 
> key=(null)
> [   17.392686] audit: type=1327 audit(1468234322.092:519): 
> proctitle=6D6B6469720074657374
> [   17.409404] audit: type=1330 audit(1468234322.092:519): 
> cap_used=0002
> [   17.425404] audit: type=1331 audit(1468234322.092:519): cgroups=:/;
> (initramfs) echo $$ >cgroup.procs
> (initramfs) mknod /dev/z_$$ c 1 2
> [   28.385681] audit: type=1300 audit(1468234333.144:520): arch=c03e 
> syscall=133 success=yes exit=0 a0=7ffe16324e11 a1=21b6 a2=102 a3=5c9 items=0 
> ppid=469 pid=472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mknod" exe="/bin/mknod" 
> key=(null)
> [   28.443674] audit: type=1327 audit(1468234333.144:520): 
> proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032
> [   28.465888] audit: type=1330 audit(1468234333.144:520): 
> cap_used=0800
> [   28.482080] audit: type=1331 audit(1468234333.144:520): cgroups=:/test;
> (initramfs) chown 1234 /dev/z_*
> [   34.772992] audit: type=1300 audit(1468234339.532:521): arch=c03e 
> syscall=92 success=yes exit=0 a0=7ffd0b563e17 a1=4d2 a2=0 a3=60a items=0 
> ppid=469 pid=473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="chown" exe="/bin/chown" 
> key=(null)
> [   34.828569] audit: type=1327 audit(1468234339.532:521): 
> proctitle=63686F776E0031323334002F6465762F7A5F343639
> [   34.848747] audit: type=1330 audit(1468234339.532:521): 
> cap_used=0001
> [   34.864404] audit: type=1331 audit(1468234339.532:521): cgroups=:/test;
> 
> Signed-off-by: Topi Miettinen 
> ---
>  include/linux/audit.h  |  4 +++
>  include/linux/cgroup.h |  2 ++
>  include/uapi/linux/audit.h |  2 ++
>  kernel/audit.c |  7 +++---
>  kernel/audit.h |  1 +
>  kernel/auditsc.c   | 28 -
>  kernel/capability.c|  5 ++--
>  kernel/cgroup.c| 62 
> ++
>  8 files changed, 105 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index e38e3fc..971cb2e 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -438,6 +438,8 @@ static inline void audit_mmap_fd(int fd, int flags)
>   __audit_mmap_fd(fd, flags);
>  }
>  
> +extern void audit_log_cap_use(int cap);
> +
>  extern int 

Re: [PATCH] capabilities: audit capability use

[Serge E. Hallyn]

Quoting Topi Miettinen (toiwo...@gmail.com):
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
> 
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
> 
> Generate an audit message at system call exit, when capabilities are used.
> This can then be used to configure capability sets for services by a
> software developer, maintainer or system administrator.
> 
> Test case demonstrating basic capability monitoring with the new
> message types 1330 and 1331 and how the cgroups are displayed (boot to
> rdshell):

Thanks, Topi, I'll find time this week to look this over in detail.

How much chattier does this make the syslog/journald during a regular
boot?  I was thinking "this is audit, we can choose what messages
will show up", but I guess that' sonly what auditd actually listens to,
not what kernel emits?  (sorry i've not looked at audit in a long
time).  Drat, that makes it seem like tracepoints would be better
after all.  But let's see how much it addes to the noise.

> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
> 
> (initramfs) cd /sys/fs
> (initramfs) mount -t cgroup2 cgroup cgroup
> [   12.343152] audit_printk_skb: 5886 callbacks suppressed
> [   12.355214] audit: type=1300 audit(1468234317.100:518): arch=c03e 
> syscall=165 success=yes exit=0 a0=7fffe1e9ae2d a1=7fffe1e9ae34 
> a2=7fffe1e9ae25 a3=8000 items=0 ppid=469 pid=470 auid=4294967295 uid=0 gid=0 
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 
> comm="mount" exe="/bin/mount" key=(null)
> [   12.414853] audit: type=1327 audit(1468234317.100:518): 
> proctitle=6D6F756E74002D74006367726F757032006367726F7570006367726F7570
> [   12.438338] audit: type=1330 audit(1468234317.100:518): 
> cap_used=0020
> [   12.453893] audit: type=1331 audit(1468234317.100:518): cgroups=:/;
> (initramfs) cd cgroup
> (initramfs) mkdir test; cd test
> [   17.335625] audit: type=1300 audit(1468234322.092:519): arch=c03e 
> syscall=83 success=yes exit=0 a0=7ffddfd75e29 a1=1ff a2=0 a3=1e2 items=0 
> ppid=469 pid=471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mkdir" exe="/bin/mkdir" 
> key=(null)
> [   17.392686] audit: type=1327 audit(1468234322.092:519): 
> proctitle=6D6B6469720074657374
> [   17.409404] audit: type=1330 audit(1468234322.092:519): 
> cap_used=0002
> [   17.425404] audit: type=1331 audit(1468234322.092:519): cgroups=:/;
> (initramfs) echo $$ >cgroup.procs
> (initramfs) mknod /dev/z_$$ c 1 2
> [   28.385681] audit: type=1300 audit(1468234333.144:520): arch=c03e 
> syscall=133 success=yes exit=0 a0=7ffe16324e11 a1=21b6 a2=102 a3=5c9 items=0 
> ppid=469 pid=472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="mknod" exe="/bin/mknod" 
> key=(null)
> [   28.443674] audit: type=1327 audit(1468234333.144:520): 
> proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032
> [   28.465888] audit: type=1330 audit(1468234333.144:520): 
> cap_used=0800
> [   28.482080] audit: type=1331 audit(1468234333.144:520): cgroups=:/test;
> (initramfs) chown 1234 /dev/z_*
> [   34.772992] audit: type=1300 audit(1468234339.532:521): arch=c03e 
> syscall=92 success=yes exit=0 a0=7ffd0b563e17 a1=4d2 a2=0 a3=60a items=0 
> ppid=469 pid=473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=ttyS0 ses=4294967295 comm="chown" exe="/bin/chown" 
> key=(null)
> [   34.828569] audit: type=1327 audit(1468234339.532:521): 
> proctitle=63686F776E0031323334002F6465762F7A5F343639
> [   34.848747] audit: type=1330 audit(1468234339.532:521): 
> cap_used=0001
> [   34.864404] audit: type=1331 audit(1468234339.532:521): cgroups=:/test;
> 
> Signed-off-by: Topi Miettinen 
> ---
>  include/linux/audit.h  |  4 +++
>  include/linux/cgroup.h |  2 ++
>  include/uapi/linux/audit.h |  2 ++
>  kernel/audit.c |  7 +++---
>  kernel/audit.h |  1 +
>  kernel/auditsc.c   | 28 -
>  kernel/capability.c|  5 ++--
>  kernel/cgroup.c| 62 
> ++
>  8 files changed, 105 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index e38e3fc..971cb2e 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -438,6 +438,8 @@ static inline void audit_mmap_fd(int fd, int flags)
>   __audit_mmap_fd(fd, flags);
>  }
>  
> +extern void audit_log_cap_use(int cap);
> +
>  extern int audit_n_rules;
>  

[PATCH 0/3] iio: complete the setup of buffer timestamps

[Alison Schofield]

These drivers are using iio_poll_func->timestamp in their triggered buffer
handler as the timestamp pushed to buffer.  Problem is that it was not set up
at probe time via iio_triggered_buffer_setup(), so timestamp is always 0.

Buffer space has been allocated for the timestamp, so it seems to be
wanted.  

These patches make the fix io_triggered_buffer_setup() during probe by
passing the iio_pollfunc_store_time parameter.

Alternative change would be to use iio_get_time_ns() directly in the
push_to_buffers call in the handler.  We can do this if you are not
one of those "devices (who) need a timestamp grabbed as soon as possible
after the trigger" (from iio_poll_func definition)

Either way you are using iio_get_tme_ns(), it's just a question of when.  
Let me know if you'd rather go the slower way.


Alison Schofield (3):
  iio: accel: bma220_spi: set up buffer timestamps for non-zero values
  iio: humidity: am2315: set up buffer timestamps for non-zero values
  iio: proximity: as3935: set up buffer timestamps for non-zero values

 drivers/iio/accel/bma220_spi.c | 2 +-
 drivers/iio/humidity/am2315.c  | 2 +-
 drivers/iio/proximity/as3935.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.1.4

Re: [PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

[Robin Murphy]

On 09/07/16 03:09, Mitchel Humpherys wrote:
> The PL330 can perform privileged instruction fetches.  This can result

Nit: "can" is a bit of an understatement. Instruction fetches on both
the manager and channel threads have the "privileged" and "instruction"
AxPROT bits hard-coded whether you like it or not. It's only the data
accesses by the channel threads which are in any way configurable.

Robin.

> in SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
> specifies that mappings that are writeable at one execution level shall
> not be executable at any higher-privileged level.  Fix this by using the
> DMA_ATTR_PRIVILEGED_EXECUTABLE attribute, which will ensure that the
> microcode IOMMU mapping is not writeable.
> 
> Cc: Dan Williams 
> Cc: Jassi Brar 
> Signed-off-by: Mitchel Humpherys 
> ---
>  drivers/dma/pl330.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 372b4359da97..25bc49d47c45 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -1854,14 +1854,17 @@ static int dmac_alloc_resources(struct pl330_dmac 
> *pl330)
>  {
>   int chans = pl330->pcfg.num_chan;
>   int ret;
> + DEFINE_DMA_ATTRS(attrs);
>  
> + dma_set_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, );
>   /*
>* Alloc MicroCode buffer for 'chans' Channel threads.
>* A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
>*/
> - pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
> + pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
>   chans * pl330->mcbufsz,
> - >mcode_bus, GFP_KERNEL);
> + >mcode_bus, GFP_KERNEL,
> + );
>   if (!pl330->mcode_cpu) {
>   dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
>   __func__, __LINE__);
> 

[PATCH 0/3] iio: complete the setup of buffer timestamps

[Alison Schofield]

These drivers are using iio_poll_func->timestamp in their triggered buffer
handler as the timestamp pushed to buffer.  Problem is that it was not set up
at probe time via iio_triggered_buffer_setup(), so timestamp is always 0.

Buffer space has been allocated for the timestamp, so it seems to be
wanted.  

These patches make the fix io_triggered_buffer_setup() during probe by
passing the iio_pollfunc_store_time parameter.

Alternative change would be to use iio_get_time_ns() directly in the
push_to_buffers call in the handler.  We can do this if you are not
one of those "devices (who) need a timestamp grabbed as soon as possible
after the trigger" (from iio_poll_func definition)

Either way you are using iio_get_tme_ns(), it's just a question of when.  
Let me know if you'd rather go the slower way.


Alison Schofield (3):
  iio: accel: bma220_spi: set up buffer timestamps for non-zero values
  iio: humidity: am2315: set up buffer timestamps for non-zero values
  iio: proximity: as3935: set up buffer timestamps for non-zero values

 drivers/iio/accel/bma220_spi.c | 2 +-
 drivers/iio/humidity/am2315.c  | 2 +-
 drivers/iio/proximity/as3935.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.1.4

Re: [PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

[Robin Murphy]

On 09/07/16 03:09, Mitchel Humpherys wrote:
> The PL330 can perform privileged instruction fetches.  This can result

Nit: "can" is a bit of an understatement. Instruction fetches on both
the manager and channel threads have the "privileged" and "instruction"
AxPROT bits hard-coded whether you like it or not. It's only the data
accesses by the channel threads which are in any way configurable.

Robin.

> in SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
> specifies that mappings that are writeable at one execution level shall
> not be executable at any higher-privileged level.  Fix this by using the
> DMA_ATTR_PRIVILEGED_EXECUTABLE attribute, which will ensure that the
> microcode IOMMU mapping is not writeable.
> 
> Cc: Dan Williams 
> Cc: Jassi Brar 
> Signed-off-by: Mitchel Humpherys 
> ---
>  drivers/dma/pl330.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 372b4359da97..25bc49d47c45 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -1854,14 +1854,17 @@ static int dmac_alloc_resources(struct pl330_dmac 
> *pl330)
>  {
>   int chans = pl330->pcfg.num_chan;
>   int ret;
> + DEFINE_DMA_ATTRS(attrs);
>  
> + dma_set_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, );
>   /*
>* Alloc MicroCode buffer for 'chans' Channel threads.
>* A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
>*/
> - pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
> + pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
>   chans * pl330->mcbufsz,
> - >mcode_bus, GFP_KERNEL);
> + >mcode_bus, GFP_KERNEL,
> + );
>   if (!pl330->mcode_cpu) {
>   dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
>   __func__, __LINE__);
> 

Re: [PATCH 1/7] security, overlayfs: provide copy up security hook for unioned files

[Stephen Smalley]

On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook to label new file correctly when a file is copied
> up from lower layer to upper layer of a overlay/union mount.
> 
> This hook can prepare a new set of creds which are suitable for new file
> creation during copy up. Caller will use new creds to create file and then
> revert back to old creds and release new creds.
> 
> Signed-off-by: Vivek Goyal 
> ---
>  fs/overlayfs/copy_up.c| 18 ++
>  include/linux/lsm_hooks.h | 11 +++
>  include/linux/security.h  |  6 ++
>  security/security.c   |  8 
>  4 files changed, 43 insertions(+)
> 
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 80aa6f1..8ebea18 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -246,6 +246,8 @@ static int ovl_copy_up_locked(struct dentry *workdir, 
> struct dentry *upperdir,
>   struct dentry *upper = NULL;
>   umode_t mode = stat->mode;
>   int err;
> + const struct cred *old_creds = NULL;
> + struct cred *new_creds = NULL;
>  
>   newdentry = ovl_lookup_temp(workdir, dentry);
>   err = PTR_ERR(newdentry);
> @@ -258,10 +260,26 @@ static int ovl_copy_up_locked(struct dentry *workdir, 
> struct dentry *upperdir,
>   if (IS_ERR(upper))
>   goto out1;
>  
> + err = security_inode_copy_up(dentry, _creds);
> + if (err < 0) {
> + if (new_creds)
> + put_cred(new_creds);

Why do we need a put_cred() here?

> + goto out2;
> + }
> +
> + if (new_creds)
> + old_creds = override_creds(new_creds);
> +
>   /* Can't properly set mode on creation because of the umask */
>   stat->mode &= S_IFMT;
>   err = ovl_create_real(wdir, newdentry, stat, link, NULL, true);
>   stat->mode = mode;
> +
> + if (new_creds) {
> + revert_creds(old_creds);
> + put_cred(new_creds);
> + }
> +
>   if (err)
>   goto out2;
>  
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 7ae3976..c1f95be 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -401,6 +401,15 @@
>   *   @inode contains a pointer to the inode.
>   *   @secid contains a pointer to the location where result will be saved.
>   *   In case of failure, @secid will be set to zero.
> + * @inode_copy_up:
> + *   A file is about to be copied up from lower layer to upper layer of
> + *   overlay filesystem. Security module can prepare a set of new creds
> + *   and modify as need be and return new creds. Caller will switch to
> + *   new creds temporarily to create new file and release newly allocated
> + *   creds.
> + *   @src indicates the union dentry of file that is being copied up.
> + *   @new pointer to pointer to return newly allocated creds.
> + *   Returns 0 on success or a negative error code on error.
>   *
>   * Security hooks for file operations
>   *
> @@ -1425,6 +1434,7 @@ union security_list_options {
>   int (*inode_listsecurity)(struct inode *inode, char *buffer,
>   size_t buffer_size);
>   void (*inode_getsecid)(struct inode *inode, u32 *secid);
> + int (*inode_copy_up) (struct dentry *src, struct cred **new);
>  
>   int (*file_permission)(struct file *file, int mask);
>   int (*file_alloc_security)(struct file *file);
> @@ -1696,6 +1706,7 @@ struct security_hook_heads {
>   struct list_head inode_setsecurity;
>   struct list_head inode_listsecurity;
>   struct list_head inode_getsecid;
> + struct list_head inode_copy_up;
>   struct list_head file_permission;
>   struct list_head file_alloc_security;
>   struct list_head file_free_security;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 14df373..c976d79 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -282,6 +282,7 @@ int security_inode_getsecurity(struct inode *inode, const 
> char *name, void **buf
>  int security_inode_setsecurity(struct inode *inode, const char *name, const 
> void *value, size_t size, int flags);
>  int security_inode_listsecurity(struct inode *inode, char *buffer, size_t 
> buffer_size);
>  void security_inode_getsecid(struct inode *inode, u32 *secid);
> +int security_inode_copy_up(struct dentry *src, struct cred **new);
>  int security_file_permission(struct file *file, int mask);
>  int security_file_alloc(struct file *file);
>  void security_file_free(struct file *file);
> @@ -758,6 +759,11 @@ static inline void security_inode_getsecid(struct inode 
> *inode, u32 *secid)
>   *secid = 0;
>  }
>  
> +static inline int security_inode_copy_up(struct dentry *src, struct cred 
> **new)
> +{
> + return 0;
> +}
> +
>  static inline int security_file_permission(struct file *file, int mask)
>  {
>   return 0;
> diff --git a/security/security.c b/security/security.c
> index 

Re: [PATCH 1/7] security, overlayfs: provide copy up security hook for unioned files

[Stephen Smalley]

On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook to label new file correctly when a file is copied
> up from lower layer to upper layer of a overlay/union mount.
> 
> This hook can prepare a new set of creds which are suitable for new file
> creation during copy up. Caller will use new creds to create file and then
> revert back to old creds and release new creds.
> 
> Signed-off-by: Vivek Goyal 
> ---
>  fs/overlayfs/copy_up.c| 18 ++
>  include/linux/lsm_hooks.h | 11 +++
>  include/linux/security.h  |  6 ++
>  security/security.c   |  8 
>  4 files changed, 43 insertions(+)
> 
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 80aa6f1..8ebea18 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -246,6 +246,8 @@ static int ovl_copy_up_locked(struct dentry *workdir, 
> struct dentry *upperdir,
>   struct dentry *upper = NULL;
>   umode_t mode = stat->mode;
>   int err;
> + const struct cred *old_creds = NULL;
> + struct cred *new_creds = NULL;
>  
>   newdentry = ovl_lookup_temp(workdir, dentry);
>   err = PTR_ERR(newdentry);
> @@ -258,10 +260,26 @@ static int ovl_copy_up_locked(struct dentry *workdir, 
> struct dentry *upperdir,
>   if (IS_ERR(upper))
>   goto out1;
>  
> + err = security_inode_copy_up(dentry, _creds);
> + if (err < 0) {
> + if (new_creds)
> + put_cred(new_creds);

Why do we need a put_cred() here?

> + goto out2;
> + }
> +
> + if (new_creds)
> + old_creds = override_creds(new_creds);
> +
>   /* Can't properly set mode on creation because of the umask */
>   stat->mode &= S_IFMT;
>   err = ovl_create_real(wdir, newdentry, stat, link, NULL, true);
>   stat->mode = mode;
> +
> + if (new_creds) {
> + revert_creds(old_creds);
> + put_cred(new_creds);
> + }
> +
>   if (err)
>   goto out2;
>  
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 7ae3976..c1f95be 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -401,6 +401,15 @@
>   *   @inode contains a pointer to the inode.
>   *   @secid contains a pointer to the location where result will be saved.
>   *   In case of failure, @secid will be set to zero.
> + * @inode_copy_up:
> + *   A file is about to be copied up from lower layer to upper layer of
> + *   overlay filesystem. Security module can prepare a set of new creds
> + *   and modify as need be and return new creds. Caller will switch to
> + *   new creds temporarily to create new file and release newly allocated
> + *   creds.
> + *   @src indicates the union dentry of file that is being copied up.
> + *   @new pointer to pointer to return newly allocated creds.
> + *   Returns 0 on success or a negative error code on error.
>   *
>   * Security hooks for file operations
>   *
> @@ -1425,6 +1434,7 @@ union security_list_options {
>   int (*inode_listsecurity)(struct inode *inode, char *buffer,
>   size_t buffer_size);
>   void (*inode_getsecid)(struct inode *inode, u32 *secid);
> + int (*inode_copy_up) (struct dentry *src, struct cred **new);
>  
>   int (*file_permission)(struct file *file, int mask);
>   int (*file_alloc_security)(struct file *file);
> @@ -1696,6 +1706,7 @@ struct security_hook_heads {
>   struct list_head inode_setsecurity;
>   struct list_head inode_listsecurity;
>   struct list_head inode_getsecid;
> + struct list_head inode_copy_up;
>   struct list_head file_permission;
>   struct list_head file_alloc_security;
>   struct list_head file_free_security;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 14df373..c976d79 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -282,6 +282,7 @@ int security_inode_getsecurity(struct inode *inode, const 
> char *name, void **buf
>  int security_inode_setsecurity(struct inode *inode, const char *name, const 
> void *value, size_t size, int flags);
>  int security_inode_listsecurity(struct inode *inode, char *buffer, size_t 
> buffer_size);
>  void security_inode_getsecid(struct inode *inode, u32 *secid);
> +int security_inode_copy_up(struct dentry *src, struct cred **new);
>  int security_file_permission(struct file *file, int mask);
>  int security_file_alloc(struct file *file);
>  void security_file_free(struct file *file);
> @@ -758,6 +759,11 @@ static inline void security_inode_getsecid(struct inode 
> *inode, u32 *secid)
>   *secid = 0;
>  }
>  
> +static inline int security_inode_copy_up(struct dentry *src, struct cred 
> **new)
> +{
> + return 0;
> +}
> +
>  static inline int security_file_permission(struct file *file, int mask)
>  {
>   return 0;
> diff --git a/security/security.c b/security/security.c
> index 7095693..3d142aa 100644
> 

Re: [PATCH 00/30] ACPICA: 20160318 Release

[Matthias Brugger]

On 11/07/16 16:54, Rafael J. Wysocki wrote:

On Monday, July 11, 2016 04:48:26 PM Rafael J. Wysocki wrote:

On Monday, July 11, 2016 04:38:17 PM Matthias Brugger wrote:

Hi Rafael,

On 24/03/16 14:08, Rafael J. Wysocki wrote:

On Thu, Mar 24, 2016 at 2:38 AM, Lv Zheng  wrote:

The 20160318 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
 All hardware drivers related to the machines of i386/x86_64
 All "drivers/acpi" configurations
 All "drivers/platform" drivers
 All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160212 Release):
506 lines
After applying (20160318 Release):
494 lines

Al Stone (1):
ACPICA: IORT: Add in support for the SMMUv3 subtable

Aleksey Makarov (1):


Bob Moore (16):
ACPICA: Headers: Minor update for SPCR ACPI table
ACPICA: ACPI 6.1: Updates for the HEST ACPI table
ACPICA: ACPI 6.1: Update NFIT table for additional new fields
ACPICA: Headers: Update DMAR table for October 2014 I/O spec
ACPICA: Tables: Update FADT handling
ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
ACPICA: iASL/Headers: Fix incorrect definition of FPDT table
ACPICA: Intepreter: Add object extensions to Concatenate operand
ACPICA: Interpreter: Update some function headers, no functional
  change
ACPICA: iASL: Cleanup/optimization for ToPLD macro support
ACPICA: Cleanup some invocation indentations, no functional change
ACPICA: Headers: Update generation of the ACPICA library
ACPICA: Utilities: Update for strtoul64 merger
ACPICA: All: const keyword changes across the ACPICA source
ACPICA: iASL/Disassembler: Improve handling of unresolved methods
ACPICA: Update version to 20160318

Lv Zheng (11):
ACPICA: Linuxize: reduce divergences for 20160212 release
ACPICA: Linuxize: Remove useless platform headers
ACPICA: Utilities: Add ACPI_IS_POWER_OF_TWO()
Utilities: Fix missing parentheses in ACPI_GET_BITS()/ACPI_SET_BITS()
ACPICA: Hardware: Enhance acpi_hw_validate_register() with
  access_width/bit_offset awareness
ACPICA: Hardware: Add access_width/bit_offset support in
  acpi_hw_read()
ACPICA: Hardware: Add access_width/bit_offset support for
  acpi_hw_write()
ACPICA: Interpreter: Fix wrong conditions for
  acpi_ev_install_region_handlers() invocation
ACPICA: Tables: Fix wrong MLC condition for dynamic table loading
ACPICA: Events: Fix an issue that _REG association can happen before
  namespace is initialized
ACPICA: Namespace: Reorder \_SB._INI to make sure it is evaluated
  before _REG evaluations

Will Miles (1):
ACPICA: Add support for QNX 6.6 platform


This is too late to go in during the current merge window, but I'll
queue it up and send a separate pull request for 4.6 with it next
week.

I'll fix up the whitespace breakage in the first patch (it is easy
enough to fix up manually), but as Len said, please fix the process to
avoid such things in the future.



I wasn't able to spot this series in linux-next, epsecially patch 03/30:
"ACPICA: Headers: Add new constants for the DBG2 ACPI table"

Can you please clarify what happened?


It was in linux-next.  I'm not sure why you didn't spot it in there.


It wasn't in there before the merge window opened, though, which really
seems to be what your question is about, right?

In this particular case an ACPICA release happened right before the
opening of a merge window and the choice was to either push it regardless
or to defer it to the next merge window.

The latter is not really attractive, though, because it only causes the
delta between upstream ACPICA and the Linux kernel to grow and we get more
stuff in in one go.

Please note, though, that it had spent some time in linux-next during the
merge window before it was pushed.



Don't worry Rafael, I screwed up my branches, that's why I didn't found 
the patch I was looking for.


Thanks for your explication.
Matthias

Re: [PATCH 00/30] ACPICA: 20160318 Release

[Matthias Brugger]

On 11/07/16 16:54, Rafael J. Wysocki wrote:

On Monday, July 11, 2016 04:48:26 PM Rafael J. Wysocki wrote:

On Monday, July 11, 2016 04:38:17 PM Matthias Brugger wrote:

Hi Rafael,

On 24/03/16 14:08, Rafael J. Wysocki wrote:

On Thu, Mar 24, 2016 at 2:38 AM, Lv Zheng  wrote:

The 20160318 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
 All hardware drivers related to the machines of i386/x86_64
 All "drivers/acpi" configurations
 All "drivers/platform" drivers
 All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160212 Release):
506 lines
After applying (20160318 Release):
494 lines

Al Stone (1):
ACPICA: IORT: Add in support for the SMMUv3 subtable

Aleksey Makarov (1):


Bob Moore (16):
ACPICA: Headers: Minor update for SPCR ACPI table
ACPICA: ACPI 6.1: Updates for the HEST ACPI table
ACPICA: ACPI 6.1: Update NFIT table for additional new fields
ACPICA: Headers: Update DMAR table for October 2014 I/O spec
ACPICA: Tables: Update FADT handling
ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
ACPICA: iASL/Headers: Fix incorrect definition of FPDT table
ACPICA: Intepreter: Add object extensions to Concatenate operand
ACPICA: Interpreter: Update some function headers, no functional
  change
ACPICA: iASL: Cleanup/optimization for ToPLD macro support
ACPICA: Cleanup some invocation indentations, no functional change
ACPICA: Headers: Update generation of the ACPICA library
ACPICA: Utilities: Update for strtoul64 merger
ACPICA: All: const keyword changes across the ACPICA source
ACPICA: iASL/Disassembler: Improve handling of unresolved methods
ACPICA: Update version to 20160318

Lv Zheng (11):
ACPICA: Linuxize: reduce divergences for 20160212 release
ACPICA: Linuxize: Remove useless platform headers
ACPICA: Utilities: Add ACPI_IS_POWER_OF_TWO()
Utilities: Fix missing parentheses in ACPI_GET_BITS()/ACPI_SET_BITS()
ACPICA: Hardware: Enhance acpi_hw_validate_register() with
  access_width/bit_offset awareness
ACPICA: Hardware: Add access_width/bit_offset support in
  acpi_hw_read()
ACPICA: Hardware: Add access_width/bit_offset support for
  acpi_hw_write()
ACPICA: Interpreter: Fix wrong conditions for
  acpi_ev_install_region_handlers() invocation
ACPICA: Tables: Fix wrong MLC condition for dynamic table loading
ACPICA: Events: Fix an issue that _REG association can happen before
  namespace is initialized
ACPICA: Namespace: Reorder \_SB._INI to make sure it is evaluated
  before _REG evaluations

Will Miles (1):
ACPICA: Add support for QNX 6.6 platform


This is too late to go in during the current merge window, but I'll
queue it up and send a separate pull request for 4.6 with it next
week.

I'll fix up the whitespace breakage in the first patch (it is easy
enough to fix up manually), but as Len said, please fix the process to
avoid such things in the future.



I wasn't able to spot this series in linux-next, epsecially patch 03/30:
"ACPICA: Headers: Add new constants for the DBG2 ACPI table"

Can you please clarify what happened?


It was in linux-next.  I'm not sure why you didn't spot it in there.


It wasn't in there before the merge window opened, though, which really
seems to be what your question is about, right?

In this particular case an ACPICA release happened right before the
opening of a merge window and the choice was to either push it regardless
or to defer it to the next merge window.

The latter is not really attractive, though, because it only causes the
delta between upstream ACPICA and the Linux kernel to grow and we get more
stuff in in one go.

Please note, though, that it had spent some time in linux-next during the
merge window before it was pushed.



Don't worry Rafael, I screwed up my branches, that's why I didn't found 
the patch I was looking for.


Thanks for your explication.
Matthias

Re: [PATCH 1/1] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

[Marc Zyngier]

On 03/07/16 01:24, Alexander Popov wrote:
> If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive()
> for its parent has returned an error, then do return and avoid calling
> irq_domain_free_irqs_recursive() uselessly, because:
> - if domain->ops->alloc() had failed for an auto-recursive irq_domain,
>then irq_domain_free_irqs_recursive() had already been called;
> - if domain->ops->alloc() had failed for a not auto-recursive irq_domain,
>then there is nothing to free at all.
> 
> Signed-off-by: Alexander Popov 
> ---
>  kernel/irq/irqdomain.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 8798b6c..6458e34 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -1144,8 +1144,10 @@ int irq_domain_alloc_irqs_recursive(struct irq_domain 
> *domain,
>   if (recursive)
>   ret = irq_domain_alloc_irqs_recursive(parent, irq_base,
> nr_irqs, arg);
> - if (ret >= 0)
> - ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
>   if (ret < 0 && recursive)
>   irq_domain_free_irqs_recursive(parent, irq_base, nr_irqs);
>  
> 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 1/1] irqdomain: Fix irq_domain_alloc_irqs_recursive() error handling

[Marc Zyngier]

On 03/07/16 01:24, Alexander Popov wrote:
> If an irq_domain is auto-recursive and irq_domain_alloc_irqs_recursive()
> for its parent has returned an error, then do return and avoid calling
> irq_domain_free_irqs_recursive() uselessly, because:
> - if domain->ops->alloc() had failed for an auto-recursive irq_domain,
>then irq_domain_free_irqs_recursive() had already been called;
> - if domain->ops->alloc() had failed for a not auto-recursive irq_domain,
>then there is nothing to free at all.
> 
> Signed-off-by: Alexander Popov 
> ---
>  kernel/irq/irqdomain.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 8798b6c..6458e34 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -1144,8 +1144,10 @@ int irq_domain_alloc_irqs_recursive(struct irq_domain 
> *domain,
>   if (recursive)
>   ret = irq_domain_alloc_irqs_recursive(parent, irq_base,
> nr_irqs, arg);
> - if (ret >= 0)
> - ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + ret = domain->ops->alloc(domain, irq_base, nr_irqs, arg);
>   if (ret < 0 && recursive)
>   irq_domain_free_irqs_recursive(parent, irq_base, nr_irqs);
>  
> 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Prarit Bhargava]

Didn't get any feedback or review comments on this patch.  Resending ...

P.

---8<---

The iwlwifi driver implements a thermal zone and hwmon device, but
returns -EIO on temperature reads if the firmware isn't loaded.  This
results in the error

iwlwifi-virtual-0
Adapter: Virtual device
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A

being output when using sensors from the lm-sensors package.  Since
the temperature cannot be read unless the ucode is loaded there is no
reason to add the interface only to have it return an error 100% of
the time.

This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
stops the thermal zone from being created if the ucode hasn't been loaded.

Signed-off-by: Prarit Bhargava 
Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: Chaya Rachel Ivgi 
Cc: Sara Sharon 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 58fc7b3c711c..64802659711f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
ret = iwl_mvm_get_temp(mvm, );
if (ret)
goto out;
@@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
ret = -EINVAL;
goto out;
@@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm 
*mvm)
return;
}
 
+   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
+   return;
+
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
 
mvm->tz_device.tzone = thermal_zone_device_register(name,
-- 
1.7.9.3

[PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Prarit Bhargava]

Didn't get any feedback or review comments on this patch.  Resending ...

P.

---8<---

The iwlwifi driver implements a thermal zone and hwmon device, but
returns -EIO on temperature reads if the firmware isn't loaded.  This
results in the error

iwlwifi-virtual-0
Adapter: Virtual device
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A

being output when using sensors from the lm-sensors package.  Since
the temperature cannot be read unless the ucode is loaded there is no
reason to add the interface only to have it return an error 100% of
the time.

This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
stops the thermal zone from being created if the ucode hasn't been loaded.

Signed-off-by: Prarit Bhargava 
Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: Chaya Rachel Ivgi 
Cc: Sara Sharon 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 58fc7b3c711c..64802659711f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
ret = iwl_mvm_get_temp(mvm, );
if (ret)
goto out;
@@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
ret = -EINVAL;
goto out;
@@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm 
*mvm)
return;
}
 
+   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
+   return;
+
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
 
mvm->tz_device.tzone = thermal_zone_device_register(name,
-- 
1.7.9.3

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

[Mark Rutland]

On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote:
> On Jul 11, 2016 3:08 AM, "Mark Rutland"  wrote:
> >
> > Hi,
> >
> > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote:
> > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
> > > then thread_info is defined as a single 'u32 flags' and is the first
> > > entry of task_struct.  thread_info::task is removed (it serves no
> > > purpose if thread_info is embedded in task_struct), and
> > > thread_info::cpu gets its own slot in task_struct.
> > >
> > > This is heavily based on a patch written by Linus.
> >
> > I've been considering how we'd implement this for arm64, and I suspect
> > that we'll also need to fold our preempt_count into task_struct
> > (following from the style of asm-generic/preempt.h).
> >
> > As far as I can see, we can't make our preempt-count a percpu variable
> > as with x86, as our percpu ops themselves are based on disabling
> > preemption.
> 
> How do you intend to find 'current' to get to the preempt count
> without first disabling preemption?

Good point.

For some reason I had convinced myself that it only mattered for RMW
sequences, so evidently I hadn't considered things thoroughly enough. :(

> > To that end, would it be possible to keep the thread_info definition per
> > arch, even with CONFIG_THREAD_INFO_IN_TASK?
> 
> In principal, yes, but could you alternatively put it in
> thread_struct?  My goal here is to encourage people to clean up their
> use of thread_info vs thread_struct at the same time.  For x86, that
> cleanup was trivial -- most of the work was addressing relative to
> current instead of the stack pointer, and that had to happen
> regardless.

I'm more than happy to do that, modulo the above permitting.

Sorry for the noise!

Thanks,
Mark.

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

[Mark Rutland]

On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote:
> On Jul 11, 2016 3:08 AM, "Mark Rutland"  wrote:
> >
> > Hi,
> >
> > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote:
> > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
> > > then thread_info is defined as a single 'u32 flags' and is the first
> > > entry of task_struct.  thread_info::task is removed (it serves no
> > > purpose if thread_info is embedded in task_struct), and
> > > thread_info::cpu gets its own slot in task_struct.
> > >
> > > This is heavily based on a patch written by Linus.
> >
> > I've been considering how we'd implement this for arm64, and I suspect
> > that we'll also need to fold our preempt_count into task_struct
> > (following from the style of asm-generic/preempt.h).
> >
> > As far as I can see, we can't make our preempt-count a percpu variable
> > as with x86, as our percpu ops themselves are based on disabling
> > preemption.
> 
> How do you intend to find 'current' to get to the preempt count
> without first disabling preemption?

Good point.

For some reason I had convinced myself that it only mattered for RMW
sequences, so evidently I hadn't considered things thoroughly enough. :(

> > To that end, would it be possible to keep the thread_info definition per
> > arch, even with CONFIG_THREAD_INFO_IN_TASK?
> 
> In principal, yes, but could you alternatively put it in
> thread_struct?  My goal here is to encourage people to clean up their
> use of thread_info vs thread_struct at the same time.  For x86, that
> cleanup was trivial -- most of the work was addressing relative to
> current instead of the stack pointer, and that had to happen
> regardless.

I'm more than happy to do that, modulo the above permitting.

Sorry for the noise!

Thanks,
Mark.

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

[Tyrel Datwyler]

On 07/08/2016 04:57 PM, Nathan Fontenot wrote:
> On 07/08/2016 06:19 PM, Tyrel Datwyler wrote:
>> PowerVM seems to only ever provide a single hotplug slot per PHB.
>> The under lying slot hotplug registration code assumed multiple slots,
>> but the actual implementation is broken for multiple slots. This went
>> unnoticed for years due to the nature of PowerVM as mentioned
>> previously. Under qemu/kvm the hotplug slot model aligns more with
>> x86 where multiple slots are presented under a single PHB. As seen
>> in the following each additional slot after the first fails to
>> register due to each slot always being compared against the first
>> child node of the PHB in the device tree.
>>
>> [6.492291] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
>> [6.492569] rpaphp: Slot [Slot 0] registered
>> [6.492577] rpaphp: pci_hp_register failed with error -16
>> [6.493082] rpaphp: pci_hp_register failed with error -16
>> [6.493138] rpaphp: pci_hp_register failed with error -16
>> [6.493161] rpaphp: pci_hp_register failed with error -16
>>
>> The registration logic is fixed so that each slot is compared
>> against the existing child devices of the PHB in the device tree to
>> determine present slots vs empty slots.
>>
>> [   38.481750] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
>> [   38.482004] rpaphp: Slot [C0] registered
>> [   38.482127] rpaphp: Slot [C1] registered
>> [   38.482241] rpaphp: Slot [C2] registered
>> [   38.482356] rpaphp: Slot [C3] registered
>> [   38.482495] rpaphp: Slot [C4] registered
>>
>> Signed-off-by: Tyrel Datwyler 
>> ---
>>  drivers/pci/hotplug/rpaphp_slot.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/rpaphp_slot.c 
>> b/drivers/pci/hotplug/rpaphp_slot.c
>> index 6937c72..c90fa8d 100644
>> --- a/drivers/pci/hotplug/rpaphp_slot.c
>> +++ b/drivers/pci/hotplug/rpaphp_slot.c
>> @@ -117,8 +117,10 @@ EXPORT_SYMBOL_GPL(rpaphp_deregister_slot);
>>  int rpaphp_register_slot(struct slot *slot)
>>  {
>>  struct hotplug_slot *php_slot = slot->hotplug_slot;
>> +struct device_node *child;
>> +u32 my_index;
>>  int retval;
>> -int slotno;
>> +int slotno = -1;
>>
>>  dbg("%s registering slot:path[%s] index[%x], name[%s] pdomain[%x] 
>> type[%d]\n",
>>  __func__, slot->dn->full_name, slot->index, slot->name,
>> @@ -130,10 +132,15 @@ int rpaphp_register_slot(struct slot *slot)
>>  return -EAGAIN;
>>  }
>>
>> -if (slot->dn->child)
>> -slotno = PCI_SLOT(PCI_DN(slot->dn->child)->devfn);
>> -else
>> -slotno = -1;
>> +for_each_child_of_node(slot->dn, child) {
>> +retval = of_property_read_u32(child, "my,ibm-drc-index", 
>> _index);
> 
> Shouldn't this be reading ibm,my-drc-index? instead of my,ibm-drc-index.

Doh, indeed it should.

-Tyrel

> 
> -Nathan
> 
>> +if (my_index == slot->index) {
>> +slotno = PCI_SLOT(PCI_DN(child)->devfn);
>> +of_node_put(child);
>> +break;
>> +}
>> +}
>> +
>>  retval = pci_hp_register(php_slot, slot->bus, slotno, slot->name);
>>  if (retval) {
>>  err("pci_hp_register failed with error %d\n", retval);
>>
> 

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

[Tyrel Datwyler]

On 07/08/2016 04:57 PM, Nathan Fontenot wrote:
> On 07/08/2016 06:19 PM, Tyrel Datwyler wrote:
>> PowerVM seems to only ever provide a single hotplug slot per PHB.
>> The under lying slot hotplug registration code assumed multiple slots,
>> but the actual implementation is broken for multiple slots. This went
>> unnoticed for years due to the nature of PowerVM as mentioned
>> previously. Under qemu/kvm the hotplug slot model aligns more with
>> x86 where multiple slots are presented under a single PHB. As seen
>> in the following each additional slot after the first fails to
>> register due to each slot always being compared against the first
>> child node of the PHB in the device tree.
>>
>> [6.492291] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
>> [6.492569] rpaphp: Slot [Slot 0] registered
>> [6.492577] rpaphp: pci_hp_register failed with error -16
>> [6.493082] rpaphp: pci_hp_register failed with error -16
>> [6.493138] rpaphp: pci_hp_register failed with error -16
>> [6.493161] rpaphp: pci_hp_register failed with error -16
>>
>> The registration logic is fixed so that each slot is compared
>> against the existing child devices of the PHB in the device tree to
>> determine present slots vs empty slots.
>>
>> [   38.481750] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
>> [   38.482004] rpaphp: Slot [C0] registered
>> [   38.482127] rpaphp: Slot [C1] registered
>> [   38.482241] rpaphp: Slot [C2] registered
>> [   38.482356] rpaphp: Slot [C3] registered
>> [   38.482495] rpaphp: Slot [C4] registered
>>
>> Signed-off-by: Tyrel Datwyler 
>> ---
>>  drivers/pci/hotplug/rpaphp_slot.c | 17 -
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/rpaphp_slot.c 
>> b/drivers/pci/hotplug/rpaphp_slot.c
>> index 6937c72..c90fa8d 100644
>> --- a/drivers/pci/hotplug/rpaphp_slot.c
>> +++ b/drivers/pci/hotplug/rpaphp_slot.c
>> @@ -117,8 +117,10 @@ EXPORT_SYMBOL_GPL(rpaphp_deregister_slot);
>>  int rpaphp_register_slot(struct slot *slot)
>>  {
>>  struct hotplug_slot *php_slot = slot->hotplug_slot;
>> +struct device_node *child;
>> +u32 my_index;
>>  int retval;
>> -int slotno;
>> +int slotno = -1;
>>
>>  dbg("%s registering slot:path[%s] index[%x], name[%s] pdomain[%x] 
>> type[%d]\n",
>>  __func__, slot->dn->full_name, slot->index, slot->name,
>> @@ -130,10 +132,15 @@ int rpaphp_register_slot(struct slot *slot)
>>  return -EAGAIN;
>>  }
>>
>> -if (slot->dn->child)
>> -slotno = PCI_SLOT(PCI_DN(slot->dn->child)->devfn);
>> -else
>> -slotno = -1;
>> +for_each_child_of_node(slot->dn, child) {
>> +retval = of_property_read_u32(child, "my,ibm-drc-index", 
>> _index);
> 
> Shouldn't this be reading ibm,my-drc-index? instead of my,ibm-drc-index.

Doh, indeed it should.

-Tyrel

> 
> -Nathan
> 
>> +if (my_index == slot->index) {
>> +slotno = PCI_SLOT(PCI_DN(child)->devfn);
>> +of_node_put(child);
>> +break;
>> +}
>> +}
>> +
>>  retval = pci_hp_register(php_slot, slot->bus, slotno, slot->name);
>>  if (retval) {
>>  err("pci_hp_register failed with error %d\n", retval);
>>
> 

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[Rob Herring]

On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote:
> This patch adds the devicetree documentation required for Rockchip
> USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
> 
> It supports DRD mode, and could operate in device mode (SS, HS, FS)
> and host mode (SS, HS, FS, LS).
> 
> Signed-off-by: William Wu 
> ---
> Changes in v6:
> - rename bus_clk, and add usbdrd3_1 node as an example (Heiko)
> 
> Changes in v5:
> - rename clock-names, and remove unnecessary clocks (Heiko)
> 
> Changes in v4:
> - modify commit log, and add phy documentation location (Sergei)
> 
> Changes in v3:
> - add dwc3 address (balbi)
> 
> Changes in v2:
> - add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian)
> 
>  .../devicetree/bindings/usb/rockchip,dwc3.txt  | 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt

Acked-by: Rob Herring 

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[Rob Herring]

On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote:
> This patch adds the devicetree documentation required for Rockchip
> USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
> 
> It supports DRD mode, and could operate in device mode (SS, HS, FS)
> and host mode (SS, HS, FS, LS).
> 
> Signed-off-by: William Wu 
> ---
> Changes in v6:
> - rename bus_clk, and add usbdrd3_1 node as an example (Heiko)
> 
> Changes in v5:
> - rename clock-names, and remove unnecessary clocks (Heiko)
> 
> Changes in v4:
> - modify commit log, and add phy documentation location (Sergei)
> 
> Changes in v3:
> - add dwc3 address (balbi)
> 
> Changes in v2:
> - add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian)
> 
>  .../devicetree/bindings/usb/rockchip,dwc3.txt  | 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt

Acked-by: Rob Herring 

Re: [PATCH v6 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk

[Rob Herring]

On Thu, Jul 07, 2016 at 10:54:25AM +0800, William Wu wrote:
> Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
> which specifies whether disable delay PHY power change
> from P0 to P1/P2/P3 when link state changing from U0
> to U1/U2/U3 respectively.
> 
> Signed-off-by: William Wu 
> ---
> Changes in v6:
> - use '-' instead of '_' in dts (Rob Herring)
> 
> Changes in v5:
> - None
> 
> Changes in v4:
> - rebase on top of balbi testing/next, remove pdata (balbi)
> 
> Changes in v3:
> - None
> 
> Changes in v2:
> - None
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
>  drivers/usb/dwc3/core.c| 5 +
>  drivers/usb/dwc3/core.h| 3 +++
>  3 files changed, 10 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v6 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk

[Rob Herring]

On Thu, Jul 07, 2016 at 10:54:25AM +0800, William Wu wrote:
> Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
> which specifies whether disable delay PHY power change
> from P0 to P1/P2/P3 when link state changing from U0
> to U1/U2/U3 respectively.
> 
> Signed-off-by: William Wu 
> ---
> Changes in v6:
> - use '-' instead of '_' in dts (Rob Herring)
> 
> Changes in v5:
> - None
> 
> Changes in v4:
> - rebase on top of balbi testing/next, remove pdata (balbi)
> 
> Changes in v3:
> - None
> 
> Changes in v2:
> - None
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
>  drivers/usb/dwc3/core.c| 5 +
>  drivers/usb/dwc3/core.h| 3 +++
>  3 files changed, 10 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

[Robin Murphy]

On 09/07/16 03:09, Mitchel Humpherys wrote:
> The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating
> mappings that are executable by privileged DMA engines.  Implement it in
> dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.
> 
> Signed-off-by: Mitchel Humpherys 
> ---
>  arch/arm64/mm/dma-mapping.c |  6 +++---
>  drivers/iommu/dma-iommu.c   | 15 +++
>  include/linux/dma-iommu.h   |  3 ++-
>  3 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index c566ec83719f..44f676268df6 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -543,7 +543,7 @@ static void *__iommu_alloc_attrs(struct device *dev, 
> size_t size,
>struct dma_attrs *attrs)
>  {
>   bool coherent = is_device_dma_coherent(dev);
> - int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
> + int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
>   size_t iosize = size;
>   void *addr;
>  
> @@ -697,7 +697,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, 
> struct page *page,
>  struct dma_attrs *attrs)
>  {
>   bool coherent = is_device_dma_coherent(dev);
> - int prot = dma_direction_to_prot(dir, coherent);
> + int prot = dma_direction_to_prot(dir, coherent, attrs);
>   dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
>  
>   if (!iommu_dma_mapping_error(dev, dev_addr) &&
> @@ -755,7 +755,7 @@ static int __iommu_map_sg_attrs(struct device *dev, 
> struct scatterlist *sgl,
>   __iommu_sync_sg_for_device(dev, sgl, nelems, dir);
>  
>   return iommu_dma_map_sg(dev, sgl, nelems,
> - dma_direction_to_prot(dir, coherent));
> + dma_direction_to_prot(dir, coherent, attrs));
>  }
>  
>  static void __iommu_unmap_sg_attrs(struct device *dev,
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index ea5a9ebf0f78..ccc6219da228 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -132,23 +132,30 @@ EXPORT_SYMBOL(iommu_dma_init_domain);
>   * dma_direction_to_prot - Translate DMA API directions to IOMMU API page 
> flags

Privilege really isn't a direction :(

If we're going to cram more into this function it really wants renaming
and redocumenting.

>   * @dir: Direction of DMA transfer
>   * @coherent: Is the DMA master cache-coherent?
> + * @attrs: DMA attributes for the mapping
>   *
>   * Return: corresponding IOMMU API page protection flags
>   */
> -int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
> +int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
> +   struct dma_attrs *attrs)
>  {
>   int prot = coherent ? IOMMU_CACHE : 0;
>  
>   switch (dir) {
>   case DMA_BIDIRECTIONAL:
> - return prot | IOMMU_READ | IOMMU_WRITE;
> + prot |= IOMMU_READ | IOMMU_WRITE;
>   case DMA_TO_DEVICE:
> - return prot | IOMMU_READ;
> + prot |= IOMMU_READ;
>   case DMA_FROM_DEVICE:
> - return prot | IOMMU_WRITE;
> + prot |= IOMMU_WRITE;
>   default:
>   return 0;
>   }
> + if (dma_get_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, attrs)) {
> + prot &= ~IOMMU_WRITE;

Hey, we didn't say anything anywhere about anything being privileged
read-only! Frankly, I think this is going to create more problems that
it solves. Implementing IOMMU_PRIV as simply unprivileged no-access
should be sufficient.

Robin.

> + prot |= IOMMU_PRIV;
> + }
> + return prot;
>  }
>  
>  static struct iova *__alloc_iova(struct iova_domain *iovad, size_t size,
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 8443bbb5c071..d5a37e58d29b 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -32,7 +32,8 @@ void iommu_put_dma_cookie(struct iommu_domain *domain);
>  int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 
> size);
>  
>  /* General helpers for DMA-API <-> IOMMU-API interaction */
> -int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
> +int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
> +   struct dma_attrs *attrs);
>  
>  /*
>   * These implement the bulk of the relevant DMA mapping callbacks, but 
> require
> 

Re: [PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

[Robin Murphy]

On 09/07/16 03:09, Mitchel Humpherys wrote:
> The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating
> mappings that are executable by privileged DMA engines.  Implement it in
> dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.
> 
> Signed-off-by: Mitchel Humpherys 
> ---
>  arch/arm64/mm/dma-mapping.c |  6 +++---
>  drivers/iommu/dma-iommu.c   | 15 +++
>  include/linux/dma-iommu.h   |  3 ++-
>  3 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index c566ec83719f..44f676268df6 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -543,7 +543,7 @@ static void *__iommu_alloc_attrs(struct device *dev, 
> size_t size,
>struct dma_attrs *attrs)
>  {
>   bool coherent = is_device_dma_coherent(dev);
> - int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
> + int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
>   size_t iosize = size;
>   void *addr;
>  
> @@ -697,7 +697,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, 
> struct page *page,
>  struct dma_attrs *attrs)
>  {
>   bool coherent = is_device_dma_coherent(dev);
> - int prot = dma_direction_to_prot(dir, coherent);
> + int prot = dma_direction_to_prot(dir, coherent, attrs);
>   dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
>  
>   if (!iommu_dma_mapping_error(dev, dev_addr) &&
> @@ -755,7 +755,7 @@ static int __iommu_map_sg_attrs(struct device *dev, 
> struct scatterlist *sgl,
>   __iommu_sync_sg_for_device(dev, sgl, nelems, dir);
>  
>   return iommu_dma_map_sg(dev, sgl, nelems,
> - dma_direction_to_prot(dir, coherent));
> + dma_direction_to_prot(dir, coherent, attrs));
>  }
>  
>  static void __iommu_unmap_sg_attrs(struct device *dev,
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index ea5a9ebf0f78..ccc6219da228 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -132,23 +132,30 @@ EXPORT_SYMBOL(iommu_dma_init_domain);
>   * dma_direction_to_prot - Translate DMA API directions to IOMMU API page 
> flags

Privilege really isn't a direction :(

If we're going to cram more into this function it really wants renaming
and redocumenting.

>   * @dir: Direction of DMA transfer
>   * @coherent: Is the DMA master cache-coherent?
> + * @attrs: DMA attributes for the mapping
>   *
>   * Return: corresponding IOMMU API page protection flags
>   */
> -int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
> +int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
> +   struct dma_attrs *attrs)
>  {
>   int prot = coherent ? IOMMU_CACHE : 0;
>  
>   switch (dir) {
>   case DMA_BIDIRECTIONAL:
> - return prot | IOMMU_READ | IOMMU_WRITE;
> + prot |= IOMMU_READ | IOMMU_WRITE;
>   case DMA_TO_DEVICE:
> - return prot | IOMMU_READ;
> + prot |= IOMMU_READ;
>   case DMA_FROM_DEVICE:
> - return prot | IOMMU_WRITE;
> + prot |= IOMMU_WRITE;
>   default:
>   return 0;
>   }
> + if (dma_get_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, attrs)) {
> + prot &= ~IOMMU_WRITE;

Hey, we didn't say anything anywhere about anything being privileged
read-only! Frankly, I think this is going to create more problems that
it solves. Implementing IOMMU_PRIV as simply unprivileged no-access
should be sufficient.

Robin.

> + prot |= IOMMU_PRIV;
> + }
> + return prot;
>  }
>  
>  static struct iova *__alloc_iova(struct iova_domain *iovad, size_t size,
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 8443bbb5c071..d5a37e58d29b 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -32,7 +32,8 @@ void iommu_put_dma_cookie(struct iommu_domain *domain);
>  int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 
> size);
>  
>  /* General helpers for DMA-API <-> IOMMU-API interaction */
> -int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
> +int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
> +   struct dma_attrs *attrs);
>  
>  /*
>   * These implement the bulk of the relevant DMA mapping callbacks, but 
> require
> 

[PATCH v16 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.

With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.

Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service

The patch implements the necessary support in the guest side by introducing
a new socket address family AF_HYPERV.

Signed-off-by: Dexuan Cui 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Cc: Cathy Avery 
Cc: Olaf Hering 
---

You can also get the patch by (commit 5dde7975):
https://github.com/dcui/linux/tree/decui/hv_sock/net-next/20160711_v16


For the change log before v12, please see https://lkml.org/lkml/2016/5/15/31

In v12, the changes are mainly the following:

1) remove the module params as David suggested.

2) use 5 exact pages for VMBus send/recv rings, respectively.
The host side's design of the feature requires 5 exact pages for recv/send
rings respectively -- this is suboptimal considering memory consumption,
however unluckily we have to live with it, before the host comes up with
a new design in the future. :-(

3) remove the per-connection static send/recv buffers
Instead, we allocate and free the buffers dynamically only when we recv/send
data. This means: when a connection is idle, no memory is consumed as
recv/send buffers at all.

In v13:
I return ENOMEM on buffer alllocation failure

   Actually "man read/write" says "Other errors may occur, depending on the
object connected to fd". "man send/recv" indeed lists ENOMEM.
   Considering AF_HYPERV is a new socket type, ENOMEM seems OK here.
   In the long run, I think we should add a new API in the VMBus driver,
allowing data copy from VMBus ringbuffer into user mode buffer directly.
This way, we can even eliminate this temporary buffer.

In v14:
fix some coding style issues pointed out by David.

In v15:
Just some stylistic changes addressing comments from Joe Perches and
Olaf Hering -- thank you!
- add a GPL blurb.
- define a new macro PAGE_SIZE_4K and use it to replace PAGE_SIZE
- change sk_to_hvsock/hvsock_to_sk() from macros to inline functions
- remove a not-very-useful pr_err()
- fix some typos in comment and coding style issues.

In v16:
Made stylistic changes addressing comments from Vitaly Kuznetsov.
Thank you very much for the detailed comments, Vitaly!

Looking forward to your comments!

 MAINTAINERS |2 +
 include/linux/hyperv.h  |   13 +
 include/linux/socket.h  |4 +-
 include/net/af_hvsock.h |   78 +++
 include/uapi/linux/hyperv.h |   23 +
 net/Kconfig |1 +
 net/Makefile|1 +
 net/hv_sock/Kconfig |   10 +
 net/hv_sock/Makefile|3 +
 net/hv_sock/af_hvsock.c | 1509 +++
 10 files changed, 1643 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50f69ba..6eaa26f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5514,7 +5514,9 @@ F:drivers/pci/host/pci-hyperv.c
 F: drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/video/fbdev/hyperv_fb.c
+F: net/hv_sock/
 F: include/linux/hyperv.h
+F: include/net/af_hvsock.h
 F: tools/hv/
 F: Documentation/ABI/stable/sysfs-bus-vmbus
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 50f493e..1cda6ea5 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1508,5 +1508,18 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
vmbus_set_event(channel);
 }
 
+struct vmpipe_proto_header {
+   u32 pkt_type;
+   u32 data_size;
+};
+
+#define HVSOCK_HEADER_LEN  (sizeof(struct vmpacket_descriptor) + \
+sizeof(struct vmpipe_proto_header))
+
+/* See 'prev_indices' in hv_ringbuffer_read(), hv_ringbuffer_write() */
+#define PREV_INDICES_LEN   (sizeof(u64))
 
+#define HVSOCK_PKT_LEN(payload_len)(HVSOCK_HEADER_LEN + \
+   ALIGN((payload_len), 8) + \
+   PREV_INDICES_LEN)
 #endif /* _HYPERV_H */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index b5cc5a6..0b68b58 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -202,8 +202,9 @@ struct ucred {
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
 #define AF_QIPCRTR 42  /* Qualcomm IPC Router  */
+#define AF_HYPERV  43 

[PATCH v16 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.

With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.

Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service

The patch implements the necessary support in the guest side by introducing
a new socket address family AF_HYPERV.

Signed-off-by: Dexuan Cui 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Cc: Cathy Avery 
Cc: Olaf Hering 
---

You can also get the patch by (commit 5dde7975):
https://github.com/dcui/linux/tree/decui/hv_sock/net-next/20160711_v16


For the change log before v12, please see https://lkml.org/lkml/2016/5/15/31

In v12, the changes are mainly the following:

1) remove the module params as David suggested.

2) use 5 exact pages for VMBus send/recv rings, respectively.
The host side's design of the feature requires 5 exact pages for recv/send
rings respectively -- this is suboptimal considering memory consumption,
however unluckily we have to live with it, before the host comes up with
a new design in the future. :-(

3) remove the per-connection static send/recv buffers
Instead, we allocate and free the buffers dynamically only when we recv/send
data. This means: when a connection is idle, no memory is consumed as
recv/send buffers at all.

In v13:
I return ENOMEM on buffer alllocation failure

   Actually "man read/write" says "Other errors may occur, depending on the
object connected to fd". "man send/recv" indeed lists ENOMEM.
   Considering AF_HYPERV is a new socket type, ENOMEM seems OK here.
   In the long run, I think we should add a new API in the VMBus driver,
allowing data copy from VMBus ringbuffer into user mode buffer directly.
This way, we can even eliminate this temporary buffer.

In v14:
fix some coding style issues pointed out by David.

In v15:
Just some stylistic changes addressing comments from Joe Perches and
Olaf Hering -- thank you!
- add a GPL blurb.
- define a new macro PAGE_SIZE_4K and use it to replace PAGE_SIZE
- change sk_to_hvsock/hvsock_to_sk() from macros to inline functions
- remove a not-very-useful pr_err()
- fix some typos in comment and coding style issues.

In v16:
Made stylistic changes addressing comments from Vitaly Kuznetsov.
Thank you very much for the detailed comments, Vitaly!

Looking forward to your comments!

 MAINTAINERS |2 +
 include/linux/hyperv.h  |   13 +
 include/linux/socket.h  |4 +-
 include/net/af_hvsock.h |   78 +++
 include/uapi/linux/hyperv.h |   23 +
 net/Kconfig |1 +
 net/Makefile|1 +
 net/hv_sock/Kconfig |   10 +
 net/hv_sock/Makefile|3 +
 net/hv_sock/af_hvsock.c | 1509 +++
 10 files changed, 1643 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50f69ba..6eaa26f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5514,7 +5514,9 @@ F:drivers/pci/host/pci-hyperv.c
 F: drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/video/fbdev/hyperv_fb.c
+F: net/hv_sock/
 F: include/linux/hyperv.h
+F: include/net/af_hvsock.h
 F: tools/hv/
 F: Documentation/ABI/stable/sysfs-bus-vmbus
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 50f493e..1cda6ea5 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1508,5 +1508,18 @@ static inline void commit_rd_index(struct vmbus_channel 
*channel)
vmbus_set_event(channel);
 }
 
+struct vmpipe_proto_header {
+   u32 pkt_type;
+   u32 data_size;
+};
+
+#define HVSOCK_HEADER_LEN  (sizeof(struct vmpacket_descriptor) + \
+sizeof(struct vmpipe_proto_header))
+
+/* See 'prev_indices' in hv_ringbuffer_read(), hv_ringbuffer_write() */
+#define PREV_INDICES_LEN   (sizeof(u64))
 
+#define HVSOCK_PKT_LEN(payload_len)(HVSOCK_HEADER_LEN + \
+   ALIGN((payload_len), 8) + \
+   PREV_INDICES_LEN)
 #endif /* _HYPERV_H */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index b5cc5a6..0b68b58 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -202,8 +202,9 @@ struct ucred {
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
 #define AF_QIPCRTR 42  /* Qualcomm IPC Router  */
+#define AF_HYPERV  43  /* Hyper-V Sockets  */
 
-#define AF_MAX 43  /* For now.. */
+#define AF_MAX 44  /* 

Re: [PATCH v2 0/6] Add support for privileged mappings

[Jordan Crouse]

On Mon, Jul 11, 2016 at 03:02:24PM +0100, Robin Murphy wrote:
> Hey Mitch,
> 
> Thanks for having the necessary go at the DMA API - I think the series
> looks broadly workable now.
> 
> On 09/07/16 03:09, Mitchel Humpherys wrote:
> > The following patch to the ARM SMMU driver:
> > 
> > commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
> > Author: Robin Murphy 
> > Date:   Tue Jan 26 18:06:34 2016 +
> > 
> > iommu/arm-smmu: Treat all device transactions as unprivileged
> > 
> > started forcing all SMMU transactions to come through as "unprivileged".
> > The rationale given was that:
> > 
> >   (1) There is no way in the IOMMU API to even request privileged mappings.
> > 
> >   (2) It's difficult to implement a DMA mapper that correctly models the
> >   ARM VMSAv8 behavior of unprivileged-writeable =>
> >   privileged-execute-never.
> > 
> > This series rectifies (1) by introducing an IOMMU API for privileged
> > mappings and implements it in io-pgtable-arm.
> > 
> > This series rectifies (2) by introducing a new dma attribute
> > (DMA_ATTR_PRIVILEGED_EXECUTABLE) for users of the DMA API that need
> > privileged, executable mappings, and implements it in the arm64 IOMMU DMA
> > mapper.  The one known user (pl330.c) is converted over to the new
> > attribute.
> > 
> > Jordan and Jeremy can provide more info on the use case if needed, but the
> > high level is that it's a security feature to prevent attacks such as [1].
> 
> My understanding of that hack is that it involves switching the GPU into
> privileged mode to get at the mapping of the IOMMU registers in the
> first place, so I don't see at a glance how having privileged mappings
> defends against that. What it clearly does do, however, is get us _to_
> the point where it's necessary to do such a privilege switch in the
> first place, as opposed to everything being trivially wide-open, which
> is no bad thing.

It was a two pronged attack.  First the attacker had to use the GPU to construct
a new pagetable and some various GPU command buffers and then they could switch
the context to the new pagetable to complete the attack.

The first part was made possible by vast tracts of read/write memory that is
mapped globally and accessible to all users so it was easy and legal to write
whatever the user wished including a pusedo-pagetable.

As you said, while the actual fix for the exploit was blocking access to the 
SMMU
registers it isn't a bad thing if we get in the habit of assuming that we 
shouldn't
leave a bunch of scratch memory around for somebody clever to take advantage of.

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 0/6] Add support for privileged mappings

[Jordan Crouse]

On Mon, Jul 11, 2016 at 03:02:24PM +0100, Robin Murphy wrote:
> Hey Mitch,
> 
> Thanks for having the necessary go at the DMA API - I think the series
> looks broadly workable now.
> 
> On 09/07/16 03:09, Mitchel Humpherys wrote:
> > The following patch to the ARM SMMU driver:
> > 
> > commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
> > Author: Robin Murphy 
> > Date:   Tue Jan 26 18:06:34 2016 +
> > 
> > iommu/arm-smmu: Treat all device transactions as unprivileged
> > 
> > started forcing all SMMU transactions to come through as "unprivileged".
> > The rationale given was that:
> > 
> >   (1) There is no way in the IOMMU API to even request privileged mappings.
> > 
> >   (2) It's difficult to implement a DMA mapper that correctly models the
> >   ARM VMSAv8 behavior of unprivileged-writeable =>
> >   privileged-execute-never.
> > 
> > This series rectifies (1) by introducing an IOMMU API for privileged
> > mappings and implements it in io-pgtable-arm.
> > 
> > This series rectifies (2) by introducing a new dma attribute
> > (DMA_ATTR_PRIVILEGED_EXECUTABLE) for users of the DMA API that need
> > privileged, executable mappings, and implements it in the arm64 IOMMU DMA
> > mapper.  The one known user (pl330.c) is converted over to the new
> > attribute.
> > 
> > Jordan and Jeremy can provide more info on the use case if needed, but the
> > high level is that it's a security feature to prevent attacks such as [1].
> 
> My understanding of that hack is that it involves switching the GPU into
> privileged mode to get at the mapping of the IOMMU registers in the
> first place, so I don't see at a glance how having privileged mappings
> defends against that. What it clearly does do, however, is get us _to_
> the point where it's necessary to do such a privilege switch in the
> first place, as opposed to everything being trivially wide-open, which
> is no bad thing.

It was a two pronged attack.  First the attacker had to use the GPU to construct
a new pagetable and some various GPU command buffers and then they could switch
the context to the new pagetable to complete the attack.

The first part was made possible by vast tracts of read/write memory that is
mapped globally and accessible to all users so it was easy and legal to write
whatever the user wished including a pusedo-pagetable.

As you said, while the actual fix for the exploit was blocking access to the 
SMMU
registers it isn't a bad thing if we get in the habit of assuming that we 
shouldn't
leave a bunch of scratch memory around for somebody clever to take advantage of.

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH RFC V1] mfd: da9063: Update author information to remove incorrect e-mail addresses

[Steve Twiss]

From: Steve Twiss 

Remove incorrect e-mail addresses from the copyright header and
MODULE_AUTHOR() macro. These e-mail addresses are no longer in use.

The author names have not been changed, only the e-mail address have been
deleted from the source files.

Signed-off-by: Steve Twiss 

---

Hi Lee, 

There have been an increasing number of queries made from external
developers. These queries have been made to the author names written into
the driver files. Unfortunately, there are several author entries in our
source files with Dialog Semiconductor e-mail addresses that are no longer
valid.

These new changes I am proposing will erase the e-mail addresses without
affecting the author names.

I hope this is acceptable.

Regards,
Steve


 drivers/mfd/da9063-core.c| 6 +++---
 drivers/mfd/da9063-i2c.c | 2 +-
 drivers/mfd/da9063-irq.c | 2 +-
 include/linux/mfd/da9063/core.h  | 4 ++--
 include/linux/mfd/da9063/pdata.h | 4 ++--
 include/linux/mfd/da9063/registers.h | 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index af841c1..d011486 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -4,8 +4,8 @@
  * Copyright 2012 Dialog Semiconductors Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Krystian Garbaciak ,
- * Michal Hajduk 
+ * Author: Krystian Garbaciak
+ * Author: Michal Hajduk
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
@@ -242,5 +242,5 @@ void da9063_device_exit(struct da9063 *da9063)
 }
 
 MODULE_DESCRIPTION("PMIC driver for Dialog DA9063");
-MODULE_AUTHOR("Krystian Garbaciak , Michal 
Hajduk ");
+MODULE_AUTHOR("Krystian Garbaciak, Michal Hajduk");
 MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 7390108..54959be 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -3,7 +3,7 @@
  * Copyright 2012 Dialog Semiconductor Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Krystian Garbaciak 
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/drivers/mfd/da9063-irq.c b/drivers/mfd/da9063-irq.c
index 7e903fc..230c813 100644
--- a/drivers/mfd/da9063-irq.c
+++ b/drivers/mfd/da9063-irq.c
@@ -3,7 +3,7 @@
  * Copyright 2012 Dialog Semiconductor Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Michal Hajduk 
+ * Author: Michal Hajduk
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index 621af82..6cc9e6c 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- *Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/pdata.h b/include/linux/mfd/da9063/pdata.h
index 612383b..b4201de 100644
--- a/include/linux/mfd/da9063/pdata.h
+++ b/include/linux/mfd/da9063/pdata.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- * Author: Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/registers.h 
b/include/linux/mfd/da9063/registers.h
index 2e0ba6d..2c34286 100644
--- a/include/linux/mfd/da9063/registers.h
+++ b/include/linux/mfd/da9063/registers.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- *Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
-- 
end-of-patch for PATCH RFC V1

[PATCH RFC V1] mfd: da9063: Update author information to remove incorrect e-mail addresses

[Steve Twiss]

From: Steve Twiss 

Remove incorrect e-mail addresses from the copyright header and
MODULE_AUTHOR() macro. These e-mail addresses are no longer in use.

The author names have not been changed, only the e-mail address have been
deleted from the source files.

Signed-off-by: Steve Twiss 

---

Hi Lee, 

There have been an increasing number of queries made from external
developers. These queries have been made to the author names written into
the driver files. Unfortunately, there are several author entries in our
source files with Dialog Semiconductor e-mail addresses that are no longer
valid.

These new changes I am proposing will erase the e-mail addresses without
affecting the author names.

I hope this is acceptable.

Regards,
Steve


 drivers/mfd/da9063-core.c| 6 +++---
 drivers/mfd/da9063-i2c.c | 2 +-
 drivers/mfd/da9063-irq.c | 2 +-
 include/linux/mfd/da9063/core.h  | 4 ++--
 include/linux/mfd/da9063/pdata.h | 4 ++--
 include/linux/mfd/da9063/registers.h | 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index af841c1..d011486 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -4,8 +4,8 @@
  * Copyright 2012 Dialog Semiconductors Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Krystian Garbaciak ,
- * Michal Hajduk 
+ * Author: Krystian Garbaciak
+ * Author: Michal Hajduk
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
@@ -242,5 +242,5 @@ void da9063_device_exit(struct da9063 *da9063)
 }
 
 MODULE_DESCRIPTION("PMIC driver for Dialog DA9063");
-MODULE_AUTHOR("Krystian Garbaciak , Michal 
Hajduk ");
+MODULE_AUTHOR("Krystian Garbaciak, Michal Hajduk");
 MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 7390108..54959be 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -3,7 +3,7 @@
  * Copyright 2012 Dialog Semiconductor Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Krystian Garbaciak 
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/drivers/mfd/da9063-irq.c b/drivers/mfd/da9063-irq.c
index 7e903fc..230c813 100644
--- a/drivers/mfd/da9063-irq.c
+++ b/drivers/mfd/da9063-irq.c
@@ -3,7 +3,7 @@
  * Copyright 2012 Dialog Semiconductor Ltd.
  * Copyright 2013 Philipp Zabel, Pengutronix
  *
- * Author: Michal Hajduk 
+ * Author: Michal Hajduk
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index 621af82..6cc9e6c 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- *Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/pdata.h b/include/linux/mfd/da9063/pdata.h
index 612383b..b4201de 100644
--- a/include/linux/mfd/da9063/pdata.h
+++ b/include/linux/mfd/da9063/pdata.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- * Author: Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
diff --git a/include/linux/mfd/da9063/registers.h 
b/include/linux/mfd/da9063/registers.h
index 2e0ba6d..2c34286 100644
--- a/include/linux/mfd/da9063/registers.h
+++ b/include/linux/mfd/da9063/registers.h
@@ -3,8 +3,8 @@
  *
  * Copyright 2012 Dialog Semiconductor Ltd.
  *
- * Author: Michal Hajduk 
- *Krystian Garbaciak 
+ * Author: Michal Hajduk
+ * Author: Krystian Garbaciak
  *
  *  This program is free software; you can redistribute  it and/or modify it
  *  under  the terms of  the GNU General  Public License as published by the
-- 
end-of-patch for PATCH RFC V1

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

[Rob Herring]

On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote:
> Add a quirk to configure the core to support the
> UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
> interface is hardware property, and it's platform
> dependent. Normall, the PHYIf can be configured

s/Normall/Normally/
s/PHYIf/PHYIF/

> during coreconsultant. But for some specific usb

s/usb/USB/

> cores(e.g. rk3399 soc dwc3), the default PHYIf
> configuration value is fault, so we need to
> reconfigure it by software.
> 
> And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM

s/dwc3/DWC3/

> must be set to the corresponding value according to
> the UTMI+ PHY interface.

And wrap your lines at 70-74 characters.

Rob

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

[Rob Herring]

On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote:
> Add a quirk to configure the core to support the
> UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
> interface is hardware property, and it's platform
> dependent. Normall, the PHYIf can be configured

s/Normall/Normally/
s/PHYIf/PHYIF/

> during coreconsultant. But for some specific usb

s/usb/USB/

> cores(e.g. rk3399 soc dwc3), the default PHYIf
> configuration value is fault, so we need to
> reconfigure it by software.
> 
> And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM

s/dwc3/DWC3/

> must be set to the corresponding value according to
> the UTMI+ PHY interface.

And wrap your lines at 70-74 characters.

Rob

[PATCH] pinctrl: stm32f429: driver init call change

[Alexandre TORGUE]

As nothing special is done in driver init then device_initcall() can be
changed in builtin_platform_driver() call.

Signed-off-by: Alexandre TORGUE 

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c 
b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
index e9b15dc..a5d50ca 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32f429.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
@@ -1583,9 +1583,4 @@ static struct platform_driver stm32f429_pinctrl_driver = {
.of_match_table = stm32f429_pctrl_match,
},
 };
-
-static int __init stm32f429_pinctrl_init(void)
-{
-   return platform_driver_register(_pinctrl_driver);
-}
-device_initcall(stm32f429_pinctrl_init);
+builtin_platform_driver(stm32f429_pinctrl_driver);
-- 
1.9.1

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

[Andy Lutomirski]

On Jul 11, 2016 3:08 AM, "Mark Rutland"  wrote:
>
> Hi,
>
> On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote:
> > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
> > then thread_info is defined as a single 'u32 flags' and is the first
> > entry of task_struct.  thread_info::task is removed (it serves no
> > purpose if thread_info is embedded in task_struct), and
> > thread_info::cpu gets its own slot in task_struct.
> >
> > This is heavily based on a patch written by Linus.
>
> I've been considering how we'd implement this for arm64, and I suspect
> that we'll also need to fold our preempt_count into task_struct
> (following from the style of asm-generic/preempt.h).
>
> As far as I can see, we can't make our preempt-count a percpu variable
> as with x86, as our percpu ops themselves are based on disabling
> preemption.

How do you intend to find 'current' to get to the preempt count
without first disabling preemption?

>
> To that end, would it be possible to keep the thread_info definition per
> arch, even with CONFIG_THREAD_INFO_IN_TASK?

In principal, yes, but could you alternatively put it in
thread_struct?  My goal here is to encourage people to clean up their
use of thread_info vs thread_struct at the same time.  For x86, that
cleanup was trivial -- most of the work was addressing relative to
current instead of the stack pointer, and that had to happen
regardless.

--Andy

[PATCH] pinctrl: stm32f429: driver init call change

[Alexandre TORGUE]

As nothing special is done in driver init then device_initcall() can be
changed in builtin_platform_driver() call.

Signed-off-by: Alexandre TORGUE 

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c 
b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
index e9b15dc..a5d50ca 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32f429.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
@@ -1583,9 +1583,4 @@ static struct platform_driver stm32f429_pinctrl_driver = {
.of_match_table = stm32f429_pctrl_match,
},
 };
-
-static int __init stm32f429_pinctrl_init(void)
-{
-   return platform_driver_register(_pinctrl_driver);
-}
-device_initcall(stm32f429_pinctrl_init);
+builtin_platform_driver(stm32f429_pinctrl_driver);
-- 
1.9.1

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

[Andy Lutomirski]

On Jul 11, 2016 3:08 AM, "Mark Rutland"  wrote:
>
> Hi,
>
> On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote:
> > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
> > then thread_info is defined as a single 'u32 flags' and is the first
> > entry of task_struct.  thread_info::task is removed (it serves no
> > purpose if thread_info is embedded in task_struct), and
> > thread_info::cpu gets its own slot in task_struct.
> >
> > This is heavily based on a patch written by Linus.
>
> I've been considering how we'd implement this for arm64, and I suspect
> that we'll also need to fold our preempt_count into task_struct
> (following from the style of asm-generic/preempt.h).
>
> As far as I can see, we can't make our preempt-count a percpu variable
> as with x86, as our percpu ops themselves are based on disabling
> preemption.

How do you intend to find 'current' to get to the preempt count
without first disabling preemption?

>
> To that end, would it be possible to keep the thread_info definition per
> arch, even with CONFIG_THREAD_INFO_IN_TASK?

In principal, yes, but could you alternatively put it in
thread_struct?  My goal here is to encourage people to clean up their
use of thread_info vs thread_struct at the same time.  For x86, that
cleanup was trivial -- most of the work was addressing relative to
current instead of the stack pointer, and that had to happen
regardless.

--Andy