Re: PSA: Do not use "Reported-By" without reporter's approval

[Bhaskar Chowdhury]

Make sense Kai!

On 15:30 Wed 22 May , Konstantin Ryabitsev wrote:

Hello, all:

It is common courtesy to include this tagline when submitting patches:

Reported-By: J. Doe 

Please ask the reporter's permission before doing so (even if they'd
submitted a public bugzilla report or sent a report to the mailing
list). They need to understand and agree that:

- their name and email address will become a permanent, non-excisable
 part of the Linux Kernel git history
- their name and email address will be stored on multiple public
 archival copies of the linux kernel mailing list, collected and
 managed by different legal entities

With or without GDPR laws, this is something the reporter needs to be
aware of and they need to be okay with it, as a matter of courtesy.

-K


signature.asc
Description: PGP signature

Re: [PATCH 2/3] firmware: add offset to request_firmware_into_buf

[Greg Kroah-Hartman]

On Wed, May 22, 2019 at 07:51:12PM -0700, Scott Branden wrote:
> Add offset to request_firmware_into_buf to allow for portions
> of firmware file to be read into a buffer.  Necessary where firmware
> needs to be loaded in portions from file in memory constrained systems.
> 
> Signed-off-by: Scott Branden 
> ---
>  drivers/base/firmware_loader/firmware.h |  5 +++
>  drivers/base/firmware_loader/main.c | 49 +
>  include/linux/firmware.h|  8 +++-
>  3 files changed, 45 insertions(+), 17 deletions(-)

No new firmware test for this new option?  How do we know it even works?
:)

thanks,

greg k-h

Re: [PATCH v2 bpf-next 4/4] selftests/bpf: add auto-detach test

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> Add a kselftest to cover bpf auto-detachment functionality.
> The test creates a cgroup, associates some resources with it,
> attaches a couple of bpf programs and deletes the cgroup.
> 
> Then it checks that bpf programs are going away in 5 seconds.
> 
> Expected output:
>$ ./test_cgroup_attach
>#override:PASS
>#multi:PASS
>#autodetach:PASS
>test_cgroup_attach:PASS
> 
> On a kernel without auto-detaching:
>$ ./test_cgroup_attach
>#override:PASS
>#multi:PASS
>#autodetach:FAIL
>test_cgroup_attach:FAIL
> 
> Signed-off-by: Roman Gushchin 
> ---
>   .../selftests/bpf/test_cgroup_attach.c| 99 ++-
>   1 file changed, 98 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/bpf/test_cgroup_attach.c 
> b/tools/testing/selftests/bpf/test_cgroup_attach.c
> index 93d4fe295e7d..bc5bd0f1728e 100644
> --- a/tools/testing/selftests/bpf/test_cgroup_attach.c
> +++ b/tools/testing/selftests/bpf/test_cgroup_attach.c
> @@ -456,9 +456,106 @@ static int test_multiprog(void)
>   return rc;
>   }
>   
> +static int test_autodetach(void)
> +{
> + __u32 prog_cnt = 4, attach_flags;
> + int allow_prog[2] = {0};
> + __u32 prog_ids[2] = {0};
> + int cg = 0, i, rc = -1;
> + void *ptr = NULL;
> + int attempts;
> +
> +
Also extra line here.

> + for (i = 0; i < ARRAY_SIZE(allow_prog); i++) {
> + allow_prog[i] = prog_load_cnt(1, 1 << i);
> + if (!allow_prog[i])
> + goto err;
> + }
> +
> + if (setup_cgroup_environment())
> + goto err;
> +
> + /* create a cgroup, attach two programs and remember their ids */
> + cg = create_and_get_cgroup("/cg_autodetach");
[...]
> +
>   int main(int argc, char **argv)
>   {
> - int (*tests[])(void) = {test_foo_bar, test_multiprog};
> + int (*tests[])(void) = {
> + test_foo_bar,
> + test_multiprog,
> + test_autodetach,
> + };
>   int errors = 0;
>   int i;
>   
> 

Re: -Wuninitialized warning in drivers/misc/sgi-xp/xpc_partition.c

[Greg Kroah-Hartman]

On Wed, May 22, 2019 at 06:56:39PM -0700, Nathan Chancellor wrote:
> On Thu, May 02, 2019 at 08:33:40PM -0700, Nathan Chancellor wrote:
> > Hi all,
> > 
> > When building with -Wuninitialized, Clang warns:
> > 
> > drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is 
> > uninitialized when used within its own initialization [-Wuninitialized]
> > void *buf = buf;
> >   ~~~   ^~~
> > 1 warning generated.
> > 
> > I am not really sure how to properly initialize buf in this instance.
> > I would assume it would involve xpc_kmalloc_cacheline_aligned like
> > further down in the function but maybe not, this function isn't entirely
> > clear. Could we get your input, this is one of the last warnings I see
> > in a few allyesconfig builds.
> > 
> > Thanks,
> > Nathan
> 
> Hi all,
> 
> Friendly ping for comments/input. This is one of a few remaining
> warnings I see, it'd be nice to get it fixed up so we can turn it on for
> the whole kernel.

Patches are gladly welcome :)

thanks,

greg k-h

[PATCH] scsi: smartpqi: properly set both the DMA mask and the coherent DMA mask in pqi_pci_init()

[Lianbo Jiang]

When SME is enabled, the smartpqi driver won't work on the HP DL385
G10 machine, which causes the failure of kernel boot because it fails
to allocate pqi error buffer. Please refer to the kernel log:

[9.431749] usbcore: registered new interface driver uas
[9.441524] Microsemi PQI Driver (v1.1.4-130)
[9.442956] i40e :04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5
[9.447237] smartpqi :23:00.0: Microsemi Smart Family Controller found
 Starting dracut initqueue hook...
[  OK  ] Started Show Plymouth Boot Scre[9.471654] Broadcom NetXtreme-C/E 
driver bnxt_en v1.9.1
en.
[  OK  ] Started Forward Password Requests to Plymouth Directory Watch.
[[0;[9.487108] smartpqi :23:00.0: failed to allocate PQI error buffer

[  139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - 
starting timeout scripts

For correct operation, lets call the dma_set_mask_and_coherent() to
properly set the mask for both streaming and coherent, in order to
inform the kernel about the devices DMA addressing capabilities.

Signed-off-by: Lianbo Jiang 
---
 drivers/scsi/smartpqi/smartpqi_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index c26cac819f9e..8b1fde6c7dab 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -7282,7 +7282,7 @@ static int pqi_pci_init(struct pqi_ctrl_info *ctrl_info)
else
mask = DMA_BIT_MASK(32);
 
-   rc = dma_set_mask(_info->pci_dev->dev, mask);
+   rc = dma_set_mask_and_coherent(_info->pci_dev->dev, mask);
if (rc) {
dev_err(_info->pci_dev->dev, "failed to set DMA mask\n");
goto disable_device;
-- 
2.17.1

Re: [PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf

[Greg Kroah-Hartman]

On Wed, May 22, 2019 at 07:51:13PM -0700, Scott Branden wrote:
> Adjust request_firmware_into_buf API to allow for portions
> of firmware file to be read into a buffer.  mdt_loader still
> retricts request fo whole file read into buffer.
> 
> Signed-off-by: Scott Branden 
> ---
>  drivers/soc/qcom/mdt_loader.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 1c488024c698..ad20d159699c 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const 
> struct firmware *fw,
>  
>   if (phdr->p_filesz) {
>   sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> - ret = request_firmware_into_buf(_fw, fw_name, dev,
> - ptr, phdr->p_filesz);
> + ret = request_firmware_into_buf
> + (_fw, fw_name, dev,
> +  ptr, phdr->p_filesz,
> +  0,
> +  KERNEL_PREAD_FLAG_WHOLE);

So, all that work in the first 2 patches for no real change at all?  Why
are these changes even needed?

And didn't you break this driver in patch 2/3?  You can't fix it up
later here, you need to also resolve that in the 2nd patch.

thanks,

greg k-h

[PATCH 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox

[Peng Fan]

The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---

V1:
arm,func-ids is still kept as an optional property, because there is no
defined SMC funciton id passed from SCMI. So in my test, I still use
arm,func-ids for ARM SIP service.

 .../devicetree/bindings/mailbox/arm-smc.txt| 96 ++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt 
b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index ..12fc5997933d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,96 @@
+ARM SMC Mailbox Interface
+=
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCMI interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1].
+Firmware expects an SMC function identifier in r0 or w0. The supported
+identifiers are passed from consumers, or listed in the the arm,func-ids
+properties as described below. The firmware can return one value in
+the first SMC result register, it is expected to be an error value,
+which shall be propagated to the mailbox client.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+
+- compatible:  Shall be "arm,smc-mbox"
+- #mbox-cells  Shall be 1 - the index of the channel needed.
+- arm,num-chansThe number of channels supported.
+- method:  A string, either:
+   "hvc": if the driver shall use an HVC call, or
+   "smc": if the driver shall use an SMC call.
+
+Optional properties:
+- arm,func-ids An array of 32-bit values specifying the function
+   IDs used by each mailbox channel. Those function IDs
+   follow the ARM SMC calling convention standard [1].
+   There is one identifier per channel and the number
+   of supported channels is determined by the length
+   of this array.
+
+Example:
+
+
+   sram@91 {
+   compatible = "mmio-sram";
+   reg = <0x0 0x93f000 0x0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0 0x93f000 0x1000>;
+
+   cpu_scp_lpri: scp-shmem@0 {
+   compatible = "arm,scmi-shmem";
+   reg = <0x0 0x200>;
+   };
+
+   cpu_scp_hpri: scp-shmem@200 {
+   compatible = "arm,scmi-shmem";
+   reg = <0x200 0x200>;
+   };
+   };
+
+   smc_mbox: mailbox {
+   #mbox-cells = <1>;
+   compatible = "arm,smc-mbox";
+   method = "smc";
+   arm,num-chans = <0x2>;
+   /* Optional */
+   arm,func-ids = <0xc2fe>, <0xc2ff>;
+   };
+
+   firmware {
+   scmi {
+   compatible = "arm,scmi";
+   mboxes = < 0  1>;
+   mbox-names = "tx", "rx";
+   shmem = <_scp_lpri _scp_hpri>;
+   };
+   };
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.16.4

[PATCH 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig |   7 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/arm-smc-mailbox.c   | 154 
 include/linux/mailbox/arm-smc-mailbox.h |  10 +++
 4 files changed, 173 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smc-mailbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..f4da1061f7f0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_USE_HVC   BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   struct arm_smccc_res res;
+   u32 function_id;
+
+   if (chan_data->function_id != UINT_MAX)
+   function_id = chan_data->function_id;
+   else
+   function_id = cmd->a0;
+
+   if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+   arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+   else
+   arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, );
+
+   mbox_chan_received_data(link, (void *)res.a0);
+
+   return 0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+   .send_data  = arm_smc_send_data,
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct mbox_controller *mbox;
+   struct arm_smc_chan_data *chan_data;
+   const char *method;
+   bool use_hvc = false;
+   int ret, i;
+   u32 val;
+
+   if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
+   if (val < 1 || val > INT_MAX) {
+   dev_err(dev, "invalid arm,num-chans value %u of 
%pOFn\n", val, pdev->dev.of_node);
+   return -EINVAL;
+   }
+   }
+
+   if (!of_property_read_string(dev->of_node, "method", )) {
+   if (!strcmp("hvc", method)) {
+   use_hvc = true;
+   } else if (!strcmp("smc", method)) {
+   use_hvc = false;
+   } else {
+   dev_warn(dev, "invalid \"method\" property: %s\n",
+method);
+
+   return -EINVAL;
+   }
+   }
+
+   mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+   if (!mbox)
+   return -ENOMEM;
+
+   mbox->num_chans = val;
+   mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+  GFP_KERNEL);
+   if (!mbox->chans)
+   return -ENOMEM;
+
+   chan_data = devm_kcalloc(dev, 

[PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
though this is synchronous and one-way only (triggered by the OS only,
without providing an asynchronous way of triggering request from the
firmware).
And while providing SCMI services was the reason for this exercise, this
driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi

Peng Fan (2):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.txt|  96 +
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 154 +
 include/linux/mailbox/arm-smc-mailbox.h|  10 ++
 5 files changed, 269 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smc-mailbox.h

-- 
2.16.4

Re: [PATCH v2 bpf-next 4/4] selftests/bpf: add auto-detach test

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> Add a kselftest to cover bpf auto-detachment functionality.
> The test creates a cgroup, associates some resources with it,
> attaches a couple of bpf programs and deletes the cgroup.
> 
> Then it checks that bpf programs are going away in 5 seconds.
> 
> Expected output:
>$ ./test_cgroup_attach
>#override:PASS
>#multi:PASS
>#autodetach:PASS
>test_cgroup_attach:PASS
> 
> On a kernel without auto-detaching:
>$ ./test_cgroup_attach
>#override:PASS
>#multi:PASS
>#autodetach:FAIL
>test_cgroup_attach:FAIL

I ran this problem without both old and new kernels and
both get all PASSes. My testing environment is a VM.
Could you specify how to trigger the above failure?

> 
> Signed-off-by: Roman Gushchin 
> ---
>   .../selftests/bpf/test_cgroup_attach.c| 99 ++-
>   1 file changed, 98 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/bpf/test_cgroup_attach.c 
> b/tools/testing/selftests/bpf/test_cgroup_attach.c
> index 93d4fe295e7d..bc5bd0f1728e 100644
> --- a/tools/testing/selftests/bpf/test_cgroup_attach.c
> +++ b/tools/testing/selftests/bpf/test_cgroup_attach.c
> @@ -456,9 +456,106 @@ static int test_multiprog(void)
>   return rc;
>   }
>   
> +static int test_autodetach(void)
> +{
> + __u32 prog_cnt = 4, attach_flags;
> + int allow_prog[2] = {0};
> + __u32 prog_ids[2] = {0};
> + int cg = 0, i, rc = -1;
> + void *ptr = NULL;
> + int attempts;
> +
> +
> + for (i = 0; i < ARRAY_SIZE(allow_prog); i++) {
> + allow_prog[i] = prog_load_cnt(1, 1 << i);
> + if (!allow_prog[i])
> + goto err;
> + }
> +
> + if (setup_cgroup_environment())
> + goto err;
> +
> + /* create a cgroup, attach two programs and remember their ids */
> + cg = create_and_get_cgroup("/cg_autodetach");
> + if (cg < 0)
> + goto err;
> +
> + if (join_cgroup("/cg_autodetach"))
> + goto err;
> +
> + for (i = 0; i < ARRAY_SIZE(allow_prog); i++) {
> + if (bpf_prog_attach(allow_prog[i], cg, BPF_CGROUP_INET_EGRESS,
> + BPF_F_ALLOW_MULTI)) {
> + log_err("Attaching prog[%d] to cg:egress", i);
> + goto err;
> + }
> + }
> +
> + /* make sure that programs are attached and run some traffic */
> + assert(bpf_prog_query(cg, BPF_CGROUP_INET_EGRESS, 0, _flags,
> +   prog_ids, _cnt) == 0);
> + assert(system(PING_CMD) == 0);
> +
> + /* allocate some memory (4Mb) to pin the original cgroup */
> + ptr = malloc(4 * (1 << 20));
> + if (!ptr)
> + goto err;
> +
> + /* close programs and cgroup fd */
> + for (i = 0; i < ARRAY_SIZE(allow_prog); i++) {
> + close(allow_prog[i]);
> + allow_prog[i] = 0;
> + }
> +
> + close(cg);
> + cg = 0;
> +
> + /* leave the cgroup and remove it. don't detach programs */
> + cleanup_cgroup_environment();
> +
> + /* wait for the asynchronous auto-detachment.
> +  * wait for no more than 5 sec and give up.
> +  */
> + for (i = 0; i < ARRAY_SIZE(prog_ids); i++) {
> + for (attempts = 5; attempts >= 0; attempts--) {
> + int fd = bpf_prog_get_fd_by_id(prog_ids[i]);
> +
> + if (fd < 0)
> + break;
> +
> + /* don't leave the fd open */
> + close(fd);
> +
> + if (!attempts)
> + goto err;
> +
> + sleep(1);
> + }
> + }
> +
> + rc = 0;
> +err:
> + for (i = 0; i < ARRAY_SIZE(allow_prog); i++)
> + if (allow_prog[i] > 0)
> + close(allow_prog[i]);
> + if (cg)
> + close(cg);
> + free(ptr);
> + cleanup_cgroup_environment();
> + if (!rc)
> + printf("#autodetach:PASS\n");
> + else
> + printf("#autodetach:FAIL\n");
> + return rc;
> +}
> +
>   int main(int argc, char **argv)
>   {
> - int (*tests[])(void) = {test_foo_bar, test_multiprog};
> + int (*tests[])(void) = {
> + test_foo_bar,
> + test_multiprog,
> + test_autodetach,
> + };
>   int errors = 0;
>   int i;
>   
> 

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

[Kris Van Hees]

On Wed, May 22, 2019 at 01:53:31PM -0700, Alexei Starovoitov wrote:
> On Wed, May 22, 2019 at 01:23:27AM -0400, Kris Van Hees wrote:
> > 
> > Userspace aside, there are various features that are not currently available
> > such as retrieving the ppid of the current task, and various other data 
> > items
> > that relate to the current task that triggered a probe.  There are ways to
> > work around it (using the bpf_probe_read() helper, which actually performs a
> > probe_kernel_read()) but that is rather clunky
> 
> Sounds like you're admiting that the access to all kernel data structures
> is actually available, but you don't want to change user space to use it?

I of course agree that access to all kernel structures can be done using the
bpf_probe_read() helper.  But I hope you agree that the availability of that
helper doesn't mean that there is no room for more elegant ways to access
information.  There are already helpers (e.g. bpf_get_current_pid_tgid) that
could be replaced by BPF code that uses bpf_probe_read to accomplish the same
thing.

> > triggered the execution.  Often, a single DTrace clause is associated with
> > multiple probes, of different types.  Probes in the kernel (kprobe, perf 
> > event,
> > tracepoint, ...) are associated with their own BPF program type, so it is 
> > not
> > possible to load the DTrace clause (translated into BPF code) once and
> > associate it with probes of different types.  Instead, I'd have to load it
> > as a BPF_PROG_TYPE_KPROBE program to associate it with a kprobe, and I'd 
> > have
> > to load it as a BPF_PROG_TYPE_TRACEPOINT program to associate it with a
> > tracepoint, and so on.  This also means that I suddenly have to add code to
> > the userspace component to know about the different program types with more
> > detail, like what helpers are available to specific program types.
> 
> That also sounds that there is a solution, but you don't want to change user 
> space ?

I think there is a difference between a solution and a good solution.  Adding
a lot of knowledge in the userspace component about how things are imeplemented
at the kernel level makes for a more fragile infrastructure and involves
breaking down well established boundaries in DTrace that are part of the design
specifically to ensure that userspace doesn't need to depend on such intimate
knowledge.

> > Another advantage of being able to operate on a more abstract probe concept
> > that is not tied to a specific probe type is that the userspace component 
> > does
> > not need to know about the implementation details of the specific probes.
> 
> If that is indeed the case that dtrace is broken _by design_
> and nothing on the kernel side can fix it.
> 
> bpf prog attached to NMI is running in NMI.
> That is very different execution context vs kprobe.
> kprobe execution context is also different from syscall.
> 
> The user writing the script has to be aware in what context
> that script will be executing.

The design behind DTrace definitely recognizes that different types of probes
operate in different ways and have different data associated with them.  That
is why probes (in legacy DTrace) are managed by providers, one for each type
of probe.  The providers handle the specifics of a probe type, and provide a
generic probe API to the processing component of DTrace:

SDT probes -> SDT provider ---+
  |
FBT probes -> FBT provider ---+--> DTrace engine
  |
syscall probes -> systrace provider --+

This means that the DTrace processing component can be implemented based on a
generic probe concept, and the providers will take care of the specifics.  In
that sense, it is similar to so many other parts of the kernel where a generic
API is exposed so that higher level components don't need to know implementation
details.

In DTrace, people write scripts based on UAPI-style interfaces and they don't
have to concern themselves with e.g. knowing how to get the value of the 3rd
argument that was passed by the firing probe.  All they need to know is that
the probe will have a 3rd argument, and that the 3rd argument to *any* probe
can be accessed as 'arg2' (or args[2] for typed arguments, if the provider is
capable of providing that).  Different probes have different ways of passing
arguments, and only the provider code for each probe type needs to know how
to retrieve the argument values.

Does this help bring clarity to the reasons why an abstract (generic) probe
concept is part of DTrace's design?

Re: [PATCH v2 bpf-next 3/4] selftests/bpf: enable all available cgroup v2 controllers

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> Enable all available cgroup v2 controllers when setting up
> the environment for the bpf kselftests. It's required to properly test
> the bpf prog auto-detach feature. Also it will generally increase
> the code coverage.
> 
> Signed-off-by: Roman Gushchin 
Looks good to me. Ack with one nit below.
Acked-by: Yonghong Song 

> ---
>   tools/testing/selftests/bpf/cgroup_helpers.c | 57 
>   1 file changed, 57 insertions(+)
> 
> diff --git a/tools/testing/selftests/bpf/cgroup_helpers.c 
> b/tools/testing/selftests/bpf/cgroup_helpers.c
> index 6692a40a6979..4efe57c171cd 100644
> --- a/tools/testing/selftests/bpf/cgroup_helpers.c
> +++ b/tools/testing/selftests/bpf/cgroup_helpers.c
> @@ -33,6 +33,60 @@
>   snprintf(buf, sizeof(buf), "%s%s%s", CGROUP_MOUNT_PATH, \
>CGROUP_WORK_DIR, path)
>   
> +/**
> + * enable_all_controllers() - Enable all available cgroup v2 controllers
> + *
> + * Enable all available cgroup v2 controllers in order to increase
> + * the code coverage.
> + *
> + * If successful, 0 is returned.
> + */
> +int enable_all_controllers(char *cgroup_path)
> +{
> + char path[PATH_MAX + 1];
> + char buf[PATH_MAX];
> + char *c, *c2;
> + int fd, cfd;
> + size_t len;
> +
> + snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path);
> + fd = open(path, O_RDONLY);
> + if (fd < 0) {
> + log_err("Opening cgroup.controllers: %s", path);
> + return -1;
It looks like either -1 or 1 could be returned to indicate an error
in this file. Maybe, at least for the consistency of this file,
always returning 1 is preferred as setup_cgroup_environment()
has the following comments:
  * This function will print an error to stderr and return 1 if it is unable
  * to setup the cgroup environment. If setup is successful, 0 is returned.

> + }
> +
> + len = read(fd, buf, sizeof(buf) - 1);
> + if (len < 0) {
> + close(fd);
> + log_err("Reading cgroup.controllers: %s", path);
> + return -1;
> + }
> + buf[len] = 0;
> + close(fd);
> +
> + /* No controllers available? We're probably on cgroup v1. */
> + if (len == 0)
> + return 0;
> +
> + snprintf(path, sizeof(path), "%s/cgroup.subtree_control", cgroup_path);
> + cfd = open(path, O_RDWR);
> + if (cfd < 0) {
> + log_err("Opening cgroup.subtree_control: %s", path);
> + return -1;
> + }
> +
> + for (c = strtok_r(buf, " ", ); c; c = strtok_r(NULL, " ", )) {
> + if (dprintf(cfd, "+%s\n", c) <= 0) {
> + log_err("Enabling controller %s: %s", c, path);
> + close(cfd);
> + return -1;
> + }
> + }
> + close(cfd);
> + return 0;
> +}
> +
>   /**
>* setup_cgroup_environment() - Setup the cgroup environment
>*
> @@ -71,6 +125,9 @@ int setup_cgroup_environment(void)
>   return 1;
>   }
>   
> + if (enable_all_controllers(cgroup_workdir))
> + return 1;
> +
>   return 0;
>   }
>   
> 

Re: [PATCH 5.0 119/123] s390/mm: convert to the generic get_user_pages_fast code

[Greg Kroah-Hartman]

On Wed, May 22, 2019 at 04:46:16PM -0500, Justin Forbes wrote:
> On Mon, May 20, 2019 at 7:30 AM Greg Kroah-Hartman
>  wrote:
> >
> > From: Martin Schwidefsky 
> >
> > commit 1a42010cdc26bb7e5912984f3c91b8c6d55f089a upstream.
> >
> > Define the gup_fast_permitted to check against the asce_limit of the
> > mm attached to the current task, then replace the s390 specific gup
> > code with the generic implementation in mm/gup.c.
> >
> > Signed-off-by: Martin Schwidefsky 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> While this code seems to work fine upstream, when backported to 5.0 it
> fails to build:
> 
> BUILDSTDERR: In file included from ./include/linux/mm.h:98,
> BUILDSTDERR:  from mm/gup.c:6:
> BUILDSTDERR: mm/gup.c: In function '__get_user_pages_fast':
> BUILDSTDERR: ./arch/s390/include/asm/pgtable.h:1277:28: error: too
> many arguments to function 'gup_fast_permitted'
> BUILDSTDERR:  #define gup_fast_permitted gup_fast_permitted
> BUILDSTDERR: ^~
> BUILDSTDERR: mm/gup.c:1856:6: note: in expansion of macro 'gup_fast_permitted'
> BUILDSTDERR:   if (gup_fast_permitted(start, nr_pages, write)) {
> 
> It is missing upstream commit ad8cfb9c42ef83ecf4079bc7d77e6557648e952b
> mm/gup: Remove the 'write' parameter from gup_fast_permitted()

Oops, thanks for catching this.  I'll go queue this patch up now.

greg k-h

Re: [PATCH v2 bpf-next 2/4] selftests/bpf: convert test_cgrp2_attach2 example into kselftest

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> Convert test_cgrp2_attach2 example into a proper test_cgroup_attach
> kselftest. It's better because we do run kselftest on a constant
> basis, so there are better chances to spot a potential regression.
> 
> Also make it slightly less verbose to conform kselftests output style.
> 
> Output example:
>$ ./test_cgroup_attach
>#override:PASS
>#multi:PASS
>test_cgroup_attach:PASS
> 
> Signed-off-by: Roman Gushchin 
Ack except the nit below.
Acked-by: Yonghong Song 
> ---
>   samples/bpf/Makefile  |  2 -
>   tools/testing/selftests/bpf/Makefile  |  4 +-
>   .../selftests/bpf/test_cgroup_attach.c| 48 ---
>   3 files changed, 35 insertions(+), 19 deletions(-)
>   rename samples/bpf/test_cgrp2_attach2.c => 
> tools/testing/selftests/bpf/test_cgroup_attach.c (92%)
> 
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 4f0a1cdbfe7c..253e5a2856be 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -26,7 +26,6 @@ hostprogs-y += map_perf_test
>   hostprogs-y += test_overhead
>   hostprogs-y += test_cgrp2_array_pin
>   hostprogs-y += test_cgrp2_attach
> -hostprogs-y += test_cgrp2_attach2
>   hostprogs-y += test_cgrp2_sock
>   hostprogs-y += test_cgrp2_sock2
>   hostprogs-y += xdp1
> @@ -81,7 +80,6 @@ map_perf_test-objs := bpf_load.o map_perf_test_user.o
>   test_overhead-objs := bpf_load.o test_overhead_user.o
>   test_cgrp2_array_pin-objs := test_cgrp2_array_pin.o
>   test_cgrp2_attach-objs := test_cgrp2_attach.o
> -test_cgrp2_attach2-objs := test_cgrp2_attach2.o $(CGROUP_HELPERS)
>   test_cgrp2_sock-objs := test_cgrp2_sock.o
>   test_cgrp2_sock2-objs := bpf_load.o test_cgrp2_sock2.o
>   xdp1-objs := xdp1_user.o
> diff --git a/tools/testing/selftests/bpf/Makefile 
> b/tools/testing/selftests/bpf/Makefile
> index 66f2dca1dee1..e09f419f4d7e 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -23,7 +23,8 @@ TEST_GEN_PROGS = test_verifier test_tag test_maps 
> test_lru_map test_lpm_map test
>   test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
>   test_sock test_btf test_sockmap test_lirc_mode2_user get_cgroup_id_user 
> \
>   test_socket_cookie test_cgroup_storage test_select_reuseport 
> test_section_names \
> - test_netcnt test_tcpnotify_user test_sock_fields test_sysctl
> + test_netcnt test_tcpnotify_user test_sock_fields test_sysctl \
> + test_cgroup_attach
>   
>   BPF_OBJ_FILES = $(patsubst %.c,%.o, $(notdir $(wildcard progs/*.c)))
>   TEST_GEN_FILES = $(BPF_OBJ_FILES)
> @@ -96,6 +97,7 @@ $(OUTPUT)/test_cgroup_storage: cgroup_helpers.c
>   $(OUTPUT)/test_netcnt: cgroup_helpers.c
>   $(OUTPUT)/test_sock_fields: cgroup_helpers.c
>   $(OUTPUT)/test_sysctl: cgroup_helpers.c
> +$(OUTPUT)/test_cgroup_attach: cgroup_helpers.c
>   
>   .PHONY: force
>   
> diff --git a/samples/bpf/test_cgrp2_attach2.c 
> b/tools/testing/selftests/bpf/test_cgroup_attach.c
> similarity index 92%
> rename from samples/bpf/test_cgrp2_attach2.c
> rename to tools/testing/selftests/bpf/test_cgroup_attach.c
> index 0bb6507256b7..93d4fe295e7d 100644
> --- a/samples/bpf/test_cgrp2_attach2.c
> +++ b/tools/testing/selftests/bpf/test_cgroup_attach.c
> @@ -1,3 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
>   /* eBPF example program:
>*
>* - Creates arraymap in kernel with 4 bytes keys and 8 byte values
> @@ -25,20 +27,27 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   #include 
>   
> -#include "bpf_insn.h"
> +#include "bpf_util.h"
>   #include "bpf_rlimit.h"
>   #include "cgroup_helpers.h"
>   
>   #define FOO "/foo"
>   #define BAR "/foo/bar/"
> -#define PING_CMD "ping -c1 -w1 127.0.0.1 > /dev/null"
> +#define PING_CMD "ping -q -c1 -w1 127.0.0.1 > /dev/null"
>   
>   char bpf_log_buf[BPF_LOG_BUF_SIZE];
>   
> +#ifdef DEBUG
> +#define debug(args...) printf(args)
> +#else
> +#define debug(args...)
> +#endif
> +
>   static int prog_load(int verdict)
>   {
>   int ret;
> @@ -89,7 +98,7 @@ static int test_foo_bar(void)
>   goto err;
>   }
>   
> - printf("Attached DROP prog. This ping in cgroup /foo should fail...\n");
> + debug("Attached DROP prog. This ping in cgroup /foo should fail...\n");
>   assert(system(PING_CMD) != 0);
>   
>   /* Create cgroup /foo/bar, get fd, and join it */
> @@ -100,7 +109,7 @@ static int test_foo_bar(void)
>   if (join_cgroup(BAR))
>   goto err;
>   
> - printf("Attached DROP prog. This ping in cgroup /foo/bar should 
> fail...\n");
> + debug("Attached DROP prog. This ping in cgroup /foo/bar should 
> fail...\n");
>   assert(system(PING_CMD) != 0);
>   
>   if (bpf_prog_attach(allow_prog, bar, BPF_CGROUP_INET_EGRESS,
> @@ -109,7 +118,7 @@ static int test_foo_bar(void)
>   goto err;
>   }
>   
> - printf("Attached PASS prog. This ping 

Re: [PATCH 1/6] staging: kpc2000: make kconfig symbol 'KPC2000' select dependencies

[Greg Kroah-Hartman]

On Thu, May 23, 2019 at 01:35:02AM +, Geordan Neukum wrote:
> On Wed, May 22, 2019 at 12:27 PM Greg Kroah-Hartman
>  wrote:
> > depends on is better than select.  There's a change to depend on UIO for
> > this code already in my -linus branch which will show up in Linus's tree
> > in a week or so.
> 
> Noted on both accounts. Thanks for the feedback and sorry for the
> inconvenience on the latter.
> 
> > Are you sure we need MFD_CORE as well for this code?
> 
> I noticed the build issue when working locally. I was doing
> something along the lines of: 'make distclean && make x86_64_defconfig',
> selecting 'CONFIG_KPC2000' and 'CONFIG_UIO' via menuconfig, then
> running a good old 'make'. From make, I received an error along the
> lines of:
> 
> ERROR: "mfd_remove_devices"
> [drivers/staging/kpc2000/kpc2000/kpc2000.ko] undefined!
> ERROR: "mfd_add_devices" [drivers/staging/kpc2000/kpc2000/kpc2000.ko] 
> undefined!
> make[1]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
> make: *** [Makefile:1290: modules] Error 2
> 
> which appears to indicate that those two symbols are undefined. When
> I looked, it appeared that those symbols were exported from the
> mfd-core which is why I also threw in a select for that Kconfig
> symbol. Assuming that I didn't do something silly above, I'd be happy
> to submit a new patch (with only a depends on for MFD_CORE) as I
> continue trying to fix up the i2c driver.

Yes, a depends for MFD_CORE would be good, can you base it against my
staging-linus branch so that fix can go to Linus for this release?

thanks,

greg k-h

[PATCH v2] perf/x86: always include regs->ip in callchain

[Song Liu]

Commit d15d356887e7 removes regs->ip for !perf_hw_regs(regs) case. This
patch adds regs->ip back.

Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without 
CONFIG_FRAME_POINTER")
Cc: Kairui Song 
Cc: Peter Zijlstra (Intel) 
Signed-off-by: Song Liu 
---
 arch/x86/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index f315425d8468..7b8a9eb4d5fd 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2402,9 +2402,9 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx 
*entry, struct pt_regs *re
return;
}
 
+   if (perf_callchain_store(entry, regs->ip))
+   return;
if (perf_hw_regs(regs)) {
-   if (perf_callchain_store(entry, regs->ip))
-   return;
unwind_start(, current, regs, NULL);
} else {
unwind_start(, current, NULL, (void *)regs->sp);
-- 
2.17.1

Re: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE

[Marek Szyprowski]

Hi Robin,

On 2019-05-22 15:55, Robin Murphy wrote:
> On 22/05/2019 14:34, Christoph Hellwig wrote:
>> On Wed, May 22, 2019 at 02:25:38PM +0100, Robin Murphy wrote:
>>> Sure, but that should be irrelevant since the effective problem here 
>>> is in
>>> the sync_*_for_cpu direction, and it's the unmap which nobbles the 
>>> buffer.
>>> If the driver does this:
>>>
>>> dma_map_single(whole buffer);
>>> 
>>> dma_unmap_single(whole buffer);
>>> 
>>>
>>> then it could instead do this and be happy:
>>>
>>> dma_map_single(whole buffer, SKIP_CPU_SYNC);
>>> 
>>> dma_sync_single_for_cpu(updated part of buffer);
>>> dma_unmap_single(whole buffer, SKIP_CPU_SYNC);
>>> 
>>
>> Assuming the driver knows how much was actually DMAed this would
>> solve the issue.  Horia, does this work for you?
>
> Ohhh, and now I've just twigged what you were suggesting - your 
> DMA_ATTR_PARTIAL flag would mean "treat this as a read-modify-write of 
> the buffer because we *don't* know exactly which parts the device may 
> write to". So indeed if we did go down that route we wouldn't need any 
> of the sync stuff I was worrying about (but I might suggest naming it 
> DMA_ATTR_UPDATE instead). Apologies for being slow :)

Don't we have DMA_BIDIRECTIONAL for such case? Maybe we should update 
documentation a bit to point that DMA_FROM_DEVICE expects the whole 
buffer to be filled by the device?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v4 11/14] dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm

[Vinod Koul]

On 22-05-19, 10:00, Robin Gong wrote:
> Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
> check ignore such special case without dma channel enabled, which caused
> ecspi1 rx works failed. Actually, no need to check event_id0/event_id1
> and replace checking 'event_id1' with 'DMA_DEV_TO_DEV', so that configure
> event_id1 only in case DEV_TO_DEV.

Acked-by: Vinod Koul 

-- 
~Vinod

Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1

[Thomas Gleixner]

On Wed, 22 May 2019, Joe Perches wrote:

> On Thu, 2019-05-23 at 11:49 +0900, Masahiro Yamada wrote:
> > On Wed, May 22, 2019 at 3:37 PM Joe Perches  wrote:
> []
> > > I could also wire up a patch to checkpatch and docs to
> > > remove the /* */ requirement for .h files and prefer
> > > the generic // form for both .c and .h files as the
> > > current minimum tooling versions now all allow //
> > > comments
> > > .
> > 
> > We have control for minimal tool versions for building the kernel,
> > so I think // will be OK for in-kernel headers.
> > 
> > 
> > On the other hand, I am not quite sure about UAPI headers.
> > We cannot define minimum tool versions
> > for building user-space.
> > Perhaps, using // in UAPI headers causes a problem
> > if an ancient compiler is used?
> 
> Good point. Thanks.

Indeed. Did not think about the UAPI part at all.

Thanks,

tglx

Re: [PATCH v2 bpf-next 1/4] bpf: decouple the lifetime of cgroup_bpf from cgroup itself

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> Currently the lifetime of bpf programs attached to a cgroup is bound
> to the lifetime of the cgroup itself. It means that if a user
> forgets (or intentionally avoids) to detach a bpf program before
> removing the cgroup, it will stay attached up to the release of the
> cgroup. Since the cgroup can stay in the dying state (the state
> between being rmdir()'ed and being released) for a very long time, it
> leads to a waste of memory. Also, it blocks a possibility to implement
> the memcg-based memory accounting for bpf objects, because a circular
> reference dependency will occur. Charged memory pages are pinning the
> corresponding memory cgroup, and if the memory cgroup is pinning
> the attached bpf program, nothing will be ever released.
> 
> A dying cgroup can not contain any processes, so the only chance for
> an attached bpf program to be executed is a live socket associated
> with the cgroup. So in order to release all bpf data early, let's
> count associated sockets using a new percpu refcounter. On cgroup
> removal the counter is transitioned to the atomic mode, and as soon
> as it reaches 0, all bpf programs are detached.
> 
> The reference counter is not socket specific, and can be used for any
> other types of programs, which can be executed from a cgroup-bpf hook
> outside of the process context, had such a need arise in the future.
> 
> Signed-off-by: Roman Gushchin 
> Cc: jo...@redhat.com

The logic looks sound to me. With one nit below,
Acked-by: Yonghong Song 

> ---
>   include/linux/bpf-cgroup.h |  8 ++--
>   include/linux/cgroup.h | 18 ++
>   kernel/bpf/cgroup.c| 25 ++---
>   kernel/cgroup/cgroup.c | 11 ---
>   4 files changed, 54 insertions(+), 8 deletions(-)
> 
[...]
> @@ -167,7 +178,12 @@ int cgroup_bpf_inherit(struct cgroup *cgrp)
>*/
>   #define NR ARRAY_SIZE(cgrp->bpf.effective)
>   struct bpf_prog_array __rcu *arrays[NR] = {};
> - int i;
> + int ret, i;
> +
> + ret = percpu_ref_init(>bpf.refcnt, cgroup_bpf_release, 0,
> +   GFP_KERNEL);
> + if (ret)
> + return -ENOMEM;
Maybe return "ret" here instead of -ENOMEM. Currently, percpu_ref_init
only return error code is -ENOMEM. But in the future, it could
change?

>   
>   for (i = 0; i < NR; i++)
>   INIT_LIST_HEAD(>bpf.progs[i]);
> @@ -183,6 +199,9 @@ int cgroup_bpf_inherit(struct cgroup *cgrp)
>   cleanup:
>   for (i = 0; i < NR; i++)
>   bpf_prog_array_free(arrays[i]);
> +
> + percpu_ref_exit(>bpf.refcnt);
> +
>   return -ENOMEM;
>   }
>   
[...]

Re: [PATCH] tick/sched: Drop duplicated tick_sched.inidle

[Peter Xu]

On Wed, May 22, 2019 at 02:18:41PM +0200, Frederic Weisbecker wrote:
> On Wed, May 22, 2019 at 11:29:06AM +0800, Peter Xu wrote:
> > It is set before entering idle and cleared when quitting idle, though
> > it seems to be a complete duplicate of tick_sched.idle_active.  We
> > should probably be able to use any one of them to replace the other.
> 
> Not exactly.
> 
> @inidle is set on idle entry and cleared on idle exit.
> @idle_active is the same but it's cleared during idle interrupts
> so that idle_sleeptime only account real idle time.
> 
> And note below:
> 
> > @@ -1017,7 +1015,7 @@ void tick_nohz_irq_exit(void)
> >  {
> > struct tick_sched *ts = this_cpu_ptr(_cpu_sched);
> >  
> > -   if (ts->inidle)
> > +   if (ts->idle_active)
> > tick_nohz_start_idle(ts);
> 
> idle_active will always be cleared here from tick_nohz_irq_enter().
> We actually want to conditionally set it again depending on the inidle value.

You are right; I've missed the calls from irq enter/exit. Thanks, Frederic.

-- 
Peter Xu
 

Re: [PATCH AUTOSEL 5.1 077/375] USB: serial: fix initial-termios handling

[Johan Hovold]

Hi Sasha,

On Wed, May 22, 2019 at 03:16:17PM -0400, Sasha Levin wrote:
> From: Johan Hovold 
> 
> [ Upstream commit 579bebe5dd522580019e7b10b07daaf500f9fb1e ]
> 
> The USB-serial driver init_termios callback is used to override the
> default initial terminal settings provided by USB-serial core.
> 
> After a bug was fixed in the original implementation introduced by
> commit fe1ae7fdd2ee ("tty: USB serial termios bits"), the init_termios
> callback was no longer called just once on first use as intended but
> rather on every (first) open.
> 
> This specifically meant that the terminal settings saved on (final)
> close were ignored when reopening a port for drivers overriding the
> initial settings.
> 
> Also update the outdated function header referring to the creation of
> termios objects.
> 
> Fixes: 7e29bb4b779f ("usb-serial: fix termios initialization logic")
> Signed-off-by: Johan Hovold 
> Signed-off-by: Sasha Levin 

The stable tag was left out on purpose as this is essentially a new
feature, and definitely a behavioural change which should not be
backported.

Please drop from your autosel queues.

Also, may I ask you again not to include usb-serial (and drivers/gnss)
in your autosel processing.

Thanks,
Johan

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

[Kris Van Hees]

On Wed, May 22, 2019 at 12:55:27PM -0700, Alexei Starovoitov wrote:
> On Wed, May 22, 2019 at 02:22:15PM -0400, Kris Van Hees wrote:
> > On Wed, May 22, 2019 at 04:25:32PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote:
> > > 
> > > > and no changes are necessary in kernel/events/ring_buffer.c either.
> > > 
> > > Let me just NAK them on the principle that I don't see them in my inbox.
> > 
> > My apologies for failing to include you on the Cc for the patches.  That was
> > an oversight on my end and certainly not intentional.
> > 
> > > Let me further NAK it for adding all sorts of garbage to the code --
> > > we're not going to do gaps and stay_in_page nonsense.
> > 
> > Could you give some guidance in terms of an alternative?  The ring buffer 
> > code
> > provides both non-contiguous page allocation support and a vmalloc-based
> > allocation, and the vmalloc version certainly would avoid the entire gap and
> > page boundary stuff.  But since the allocator is chosen at build time based 
> > on
> > the arch capabilities, there is no way to select a specific memory 
> > allocator.
> > I'd be happy to use an alternative approach that allows direct writing into
> > the ring buffer.
> 
> You do not _need_ direct write from bpf prog.
> dtrace language doesn't mandate direct write.
> 'direct write into ring buffer form bpf prog' is an interesting idea and
> may be nice performance optimization, but in no way it's a blocker for dtrace 
> scripts.
> Also it's far from clear that it actually brings performance benefits.
> Letting bpf progs write directly into ring buffer comes with
> a lot of corner cases. It's something to carefully analyze.

I agree that doing direct writes is something that can be deferred right now,
especially because there are more fundamental things to focus on.  Thank you
for your acknowledgement of the idea, and I certainly look forward to exploring
this further at a later time,

> I suggest to proceed with user space dtrace conversion to bpf
> without introducing kernel changes.

Re: [PATCH v2 bpf-next 0/4] cgroup bpf auto-detachment

[Yonghong Song]

On 5/22/19 4:20 PM, Roman Gushchin wrote:
> This patchset implements a cgroup bpf auto-detachment functionality:
> bpf programs are attached as soon as possible after removal of the
typo here "attached" => "detached"?

> cgroup, without waiting for the release of all associated resources.
> 
> Patches 2 and 3 are required to implement a corresponding kselftest
> in patch 4.
> 
> v2:
>1) removed a bogus check in patch 4
>2) moved buf[len] = 0 in patch 2
> 
> 
> Roman Gushchin (4):
>bpf: decouple the lifetime of cgroup_bpf from cgroup itself
>selftests/bpf: convert test_cgrp2_attach2 example into kselftest
>selftests/bpf: enable all available cgroup v2 controllers
>selftests/bpf: add auto-detach test
> 
>   include/linux/bpf-cgroup.h|   8 +-
>   include/linux/cgroup.h|  18 +++
>   kernel/bpf/cgroup.c   |  25 ++-
>   kernel/cgroup/cgroup.c|  11 +-
>   samples/bpf/Makefile  |   2 -
>   tools/testing/selftests/bpf/Makefile  |   4 +-
>   tools/testing/selftests/bpf/cgroup_helpers.c  |  57 +++
>   .../selftests/bpf/test_cgroup_attach.c| 145 --
>   8 files changed, 243 insertions(+), 27 deletions(-)
>   rename samples/bpf/test_cgrp2_attach2.c => 
> tools/testing/selftests/bpf/test_cgroup_attach.c (79%)
> 

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

[Kris Van Hees]

On Wed, May 22, 2019 at 01:16:25PM -0700, Alexei Starovoitov wrote:
> On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote:
> > 
> > Could you elaborate on why you believe my patches are not adding generic
> > features?  I can certainly agree that the DTrace-specific portions are less
> > generic (although they are certainly available for anyone to use), but I
> > don't quite understand why the new features are deemed non-generic and why
> > you believe no one else can use this?
> 
> And once again your statement above contradicts your own patches.
> The patch 2 adds new prog type BPF_PROG_TYPE_DTRACE and the rest of the 
> patches
> are tying everything to it.
> This approach contradicts bpf philosophy of being generic execution engine
> and not favoriting one program type vs another.

I am not sure I understand where you see a contradiction.  What I posted is
a generic feature, and sample code that demonstrates how it can be used based
on the use-case that I am currently working on.  So yes, the sample code is
very specific but it does not restrict the use of the cross-prog-type tail-call
feature.  That feature is designed to be generic.

Probes come in different types (kprobe, tracepoint, perf event, ...) and they
each have their own very specific data associated with them.  I agree 100%
with you on that.  And sometimes tracing makes use of those specifics.  But
even from looking at the implementation of the various probe related prog
types (and e.g. the list of helpers they each support) it shows that there is
a lot of commonality as well.  That common functionality is common to all the
probe program types, and that is where I suggest introducing a program type
that captures the common concept of a probe, so perhaps a better name would
be BPF_PROG_TYPE_PROBE.

The principle remains the same though...  I am proposing adding support for
program types that provide common functionality so that programs for various
program types can make use of the more generic programs stored in prog arrays.

> I have nothing against dtrace language and dtrace scripts.
> Go ahead and compile them into bpf.
> All patches to improve bpf infrastructure are very welcomed.
> 
> In particular you brought up a good point that there is a use case
> for sharing a piece of bpf program between kprobe and tracepoint events.
> The better way to do that is via bpf2bpf call.
> Example:
> void bpf_subprog(arbitrary args)
> {
> }
> 
> SEC("kprobe/__set_task_comm")
> int bpf_prog_kprobe(struct pt_regs *ctx)
> {
>   bpf_subprog(...);
> }
> 
> SEC("tracepoint/sched/sched_switch")
> int bpf_prog_tracepoint(struct sched_switch_args *ctx)
> {
>   bpf_subprog(...);
> }
> 
> Such configuration is not supported by the verifier yet.
> We've been discussing it for some time, but no work has started,
> since there was no concrete use case.
> If you can work on adding support for it everyone will benefit.
> 
> Could you please consider doing that as a step forward?

This definitely looks to be an interesting addition and I am happy to look into
that further.  I have a few questions that I hope you can shed light on...

1. What context would bpf_subprog execute with?  If it can be called from
   multiple different prog types, would it see whichever context the caller
   is executing with?  Or would you envision bpf_subprog to not be allowed to
   access the execution context because it cannot know which one is in use?

2. Given that BPF programs are loaded with a specification of the prog type, 
   how would one load a code construct as the one you outline above?  How can
   you load a BPF function and have it be used as subprog from programs that
   are loaded separately?  I.e. in the sample above, if bpf_subprog is loaded
   as part of loading bpf_prog_kprobe (prog type KPROBE), how can it be
   referenced from bpf_prog_tracepoint (prog type TRACEPOINT) which would be
   loaded separately?

Cheers,
Kris

Re: [PATCH 11/12] powerpc/pseries/svm: Force SWIOTLB for secure guests

[Thiago Jung Bauermann]

Hello Christoph,

Thanks for reviewing the patch!

Christoph Hellwig  writes:

>> diff --git a/arch/powerpc/include/asm/mem_encrypt.h 
>> b/arch/powerpc/include/asm/mem_encrypt.h
>> new file mode 100644
>> index ..45d5e4d0e6e0
>> --- /dev/null
>> +++ b/arch/powerpc/include/asm/mem_encrypt.h
>> @@ -0,0 +1,19 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * SVM helper functions
>> + *
>> + * Copyright 2019 IBM Corporation
>> + */
>> +
>> +#ifndef _ASM_POWERPC_MEM_ENCRYPT_H
>> +#define _ASM_POWERPC_MEM_ENCRYPT_H
>> +
>> +#define sme_me_mask 0ULL
>> +
>> +static inline bool sme_active(void) { return false; }
>> +static inline bool sev_active(void) { return false; }
>> +
>> +int set_memory_encrypted(unsigned long addr, int numpages);
>> +int set_memory_decrypted(unsigned long addr, int numpages);
>> +
>> +#endif /* _ASM_POWERPC_MEM_ENCRYPT_H */
>
> S/390 seems to be adding a stub header just like this.  Can you please
> clean up the Kconfig and generic headers bits for memory encryption so
> that we don't need all this boilerplate code?

Yes, that's a good idea. Will do.

>>  config PPC_SVM
>>  bool "Secure virtual machine (SVM) support for POWER"
>>  depends on PPC_PSERIES
>> +select SWIOTLB
>> +select ARCH_HAS_MEM_ENCRYPT
>>  default n
>
> n is the default default, no need to explictly specify it.

Indeed. Changed for the next version.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [PATCH 2/2] Input: synaptics - remove X240 from the topbuttonpad list

[Aaron Ma]

On 5/21/19 2:49 PM, Benjamin Tissoires wrote:
> A quick google image search showed that the X240 had 2 versions: one
> with the top software buttons, one without.
> 
> And this definitively rings a bell. I am sure we asked Lenovo and
> Synaptics to change the PnPID when they would do such a change, but
> they "forgot" during the *40 series refresh.
> We have code in place to fix the reported ranges of the coordinates,
> and we had to check against the board id (see min_max_pnpid_table[] in
> synaptics.c).
> Unfortunately, X240 (LEN0035) is not part of this table, so I don't
> know which refresh of the board ID has implemented the non top
> software buttons.

After double confirm from Lenovo, looks like they mixed up with
touchpads on X240/X240s.

For now only one user reported this LEN0035 doesn't work on SMBus mode.
module parameter can be a workaround.
Maybe some touchpads with software top buttons are working well on
SMBus. Let's keep eyes on this issue for now.

Regards,
Aaron

> 
> Cheers,
> Benjamin

Re: Linux Testing Microconference at LPC

[Knut Omang]

On Wed, 2019-05-22 at 14:02 -0700, Brendan Higgins wrote:
> On Wed, May 15, 2019 at 08:36:49PM -0400, Sasha Levin wrote:
> > On Wed, May 15, 2019 at 04:44:19PM -0600, shuah wrote:
> > > Hi Sasha and Dhaval,
> > > 
> > > On 4/11/19 11:37 AM, Dhaval Giani wrote:
> > > > Hi Folks,
> > > > 
> > > > This is a call for participation for the Linux Testing microconference
> > > > at LPC this year.
> > > > 
> > > > For those who were at LPC last year, as the closing panel mentioned,
> > > > testing is probably the next big push needed to improve quality. From
> > > > getting more selftests in, to regression testing to ensure we don't
> > > > break realtime as more of PREEMPT_RT comes in, to more stable distros,
> > > > we need more testing around the kernel.
> > > > 
> > > > We have talked about different efforts around testing, such as fuzzing
> > > > (using syzkaller and trinity), automating fuzzing with syzbot, 0day
> > > > testing, test frameworks such as ktests, smatch to find bugs in the
> > > > past. We want to push this discussion further this year and are
> > > > interested in hearing from you what you want to talk about, and where
> > > > kernel testing needs to go next.
> > > > 
> > > > Please let us know what topics you believe should be a part of the
> > > > micro conference this year.
> > > > 
> > > > Thanks!
> > > > Sasha and Dhaval
> > > > 
> > > 
> > > A talk on KUnit from Brendan Higgins will be good addition to this
> > > Micro-conference. I am cc'ing Brendan on this thread.
> > > 
> > > Please consider adding it.
> > 
> > FWIW, the topic of unit tests is already on the schedule. There seems to
> > be two different sub-topics here (kunit vs KTF) so there's a good
> > discussion to be had here on many levels.
> 
> Cool, so do we just want to go with that? Have a single slot for KUnit
> and KTF combined?
> 
> We can each present our work up to this point; maybe offer some
> background and rationale on why we made the decision we have and then we
> can have some moderated discussion on, pros, cons, next steps, etc?

I definitely had KTF and KUnit in mind when proposing this topic.
If you recall from the last time we discussed unit testing, each slot is 
fairly limited in time. My plan for the intro for discussion is to 
itemize some of the distinct goals we try to achieve with our frameworks and 
have a
discussion based on that. In light of the discussion around your patch sets,
one topic is also the question of whether a common API would be useful/desired, 
and whether we can "capture" a short namespace for that.

Thanks,
Knut

> Cheers

[PATCH V6 1/2] soc: imx: Add SCU SoC info driver support

[Anson Huang]

Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
driver dependency into Kconfig as CONFIG_IMX_SCU must be
selected to support i.MX SCU SoC driver, also need to use
platform driver model to make sure IMX_SCU driver is probed
before i.MX SCU SoC driver.

With this patch, SoC info can be read from sysfs:

i.mx8qxp-mek# cat /sys/devices/soc0/family
Freescale i.MX

i.mx8qxp-mek# cat /sys/devices/soc0/soc_id
0x2

i.mx8qxp-mek# cat /sys/devices/soc0/machine
Freescale i.MX8QXP MEK

i.mx8qxp-mek# cat /sys/devices/soc0/revision
1.1

Signed-off-by: Anson Huang 
Reviewed-by: Abel Vesa 
Reviewed-by: Dong Aisheng 
---
Changes since V5:
- remove unnecessary comment;
- improve the IPC message structure definition;
- improve the error check and return value in imx_scu_soc_init() to 
save some code.
---
 drivers/soc/imx/Kconfig   |   9 +++
 drivers/soc/imx/Makefile  |   1 +
 drivers/soc/imx/soc-imx-scu.c | 147 ++
 3 files changed, 157 insertions(+)
 create mode 100644 drivers/soc/imx/soc-imx-scu.c

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index ade1b46..8aaebf1 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -8,4 +8,13 @@ config IMX_GPCV2_PM_DOMAINS
select PM_GENERIC_DOMAINS
default y if SOC_IMX7D
 
+config IMX_SCU_SOC
+   bool "i.MX System Controller Unit SoC info support"
+   depends on IMX_SCU
+   select SOC_BUS
+   help
+ If you say yes here you get support for the NXP i.MX System
+ Controller Unit SoC info module, it will provide the SoC info
+ like SoC family, ID and revision etc.
+
 endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index caa8653..cf9ca42 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -2,3 +2,4 @@
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
 obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
+obj-$(CONFIG_IMX_SCU_SOC) += soc-imx-scu.o
diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
new file mode 100644
index 000..258c987
--- /dev/null
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX_SCU_SOC_DRIVER_NAME"imx-scu-soc"
+
+static struct imx_sc_ipc *soc_ipc_handle;
+
+struct imx_sc_msg_misc_get_soc_id {
+   struct imx_sc_rpc_msg hdr;
+   union {
+   struct {
+   u32 control;
+   u16 resource;
+   } __packed req;
+   struct {
+   u32 id;
+   } __packed resp;
+   } data;
+} __packed;
+
+static u32 imx_scu_soc_id(void)
+{
+   struct imx_sc_msg_misc_get_soc_id msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_MISC;
+   hdr->func = IMX_SC_MISC_FUNC_GET_CONTROL;
+   hdr->size = 3;
+
+   msg.data.req.control = IMX_SC_C_ID;
+   msg.data.req.resource = IMX_SC_R_SYSTEM;
+
+   ret = imx_scu_call_rpc(soc_ipc_handle, , true);
+   if (ret) {
+   pr_err("%s: get soc info failed, ret %d\n", __func__, ret);
+   /* return 0 means getting revision failed */
+   return 0;
+   }
+
+   return msg.data.resp.id;
+}
+
+static int imx_scu_soc_probe(struct platform_device *pdev)
+{
+   struct soc_device_attribute *soc_dev_attr;
+   struct soc_device *soc_dev;
+   u32 id, val;
+   int ret;
+
+   ret = imx_scu_get_handle(_ipc_handle);
+   if (ret)
+   return ret;
+
+   soc_dev_attr = devm_kzalloc(>dev, sizeof(*soc_dev_attr),
+   GFP_KERNEL);
+   if (!soc_dev_attr)
+   return -ENOMEM;
+
+   soc_dev_attr->family = "Freescale i.MX";
+
+   ret = of_property_read_string(of_root,
+ "model",
+ _dev_attr->machine);
+   if (ret)
+   return ret;
+
+   id = imx_scu_soc_id();
+
+   /* format soc_id value passed from SCU firmware */
+   val = id & 0x1f;
+   soc_dev_attr->soc_id = val ? kasprintf(GFP_KERNEL, "0x%x", val)
+  : "unknown";
+   if (!soc_dev_attr->soc_id)
+   return -ENOMEM;
+
+   /* format revision value passed from SCU firmware */
+   val = (id >> 5) & 0xf;
+   val = (((val >> 2) + 1) << 4) | (val & 0x3);
+   soc_dev_attr->revision = val ? kasprintf(GFP_KERNEL,
+"%d.%d",
+(val >> 4) & 0xf,
+val & 0xf) : "unknown";
+   if (!soc_dev_attr->revision) {
+   ret = -ENOMEM;
+   goto 

[PATCH V6 2/2] arm64: defconfig: Add i.MX SCU SoC info driver

[Anson Huang]

This patch selects CONFIG_IMX_SCU_SOC by default to support
i.MX system controller unit SoC info driver.

Signed-off-by: Anson Huang 
Reviewed-by: Abel Vesa 
Reviewed-by: Dong Aisheng 
---
No changes.
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c91642d..aaca4a0 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -694,6 +694,7 @@ CONFIG_RPMSG_QCOM_GLINK_RPM=y
 CONFIG_RPMSG_QCOM_GLINK_SMEM=m
 CONFIG_RPMSG_QCOM_SMD=y
 CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IMX_SCU_SOC=y
 CONFIG_QCOM_COMMAND_DB=y
 CONFIG_QCOM_GENI_SE=y
 CONFIG_QCOM_GLINK_SSR=m
-- 
2.7.4

Re: [PATCH] PCI / PM: Don't runtime suspend when device only supports wakeup from D0

[Kai-Heng Feng]

at 04:52, Bjorn Helgaas  wrote:


On Wed, May 22, 2019 at 02:39:56PM -0400, Alan Stern wrote:

On Wed, 22 May 2019, Bjorn Helgaas wrote:

On Wed, May 22, 2019 at 11:46:25PM +0800, Kai Heng Feng wrote:

On May 22, 2019, at 9:48 PM, Bjorn Helgaas  wrote:
On Wed, May 22, 2019 at 11:42:14AM +0800, Kai Heng Feng wrote:

at 6:23 AM, Bjorn Helgaas  wrote:

On Wed, May 22, 2019 at 12:31:04AM +0800, Kai-Heng Feng wrote:
There's an xHC device that doesn't wake when a USB device gets  
plugged
to its USB port. The driver's own runtime suspend callback was  
called,

PME signaling was enabled, but it stays at PCI D0.



...
And I guess this patch basically means we wouldn't call the driver's
suspend callback if we're merely going to stay at D0, so the driver
would have no idea anything happened.  That might match
Documentation/power/pci.txt better, because it suggests that the
suspend callback is related to putting a device in a low-power state,
and D0 is not a low-power state.


Yes, the patch is to let the device stay at D0 and don’t run driver’s  
own

runtime suspend routine.

I guess I’ll just proceed to send a V2 with updated commit message?


Now that I understand what "runtime suspended to D0" means, help me
understand what's actually wrong.


Kai's point is that the xhci-hcd driver thinks the device is now in
runtime suspend, because the runtime_suspend method has been executed.
But in fact the device is still in D0, and as a result, PME signalling
may not work correctly.


The device claims to be able to signal PME from D0 (this is from the lspci
in https://bugzilla.kernel.org/show_bug.cgi?id=203673):

  00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller (rev 20) (prog-if 30 [XHCI])
Capabilities: [50] Power Management version 3
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

From the xHCI spec r1.0, sec 4.15.2.3, it looks like a connect
detected while in D0 should assert PME# if enabled (and WCE is set).


I think section 4.15.2.3 is about S3 wake up, no S0 we are discussing here.




On the other hand, it wasn't clear from the patch description whether
this actually causes a problem on real systems.  The description only
said that the problem was theoretical.


Kai did say nothing happens when hot-adding a USB device, so I think
there really is a problem.  This should be an obvious problem that
lots of people would trip over, so I expect there should be reports in
launchpad, etc.  I'd really like to have those bread crumbs.  Kai, can
you add a complete dmesg log to the bugzilla?  Hints from the log,
like the platform name, can help find related reports.


It’s a platform in development so the name can’t be disclosed.




The PCI core apparently *does* enable PME when we "suspend to D0".
But somehow calling the xHCI runtime suspend callback makes the
driver unable to notice when the PME is signaled?


According to Kai, PME signalling doesn't work in D0 -- or at least,
it is _documented_ not to work in D0 -- even though it is enabled
and the device claims to support it.


I didn't understand this part.  From a PCI perspective, PME signaling
while in D0 is an optional feature and should work if the device
advertises support for it.  If it doesn't work on this device, we
should have a quirk to indicate that.


The only document I can find is the "Device Working State D0” from Microsoft.
It says:
"As a best practice, the driver should configure the device to generate  
interrupts only when the device is in D0, and to generate wake signals only  
when the device is in a low-power Dx state.”


Wake-up capability
Not applicable.

Unfortunately PCI spec isn’t publicly available so I can only refer to  
Microsoft document.




But I thought Kai said the device *can* signal PME from D0, but for
some reason we don't handle it correctly if we have called the xHCI
suspend callback.


Sorry, what I meant is PME signaling is enabled, i.e.
"Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-“

But no signal was actually regenerated when USB device gets plugged to the  
port.
So there’s no wake up event to let PCI know it should runtime resume the  
device.




That's the part I don't understand.  Is this an xHCI driver issue?
Should the suspend callback do something different if we're staying in
D0?  I'm not sure the callback even knows what Dx state we're going
to.


As there’s no PME signal to wakeup event to signal PCI to runtime resume, I  
don’t think it’s an xHCI bug.


Kai-Heng

[PATCH 2/2] KVM: LAPIC: remove the trailing newline used in the fmt parameter of TP_printk

[Wanpeng Li]

From: Wanpeng Li 

The trailing newlines will lead to extra newlines in the trace file 
which looks like the following output, so remove it.

qemu-system-x86-15695 [002] ...1 15774.839240: kvm_hv_timer_state: vcpu_id 0 
hv_timer 1

qemu-system-x86-15695 [002] ...1 15774.839309: kvm_hv_timer_state: vcpu_id 0 
hv_timer 1

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 4d47a26..b5c831e 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -1365,7 +1365,7 @@ TRACE_EVENT(kvm_hv_timer_state,
__entry->vcpu_id = vcpu_id;
__entry->hv_timer_in_use = hv_timer_in_use;
),
-   TP_printk("vcpu_id %x hv_timer %x\n",
+   TP_printk("vcpu_id %x hv_timer %x",
__entry->vcpu_id,
__entry->hv_timer_in_use)
 );
-- 
2.7.4

[PATCH 1/2] KVM: LAPIC: Optimize timer latency consider world switch time

[Wanpeng Li]

From: Wanpeng Li 

Advance lapic timer tries to hidden the hypervisor overhead between the
host emulated timer fires and the guest awares the timer is fired. However,
even though after more sustaining optimizations, 
kvm-unit-tests/tscdeadline_latency 
still awares ~1000 cycles latency since we lost the time between the end of 
wait_lapic_expire and the guest awares the timer is fired. There are 
codes between the end of wait_lapic_expire and the world switch, futhermore, 
the world switch itself also has overhead. Actually the guest_tsc is equal 
to the target deadline time in wait_lapic_expire is too late, guest will
aware the latency between the end of wait_lapic_expire() and after vmentry 
to the guest. This patch takes this time into consideration. 

The vmentry_lapic_timer_advance_ns module parameter should be well tuned by 
host admin, it can reduce average cyclictest latency from 3us to 2us on 
Skylake server. (guest w/ nohz=off, idle=poll, host w/ preemption_timer=N, 
the cyclictest latency is not too sensitive when preemption_timer=Y for this 
optimization in my testing), kvm-unit-tests/tscdeadline_latency can reach 0.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Sean Christopherson 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c   | 17 +++--
 arch/x86/kvm/lapic.h   |  1 +
 arch/x86/kvm/vmx/vmx.c |  2 +-
 arch/x86/kvm/x86.c |  3 +++
 arch/x86/kvm/x86.h |  2 ++
 5 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index fcf42a3..6f85221 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1531,6 +1531,19 @@ static inline void adjust_lapic_timer_advance(struct 
kvm_vcpu *vcpu,
apic->lapic_timer.timer_advance_ns = timer_advance_ns;
 }
 
+u64 get_vmentry_advance_delta(struct kvm_vcpu *vcpu)
+{
+   u64 vmentry_lapic_timer_advance_cycles = 0;
+
+   if (vmentry_lapic_timer_advance_ns) {
+   vmentry_lapic_timer_advance_cycles = 
vmentry_lapic_timer_advance_ns *
+   vcpu->arch.virtual_tsc_khz;
+   do_div(vmentry_lapic_timer_advance_cycles, 100);
+   }
+   return vmentry_lapic_timer_advance_cycles;
+}
+EXPORT_SYMBOL_GPL(get_vmentry_advance_delta);
+
 void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu)
 {
struct kvm_lapic *apic = vcpu->arch.apic;
@@ -1544,7 +1557,7 @@ void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu)
 
tsc_deadline = apic->lapic_timer.expired_tscdeadline;
apic->lapic_timer.expired_tscdeadline = 0;
-   guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc());
+   guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()) + 
get_vmentry_advance_delta(vcpu);
apic->lapic_timer.advance_expire_delta = guest_tsc - tsc_deadline;
 
if (guest_tsc < tsc_deadline)
@@ -1572,7 +1585,7 @@ static void start_sw_tscdeadline(struct kvm_lapic *apic)
local_irq_save(flags);
 
now = ktime_get();
-   guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc());
+   guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()) + 
get_vmentry_advance_delta(vcpu);
 
ns = (tscdeadline - guest_tsc) * 100ULL;
do_div(ns, this_tsc_khz);
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index f974a3d..df2fe17 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -221,6 +221,7 @@ static inline int kvm_lapic_latched_init(struct kvm_vcpu 
*vcpu)
 bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector);
 
 void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu);
+u64 get_vmentry_advance_delta(struct kvm_vcpu *vcpu);
 
 bool kvm_intr_is_single_vcpu_fast(struct kvm *kvm, struct kvm_lapic_irq *irq,
struct kvm_vcpu **dest_vcpu);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index da24f18..0199ac3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7047,7 +7047,7 @@ static int vmx_set_hv_timer(struct kvm_vcpu *vcpu, u64 
guest_deadline_tsc,
 
vmx = to_vmx(vcpu);
tscl = rdtsc();
-   guest_tscl = kvm_read_l1_tsc(vcpu, tscl);
+   guest_tscl = kvm_read_l1_tsc(vcpu, tscl) + 
get_vmentry_advance_delta(vcpu);
delta_tsc = max(guest_deadline_tsc, guest_tscl) - guest_tscl;
lapic_timer_advance_cycles = nsec_to_cycles(vcpu,
ktimer->timer_advance_ns);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a4eb711..a02e2c3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -145,6 +145,9 @@ module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR);
 static int __read_mostly lapic_timer_advance_ns = -1;
 module_param(lapic_timer_advance_ns, int, S_IRUGO | S_IWUSR);
 
+u32 __read_mostly vmentry_lapic_timer_advance_ns = 0;
+module_param(vmentry_lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR);
+
 static bool __read_mostly vector_hashing = true;
 module_param(vector_hashing, bool, S_IRUGO);
 
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 275b3b6..b0a3b84 100644
--- 

Re: [PATCH -next v2] mm/hotplug: fix a null-ptr-deref during NUMA boot

[Pingfan Liu]

On Thu, May 23, 2019 at 11:58 AM Pingfan Liu  wrote:
>
> On Wed, May 22, 2019 at 7:16 PM Michal Hocko  wrote:
> >
> > On Wed 22-05-19 15:12:16, Pingfan Liu wrote:
> > > On Mon, May 13, 2019 at 11:31 PM Michal Hocko  wrote:
> > > >
> > > > On Mon 13-05-19 11:20:46, Qian Cai wrote:
> > > > > On Mon, 2019-05-13 at 16:04 +0200, Michal Hocko wrote:
> > > > > > On Mon 13-05-19 09:43:59, Qian Cai wrote:
> > > > > > > On Mon, 2019-05-13 at 14:41 +0200, Michal Hocko wrote:
> > > > > > > > On Sun 12-05-19 01:48:29, Qian Cai wrote:
> > > > > > > > > The linux-next commit ("x86, numa: always initialize all 
> > > > > > > > > possible
> > > > > > > > > nodes") introduced a crash below during boot for systems with 
> > > > > > > > > a
> > > > > > > > > memory-less node. This is due to CPUs that get onlined during 
> > > > > > > > > SMP boot,
> > > > > > > > > but that onlining triggers a page fault in bus_add_device() 
> > > > > > > > > during
> > > > > > > > > device registration:
> > > > > > > > >
> > > > > > > > >   error = sysfs_create_link(>p->devices_kset->kobj,
> > > > > > > > >
> > > > > > > > > bus->p is NULL. That "p" is the subsys_private struct, and it 
> > > > > > > > > should
> > > > > > > > > have been set in,
> > > > > > > > >
> > > > > > > > >   postcore_initcall(register_node_type);
> > > > > > > > >
> > > > > > > > > but that happens in do_basic_setup() after smp_init().
> > > > > > > > >
> > > > > > > > > The old code had set this node online via alloc_node_data(), 
> > > > > > > > > so when it
> > > > > > > > > came time to do_cpu_up() -> try_online_node(), the node was 
> > > > > > > > > already up
> > > > > > > > > and nothing happened.
> > > > > > > > >
> > > > > > > > > Now, it attempts to online the node, which registers the node 
> > > > > > > > > with
> > > > > > > > > sysfs, but that can't happen before the 'node' subsystem is 
> > > > > > > > > registered.
> > > > > > > > >
> > > > > > > > > Since kernel_init() is running by a kernel thread that is in
> > > > > > > > > SYSTEM_SCHEDULING state, fixed this by skipping registering 
> > > > > > > > > with sysfs
> > > > > > > > > during the early boot in __try_online_node().
> > > > > > > >
> > > > > > > > Relying on SYSTEM_SCHEDULING looks really hackish. Why cannot 
> > > > > > > > we simply
> > > > > > > > drop try_online_node from do_cpu_up? Your v2 remark below 
> > > > > > > > suggests that
> > > > > > > > we need to call node_set_online because something later on 
> > > > > > > > depends on
> > > > > > > > that. Btw. why do we even allocate a pgdat from this path? This 
> > > > > > > > looks
> > > > > > > > really messy.
> > > > > > >
> > > > > > > See the commit cf23422b9d76 ("cpu/mem hotplug: enable CPUs online 
> > > > > > > before
> > > > > > > local
> > > > > > > memory online")
> > > > > > >
> > > > > > > It looks like try_online_node() in do_cpu_up() is needed for 
> > > > > > > memory hotplug
> > > > > > > which is to put its node online if offlined and then 
> > > > > > > hotadd_new_pgdat()
> > > > > > > calls
> > > > > > > build_all_zonelists() to initialize the zone list.
> > > > > >
> > > > > > Well, do we still have to followthe logic that the above 
> > > > > > (unreviewed)
> > > > > > commit has established? The hotplug code in general made a lot of 
> > > > > > ad-hoc
> > > > > > design decisions which had to be revisited over time. If we are not
> > > > > > allocating pgdats for newly added memory then we should really make 
> > > > > > sure
> > > > > > to do so at a proper time and hook. I am not sure about CPU vs. 
> > > > > > memory
> > > > > > init ordering but even then I would really prefer if we could make 
> > > > > > the
> > > > > > init less obscure and _documented_.
> > > > >
> > > > > I don't know, but I think it is a good idea to keep the existing 
> > > > > logic rather
> > > > > than do a big surgery
> > > >
> > > > Adding more hacks just doesn't make the situation any better.
> > > >
> > > > > unless someone is able to confirm it is not breaking NUMA
> > > > > node physical hotplug.
> > > >
> > > > I have a machine to test whole node offline. I am just busy to prepare a
> > > > patch myself. I can have it tested though.
> > > >
> > > I think the definition of "node online" is worth of rethinking. Before
> > > patch "x86, numa: always initialize all possible nodes", online means
> > > either cpu or memory present. After this patch, only node owing memory
> > > as present.
> > >
> > > In the commit log, I think the change's motivation should be "Not to
> > > mention that it doesn't really make much sense to consider an empty
> > > node as online because we just consider this node whenever we want to
> > > iterate nodes to use and empty node is obviously not the best
> > > candidate."
> > >
> > > But in fact, we already have for_each_node_state(nid, N_MEMORY) to
> > > cover this purpose.
> >
> > I do not really think we want to spread N_MEMORY outside of the core MM.
> > It is quite confusing IMHO.
> 

Re: [PATCH -next v2] mm/hotplug: fix a null-ptr-deref during NUMA boot

[Pingfan Liu]

On Wed, May 22, 2019 at 7:16 PM Michal Hocko  wrote:
>
> On Wed 22-05-19 15:12:16, Pingfan Liu wrote:
> > On Mon, May 13, 2019 at 11:31 PM Michal Hocko  wrote:
> > >
> > > On Mon 13-05-19 11:20:46, Qian Cai wrote:
> > > > On Mon, 2019-05-13 at 16:04 +0200, Michal Hocko wrote:
> > > > > On Mon 13-05-19 09:43:59, Qian Cai wrote:
> > > > > > On Mon, 2019-05-13 at 14:41 +0200, Michal Hocko wrote:
> > > > > > > On Sun 12-05-19 01:48:29, Qian Cai wrote:
> > > > > > > > The linux-next commit ("x86, numa: always initialize all 
> > > > > > > > possible
> > > > > > > > nodes") introduced a crash below during boot for systems with a
> > > > > > > > memory-less node. This is due to CPUs that get onlined during 
> > > > > > > > SMP boot,
> > > > > > > > but that onlining triggers a page fault in bus_add_device() 
> > > > > > > > during
> > > > > > > > device registration:
> > > > > > > >
> > > > > > > >   error = sysfs_create_link(>p->devices_kset->kobj,
> > > > > > > >
> > > > > > > > bus->p is NULL. That "p" is the subsys_private struct, and it 
> > > > > > > > should
> > > > > > > > have been set in,
> > > > > > > >
> > > > > > > >   postcore_initcall(register_node_type);
> > > > > > > >
> > > > > > > > but that happens in do_basic_setup() after smp_init().
> > > > > > > >
> > > > > > > > The old code had set this node online via alloc_node_data(), so 
> > > > > > > > when it
> > > > > > > > came time to do_cpu_up() -> try_online_node(), the node was 
> > > > > > > > already up
> > > > > > > > and nothing happened.
> > > > > > > >
> > > > > > > > Now, it attempts to online the node, which registers the node 
> > > > > > > > with
> > > > > > > > sysfs, but that can't happen before the 'node' subsystem is 
> > > > > > > > registered.
> > > > > > > >
> > > > > > > > Since kernel_init() is running by a kernel thread that is in
> > > > > > > > SYSTEM_SCHEDULING state, fixed this by skipping registering 
> > > > > > > > with sysfs
> > > > > > > > during the early boot in __try_online_node().
> > > > > > >
> > > > > > > Relying on SYSTEM_SCHEDULING looks really hackish. Why cannot we 
> > > > > > > simply
> > > > > > > drop try_online_node from do_cpu_up? Your v2 remark below 
> > > > > > > suggests that
> > > > > > > we need to call node_set_online because something later on 
> > > > > > > depends on
> > > > > > > that. Btw. why do we even allocate a pgdat from this path? This 
> > > > > > > looks
> > > > > > > really messy.
> > > > > >
> > > > > > See the commit cf23422b9d76 ("cpu/mem hotplug: enable CPUs online 
> > > > > > before
> > > > > > local
> > > > > > memory online")
> > > > > >
> > > > > > It looks like try_online_node() in do_cpu_up() is needed for memory 
> > > > > > hotplug
> > > > > > which is to put its node online if offlined and then 
> > > > > > hotadd_new_pgdat()
> > > > > > calls
> > > > > > build_all_zonelists() to initialize the zone list.
> > > > >
> > > > > Well, do we still have to followthe logic that the above (unreviewed)
> > > > > commit has established? The hotplug code in general made a lot of 
> > > > > ad-hoc
> > > > > design decisions which had to be revisited over time. If we are not
> > > > > allocating pgdats for newly added memory then we should really make 
> > > > > sure
> > > > > to do so at a proper time and hook. I am not sure about CPU vs. memory
> > > > > init ordering but even then I would really prefer if we could make the
> > > > > init less obscure and _documented_.
> > > >
> > > > I don't know, but I think it is a good idea to keep the existing logic 
> > > > rather
> > > > than do a big surgery
> > >
> > > Adding more hacks just doesn't make the situation any better.
> > >
> > > > unless someone is able to confirm it is not breaking NUMA
> > > > node physical hotplug.
> > >
> > > I have a machine to test whole node offline. I am just busy to prepare a
> > > patch myself. I can have it tested though.
> > >
> > I think the definition of "node online" is worth of rethinking. Before
> > patch "x86, numa: always initialize all possible nodes", online means
> > either cpu or memory present. After this patch, only node owing memory
> > as present.
> >
> > In the commit log, I think the change's motivation should be "Not to
> > mention that it doesn't really make much sense to consider an empty
> > node as online because we just consider this node whenever we want to
> > iterate nodes to use and empty node is obviously not the best
> > candidate."
> >
> > But in fact, we already have for_each_node_state(nid, N_MEMORY) to
> > cover this purpose.
>
> I do not really think we want to spread N_MEMORY outside of the core MM.
> It is quite confusing IMHO.
> .
But it has already like this. Just git grep N_MEMORY.

> > Furthermore, changing the definition of online may
> > break something in the scheduler, e.g. in task_numa_migrate(), where
> > it calls for_each_online_node.
>
> Could you be more specific please? Why should numa balancing consider
> nodes without any memory?

[PATCH] ASoc: fix sound/soc/intel/skylake/slk-ssp-clk.c build error on IA64

[Randy Dunlap]

From: Randy Dunlap 

skl-ssp-clk.c does not build on IA64 because the driver
uses the common clock interface, so make the driver depend
on COMMON_CLK.

Fixes this build error:
../sound/soc/intel/skylake/skl-ssp-clk.c:26:16: error: field 'hw' has 
incomplete type
  struct clk_hw hw;
^~

Reported-by: kbuild test robot 
Signed-off-by: Randy Dunlap 
Cc: Mark Brown 
Cc: Pierre-Louis Bossart 
Cc: Liam Girdwood 
Cc: Jie Yang 
Cc: alsa-de...@alsa-project.org
---
 sound/soc/intel/Kconfig|3 ++-
 sound/soc/intel/boards/Kconfig |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- lnx-52-rc1.orig/sound/soc/intel/Kconfig
+++ lnx-52-rc1/sound/soc/intel/Kconfig
@@ -104,7 +104,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
 config SND_SOC_INTEL_SKYLAKE
tristate "All Skylake/SST Platforms"
depends on PCI && ACPI
-   select SND_SOC_INTEL_SKL
+   select SND_SOC_INTEL_SKL if COMMON_CLK
select SND_SOC_INTEL_APL
select SND_SOC_INTEL_KBL
select SND_SOC_INTEL_GLK
@@ -120,6 +120,7 @@ config SND_SOC_INTEL_SKYLAKE
 config SND_SOC_INTEL_SKL
tristate "Skylake Platforms"
depends on PCI && ACPI
+   depends on COMMON_CLK
select SND_SOC_INTEL_SKYLAKE_FAMILY
help
  If you have a Intel Skylake platform with the DSP enabled
--- lnx-52-rc1.orig/sound/soc/intel/boards/Kconfig
+++ lnx-52-rc1/sound/soc/intel/boards/Kconfig
@@ -286,7 +286,7 @@ config SND_SOC_INTEL_KBL_RT5663_MAX98927
select SND_SOC_MAX98927
select SND_SOC_DMIC
select SND_SOC_HDAC_HDMI
-   select SND_SOC_INTEL_SKYLAKE_SSP_CLK
+   select SND_SOC_INTEL_SKYLAKE_SSP_CLK if COMMON_CLK
help
  This adds support for ASoC Onboard Codec I2S machine driver. This will
  create an alsa sound card for RT5663 + MAX98927.

[PATCH] ASoC: sound/soc/intel/boards: limit some drivers to X86 since headers are only in arch/x86/

[Randy Dunlap]

From: Randy Dunlap 

Several drivers in sound/soc/intel/boards/ #include header files
that only exist in arch/x86/include/asm.  This causes build errors,
so make these drivers depend on X86.

Fixes these build errors (on ia64):

../sound/soc/intel/boards/bxt_da7219_max98357a.c:19:10: fatal error: 
asm/cpu_device_id.h: No such file or directory
 #include 
../sound/soc/intel/boards/bytcr_rt5640.c:31:10: fatal error: 
asm/cpu_device_id.h: No such file or directory
 #include 
../sound/soc/intel/boards/bytcr_rt5651.c:33:10: fatal error: 
asm/cpu_device_id.h: No such file or directory
 #include 
../sound/soc/intel/boards/cht_bsw_rt5645.c:29:10: fatal error: 
asm/cpu_device_id.h: No such file or directory
 #include 
../sound/soc/intel/boards/bytcht_es8316.c:33:10: fatal error: 
asm/cpu_device_id.h: No such file or directory
 #include 
../sound/soc/intel/boards/bytcht_da7213.c:26:10: fatal error: 
asm/platform_sst_audio.h: No such file or directory
 #include 

And more drivers determined by:
> grep "include.*asm.cpu_device_id.h" *.c
bxt_da7219_max98357a.c:#include 
bytcht_es8316.c:#include 
bytcr_rt5640.c:#include 
bytcr_rt5651.c:#include 
cht_bsw_rt5645.c:#include 
sof_rt5682.c:#include 
  and
> grep "include.*asm.platform_sst_audio.h" *.c
bytcht_da7213.c:#include 
bytcht_es8316.c:#include 

Signed-off-by: Randy Dunlap 
Cc: Mark Brown 
Cc: Pierre-Louis Bossart 
Cc: Liam Girdwood 
Cc: Jie Yang 
Cc: alsa-de...@alsa-project.org
---
 sound/soc/intel/boards/Kconfig |6 ++
 1 file changed, 6 insertions(+)

--- lnx-52-rc1.orig/sound/soc/intel/boards/Kconfig
+++ lnx-52-rc1/sound/soc/intel/boards/Kconfig
@@ -87,6 +87,7 @@ config SND_SOC_INTEL_BYTCR_RT5640_MACH
tristate "Baytrail and Baytrail-CR with RT5640 codec"
depends on I2C && ACPI
depends on X86_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_ACPI
select SND_SOC_RT5640
help
@@ -99,6 +100,7 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH
tristate "Baytrail and Baytrail-CR with RT5651 codec"
depends on I2C && ACPI
depends on X86_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_ACPI
select SND_SOC_RT5651
help
@@ -123,6 +125,7 @@ config SND_SOC_INTEL_CHT_BSW_RT5645_MACH
tristate "Cherrytrail & Braswell with RT5645/5650 codec"
depends on I2C && ACPI
depends on X86_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_ACPI
select SND_SOC_RT5645
help
@@ -159,6 +162,7 @@ config SND_SOC_INTEL_BYT_CHT_DA7213_MACH
tristate "Baytrail & Cherrytrail with DA7212/7213 codec"
depends on I2C && ACPI
depends on X86_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_ACPI
select SND_SOC_DA7213
help
@@ -171,6 +175,7 @@ config SND_SOC_INTEL_BYT_CHT_ES8316_MACH
tristate "Baytrail & Cherrytrail with ES8316 codec"
depends on I2C && ACPI
depends on X86_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_ACPI
select SND_SOC_ES8316
help
@@ -249,6 +254,7 @@ config SND_SOC_INTEL_BXT_DA7219_MAX98357
tristate "Broxton with DA7219 and MAX98357A in I2S Mode"
depends on I2C && ACPI
depends on MFD_INTEL_LPSS || COMPILE_TEST
+   depends on X86
select SND_SOC_DA7219
select SND_SOC_MAX98357A
select SND_SOC_DMIC

Re: [PATCH v2] configfs: Fix use-after-free when accessing sd->s_dentry

[Sahitya Tummala]

On Fri, May 17, 2019 at 10:23:12AM +0200, Christoph Hellwig wrote:
> On Thu, May 16, 2019 at 06:27:53PM +0530, stumm...@codeaurora.org wrote:
> > Hi Christoph, Al,
> >
> > Can you please consider this patch for merging?
> 
> I've been sitting on this for a while, mostly because I can't convince
> myself it is safe.  What protects other threads from using ->s_dentry
> just when we clear it?  Also why would sd->s_dentry == dentry ever be
> false?

Thanks Christoph for getting back on this.
I will try to find answers to your queries and get back on this.

Besides, Al Viro reviewed this patch [1] and commented that fix looks
good. Hence, I was following up to get this merged as I thought it
must be a miss to not pick it up :)

[1] - https://lkml.org/lkml/2019/1/3/47

Thanks,
Sahitya.

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

linux-next: Tree for May 23

[Stephen Rothwell]

Hi all,

Changes since 20190522:

The slave-dma-fixes tree gained a conflict against Linus' tree.

The drm-misc tree gained conflicts against the drm-intel tree.

Non-merge commits (relative to Linus' tree): 1529
 1601 files changed, 50560 insertions(+), 29437 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (54dee406374c Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (2bbacd1a9278 Merge tag 'kconfig-v5.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kspp-gustavo/for-next/kspp (034e673710d3 platform/x86: acer-wmi: Mark 
expected switch fall-throughs)
Merging kbuild-current/fixes (5bdd9ad875b6 Merge tag 'kbuild-fixes-v5.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging arc-current/for-curr (4c70850aeb2e ARC: [plat-hsdk]: Add missing FIFO 
size entry in GMAC node)
Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB 
instructions before cleaning the cache)
Merging arm64-fixes/for-next/fixes (7a0a93c51799 arm64: vdso: Explicitly add 
build-id option)
Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark 
m68k having modern-timekeeping)
Merging powerpc-fixes/fixes (672eaf37db9f powerpc/cacheinfo: Remove double free)
Merging sparc/master (54dee406374c Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (8f073036bf35 Merge branch 
'net-tls-fix-device-surprise-removal-with-offload')
Merging bpf/master (a195cefff49f samples, bpf: suppress compiler warning)
Merging ipsec/master (af8f3fb7fb07 net: stmmac: dma channel control register 
need to be init first)
Merging netfilter/master (2de03b45236f selftests: netfilter: add flowtable test 
script)
Merging ipvs/master (e633508a9528 netfilter: nft_fib: Fix existence check 
support)
Merging wireless-drivers/master (7a0f8ad5ff63 Merge ath-current from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git)
Merging mac80211/master (933b40530b4b mac80211: remove set but not used 
variable 'old')
Merging rdma-fixes/for-rc (a188339ca5a3 Linux 5.2-rc1)
Merging sound-current/for-linus (aeac1a0dadb4 ALSA: hda/realtek - Check headset 
type by unplug and resume)
Merging sound-asoc-fixes/for-linus (12bb37a10514 Merge branch 'asoc-5.2' into 
asoc-linus)
Merging regmap-fixes/for-linus (38ee2a8cc70e Merge branch 'regmap-5.2' into 
regmap-linus)
Merging regulator-fixes/for-linus (41a585c947de Merge branch 'regulator-5.2' 
into regulator-linus)
Merging spi-fixes/for-linus (e99091799f09 Merge branch 'spi-5.2' into spi-linus)
Merging pci-current/for-linus (a188339ca5a3 Linux 5.2-rc1)
Merging driver-core.current/driver-core-linus (a188339ca5a3 Linux 5.2-rc1)
Merging tty.current/tty-linus (5d24f455c182 tty: max310x: Fix external crystal 
register setup)
Merging usb.current/usb-linus (c1a145a3ed9a xhci: Use %zu for printing size_t 
type)
Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock 
in f_hidg_write())
Merging usb-serial-fixes/usb-linus (f3dfd4072c3e USB: seria

RE: [PATCH V5 2/2] arm64: defconfig: Add i.MX SCU SoC info driver

[Aisheng Dong]

> From: Anson Huang
> Sent: Wednesday, May 22, 2019 2:24 PM
> 
> This patch selects CONFIG_IMX_SCU_SOC by default to support i.MX system
> controller unit SoC info driver.
> 
> Signed-off-by: Anson Huang 

Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

Re: [PATCH] powerpc: Fix loading of kernel + initramfs with kexec_file_load()

[Dave Young]

On 05/22/19 at 07:01pm, Thiago Jung Bauermann wrote:
> Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> changed kexec_add_buffer() to skip searching for a memory location if
> kexec_buf.mem is already set, and use the address that is there.
> 
> In powerpc code we reuse a kexec_buf variable for loading both the kernel
> and the initramfs by resetting some of the fields between those uses, but
> not mem. This causes kexec_add_buffer() to try to load the kernel at the
> same address where initramfs will be loaded, which is naturally rejected:
> 
>   # kexec -s -l --initrd initramfs vmlinuz
>   kexec_file_load failed: Invalid argument
> 
> Setting the mem field before every call to kexec_add_buffer() fixes this
> regression.
> 
> Fixes: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  arch/powerpc/kernel/kexec_elf_64.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/kexec_elf_64.c 
> b/arch/powerpc/kernel/kexec_elf_64.c
> index ba4f18a43ee8..52a29fc73730 100644
> --- a/arch/powerpc/kernel/kexec_elf_64.c
> +++ b/arch/powerpc/kernel/kexec_elf_64.c
> @@ -547,6 +547,7 @@ static int elf_exec_load(struct kimage *image, struct 
> elfhdr *ehdr,
>   kbuf.memsz = phdr->p_memsz;
>   kbuf.buf_align = phdr->p_align;
>   kbuf.buf_min = phdr->p_paddr + base;
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>   ret = kexec_add_buffer();
>   if (ret)
>   goto out;
> @@ -581,7 +582,8 @@ static void *elf64_load(struct kimage *image, char 
> *kernel_buf,
>   struct kexec_buf kbuf = { .image = image, .buf_min = 0,
> .buf_max = ppc64_rma_size };
>   struct kexec_buf pbuf = { .image = image, .buf_min = 0,
> -   .buf_max = ppc64_rma_size, .top_down = true };
> +   .buf_max = ppc64_rma_size, .top_down = true,
> +   .mem = KEXEC_BUF_MEM_UNKNOWN };
>  
>   ret = build_elf_exec_info(kernel_buf, kernel_len, , _info);
>   if (ret)
> @@ -606,6 +608,7 @@ static void *elf64_load(struct kimage *image, char 
> *kernel_buf,
>   kbuf.bufsz = kbuf.memsz = initrd_len;
>   kbuf.buf_align = PAGE_SIZE;
>   kbuf.top_down = false;
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>   ret = kexec_add_buffer();
>   if (ret)
>   goto out;
> @@ -638,6 +641,7 @@ static void *elf64_load(struct kimage *image, char 
> *kernel_buf,
>   kbuf.bufsz = kbuf.memsz = fdt_size;
>   kbuf.buf_align = PAGE_SIZE;
>   kbuf.top_down = true;
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>   ret = kexec_add_buffer();
>   if (ret)
>   goto out;
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Reviewed-by: Dave Young 

Thanks
Dave

RE: [PATCH V5 1/2] soc: imx: Add SCU SoC info driver support

[Aisheng Dong]

> From: Anson Huang
> Sent: Wednesday, May 22, 2019 2:24 PM
> 
> Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce driver
> dependency into Kconfig as CONFIG_IMX_SCU must be selected to support
> i.MX SCU SoC driver, also need to use platform driver model to make sure
> IMX_SCU driver is probed before i.MX SCU SoC driver.
> 
> With this patch, SoC info can be read from sysfs:
> 
> i.mx8qxp-mek# cat /sys/devices/soc0/family Freescale i.MX
> 
> i.mx8qxp-mek# cat /sys/devices/soc0/soc_id
> 0x2
> 
> i.mx8qxp-mek# cat /sys/devices/soc0/machine Freescale i.MX8QXP MEK
> 
> i.mx8qxp-mek# cat /sys/devices/soc0/revision
> 1.1
> 
> Signed-off-by: Anson Huang 

A few minor comments below,
Otherwise:
Dong Aisheng 

> ---
> Changes since V4:
>   - using extern struct of_root instead of searching it again from DT;
>   - add of_node_put() after "fsl,imx-scu" is found.
> ---
>  drivers/soc/imx/Kconfig   |   9 +++
>  drivers/soc/imx/Makefile  |   1 +
>  drivers/soc/imx/soc-imx-scu.c | 155
> ++
>  3 files changed, 165 insertions(+)
>  create mode 100644 drivers/soc/imx/soc-imx-scu.c
> 
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig index
> d80f899..cbc1a41 100644
> --- a/drivers/soc/imx/Kconfig
> +++ b/drivers/soc/imx/Kconfig
> @@ -7,4 +7,13 @@ config IMX_GPCV2_PM_DOMAINS
>   select PM_GENERIC_DOMAINS
>   default y if SOC_IMX7D
> 
> +config IMX_SCU_SOC
> + bool "i.MX System Controller Unit SoC info support"
> + depends on IMX_SCU
> + select SOC_BUS
> + help
> +   If you say yes here you get support for the NXP i.MX System
> +   Controller Unit SoC info module, it will provide the SoC info
> +   like SoC family, ID and revision etc.
> +
>  endmenu
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index
> d6b529e0..ddf343d 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
>  obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
>  obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
> +obj-$(CONFIG_IMX_SCU_SOC) += soc-imx-scu.o
> diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c new
> file mode 100644 index 000..17deb4e
> --- /dev/null
> +++ b/drivers/soc/imx/soc-imx-scu.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP.
> + */
> +
> +#include  #include
> + #include  #include
> + #include  #include
> +
> +
> +#define IMX_SCU_SOC_DRIVER_NAME  "imx-scu-soc"
> +
> +static struct imx_sc_ipc *soc_ipc_handle;
> +
> +struct imx_sc_msg_misc_get_soc_id {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct {
> + u32 control;
> + u16 resource;
> + } send;

Please follow the exist naming conversion to avoid a diverge if no specific 
reasons.
s/send/req

BTW, sub structures also needs packed and better add an explicit __packed
As I'm not sure whether GCC will always generate no padding for ARM64 platforms
For above structures.

> + struct {
> + u32 id;
> + u16 reserved;

What's reserved member for?

> + } resp;
> + } data;
> +} __packed;
> +
> +static u32 imx_scu_soc_id(void)
> +{
> + struct imx_sc_msg_misc_get_soc_id msg;
> + struct imx_sc_rpc_msg *hdr = 
> + int ret;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_CONTROL;
> + hdr->size = 3;
> +
> + msg.data.send.control = IMX_SC_C_ID;
> + msg.data.send.resource = IMX_SC_R_SYSTEM;
> +
> + ret = imx_scu_call_rpc(soc_ipc_handle, , true);
> + if (ret) {
> + pr_err("%s: get soc info failed, ret %d\n", __func__, ret);
> + /* return 0 means getting revision failed */
> + return 0;
> + }
> +
> + return msg.data.resp.id;
> +}
> +
> +static int imx_scu_soc_probe(struct platform_device *pdev) {
> + struct soc_device_attribute *soc_dev_attr;
> + struct soc_device *soc_dev;
> + u32 id, val;
> + int ret;
> +
> + /* wait i.MX SCU driver ready */

Nitpick: remove this unnecessary line

> + ret = imx_scu_get_handle(_ipc_handle);
> + if (ret)
> + return ret;
> +
> + soc_dev_attr = devm_kzalloc(>dev, sizeof(*soc_dev_attr),
> + GFP_KERNEL);
> + if (!soc_dev_attr)
> + return -ENOMEM;
> +
> + soc_dev_attr->family = "Freescale i.MX";
> +
> + ret = of_property_read_string(of_root,
> +   "model",
> +   _dev_attr->machine);
> + if (ret)
> + return ret;
> +
> + id = imx_scu_soc_id();
> +
> + /* format soc_id value passed from SCU firmware */
> + val = id & 0x1f;
> + soc_dev_attr->soc_id = val ? kasprintf(GFP_KERNEL, "0x%x", val)
> +  

Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

[Baoquan He]

On 05/22/19 at 11:11am, Dave Young wrote:
> >  /*
> > - * Keep the crash kernel below this limit.  On 32 bits earlier kernels
> > - * would limit the kernel to the low 512 MiB due to mapping restrictions.
> > + * Keep the crash kernel below this limit.
> > + *
> > + * On 32 bits earlier kernels would limit the kernel to the low
> > + * 512 MiB due to mapping restrictions.
> > + *
> > + * On 64bit, old kexec-tools need to be under 896MiB. The later
> > + * supports to put kernel above 4G, up to system RAM top. Here
> 
> Above two lines are not reflected in code because we have removed
> the 896M limitation, it would be better to drop the two lines to
> avoid confusion. 

Missed these comments at bottom of mail.

Yes, will remove these two lines.

> 
> > + * kdump kernel need be restricted to be under 64TB, which is
> > + * the upper limit of system RAM in 4-level paing mode. Since
> > + * the kdump jumping could be from 5-level to 4-level, the jumping
> > + * will fail if kernel is put above 64TB, and there's no way to
> > + * detect the paging mode of the kernel which will be loaded for
> > + * dumping during the 1st kernel bootup.
> >   */
> >  #ifdef CONFIG_X86_32
> >  # define CRASH_ADDR_LOW_MAXSZ_512M
> >  # define CRASH_ADDR_HIGH_MAX   SZ_512M
> >  #else
> >  # define CRASH_ADDR_LOW_MAXSZ_4G
> > -# define CRASH_ADDR_HIGH_MAX   MAXMEM
> > +# define CRASH_ADDR_HIGH_MAX   (64UL << 40)
> 
> Maybe add a new macro in sizes.h like SZ_64T

I am fine, will add and use it here. Thanks.

Re: [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size

[Namhyung Kim]

Hi Jirka,

On Mon, May 13, 2019 at 10:00:15PM +0200, Jiri Olsa wrote:
> On Mon, May 13, 2019 at 04:47:54PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 08, 2019 at 03:19:59PM +0200, Jiri Olsa escreveu:
> > > Moving file specific code in dso__data_file_size function
> > > into separate file_size function. I'll add bpf specific
> > > code in following patches.
> > 
> > I'm applying this patch, as it just moves things around, no logic
> > change, but can you please clarify a question I have after looking at
> > this patch?
> >  
> > > Link: http://lkml.kernel.org/n/tip-rkcsft4a0f8sw33p67llx...@git.kernel.org
> > > Signed-off-by: Jiri Olsa 
> > > ---
> > >  tools/perf/util/dso.c | 19 ---
> > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> > > index e059976d9d93..cb6199c1390a 100644
> > > --- a/tools/perf/util/dso.c
> > > +++ b/tools/perf/util/dso.c
> > > @@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct 
> > > machine *machine,
> > >   return r;
> > >  }
> > >  
> > > -int dso__data_file_size(struct dso *dso, struct machine *machine)
> > > +static int file_size(struct dso *dso, struct machine *machine)
> > >  {
> > >   int ret = 0;
> > >   struct stat st;
> > >   char sbuf[STRERR_BUFSIZE];
> > >  
> > > - if (dso->data.file_size)
> > > - return 0;
> > > -
> > > - if (dso->data.status == DSO_DATA_STATUS_ERROR)
> > > - return -1;
> > > -
> > >   pthread_mutex_lock(__data_open_lock);
> > >  
> > >   /*
> > > @@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct 
> > > machine *machine)
> > >   return ret;
> > >  }
> > >  
> > > +int dso__data_file_size(struct dso *dso, struct machine *machine)
> > > +{
> > > + if (dso->data.file_size)
> > > + return 0;
> > > +
> > > + if (dso->data.status == DSO_DATA_STATUS_ERROR)
> > > + return -1;
> > > +
> > > + return file_size(dso, machine);
> > > +}
> > 
> > 
> > So the name of the function suggests we want to know the
> > "data_file_size" of a dso, then the logic in it returns _zero_ if a
> > member named "dso->data.file_size" is _not_ zero, can you please
> > clarify?
> > 
> > I was expecting something like:
> > 
> > if (dso->data.file_size)
> > return dso->data.file_size;
> > 
> > I.e. if we had already read it, return the cached value, otherwise go
> > and call some other function to get that info somehow.
> 
> we keep the data size in dso->data.file_size,
> the function just updates it
> 
> the return code is the error code.. not sure,
> why its like that, but it is ;-)
> 
> maybe we wanted separate size and error code,
> because the size needs to be u64 and we use
> int everywhere.. less casting

Maybe we can rename it to dso__update_file_size().

Thanks,
Namhyung

Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1

[Joe Perches]

On Thu, 2019-05-23 at 11:49 +0900, Masahiro Yamada wrote:
> On Wed, May 22, 2019 at 3:37 PM Joe Perches  wrote:
[]
> > I could also wire up a patch to checkpatch and docs to
> > remove the /* */ requirement for .h files and prefer
> > the generic // form for both .c and .h files as the
> > current minimum tooling versions now all allow //
> > comments
> > .
> 
> We have control for minimal tool versions for building the kernel,
> so I think // will be OK for in-kernel headers.
> 
> 
> On the other hand, I am not quite sure about UAPI headers.
> We cannot define minimum tool versions
> for building user-space.
> Perhaps, using // in UAPI headers causes a problem
> if an ancient compiler is used?

Good point. Thanks.

[PATCH v5] x86/mm/KASLR: Fix the size of vmemmap section

[Baoquan He]

kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
to support the maximum amount of system RAM in 4-level paging mode, 64 TB.

However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
the size of struct page is 64 Bytes, to support 4 PB system RAM in 5-level,
64 TB of vmemmap area is needed. The wrong hardcoding may cause vmemmap
stamping into the following cpu_entry_area section, if KASLR puts vmemmap
very close to cpu_entry_area , and the actual area of vmemmap is much
bigger than 1 TB.

So here calculate the actual size of vmemmap region, then align up to 1 TB
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this new way,
the left space can be saved to join randomization to increase the entropy.

Fiexes: eedb92abb9bb ("x86/mm: Make virtual memory layout dynamic for 
CONFIG_X86_5LEVEL=y")
Signed-off-by: Baoquan He 
Acked-by: Kirill A. Shutemov 
Reviewed-by: Kees Cook 
Cc: sta...@vger.kernel.org
---
v4->v5:
  Add Fixes tag and Cc to stable.
v3->v4:
  Fix the incorrect style of code comment;
  Add ack tags from Kirill and Kees.
v3 discussion is here:
  http://lkml.kernel.org/r/20190422091045.GB3584@localhost.localdomain
 arch/x86/mm/kaslr.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index dc3f058bdf9b..c0eedb85a92f 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -52,7 +52,7 @@ static __initdata struct kaslr_memory_region {
 } kaslr_regions[] = {
{ _offset_base, 0 },
{ _base, 0 },
-   { _base, 1 },
+   { _base, 0 },
 };
 
 /* Get size in bytes used by the memory region */
@@ -78,6 +78,7 @@ void __init kernel_randomize_memory(void)
unsigned long rand, memory_tb;
struct rnd_state rand_state;
unsigned long remain_entropy;
+   unsigned long vmemmap_size;
 
vaddr_start = pgtable_l5_enabled() ? __PAGE_OFFSET_BASE_L5 : 
__PAGE_OFFSET_BASE_L4;
vaddr = vaddr_start;
@@ -109,6 +110,14 @@ void __init kernel_randomize_memory(void)
if (memory_tb < kaslr_regions[0].size_tb)
kaslr_regions[0].size_tb = memory_tb;
 
+   /*
+* Calculate how many TB vmemmap region needs, and aligned to
+* 1TB boundary.
+*/
+   vmemmap_size = (kaslr_regions[0].size_tb << (TB_SHIFT - PAGE_SHIFT)) *
+   sizeof(struct page);
+   kaslr_regions[2].size_tb = DIV_ROUND_UP(vmemmap_size, 1UL << TB_SHIFT);
+
/* Calculate entropy available between regions */
remain_entropy = vaddr_end - vaddr_start;
for (i = 0; i < ARRAY_SIZE(kaslr_regions); i++)
-- 
2.17.2

[PATCH 3/3] soc: qcom: mdt_loader: add offset to request_firmware_into_buf

[Scott Branden]

Adjust request_firmware_into_buf API to allow for portions
of firmware file to be read into a buffer.  mdt_loader still
retricts request fo whole file read into buffer.

Signed-off-by: Scott Branden 
---
 drivers/soc/qcom/mdt_loader.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 1c488024c698..ad20d159699c 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -172,8 +172,11 @@ static int __qcom_mdt_load(struct device *dev, const 
struct firmware *fw,
 
if (phdr->p_filesz) {
sprintf(fw_name + fw_name_len - 3, "b%02d", i);
-   ret = request_firmware_into_buf(_fw, fw_name, dev,
-   ptr, phdr->p_filesz);
+   ret = request_firmware_into_buf
+   (_fw, fw_name, dev,
+ptr, phdr->p_filesz,
+0,
+KERNEL_PREAD_FLAG_WHOLE);
if (ret) {
dev_err(dev, "failed to load %s\n", fw_name);
break;
-- 
2.17.1

[PATCH 1/3] fs: introduce kernel_pread_file* support

[Scott Branden]

Add kernel_pread_file* support to kernel to allow for partial read
of files with an offset into the file.  Existing kernel_read_file
functions call new kernel_pread_file functions with offset=0 and
flags=KERNEL_PREAD_FLAG_WHOLE.

Signed-off-by: Scott Branden 
---
 fs/exec.c  | 77 --
 include/linux/fs.h | 15 +
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index d88584ebf07f..ba56450acfb3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -892,10 +892,14 @@ struct file *open_exec(const char *name)
 }
 EXPORT_SYMBOL(open_exec);
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-loff_t max_size, enum kernel_read_file_id id)
-{
-   loff_t i_size, pos;
+int kernel_pread_file(struct file *file, void **buf, loff_t *size,
+ loff_t pos, loff_t max_size, unsigned int flags,
+ enum kernel_read_file_id id)
+{
+   loff_t alloc_size;
+   loff_t buf_pos;
+   loff_t read_end;
+   loff_t i_size;
ssize_t bytes = 0;
int ret;
 
@@ -915,21 +919,31 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
ret = -EINVAL;
goto out;
}
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
+
+   /* Default read to end of file */
+   read_end = i_size;
+
+   /* Allow reading partial portion of file */
+   if ((flags & KERNEL_PREAD_FLAG_PART) &&
+   (i_size > (pos + max_size)))
+   read_end = pos + max_size;
+
+   alloc_size = read_end - pos;
+   if (i_size > SIZE_MAX || (max_size > 0 && alloc_size > max_size)) {
ret = -EFBIG;
goto out;
}
 
if (id != READING_FIRMWARE_PREALLOC_BUFFER)
-   *buf = vmalloc(i_size);
+   *buf = vmalloc(alloc_size);
if (!*buf) {
ret = -ENOMEM;
goto out;
}
 
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
+   buf_pos = 0;
+   while (pos < read_end) {
+   bytes = kernel_read(file, *buf + buf_pos, read_end - pos, );
if (bytes < 0) {
ret = bytes;
goto out_free;
@@ -937,14 +951,16 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
 
if (bytes == 0)
break;
+
+   buf_pos += bytes;
}
 
-   if (pos != i_size) {
+   if (pos != read_end) {
ret = -EIO;
goto out_free;
}
 
-   ret = security_kernel_post_read_file(file, *buf, i_size, id);
+   ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
if (!ret)
*size = pos;
 
@@ -960,10 +976,20 @@ int kernel_read_file(struct file *file, void **buf, 
loff_t *size,
allow_write_access(file);
return ret;
 }
+EXPORT_SYMBOL_GPL(kernel_pread_file);
+
+int kernel_read_file(struct file *file, void **buf, loff_t *size,
+loff_t max_size, enum kernel_read_file_id id)
+{
+   return kernel_pread_file(file, buf, size, 0, max_size,
+KERNEL_PREAD_FLAG_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
-  loff_t max_size, enum kernel_read_file_id id)
+int kernel_pread_file_from_path(const char *path, void **buf,
+   loff_t *size, loff_t pos,
+   loff_t max_size, unsigned int flags,
+   enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -975,14 +1001,23 @@ int kernel_read_file_from_path(const char *path, void 
**buf, loff_t *size,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, size, max_size, id);
+   ret = kernel_pread_file(file, buf, size, pos, max_size, flags, id);
fput(file);
return ret;
 }
+EXPORT_SYMBOL_GPL(kernel_pread_file_from_path);
+
+int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
+  loff_t max_size, enum kernel_read_file_id id)
+{
+   return kernel_pread_file_from_path(path, buf, size, 0, max_size,
+  KERNEL_PREAD_FLAG_WHOLE, id);
+}
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
-int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
-enum kernel_read_file_id id)
+int kernel_pread_file_from_fd(int fd, void **buf, loff_t *size, loff_t pos,
+ loff_t max_size, unsigned int flags,
+ enum kernel_read_file_id id)
 {
struct fd f = fdget(fd);
int ret 

[PATCH 0/3] fs: add partial file read support

[Scott Branden]

This patch series adds partial file read support to the kernel via
kernel_pread_file functions.  request_firmware_into_buf function
enhanced to allow partial file read support and single qcom driver
using existing function updated.
Change to core kernel file support allows new drivers to read partial
file to memory as necessary in memory constrained systems.

Scott Branden (3):
  fs: introduce kernel_pread_file* support
  firmware: add offset to request_firmware_into_buf
  soc: qcom: mdt_loader: add offset to request_firmware_into_buf

 drivers/base/firmware_loader/firmware.h |  5 ++
 drivers/base/firmware_loader/main.c | 49 +++-
 drivers/soc/qcom/mdt_loader.c   |  7 ++-
 fs/exec.c   | 77 +++--
 include/linux/firmware.h|  8 ++-
 include/linux/fs.h  | 15 +
 6 files changed, 125 insertions(+), 36 deletions(-)

-- 
2.17.1

[Patch v2] staging: rtl8723bs: core: rtw_recv: fix warning Comparison to NULL

[Hariprasad Kelam]

fix below warning reported by checkpatch

CHECK: Comparison to NULL could be written
"!precvpriv->pallocated_frame_buf"
CHECK: Comparison to NULL could be written "padapter"

Signed-off-by: Hariprasad Kelam 
-
changes in v2:
Corected few erorrs like (!*psta == NULL) pointed in
review
---
 drivers/staging/rtl8723bs/core/rtw_recv.c | 48 +++
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c 
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index b9f758e..b9c9bba 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -50,7 +50,7 @@ sint _rtw_init_recv_priv(struct recv_priv *precvpriv, struct 
adapter *padapter)
 
precvpriv->pallocated_frame_buf = vzalloc(NR_RECVFRAME * sizeof(union 
recv_frame) + RXFRAME_ALIGN_SZ);
 
-   if (precvpriv->pallocated_frame_buf == NULL) {
+   if (!precvpriv->pallocated_frame_buf) {
res = _FAIL;
goto exit;
}
@@ -122,7 +122,7 @@ union recv_frame *_rtw_alloc_recvframe(struct __queue 
*pfree_recv_queue)
 
list_del_init(>u.hdr.list);
padapter = precvframe->u.hdr.adapter;
-   if (padapter != NULL) {
+   if (padapter) {
precvpriv = >recvpriv;
if (pfree_recv_queue == >free_recv_queue)
precvpriv->free_recvframe_cnt--;
@@ -160,7 +160,7 @@ int rtw_free_recvframe(union recv_frame *precvframe, struct 
__queue *pfree_recv_
 
list_add_tail(&(precvframe->u.hdr.list), 
get_list_head(pfree_recv_queue));
 
-   if (padapter != NULL) {
+   if (padapter) {
if (pfree_recv_queue == >free_recv_queue)
precvpriv->free_recvframe_cnt++;
}
@@ -183,7 +183,7 @@ sint _rtw_enqueue_recvframe(union recv_frame *precvframe, 
struct __queue *queue)
 
list_add_tail(&(precvframe->u.hdr.list), get_list_head(queue));
 
-   if (padapter != NULL)
+   if (padapter)
if (queue == >free_recv_queue)
precvpriv->free_recvframe_cnt++;
 
@@ -334,7 +334,7 @@ sint recvframe_chkmic(struct adapter *adapter,  union 
recv_frame *precvframe)
prxattrib->ra[0], prxattrib->ra[1], prxattrib->ra[2], 
prxattrib->ra[3], prxattrib->ra[4], prxattrib->ra[5]));
 
/* calculate mic code */
-   if (stainfo != NULL) {
+   if (stainfo) {
if (IS_MCAST(prxattrib->ra)) {
/* mickey 
=>dot118021XGrprxmickey.skey[0]; */
/* iv = 
precvframe->u.hdr.rx_data+prxattrib->hdrlen; */
@@ -570,7 +570,7 @@ union recv_frame *portctrl(struct adapter *adapter, union 
recv_frame *precv_fram
RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, 
("portctrl:adapter->securitypriv.dot11AuthAlgrthm =%d\n", 
adapter->securitypriv.dot11AuthAlgrthm));
 
if (auth_alg == 2) {
-   if ((psta != NULL) && (psta->ieee8021x_blocked)) {
+   if ((psta) && (psta->ieee8021x_blocked)) {
__be16 be_tmp;
 
/* blocked */
@@ -859,7 +859,7 @@ sint sta2sta_data_frame(
else
*psta = rtw_get_stainfo(pstapriv, sta_addr); /*  get ap_info */
 
-   if (*psta == NULL) {
+   if (!*psta) {
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("can't get psta 
under sta2sta_data_frame ; drop pkt\n"));
ret = _FAIL;
goto exit;
@@ -942,7 +942,7 @@ sint ap2sta_data_frame(
else
*psta = rtw_get_stainfo(pstapriv, pattrib->bssid); /*  
get ap_info */
 
-   if (*psta == NULL) {
+   if (!*psta) {
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("ap2sta: 
can't get psta under STATION_MODE ; drop pkt\n"));
#ifdef DBG_RX_DROP_FRAME
DBG_871X("DBG_RX_DROP_FRAME %s can't get psta under 
STATION_MODE ; drop pkt\n", __func__);
@@ -974,7 +974,7 @@ sint ap2sta_data_frame(
 
 
*psta = rtw_get_stainfo(pstapriv, pattrib->bssid); /*  get 
sta_info */
-   if (*psta == NULL) {
+   if (!*psta) {
RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("can't 
get psta under MP_MODE ; drop pkt\n"));
#ifdef DBG_RX_DROP_FRAME
DBG_871X("DBG_RX_DROP_FRAME %s can't get psta under 
WIFI_MP_STATE ; drop pkt\n", __func__);
@@ -991,7 +991,7 @@ sint ap2sta_data_frame(
} else {
if (!memcmp(myhwaddr, pattrib->dst, ETH_ALEN) && (!bmcast)) {
*psta = rtw_get_stainfo(pstapriv, pattrib->bssid); /*  
get sta_info */
-   if (*psta == NULL) {
+   if (!*psta) {
 
 

[PATCH 2/3] firmware: add offset to request_firmware_into_buf

[Scott Branden]

Add offset to request_firmware_into_buf to allow for portions
of firmware file to be read into a buffer.  Necessary where firmware
needs to be loaded in portions from file in memory constrained systems.

Signed-off-by: Scott Branden 
---
 drivers/base/firmware_loader/firmware.h |  5 +++
 drivers/base/firmware_loader/main.c | 49 +
 include/linux/firmware.h|  8 +++-
 3 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 4c1395f8e7ed..d73d400c2023 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -29,6 +29,8 @@
  * firmware caching mechanism.
  * @FW_OPT_NOFALLBACK: Disable the fallback mechanism. Takes precedence over
  * _OPT_UEVENT and _OPT_USERHELPER.
+ * @FW_OPT_PARTIAL: Allow partial read of firmware instead of needing to read
+ * entire file.
  */
 enum fw_opt {
FW_OPT_UEVENT = BIT(0),
@@ -37,6 +39,7 @@ enum fw_opt {
FW_OPT_NO_WARN =BIT(3),
FW_OPT_NOCACHE =BIT(4),
FW_OPT_NOFALLBACK = BIT(5),
+   FW_OPT_PARTIAL =BIT(6),
 };
 
 enum fw_status {
@@ -64,6 +67,8 @@ struct fw_priv {
void *data;
size_t size;
size_t allocated_size;
+   size_t offset;
+   unsigned int flags;
 #ifdef CONFIG_FW_LOADER_USER_HELPER
bool is_paged_buf;
bool need_uevent;
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 7eaaf5ee5ba6..34d4f043b7c8 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -166,7 +166,8 @@ static int fw_cache_piggyback_on_request(const char *name);
 
 static struct fw_priv *__allocate_fw_priv(const char *fw_name,
  struct firmware_cache *fwc,
- void *dbuf, size_t size)
+ void *dbuf, size_t size,
+ size_t offset, unsigned int flags)
 {
struct fw_priv *fw_priv;
 
@@ -184,6 +185,8 @@ static struct fw_priv *__allocate_fw_priv(const char 
*fw_name,
fw_priv->fwc = fwc;
fw_priv->data = dbuf;
fw_priv->allocated_size = size;
+   fw_priv->offset = offset;
+   fw_priv->flags = flags;
fw_state_init(fw_priv);
 #ifdef CONFIG_FW_LOADER_USER_HELPER
INIT_LIST_HEAD(_priv->pending_list);
@@ -209,9 +212,11 @@ static struct fw_priv *__lookup_fw_priv(const char 
*fw_name)
 static int alloc_lookup_fw_priv(const char *fw_name,
struct firmware_cache *fwc,
struct fw_priv **fw_priv, void *dbuf,
-   size_t size, enum fw_opt opt_flags)
+   size_t size, enum fw_opt opt_flags,
+   size_t offset)
 {
struct fw_priv *tmp;
+   unsigned int pread_flags;
 
spin_lock(>lock);
if (!(opt_flags & FW_OPT_NOCACHE)) {
@@ -225,7 +230,12 @@ static int alloc_lookup_fw_priv(const char *fw_name,
}
}
 
-   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size);
+   if (opt_flags & FW_OPT_PARTIAL)
+   pread_flags = KERNEL_PREAD_FLAG_PART;
+   else
+   pread_flags = KERNEL_PREAD_FLAG_WHOLE;
+
+   tmp = __allocate_fw_priv(fw_name, fwc, dbuf, size, offset, pread_flags);
if (tmp) {
INIT_LIST_HEAD(>list);
if (!(opt_flags & FW_OPT_NOCACHE))
@@ -325,8 +335,9 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv)
}
 
fw_priv->size = 0;
-   rc = kernel_read_file_from_path(path, _priv->data, ,
-   msize, id);
+   rc = kernel_pread_file_from_path(path, _priv->data, ,
+fw_priv->offset, msize,
+fw_priv->flags, id);
if (rc) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
@@ -500,7 +511,7 @@ int assign_fw(struct firmware *fw, struct device *device,
 static int
 _request_firmware_prepare(struct firmware **firmware_p, const char *name,
  struct device *device, void *dbuf, size_t size,
- enum fw_opt opt_flags)
+ enum fw_opt opt_flags, size_t offset)
 {
struct firmware *firmware;
struct fw_priv *fw_priv;
@@ -519,7 +530,7 @@ _request_firmware_prepare(struct firmware **firmware_p, 
const char *name,
}
 
ret = alloc_lookup_fw_priv(name, _cache, _priv, dbuf, size,
- opt_flags);
+ opt_flags, offset);
 
/*

Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1

[Masahiro Yamada]

On Wed, May 22, 2019 at 3:37 PM Joe Perches  wrote:
>
> On Wed, 2019-05-22 at 13:32 +0900, Masahiro Yamada wrote:
> > On Tue, May 21, 2019 at 10:34 PM Greg KH  wrote:
> []
> > >  - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan
> > > tools can determine the license text in the file itself.  Where this
> > > happens, the license text is removed, in order to cut down on the
> > > 700+ different ways we have in the kernel today, in a quest to get
> > > rid of all of these.
> []
> > I have been wondering for a while
> > which version of spdx tags I should use in my work.
> >
> > I know the 'GPL-2.0' tag is already deprecated.
> > (https://spdx.org/licenses/GPL-2.0.html)
> >
> > But, I saw negative reaction to this:
> > https://lore.kernel.org/patchwork/patch/975394/
> >
> > Nor "-only" / "-or-later" are documented in
> > Documentation/process/license-rules.rst
> >
> > In this patch series, Thomas used 'GPL-2.0-only' and 'GPL-2.0-or-later'
> > instead of 'GPL-2.0' and 'GPL-2.0+'.
> >
> > Now, we have a great number of users of spdx v3 tags.
> > $ git grep -P 'SPDX-License-Identifier.*(?:-or-later|-only)'| wc -l
> > 4135
> > So, what I understood is:
> >
> >   For newly added tags, '*-only' and '*-or-later' are preferred.
> >
> > (But, we do not convert existing spdx v2 tags globally.)
> >
> >
> > "
> > Joe's patch was not merged, but at least
> > Documentation/process/license-rules.rst
> > should be updated in my opinion.
> >
> > (Perhaps, checkpatch.pl can suggest newer tags in case
> > patch submitters do not even know that deprecation.)
>
> I'd still prefer the kernel use of a single SPDX style.
>
> I don't know why the -only and -or-later forms were
> used for this patch, but I like it.
>
> I believe the -only and -or-later are more intelligible
> as a trivial reading of
>
> SPDX-License-Identifier: GPL-2.0
>
> would generally mean to me the original
> GPL-2.0 license without the elision of the
> (or at your option, any later version) bits
>
> whereas
>
> SPDX-License-Identifier: GPL-2.0-only
>
> seems fairly descriptive.
>
> Is it agreed that the GPL--only and GPL--or-later
> forms should be preferred for new SPDX identifiers?


I agree.


> If so, I'll submit a checkpatch patch.

That will be nice.


> I could also wire up a patch to checkpatch and docs to
> remove the /* */
> requirement for .h files and prefer
> the generic // form for both .c and
> .h files as the
> current minimum tooling versions now all allow //
> comments
> .

We have control for minimal tool versions for building the kernel,
so I think // will be OK for in-kernel headers.


On the other hand, I am not quite sure about UAPI headers.
We cannot define minimum tool versions
for building user-space.
Perhaps, using // in UAPI headers causes a problem
if an ancient compiler is used?


BTW, if we allow to use // in header files,
we have no reason to forbid // in assembly files either.

We use *.S files (assembly that should be preprocessed)
instead of *.s files.

So, comments are ripped off by CPP anyway
whichever comment style is used.


--
Best Regards
Masahiro Yamada

Re: [PATCH v2] fix use-after-free in perf_sched__lat

[Namhyung Kim]

On Wed, May 22, 2019 at 08:08:23AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 22, 2019 at 03:56:10PM +0900, Namhyung Kim escreveu:
> > On Wed, May 08, 2019 at 10:36:48PM +0800, Wei Li wrote:
> > > After thread is added to machine->threads[i].dead in
> > > __machine__remove_thread, the machine->threads[i].dead is freed
> > > when calling free(session) in perf_session__delete(). So it get a
> > > Segmentation fault when accessing it in thread__put().
> > > 
> > > In this patch, we delay the perf_session__delete until all threads
> > > have been deleted.
> > > 
> > > This can be reproduced by following steps:
> > >   ulimit -c unlimited
> > >   export MALLOC_MMAP_THRESHOLD_=0
> > >   perf sched record sleep 10
> > >   perf sched latency --sort max
> > >   Segmentation fault (core dumped)
> > > 
> > > Signed-off-by: Zhipeng Xie 
> > > Signed-off-by: Wei Li 
> > 
> > Acked-by: Namhyung Kim 
> 
> I'll try to analyse this one soon, but my first impression was that we
> should just grab reference counts when keeping a pointer to those
> threads instead of keeping _all_ threads alive when supposedly we could
> trow away unreferenced data structures.
> 
> But this is just a first impression from just reading the patch
> description, probably I'm missing something.

No, thread refcounting is fine.  We already did it and threads with the
refcount will be accessed only.

But the problem is the head of the list.  After using the thread, the
refcount is gone and thread is removed from the list and destroyed.
However the head of list is in a struct machine which was freed with
session already.

Thanks,
Namhyung


> 
> Thanks for providing instructions on readily triggering the segfault.
> 
> - Arnaldo

Re: [PATCH 3/3] perf top: Enable --namespaces option

[Namhyung Kim]

On Wed, May 22, 2019 at 10:24:24AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 22, 2019 at 02:32:50PM +0900, Namhyung Kim escreveu:
> > Since perf record already have the option, let's have it for perf top
> > as well.
> 
> I'm applying, but I wonder if this shouldn't be the default...

Not sure, it'll only add a bit of overhead to task and/or namespace
creation.

Thanks,
Namhyung


> 
> - Arnaldo
>  
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/Documentation/perf-top.txt | 5 +
> >  tools/perf/builtin-top.c  | 5 +
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/tools/perf/Documentation/perf-top.txt 
> > b/tools/perf/Documentation/perf-top.txt
> > index 44d89fb9c788..cfea87c6f38e 100644
> > --- a/tools/perf/Documentation/perf-top.txt
> > +++ b/tools/perf/Documentation/perf-top.txt
> > @@ -262,6 +262,11 @@ Default is to monitor all CPUS.
> > The number of threads to run when synthesizing events for existing 
> > processes.
> > By default, the number of threads equals to the number of online CPUs.
> >  
> > +--namespaces::
> > +   Record events of type PERF_RECORD_NAMESPACES and display it with the
> > +   'cgroup_id' sort key.
> > +
> > +
> >  INTERACTIVE PROMPTING KEYS
> >  --
> >  
> > diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> > index 3648ef576996..6651377fd762 100644
> > --- a/tools/perf/builtin-top.c
> > +++ b/tools/perf/builtin-top.c
> > @@ -1208,6 +1208,9 @@ static int __cmd_top(struct perf_top *top)
> >  
> > init_process_thread(top);
> >  
> > +   if (opts->record_namespaces)
> > +   top->tool.namespace_events = true;
> > +
> > ret = perf_event__synthesize_bpf_events(top->session, 
> > perf_event__process,
> > >session->machines.host,
> > >record_opts);
> > @@ -1500,6 +1503,8 @@ int cmd_top(int argc, const char **argv)
> > OPT_BOOLEAN(0, "force", _conf.force, "don't complain, do it"),
> > OPT_UINTEGER(0, "num-thread-synthesize", _threads_synthesize,
> > "number of thread to run event synthesize"),
> > +   OPT_BOOLEAN(0, "namespaces", >record_namespaces,
> > +   "Record namespaces events"),
> > OPT_END()
> > };
> > struct perf_evlist *sb_evlist = NULL;
> > -- 
> > 2.21.0.1020.gf2820cf01a-goog
> 
> -- 
> 
> - Arnaldo

[PATCH] sg: Fix a double-fetch bug in drivers/scsi/sg.c

[Gen Zhang]

In sg_write(), the opcode of the command is fetched the first time from 
the userspace by __get_user(). Then the whole command, the opcode 
included, is fetched again from userspace by __copy_from_user(). 
However, a malicious user can change the opcode between the two fetches.
This can cause inconsistent data and potential errors as cmnd is used in
the following codes.

Thus we should check opcode between the two fetches to prevent this.

Signed-off-by: Gen Zhang 
---
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index d3f1531..a2971b8 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -694,6 +694,8 @@ sg_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos)
hp->flags = input_size; /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
+   if (opcode != cmnd[0])
+   return -EINVAL;
if (__copy_from_user(cmnd, buf, cmd_size))
return -EFAULT;
/*
---

Re: [PATCH V2 0/4] Prevent vhost kthread from hogging CPU

[Jason Wang]

On 2019/5/20 下午8:52, Michael S. Tsirkin wrote:

On Fri, May 17, 2019 at 12:29:48AM -0400, Jason Wang wrote:

Hi:

This series try to prevent a guest triggerable CPU hogging through
vhost kthread. This is done by introducing and checking the weight
after each requrest. The patch has been tested with reproducer of
vsock and virtio-net. Only compile test is done for vhost-scsi.

Please review.
This addresses CVE-2019-3900.

OK I think we should clean this code some more but given
it's a CVE fix maybe it's best to do as a patch on top.

Acked-by: Michael S. Tsirkin

Dave do you want to merge this or should I?



According to David's last reply, it's better for you to merge I think.

Thanks

Re: [PATCH 1/3] perf tools: Protect reading thread's namespace

[Namhyung Kim]

Hi Arnaldo,

On Wed, May 22, 2019 at 10:18:32AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 22, 2019 at 02:32:48PM +0900, Namhyung Kim escreveu:
> > It seems that the current code lacks holding the namespace lock in
> > thread__namespaces().  Otherwise it can see inconsistent results.
> > 
> > Signed-off-by: Namhyung Kim 
> > ---
> >  tools/perf/util/thread.c | 15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> > index 403045a2bbea..b413ba5b9835 100644
> > --- a/tools/perf/util/thread.c
> > +++ b/tools/perf/util/thread.c
> > @@ -133,7 +133,7 @@ void thread__put(struct thread *thread)
> > }
> >  }
> >  
> > -struct namespaces *thread__namespaces(const struct thread *thread)
> > +static struct namespaces *__thread__namespaces(const struct thread *thread)
> >  {
> > if (list_empty(>namespaces_list))
> > return NULL;
> > @@ -141,10 +141,21 @@ struct namespaces *thread__namespaces(const struct 
> > thread *thread)
> > return list_first_entry(>namespaces_list, struct namespaces, 
> > list);
> >  }
> >  
> > +struct namespaces *thread__namespaces(const struct thread *thread)
> > +{
> > +   struct namespaces *ns;
> > +
> > +   down_read((struct rw_semaphore *)>namespaces_lock);
> > +   ns = __thread__namespaces(thread);
> > +   up_read((struct rw_semaphore *)>namespaces_lock);
> > +
> 
> Humm, so we need to change thread__namespaces() to remove that const
> instead of throwing it away with that cast, right?

Yes, that's possible too.  Note that thread__comm_str() has the same issue
as well.

Thanks,
Namhyung

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

[Sean Christopherson]

On Wed, May 22, 2019 at 03:42:45PM -0700, Andy Lutomirski wrote:
> On Wed, May 22, 2019 at 8:38 AM Sean Christopherson
>  wrote:
> >
> > And that straight up doesn't work with the v20 driver because mmap() with
> > the enclave_fd will run through sgx_get_unmapped_area(), which also does
> > the natural alignment adjustments (the idea being that mmap() is mapping
> > the entire enclave).  E.g. mmap() will map the wrong address if the offset
> > of a chunk is less than its size due to the driver adjusting the address.
> 
> That presumably needs to change.

If we want to allow mmap() on a subset of the enclave, yes.  I assume it's
a simple matter of respecting MAP_FIXED.

> Are we entirely missing an API to allocate a naturally aligned VA
> range?  That's kind of annoying.

Yes?

> > Eliminating sgx_get_unmapped_area() means userspace is once again on the
> > hook for naturally aligning the enclave, which is less than desirable.
> >
> > Looking back at the original API discussions around a builder process[1],
> > we never fleshed out the end-to-end flow.  While having a builder process
> > *sounds* reasonable, in practice it adds a lot of complexity without
> > providing much in the way of added security.  E.g. in addition to the
> > above mmap() issues, since the order of EADDs affects the enclave
> > measurement, the enclave owner would need to communicate the exact steps
> > to build the enclave, or the builder would need a priori knowledge of the
> > enclave format.
> >
> > Userspace can still restrict access to /dev/sgx/enclave, e.g. by having a
> > daemon that requires additional credentials to obtain a new enclave_fd.
> > So AFAICT, the only benefit to having a dedicated builder is that it can
> > do its own whitelisting of enclaves, but since we're trending towards
> > supporting whitelisting enclaves in the kernel, e.g. via sigstruct,
> > whitelisting in userspace purely in userspace also provides marginal value.
> >
> > TL;DR: Requiring VMA backing to build an enclave seems reasonable and sane.
> 
> This isn't necessarily a problem, but we pretty much have to use
> mprotect() then.

You lost me there.  Who needs to mprotect() what?

> Maybe the semantics could just be that mmap() on the SGX device gives
> natural alignment, but that there is no actual constraint enforced by
> the driver as to whether mmap() happens before or after ECREATE.
> After all, it's *ugly* for user code to reserve its address range with
> an awkward giant mmap(), there's nothing fundamentally wrong with it.
> 
> As far as I know from this whole discussion, we still haven't come up
> with any credible way to avoid tracking, per enclave page, whether
> that page came from unmodified PROT_EXEC memory.

Disallowing mmap() after ECREATE is credible, but apparently not
palatable. :-)

But actually, there's no need to disallow mmap() after ECREATE since the
LSM checks also apply to mmap(), e.g. FILE__EXECUTE would be needed to
mmap() any enclave pages PROT_EXEC.  I guess my past self thought mmap()
bypassed LSM checks?  The real problem is that mmap()'ng an existing
enclave would require FILE__WRITE and FILE__EXECUTE, which puts us back
at square one.

Tracking permissions per enclave page isn't difficult, it's the new SGX
specific LSM hooks and mprotect() interactions that I want to avoid.

Jumping back to mmap(), AIUI the fundamental issue is that we want to
allow building/running an enclave without FILE__WRITE and FILE__EXECUTE,
otherwise FILE__WRITE and FILE__EXECUTE become meaningless.  Assuming I'm
not off in the weeds, that means we really just need to special case
mmap() on enclaves so it can map enclave memory using the verified page
permissions so as not to run afoul of LSM checks.  All other behaviors,
e.g. mprotect(), can reuse the existing LSM checks for shared mappings.

So, what if we snapshot the permissions for each enclave page at EADD,
and then special case mmap() to propagate flags from the snapshot to the
VMA?  More or less the same idea as doing mprotect_fixup() using the
source VMA during EADD.  We could define the EADD semantics to match
this as well, e.g. only propagate the flags from the source VMA to the
enclave VMA if the EADD range is fully mapped with PROT_NONE.  This would
allow the enclave builder concept, albeit with funky semantics, and
wouldn't require new LSM hooks.

E.g. something like this:

static inline void sgx_mmap_update_prot_flags(struct vm_area_struct *vma,
  struct sgx_encl *encl)
{
struct radix_tree_iter iter;
struct sgx_encl_page *entry;
unsigned long addr;
vm_flags_t flags;
void **slot;

/*
 * SGX special: if userspace is requesting PROT_NONE and pages have
 * been added to the enclave, then propagate the flags snapshot from
 * the enclave to the VMA.  Do this if and only if all overlapped
 * pages are defined and have identical permissions.  Stuffing the
  

[PATCH net-next v2, 2/4] enetc: add get_ts_info interface for ethtool

[Y.b. Lu]

This patch is to add get_ts_info interface for ethtool
to support getting timestamping capability.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None.
---
 drivers/net/ethernet/freescale/enetc/enetc.h  |  3 ++
 .../ethernet/freescale/enetc/enetc_ethtool.c  | 31 +++
 .../net/ethernet/freescale/enetc/enetc_ptp.c  |  5 +++
 3 files changed, 39 insertions(+)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h 
b/drivers/net/ethernet/freescale/enetc/enetc.h
index 281bb4368b98..ea443268bf70 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -209,6 +209,9 @@ struct enetc_msg_cmd_set_primary_mac {
 
 #define ENETC_CBDR_TIMEOUT 1000 /* usecs */
 
+/* PTP driver exports */
+extern int enetc_phc_index;
+
 /* SI common */
 int enetc_pci_probe(struct pci_dev *pdev, const char *name, int sizeof_priv);
 void enetc_pci_remove(struct pci_dev *pdev);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c 
b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index b9519b6ad727..fcb52efec075 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -555,6 +555,35 @@ static void enetc_get_ringparam(struct net_device *ndev,
}
 }
 
+static int enetc_get_ts_info(struct net_device *ndev,
+struct ethtool_ts_info *info)
+{
+   int *phc_idx;
+
+   phc_idx = symbol_get(enetc_phc_index);
+   if (phc_idx) {
+   info->phc_index = *phc_idx;
+   symbol_put(enetc_phc_index);
+   } else {
+   info->phc_index = -1;
+   }
+
+#ifdef CONFIG_FSL_ENETC_HW_TIMESTAMPING
+   info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+   SOF_TIMESTAMPING_RX_HARDWARE |
+   SOF_TIMESTAMPING_RAW_HARDWARE;
+
+   info->tx_types = (1 << HWTSTAMP_TX_OFF) |
+(1 << HWTSTAMP_TX_ON);
+   info->rx_filters = (1 << HWTSTAMP_FILTER_NONE) |
+  (1 << HWTSTAMP_FILTER_ALL);
+#else
+   info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
+   SOF_TIMESTAMPING_SOFTWARE;
+#endif
+   return 0;
+}
+
 static const struct ethtool_ops enetc_pf_ethtool_ops = {
.get_regs_len = enetc_get_reglen,
.get_regs = enetc_get_regs,
@@ -571,6 +600,7 @@ static const struct ethtool_ops enetc_pf_ethtool_ops = {
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
.get_link = ethtool_op_get_link,
+   .get_ts_info = enetc_get_ts_info,
 };
 
 static const struct ethtool_ops enetc_vf_ethtool_ops = {
@@ -586,6 +616,7 @@ static const struct ethtool_ops enetc_vf_ethtool_ops = {
.set_rxfh = enetc_set_rxfh,
.get_ringparam = enetc_get_ringparam,
.get_link = ethtool_op_get_link,
+   .get_ts_info = enetc_get_ts_info,
 };
 
 void enetc_set_ethtool_ops(struct net_device *ndev)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c 
b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
index 8c1497e7d9c5..2fd2586e42bf 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
@@ -7,6 +7,9 @@
 
 #include "enetc.h"
 
+int enetc_phc_index = -1;
+EXPORT_SYMBOL(enetc_phc_index);
+
 static struct ptp_clock_info enetc_ptp_caps = {
.owner  = THIS_MODULE,
.name   = "ENETC PTP clock",
@@ -96,6 +99,7 @@ static int enetc_ptp_probe(struct pci_dev *pdev,
if (err)
goto err_no_clock;
 
+   enetc_phc_index = ptp_qoriq->phc_index;
pci_set_drvdata(pdev, ptp_qoriq);
 
return 0;
@@ -119,6 +123,7 @@ static void enetc_ptp_remove(struct pci_dev *pdev)
 {
struct ptp_qoriq *ptp_qoriq = pci_get_drvdata(pdev);
 
+   enetc_phc_index = -1;
ptp_qoriq_free(ptp_qoriq);
kfree(ptp_qoriq);
 
-- 
2.17.1

[PATCH net-next v2, 3/4] dt-binding: ptp_qoriq: support ENETC PTP compatible

[Y.b. Lu]

Add a new compatible for ENETC PTP.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added this patch.
---
 Documentation/devicetree/bindings/ptp/ptp-qoriq.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt 
b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
index 454c937076a2..6ec053449278 100644
--- a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+++ b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
@@ -4,6 +4,7 @@ General Properties:
 
   - compatible   Should be "fsl,etsec-ptp" for eTSEC
  Should be "fsl,fman-ptp-timer" for DPAA FMan
+Should be "fsl,enetc-ptp" for ENETC
   - reg  Offset and length of the register set for the device
   - interrupts   There should be at least two interrupts. Some devices
  have as many as four PTP related interrupts.
-- 
2.17.1

[PATCH net-next v2, 1/4] enetc: add hardware timestamping support

[Y.b. Lu]

This patch is to add hardware timestamping support
for ENETC. On Rx, timestamping is enabled for all
frames. On Tx, we only instruct the hardware to
timestamp the frames marked accordingly by the stack.

Because the RX BD ring dynamic allocation has not been
supported and it is too expensive to use extended RX BDs
if timestamping is not used, a Kconfig option is used to
enable extended RX BDs in order to support hardware
timestamping. This option will be removed once RX BD
ring dynamic allocation is implemented.

Signed-off-by: Yangbo Lu 
Signed-off-by: Claudiu Manoil 
---
Changes for v2:
- Rephrased Kconfig help message.
- Reverse Christmas tree order for variable definitions.
- Dropped goto in enetc_clean_tx_ring().
- Used name enetc_active_offloads instead of enetc_hw_features.
- Fixed up rx tstamp implementation.
- Rephrased commit message and added Claudiu.
---
 drivers/net/ethernet/freescale/enetc/Kconfig  |  10 ++
 drivers/net/ethernet/freescale/enetc/enetc.c  | 158 +-
 drivers/net/ethernet/freescale/enetc/enetc.h  |  12 +-
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  13 ++
 .../net/ethernet/freescale/enetc/enetc_pf.c   |   1 +
 .../net/ethernet/freescale/enetc/enetc_vf.c   |   1 +
 6 files changed, 189 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig 
b/drivers/net/ethernet/freescale/enetc/Kconfig
index 8429f5c1d810..ed0d010c7cf2 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -29,3 +29,13 @@ config FSL_ENETC_PTP_CLOCK
  packets using the SO_TIMESTAMPING API.
 
  If compiled as module (M), the module name is fsl-enetc-ptp.
+
+config FSL_ENETC_HW_TIMESTAMPING
+   bool "ENETC hardware timestamping support"
+   depends on FSL_ENETC || FSL_ENETC_VF
+   help
+ Enable hardware timestamping support on the Ethernet packets
+ using the SO_TIMESTAMPING API. Because the RX BD ring dynamic
+ allocation has not been supported and it is too expensive to use
+ extended RX BDs if timestamping is not used, this option enables
+ extended RX BDs in order to support hardware timestamping.
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c 
b/drivers/net/ethernet/freescale/enetc/enetc.c
index 491475d87736..d2ace299bed0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -13,7 +13,8 @@
 #define ENETC_MAX_SKB_FRAGS13
 #define ENETC_TXBDS_MAX_NEEDED ENETC_TXBDS_NEEDED(ENETC_MAX_SKB_FRAGS + 1)
 
-static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb);
+static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb,
+ int active_offloads);
 
 netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device *ndev)
 {
@@ -33,7 +34,7 @@ netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device 
*ndev)
return NETDEV_TX_BUSY;
}
 
-   count = enetc_map_tx_buffs(tx_ring, skb);
+   count = enetc_map_tx_buffs(tx_ring, skb, priv->active_offloads);
if (unlikely(!count))
goto drop_packet_err;
 
@@ -105,7 +106,8 @@ static void enetc_free_tx_skb(struct enetc_bdr *tx_ring,
}
 }
 
-static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb)
+static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb,
+ int active_offloads)
 {
struct enetc_tx_swbd *tx_swbd;
struct skb_frag_struct *frag;
@@ -137,7 +139,10 @@ static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, 
struct sk_buff *skb)
count++;
 
do_vlan = skb_vlan_tag_present(skb);
-   do_tstamp = skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP;
+   do_tstamp = (active_offloads & ENETC_F_TX_TSTAMP) &&
+   (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP);
+   tx_swbd->do_tstamp = do_tstamp;
+   tx_swbd->check_wb = tx_swbd->do_tstamp;
 
if (do_vlan || do_tstamp)
flags |= ENETC_TXBD_FLAGS_EX;
@@ -299,24 +304,69 @@ static int enetc_bd_ready_count(struct enetc_bdr 
*tx_ring, int ci)
return pi >= ci ? pi - ci : tx_ring->bd_count - ci + pi;
 }
 
+static void enetc_get_tx_tstamp(struct enetc_hw *hw, union enetc_tx_bd *txbd,
+   u64 *tstamp)
+{
+   u32 lo, hi;
+
+   lo = enetc_rd(hw, ENETC_SICTR0);
+   hi = enetc_rd(hw, ENETC_SICTR1);
+   if (lo <= txbd->wb.tstamp)
+   hi -= 1;
+   *tstamp = (u64)hi << 32 | txbd->wb.tstamp;
+}
+
+static void enetc_tstamp_tx(struct sk_buff *skb, u64 tstamp)
+{
+   struct skb_shared_hwtstamps shhwtstamps;
+
+   if (skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS) {
+   memset(, 0, sizeof(shhwtstamps));
+   shhwtstamps.hwtstamp = ns_to_ktime(tstamp);
+   skb_tstamp_tx(skb, );
+   

[PATCH net-next v2, 4/4] arm64: dts: fsl: ls1028a: add ENETC 1588 timer node

[Y.b. Lu]

Add ENETC 1588 timer node which is ENETC PF 4 (Physiscal Function 4).

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added compatible.
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index b04581249f0b..4cdf84c63320 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -431,6 +431,12 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+   ethernet@0,4 {
+   compatible = "fsl,enetc-ptp";
+   reg = <0x000400 0 0 0 0>;
+   clocks = < 4 0>;
+   little-endian;
+   };
};
};
 };
-- 
2.17.1

[PATCH net-next v2, 0/4] ENETC: support hardware timestamping

[Y.b. Lu]

This patch-set is to support hardware timestamping for ENETC
and also to add ENETC 1588 timer device tree node for ls1028a.

Because the ENETC RX BD ring dynamic allocation has not been
supported and it is too expensive to use extended RX BDs
if timestamping is not used, a Kconfig option is used to
enable extended RX BDs in order to support hardware
timestamping. This option will be removed once RX BD
ring dynamic allocation is implemented.

Yangbo Lu (4):
  enetc: add hardware timestamping support
  enetc: add get_ts_info interface for ethtool
  dt-binding: ptp_qoriq: support ENETC PTP compatible
  arm64: dts: fsl: ls1028a: add ENETC 1588 timer node

 .../devicetree/bindings/ptp/ptp-qoriq.txt |   1 +
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi |   6 +
 drivers/net/ethernet/freescale/enetc/Kconfig  |  10 ++
 drivers/net/ethernet/freescale/enetc/enetc.c  | 158 +-
 drivers/net/ethernet/freescale/enetc/enetc.h  |  15 +-
 .../ethernet/freescale/enetc/enetc_ethtool.c  |  31 
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  13 ++
 .../net/ethernet/freescale/enetc/enetc_pf.c   |   1 +
 .../net/ethernet/freescale/enetc/enetc_ptp.c  |   5 +
 .../net/ethernet/freescale/enetc/enetc_vf.c   |   1 +
 10 files changed, 235 insertions(+), 6 deletions(-)

-- 
2.17.1

[PATCH] powerpc/powernv: fix variable "c" set but not used

[Qian Cai]

The commit 58629c0dc349 ("powerpc/powernv/npu: Fault user page into the
hypervisor's pagetable") introduced a variable "c" to be used in
__get_user() and __get_user_nocheck() which need to stay as macros for
performance reasons, and "c" is not actually used in
pnv_npu2_handle_fault(),

arch/powerpc/platforms/powernv/npu-dma.c: In function 'pnv_npu2_handle_fault':
arch/powerpc/platforms/powernv/npu-dma.c:1122:7: warning: variable 'c'
set but not used [-Wunused-but-set-variable]

Fixed it by appending the __maybe_unused attribute, so compilers would
ignore it.

Signed-off-by: Qian Cai 
---
 arch/powerpc/platforms/powernv/npu-dma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
index 495550432f3d..5bbe59573ee6 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -1119,7 +1119,8 @@ int pnv_npu2_handle_fault(struct npu_context *context, 
uintptr_t *ea,
int i, is_write;
struct page *page[1];
const char __user *u;
-   char c;
+   /* To silence a -Wunused-but-set-variable warning. */
+   char c __maybe_unused;
 
/* mmap_sem should be held so the struct_mm must be present */
struct mm_struct *mm = context->mm;
-- 
2.20.1 (Apple Git-117)

[v4 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout

[Yang Shi]

Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole.  But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.

This doesn't make too much sense to memory reclaim.  For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it.  But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.

And, it may cause pgsteal_{kswapd|direct} is greater than
pgscan_{kswapd|direct}, like the below:

pgsteal_kswapd 122933
pgsteal_direct 26600225
pgscan_kswapd 174153
pgscan_direct 14678312

nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
break some page reclaim logic, e.g.

vmpressure: this looks at the scanned/reclaimed ratio so it won't
change semantics as long as scanned & reclaimed are fixed in parallel.

compaction/reclaim: compaction wants a certain number of physical pages
freed up before going back to compacting.

kswapd priority raising: kswapd raises priority if we scan fewer pages
than the reclaim target (which itself is obviously expressed in order-0
pages). As a result, kswapd can falsely raise its aggressiveness even
when it's making great progress.

Other than nr_scanned and nr_reclaimed, some other counters, e.g.
pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
too since they are user visible via cgroup, /proc/vmstat or trace
points, otherwise they would be underreported.

When isolating pages from LRUs, nr_taken has been accounted in base
page, but nr_scanned and nr_skipped are still accounted in THP.  It
doesn't make too much sense too since this may cause trace point
underreport the numbers as well.

So accounting those counters in base page instead of accounting THP as
one page.

nr_dirty, nr_unqueued_dirty, nr_congested and nr_writeback are used by
file cache, so they are not impacted by THP swap.

This change may result in lower steal/scan ratio in some cases since
THP may get split during page reclaim, then a part of tail pages get
reclaimed instead of the whole 512 pages, but nr_scanned is accounted
by 512, particularly for direct reclaim.  But, this should be not a
significant issue.

Cc: "Huang, Ying" 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Mel Gorman 
Cc: "Kirill A . Shutemov" 
Cc: Hugh Dickins 
Cc: Shakeel Butt 
Signed-off-by: Yang Shi 
---
v4: Fixed the comments from Johannes and Huang Ying
v3: Removed Shakeel's Reviewed-by since the patch has been changed significantly
Switched back to use compound_order per Matthew
Fixed more counters per Johannes
v2: Added Shakeel's Reviewed-by
Use hpage_nr_pages instead of compound_order per Huang Ying and William 
Kucharski

 mm/vmscan.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b65bc50..1b35a7a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1118,6 +1118,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
int may_enter_fs;
enum page_references references = PAGEREF_RECLAIM_CLEAN;
bool dirty, writeback;
+   unsigned int nr_pages;
 
cond_resched();
 
@@ -1129,7 +1130,9 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
 
VM_BUG_ON_PAGE(PageActive(page), page);
 
-   sc->nr_scanned++;
+   /* Account the number of base pages evne though THP */
+   nr_pages = 1 << compound_order(page);
+   sc->nr_scanned += nr_pages;
 
if (unlikely(!page_evictable(page)))
goto activate_locked;
@@ -1250,7 +1253,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
case PAGEREF_ACTIVATE:
goto activate_locked;
case PAGEREF_KEEP:
-   stat->nr_ref_keep++;
+   stat->nr_ref_keep += nr_pages;
goto keep_locked;
case PAGEREF_RECLAIM:
case PAGEREF_RECLAIM_CLEAN:
@@ -1315,7 +1318,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (unlikely(PageTransHuge(page)))
flags |= TTU_SPLIT_HUGE_PMD;
if (!try_to_unmap(page, flags)) {
-   stat->nr_unmap_fail++;
+   stat->nr_unmap_fail += nr_pages;
goto activate_locked;
}
}
@@ -1442,7 +1445,11 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
 
unlock_page(page);
 free_it:
-   nr_reclaimed++;
+   /*
+* THP may get swapped out in a whole, need 

[v4 PATCH 1/2] mm: vmscan: remove double slab pressure by inc'ing sc->nr_scanned

[Yang Shi]

The commit 9092c71bb724 ("mm: use sc->priority for slab shrink targets")
has broken up the relationship between sc->nr_scanned and slab pressure.
The sc->nr_scanned can't double slab pressure anymore.  So, it sounds no
sense to still keep sc->nr_scanned inc'ed.  Actually, it would prevent
from adding pressure on slab shrink since excessive sc->nr_scanned would
prevent from scan->priority raise.

The bonnie test doesn't show this would change the behavior of
slab shrinkers.

w/  w/o
  /sec%CP  /sec  %CP
Sequential delete:  3960.694.63997.6 96.2
Random delete:  2518  63.82561.6 64.6

The slight increase of "/sec" without the patch would be caused by the
slight increase of CPU usage.

Cc: Josef Bacik 
Cc: Michal Hocko 
Acked-by: Johannes Weiner 
Signed-off-by: Yang Shi 
---
v4: Added Johannes's ack

 mm/vmscan.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7acd0af..b65bc50 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1137,11 +1137,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
 
-   /* Double the slab pressure for mapped and swapcache pages */
-   if ((page_mapped(page) || PageSwapCache(page)) &&
-   !(PageAnon(page) && !PageSwapBacked(page)))
-   sc->nr_scanned++;
-
may_enter_fs = (sc->gfp_mask & __GFP_FS) ||
(PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));
 
-- 
1.8.3.1

[PATCH v2] jbd2: fix some print format mistakes

[Gaowei Pu]

There are some print format mistakes in debug messages. Fix them.

Signed-off-by: Gaowei Pu 
Reviewed-by: Jan Kara 

V2: add Reviewed-by.
---
 fs/jbd2/journal.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 37e16d969925..565e99b67b30 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -203,7 +203,7 @@ static int kjournald2(void *arg)
if (journal->j_flags & JBD2_UNMOUNT)
goto end_loop;
 
-   jbd_debug(1, "commit_sequence=%d, commit_request=%d\n",
+   jbd_debug(1, "commit_sequence=%u, commit_request=%u\n",
journal->j_commit_sequence, journal->j_commit_request);
 
if (journal->j_commit_sequence != journal->j_commit_request) {
@@ -324,7 +324,7 @@ static void journal_kill_thread(journal_t *journal)
  * IO is in progress. do_get_write_access() handles this.
  *
  * The function returns a pointer to the buffer_head to be used for IO.
- * 
+ *
  *
  * Return value:
  *  <0: Error
@@ -500,7 +500,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
target)
 */
 
journal->j_commit_request = target;
-   jbd_debug(1, "JBD2: requesting commit %d/%d\n",
+   jbd_debug(1, "JBD2: requesting commit %u/%u\n",
  journal->j_commit_request,
  journal->j_commit_sequence);
journal->j_running_transaction->t_requested = jiffies;
@@ -513,7 +513,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
target)
WARN_ONCE(1, "JBD2: bad log_start_commit: %u %u %u %u\n",
  journal->j_commit_request,
  journal->j_commit_sequence,
- target, journal->j_running_transaction ? 
+ target, journal->j_running_transaction ?
  journal->j_running_transaction->t_tid : 0);
return 0;
 }
@@ -698,12 +698,12 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid)
 #ifdef CONFIG_JBD2_DEBUG
if (!tid_geq(journal->j_commit_request, tid)) {
printk(KERN_ERR
-  "%s: error: j_commit_request=%d, tid=%d\n",
+  "%s: error: j_commit_request=%u, tid=%u\n",
   __func__, journal->j_commit_request, tid);
}
 #endif
while (tid_gt(tid, journal->j_commit_sequence)) {
-   jbd_debug(1, "JBD2: want %d, j_commit_sequence=%d\n",
+   jbd_debug(1, "JBD2: want %u, j_commit_sequence=%u\n",
  tid, journal->j_commit_sequence);
read_unlock(>j_state_lock);
wake_up(>j_wait_commit);
@@ -944,7 +944,7 @@ int __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
 
trace_jbd2_update_log_tail(journal, tid, block, freed);
jbd_debug(1,
- "Cleaning journal tail from %d to %d (offset %lu), "
+ "Cleaning journal tail from %u to %u (offset %lu), "
  "freeing %lu\n",
  journal->j_tail_sequence, tid, block, freed);
 
@@ -1318,7 +1318,7 @@ static int journal_reset(journal_t *journal)
 */
if (sb->s_start == 0) {
jbd_debug(1, "JBD2: Skipping superblock update on recovered sb "
-   "(start %ld, seq %d, errno %d)\n",
+   "(start %ld, seq %u, errno %d)\n",
journal->j_tail, journal->j_tail_sequence,
journal->j_errno);
journal->j_flags |= JBD2_FLUSHED;
@@ -1453,7 +1453,7 @@ static void jbd2_mark_journal_empty(journal_t *journal, 
int write_op)
return;
}
 
-   jbd_debug(1, "JBD2: Marking journal as empty (seq %d)\n",
+   jbd_debug(1, "JBD2: Marking journal as empty (seq %u)\n",
  journal->j_tail_sequence);
 
sb->s_sequence = cpu_to_be32(journal->j_tail_sequence);
-- 
2.21.0

mainline/master boot bisection: v5.2-rc1-165-g54dee406374c on rk3288-veyron-jaq

[kernelci.org bot]

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis  *
* that you may be involved with the breaking commit it has  *
* found.  No manual investigation has been done to verify it,   *
* and the root cause of the problem may be somewhere else.  *
* Hope this helps!  *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

mainline/master boot bisection: v5.2-rc1-165-g54dee406374c on rk3288-veyron-jaq

Summary:
  Start:  54dee406374c Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
  Details:https://kernelci.org/boot/id/5ce5984c59b514e6a47a364c
  Plain log:  
https://storage.kernelci.org//mainline/master/v5.2-rc1-165-g54dee406374c/arm/multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.txt
  HTML log:   
https://storage.kernelci.org//mainline/master/v5.2-rc1-165-g54dee406374c/arm/multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.html
  Result: 28694e009e51 thermal: rockchip: fix up the tsadc pinctrl setting 
error

Checks:
  revert: PASS
  verify: PASS

Parameters:
  Tree:   mainline
  URL:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  Branch: master
  Target: rk3288-veyron-jaq
  CPU arch:   arm
  Lab:lab-collabora
  Compiler:   gcc-8
  Config: multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y
  Test suite: boot

Breaking commit found:

---
commit 28694e009e512451ead5519dd801f9869acb1f60
Author: Elaine Zhang 
Date:   Tue Apr 30 18:09:44 2019 +0800

thermal: rockchip: fix up the tsadc pinctrl setting error

Explicitly use the pinctrl to set/unset the right mode
instead of relying on the pinctrl init mode.
And it requires setting the tshut polarity before select pinctrl.

When the temperature sensor mode is set to 0, it will automatically
reset the board via the Clock-Reset-Unit (CRU) if the over temperature
threshold is reached. However, when the pinctrl initializes, it does a
transition to "otp_out" which may lead the SoC restart all the time.

"otp_out" IO may be connected to the RESET circuit on the hardware.
If the IO is in the wrong state, it will trigger RESET.
(similar to the effect of pressing the RESET button)
which will cause the soc to restart all the time.

Signed-off-by: Elaine Zhang 
Reviewed-by: Daniel Lezcano 
Signed-off-by: Eduardo Valentin 

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 9c7643d62ed7..6dc7fc516abf 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -172,6 +172,9 @@ struct rockchip_thermal_data {
int tshut_temp;
enum tshut_mode tshut_mode;
enum tshut_polarity tshut_polarity;
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *gpio_state;
+   struct pinctrl_state *otp_state;
 };
 
 /**
@@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
return error;
}
 
+   thermal->chip->control(thermal->regs, false);
+
error = clk_prepare_enable(thermal->clk);
if (error) {
dev_err(>dev, "failed to enable converter clock: %d\n",
@@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
thermal->chip->initialize(thermal->grf, thermal->regs,
  thermal->tshut_polarity);
 
+   if (thermal->tshut_mode == TSHUT_MODE_GPIO) {
+   thermal->pinctrl = devm_pinctrl_get(>dev);
+   if (IS_ERR(thermal->pinctrl)) {
+   dev_err(>dev, "failed to find thermal pinctrl\n");
+   return PTR_ERR(thermal->pinctrl);
+   }
+
+   thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl,
+  "gpio");
+   if (IS_ERR_OR_NULL(thermal->gpio_state)) {
+   dev_err(>dev, "failed to find thermal gpio 
state\n");
+   return -EINVAL;
+   }
+
+   thermal->otp_state = pinctrl_lookup_state(thermal->pinctrl,
+ "otpout");
+   if (IS_ERR_OR_NULL(thermal->otp_state)) {
+   dev_err(>dev, "failed to find thermal otpout 
state\n");
+   return -EINVAL;
+   }
+
+   pinctrl_select_state(thermal->pinctrl, thermal->otp_state);
+   }
+
for (i = 0; i < thermal->chip->chn_num; i++) {
error = rockchip_thermal_register_sensor(pdev, thermal,
>sensors[i],
@@ -1337,8 

RE:Re: [PATCH v4 00/14] add ecspi ERR009165 for i.mx6/7 soc family

[Robin Gong]

> -Original Message-
> From: Lucas Stach 
> Sent: 2019年5月22日 18:10
> Hi Robin,
> 
> Am Mittwoch, den 22.05.2019, 09:59 + schrieb Robin Gong:
> >   There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > transfer to be send twice in DMA mode. Please get more information from:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> 
> I haven't tested this so asking the obvious question: what happens when this
> series is applied without the RAM script being present on the system? Will it
> render SPI unusable? I guess so since it changes the flow between the SPI core
> and DMA controller. Can we somehow detect that SDMA isn't using the correct
> RAM script and fall back to PIO mode in the SPI driver in that case?
> 
> Currently using the RAM script is not an option in a lot of use-cases, as it 
> still
> breaks serial DMA support. The fix for the serial issue really needs to be
> remove the broken serial script from the RAM firmware, not change the serial
> driver to deal with the broken behavior introduced by the RAM script.
Okay, I'll try to merge another patch which fix UART driver function broken 
issue with ram script so that no any broken for this patch set.
> 
> Regards,
> Lucas

[PATCH] sched: fix "runnable_avg_yN_inv" not used warnings

[Qian Cai]

runnable_avg_yN_inv[] is only used in kernel/sched/pelt.c but was
included in several other places and causes compilation warnings,

In file included from kernel/sched/pelt.h:2,
 from kernel/sched/rt.c:8:
kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined
but not used [-Wunused-const-variable=]
In file included from kernel/sched/pelt.h:2,
 from kernel/sched/fair.c:705:
kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined
but not used [-Wunused-const-variable=]
In file included from kernel/sched/pelt.h:2,
 from kernel/sched/deadline.c:19:
kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined
but not used [-Wunused-const-variable=]

Fixed it by appending the __maybe_unused attribute for it, so all
generated variables and macros can still be kept in the same file.

Signed-off-by: Qian Cai 
---
 Documentation/scheduler/sched-pelt.c | 2 +-
 kernel/sched/sched-pelt.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/scheduler/sched-pelt.c 
b/Documentation/scheduler/sched-pelt.c
index e4219139386a..6c10b8764533 100644
--- a/Documentation/scheduler/sched-pelt.c
+++ b/Documentation/scheduler/sched-pelt.c
@@ -20,7 +20,7 @@ void calc_runnable_avg_yN_inv(void)
int i;
unsigned int x;
 
-   printf("static const u32 runnable_avg_yN_inv[] = {");
+   printf("static const u32 runnable_avg_yN_inv[] __maybe_unused = {");
for (i = 0; i < HALFLIFE; i++) {
x = ((1UL<<32)-1)*pow(y, i);
 
diff --git a/kernel/sched/sched-pelt.h b/kernel/sched/sched-pelt.h
index a26473674fb7..c529706bed11 100644
--- a/kernel/sched/sched-pelt.h
+++ b/kernel/sched/sched-pelt.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /* Generated by Documentation/scheduler/sched-pelt; do not modify. */
 
-static const u32 runnable_avg_yN_inv[] = {
+static const u32 runnable_avg_yN_inv[] __maybe_unused = {
0x, 0xfa83b2da, 0xf5257d14, 0xefe4b99a, 0xeac0c6e6, 0xe5b906e6,
0xe0ccdeeb, 0xdbfbb796, 0xd744fcc9, 0xd2a81d91, 0xce248c14, 0xc9b9bd85,
0xc5672a10, 0xc12c4cc9, 0xbd08a39e, 0xb8fbaf46, 0xb504f333, 0xb123f581,
-- 
2.20.1 (Apple Git-117)

RE: [EXT] Re: [PATCH v4 10/14] dma: imx-sdma: add i.mx6ul/6sx compatible name

[Robin Gong]

Hi Rob,
Thank you for your reminding, I have added Acked-by tags gotten from 
Mark and Vinod in v4 patch set, but there is still one update (
remove checking 'event_id1' zero as 'event_id0'.) for Vinod's concern, so I 
sent new v4.
> -Original Message-
> From: Rob Herring 
> Sent: 2019年5月22日 21:51> 
> On Wed, 22 May 2019 10:00:38 +, Robin Gong wrote:
> > Add i.mx6ul and i.mx6sx compatible name in binding doc.
> >
> > Signed-off-by: Robin Gong 
> > ---
> >  Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.

From: Mr.Ahmed Owain

[Mr.Ahmed Owain]

Good Day,

Please accept my apologies for writing you a surprise letter.I am
Mr.Ahmed Owain, account Manager with an investment bank here in
Burkina Faso.I have a very important business I want to discuss with
you.There is a draft account opened in my firm by a long-time client
of our bank.I have the opportunity of transferring the left over fund
(15.8 Million UsDollars)Fiftheen Million Eight Hundred Thousand United
States of American Dollars of one of my Bank clients who died at the
collapsing of the world trade center at the United States on September
11th 2001.

I want to invest this funds and introduce you to our bank for this
deal.All I require is your honest co-operation and I guarantee you
that this will be executed under a legitimate arrangement that will
protect us from any breach of the law.I agree that 40% of this money
will be for you as my foreign partner,50% for me while 10% is for
establishing of foundation for the less privilleges in your country.If
you are really interested in my proposal further details of the
Transfer will be forwarded unto you as soon as I receive your
willingness mail for a successful transfer.

Yours Sincerely,
Mr.Ahmed Owain,

Re: [PATCH RFC v8 01/10] namei: obey trailing magic-link DAC permissions

[Aleksa Sarai]

On 2019-05-22, Andy Lutomirski  wrote:
> On Mon, May 20, 2019 at 6:34 AM Aleksa Sarai  wrote:
> > One final exception is given, which is that non-O_PATH file descriptors
> > are given re-open rights equivalent to the permissions available at
> > open-time. This allows for O_RDONLY file descriptors to be re-opened
> > O_RDWR as long as the user had MAY_WRITE access at the time of opening
> > the O_RDONLY descriptor. This is necessary to avoid breaking userspace
> > (some of the kernel's own selftests depended on this "feature").
> 
> Can you clarify this exception a bit?  I'd like to make sure it's not
> such a huge exception that it invalidates the whole point of the
> patch.

Sure. This exception applies to regular file opens, and the idea is that
the user had permissions to open the file O_RDWR originally (even if
they opened it O_RDONLY) so re-opening it O_RDWR later should not be an
issue (they could've just opened it O_RDWR in the first place). These
permissions still get masked by nd->opath_mask, so opening a magic-link
or including an O_PATH doesn't increase the permission set.

This does mean that an O_RDONLY open (if the user could've done an
O_RDWR and still done the open) results in an FMODE_PATH_WRITE. To be
honest, I'm still on the fence whether this is a great idea or not (and
I'd prefer to not include it). Though, I don't think it invalidates the
patch though, since the attack scenario of a read-only file being
re-opened later as read-write is still blocked.

The main reason for including it is the concern that there is some
program from 1993 running in a basement somewhere that depends on this
that we don't know about. Though, as a counter-example, I have run this
patchset (without this exception) on my laptop for a few days without
any visible issues.

> If you open a file for execute, by actually exec()ing it or by using
> something like the proposed O_MAYEXEC, and you have inode_permission
> to write, do you still end up with FMODE_PATH_WRITE? The code looks
> like it does, and this seems like it might be a mistake.

I'm not sure about the execve(2) example -- after all, you don't get an
fd from execve(2) and /proc/self/exe still has a mode a+rx.

I'm also not sure what the semantics of a hypothetical O_MAYEXEC would
be -- but we'd probably want to discuss re-opening semantics when it
gets included. I would argue that since O_MAYEXEC would likely be merged
after this, no userspace code would depend on this mis-feature and we
could decide to not include FMODE_EXECv2 in the handling of additional
permissions.

As an aside, I did originally implement RESOLVE_UPGRADE_NOEXEC (and the
corresponding FMODE_PATH_EXEC handling). It worked for the most part,
though execveat(AT_EMPTY_PATH) would need some additional changes to do
the may_open_magiclink() checks and I decided against including it here
until we had an O_MAYEXEC.

> Is there any way for user code to read out these new file mode bits?

There is, but it's not exactly trivial. You could check the mode of
/proc/self/fd and then compare it to the acc_mode of the "flags"
/proc/self/fdinfo. The bits present in /proc/self/fd but not in acc_mode
are the FMODE_PATH_* bits.

However, this is quite an ugly way of doing it. I see two options to
make it easier:

 1. We can add additional information to fdinfo so it includes that
FMODE_PATH_* bits to indicate how the fd can be upgraded.

 2. Previously, only the u bits of the fd mode were used to represent the
open flags. We could add the FMODE_PATH_* permissions to the g bits
and change how the permission check in trailing_symlink() operates.

The really neat thing here is that we could then know for sure which
fmode bits are set during name lookup of a magic-link rather than
assuming they're all FMODE_PATH_* bits.

In addition, userspace that depends on checking the u bits of an fd
mode would continue to work (though I'm not aware of any userspace
code that does depend on this).

Option 2 seems nicer to me in some respects, but it has the additional
cost of making the permission check less obvious (it's no longer an
"inode_permission" and is instead something different with a weird new
set of semantics). Then again, the modes of magic-links weren't obeyed
in the first place so I'd argue these semantics are entirely up for us
to decide.

> What are actual examples of uses for this exception?  Breaking
> selftests is not, in and of itself, a huge problem.

Not as far as I know. All of the re-opening users I know of do re-opens
of O_PATH or are re-opening with the same (or fewer) privileges. I also
ran this for a few days on my laptop without this exception, and didn't
have any visible issues.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH] MIPS: remove a space after -I to cope with header search paths for VDSO

[Paul Burton]

Hello,

Masahiro Yamada wrote:
> Commit 9cc342f6c4a0 ("treewide: prefix header search paths with
> $(srctree)/") caused a build error for MIPS VDSO.
> 
> CC  arch/mips/vdso/gettimeofday.o
> In file included from ../arch/mips/vdso/vdso.h:26,
> from ../arch/mips/vdso/gettimeofday.c:11:
> ../arch/mips/include/asm/page.h:12:10: fatal error: spaces.h: No such file or 
> directory
> #include 
> ^~
> 
> The cause of the error is a missing space after the compiler flag -I .
> 
> Kbuild used to have a global restriction "no space after -I", but
> commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter") got
> rid of it. Having a space after -I is no longer a big deal as far as
> Kbuild is concerned.
> 
> It is still a big deal for MIPS because arch/mips/vdso/Makefile
> filters the header search paths, like this:
> 
> ccflags-vdso :=   $(filter -I%,$(KBUILD_CFLAGS))
> ..., which relies on the assumption that there is no space after -I .
> 
> Fixes: 9cc342f6c4a0 ("treewide: prefix header search paths with $(srctree)/")
> Reported-by: kbuild test robot 
> Signed-off-by: Masahiro Yamada 

Applied to mips-fixes.

Thanks,
Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.bur...@mips.com to report it. ]

Re: -Wuninitialized warning in drivers/misc/sgi-xp/xpc_partition.c

[Nathan Chancellor]

On Thu, May 02, 2019 at 08:33:40PM -0700, Nathan Chancellor wrote:
> Hi all,
> 
> When building with -Wuninitialized, Clang warns:
> 
> drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is 
> uninitialized when used within its own initialization [-Wuninitialized]
> void *buf = buf;
>   ~~~   ^~~
> 1 warning generated.
> 
> I am not really sure how to properly initialize buf in this instance.
> I would assume it would involve xpc_kmalloc_cacheline_aligned like
> further down in the function but maybe not, this function isn't entirely
> clear. Could we get your input, this is one of the last warnings I see
> in a few allyesconfig builds.
> 
> Thanks,
> Nathan

Hi all,

Friendly ping for comments/input. This is one of a few remaining
warnings I see, it'd be nice to get it fixed up so we can turn it on for
the whole kernel.

Cheers,
Nathan

Re: [PATCH] MIPS: TXx9: Fix boot crash in free_initmem()

[Paul Burton]

Hello,

Geert Uytterhoeven wrote:
> On rbtx4927:
> 
> BUG: Bad page state in process swapper  pfn:1
> page:804b7820 refcount:0 mapcount:-128 mapping: index:0x1
> flags: 0x0()
> raw:  0100 0200  0001  ff7f 
> page dumped because: nonzero mapcount
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 
> 5.2.0-rc1-rbtx4927-00468-g3c05ea3d4077b756 #141
> Stack :  10008400 8040dc4c 87c1b974 8044af63 8040dc4c 0001 
> 804a3490
> 0001 8100 0030f231 80148558 0003 10008400 87c1dd80 3d0f9a2c
>   804b  0007  0081 
> 62722d31 0080 804b 39347874  804b7820 8040ce18 8110
> 0001 0007 0001 8100 0018 8021de24  804a
> ...
> Call Trace:
> [<8010adec>] show_stack+0x74/0x104
> [<801a5e44>] bad_page+0x130/0x138
> [<801a654c>] free_pcppages_bulk+0x17c/0x3b0
> [<801a789c>] free_unref_page+0x40/0x68
> [<801120f4>] free_init_pages+0xec/0x104
> [<803bdde8>] free_initmem+0x10/0x58
> [<803bdb8c>] kernel_init+0x20/0x100
> [<801057c8>] ret_from_kernel_thread+0x14/0x1c
> 
> As of commit b93ddc4f9156205e ("mips: Reserve memory for the kernel
> image resources"), bootmem_init() no longer reserves the memory below
> the kernel, while prom_free_prom_memory() still frees it.
> 
> Fix this by reverting commit b6263ff2d6e58cc2 ("MIPS: TXx9: Implement
> prom_free_prom_memory").
> 
> Suggested-by: Serge Semin 
> Fixes: b93ddc4f9156205e ("mips: Reserve memory for the kernel image 
> resources")
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Atsushi Nemoto 

Applied to mips-fixes.

Thanks,
Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.bur...@mips.com to report it. ]

Re: [PATCH] MIPS: mark ginvt() as __always_inline

[Paul Burton]

Hello,

Masahiro Yamada wrote:
> To meet the 'i' (immediate) constraint for the asm operands,
> this function must be always inlined.
> 
> Signed-off-by: Masahiro Yamada 

Applied to mips-fixes.

Thanks,
Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.bur...@mips.com to report it. ]

Re: [PATCH] rsi: Properly initialize data in rsi_sdio_ta_reset

[Nathan Chancellor]

On Thu, May 02, 2019 at 08:17:18PM -0700, Nathan Chancellor wrote:
> On Thu, May 02, 2019 at 11:18:01AM -0700, Nick Desaulniers wrote:
> > On Thu, May 2, 2019 at 8:16 AM Nathan Chancellor
> >  wrote:
> > >
> > > When building with -Wuninitialized, Clang warns:
> > >
> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data'
> > > is uninitialized when used here [-Wuninitialized]
> > > put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
> > >  ^~~~
> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the
> > > variable 'data' to silence this warning
> > > u8 *data;
> > > ^
> > >  = NULL
> > > 1 warning generated.
> > >
> > > Using Clang's suggestion of initializing data to NULL wouldn't work out
> > > because data will be dereferenced by put_unaligned_le32. Use kzalloc to
> > > properly initialize data, which matches a couple of other places in this
> > > driver.
> > >
> > > Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device")
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/464
> > > Signed-off-by: Nathan Chancellor 
> > > ---
> > >  drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 ++---
> > >  1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
> > > b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > index f9c67ed473d1..b35728564c7b 100644
> > > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > @@ -929,11 +929,15 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> > > u32 addr;
> > > u8 *data;
> > >
> > > +   data = kzalloc(sizeof(u32), GFP_KERNEL);
> > 
> > Something fishy is going on here.  We allocate 4 B but declare data as
> > a u8* (pointer to individual bytes)?  In general, dynamically
> > allocating that few bytes is a code smell; either you meant to just
> > use the stack, or this memory's lifetime extends past the lifetime of
> > this stackframe, at which point you probably just meant to stack
> > allocate space in a higher parent frame and pass this preallocated
> > memory down to the child frame to get filled in.
> > 
> > Reading through this code, I don't think that the memory is meant to
> > outlive the stack frame.  Is there a reason why we can't just declare
> > data as:
> > 
> > u8 data [4];
> 
> data was __le32 in rsi_reset_chip() before commit f700546682a6 ("rsi:
> fix nommu_map_sg overflow kernel panic").
> 
> I wonder if this would be okay for this function:
> 
> -
> 
> diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
> b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> index f9c67ed473d1..0330c50ab99c 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> @@ -927,7 +927,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>  {
> int status;
> u32 addr;
> -   u8 *data;
> +   u8 data;
>  
> status = rsi_sdio_master_access_msword(adapter, TA_BASE_ADDR);
> if (status < 0) {
> @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> }
>  
> rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__);
> -   put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
> +   put_unaligned_le32(TA_HOLD_THREAD_VALUE, );
> addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
>   (u8 *),
> @@ -947,7 +947,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return status;
> }
>  
> -   put_unaligned_le32(TA_SOFT_RST_CLR, data);
> +   put_unaligned_le32(TA_SOFT_RST_CLR, );
> addr = TA_SOFT_RESET_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
>   (u8 *),
> @@ -957,7 +957,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return status;
> }
>  
> -   put_unaligned_le32(TA_PC_ZERO, data);
> +   put_unaligned_le32(TA_PC_ZERO, );
> addr = TA_TH0_PC_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
>   (u8 *),
> @@ -967,7 +967,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return -EINVAL;
> }
>  
> -   put_unaligned_le32(TA_RELEASE_THREAD_VALUE, data);
> +   put_unaligned_le32(TA_RELEASE_THREAD_VALUE, );
> addr = TA_RELEASE_THREAD_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
>   (u8 *),
> 
> 
> > 
> > then use ARRAY_SIZE(data) or RSI_9116_REG_SIZE in rsi_reset_chip(),
> > getting rid of 

Re: [PATCH] kbuild: Enable -Wsometimes-uninitialized

[Nathan Chancellor]

On Tue, Apr 30, 2019 at 11:46:44AM +0200, Arnd Bergmann wrote:
> Ah, I thought they were all fixed, as I don't see any remaining warnings
> in my tree. It seems that I never send this workaround for
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK:
> 
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 5f3efabc36f4..cbe1ea0fce84 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -68,8 +68,15 @@ extern void __init_waitqueue_head(struct
> wait_queue_head *wq_head, const char *n
> } while (0)
> 
>  #ifdef CONFIG_LOCKDEP
> -# define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \
> -   ({ init_waitqueue_head(); name; })
> +# define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) {
>  \
> +   .lock   = __SPIN_LOCK_UNLOCKED(name.lock),
>  \
> +   .head   = ({
>  \
> +   static struct lock_class_key __key;
>  \
> +   lockdep_set_class_and_name(&(name).lock, &__key, #
> name);   \
> +   (struct list_head){ &(name).head, &(name).head };
>  \
> +   }),
>  \
> +}
> +
>  # define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
>  #else
> 
> Are there any others you see?
> 
>   Arnd

Hi Arnd,

Were you planning on sending this out for review? It would be nice to
get these fixed so we can get this warning enabled.

I am bumping the other patches/inquiries I have sent now.

Cheers,
Nathan

[PATCHv3] arm64: dts: ls1028a: add flexspi nodes

[Xiaowei Bao]

From: Xiaowei Bao 

Add fspi node property for LS1028A SoC for FlexSPI driver.
Property added for the FlexSPI controller and for the connected
slave device for the LS1028ARDB and LS1028AQDS target.
This is having one SPI-NOR flash device, mt35xu02g connected at
CS0.

Signed-off-by: Xiaowei Bao 
---
v3:
 - move the "spansion,m25p80" compatible property to the top.

 arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts |   15 +++
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts |   15 +++
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi|   12 
 3 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 5c3ff43..b8cabd3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -166,6 +166,21 @@
};
 };
 
+ {
+   status = "okay";
+   mt35xu02g: flash@0 {
+   compatible = "spansion,m25p80";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   m25p,fast-read;
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   /* The following setting enables 1-1-8 (CMD-ADDR-DATA) mode */
+   spi-rx-bus-width = <8>; /* 8 SPI Rx lines */
+   spi-tx-bus-width = <1>; /* 1 SPI Tx line */
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index f7d4da6..b5e052c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -152,6 +152,21 @@
};
 };
 
+ {
+   status = "okay";
+   mt35xu02g: flash@0 {
+   compatible = "spansion,m25p80";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   m25p,fast-read;
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   /* The following setting enables 1-1-8 (CMD-ADDR-DATA) mode */
+   spi-rx-bus-width = <8>; /* 8 SPI Rx lines */
+   spi-tx-bus-width = <1>; /* 1 SPI Tx line */
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index e8095cf..06d9c90 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -189,6 +189,18 @@
snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
 
+   fspi: spi@20c {
+   compatible = "nxp,lx2160a-fspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+   reg-names = "FSPI", "FSPI-memory";
+   interrupts = <0 25 0x4>; /* Level high type */
+   clocks = < 4 3>, < 4 3>;
+   clock-names = "fspi_en", "fspi";
+   };
+
i2c0: i2c@200 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
-- 
1.7.1

Re: [PATCH v2] kasan: Initialize tag to 0xff in __kasan_kmalloc

[Nathan Chancellor]

On Thu, May 02, 2019 at 06:40:52PM +0200, Andrey Konovalov wrote:
> On Thu, May 2, 2019 at 6:31 PM Nathan Chancellor
>  wrote:
> >
> > When building with -Wuninitialized and CONFIG_KASAN_SW_TAGS unset, Clang
> > warns:
> >
> > mm/kasan/common.c:484:40: warning: variable 'tag' is uninitialized when
> > used here [-Wuninitialized]
> > kasan_unpoison_shadow(set_tag(object, tag), size);
> >   ^~~
> >
> > set_tag ignores tag in this configuration but clang doesn't realize it
> > at this point in its pipeline, as it points to arch_kasan_set_tag as
> > being the point where it is used, which will later be expanded to
> > (void *)(object) without a use of tag. Initialize tag to 0xff, as it
> > removes this warning and doesn't change the meaning of the code.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/465
> > Signed-off-by: Nathan Chancellor 
> 
> Reviewed-by: Andrey Konovalov 
> 
> Thanks!
> 

Thanks Andrey! Did anyone else have any other comments or can this be
picked up?

Cheers,
Nathan

Re: [PATCH] regulator: max77650: Move max77651_SBB1_desc's declaration down

[Axel Lin]

Nathan Chancellor  於 2019年5月23日 週四 上午9:27寫道：
>
> Clang warns:
>
> drivers/regulator/max77650-regulator.c:32:39: warning: tentative
> definition of variable with internal linkage has incomplete non-array
> type 'struct max77650_regulator_desc'
> [-Wtentative-definition-incomplete-type]
> static struct max77650_regulator_desc max77651_SBB1_desc;
>   ^
> drivers/regulator/max77650-regulator.c:32:15: note: forward declaration
> of 'struct max77650_regulator_desc'
> static struct max77650_regulator_desc max77651_SBB1_desc;
>   ^
> 1 warning generated.
>
> Move max77651_SBB1_desc's declaration below max77650_regulator_desc's
> definition so this warning does not happen.
>
> Fixes: 3df4235ac41c ("regulator: max77650: Convert MAX77651 SBB1 to pickable 
> linear range")
> Link: https://github.com/ClangBuiltLinux/linux/issues/491
> Signed-off-by: Nathan Chancellor 
Reviewed-by: Axel Lin 

[PATCH] scsi: hpsa: Avoid using dev uninitialized in hpsa_eh_device_reset_handler

[Nathan Chancellor]

Clang warns:

drivers/scsi/hpsa.c:5964:6: warning: variable 'dev' is used
uninitialized whenever 'if' condition is true
[-Wsometimes-uninitialized]
if (lockup_detected(h)) {
^~
drivers/scsi/hpsa.c:6042:6: note: uninitialized use occurs here
if (dev)
^~~
drivers/scsi/hpsa.c:5964:2: note: remove the 'if' if its condition is
always false
if (lockup_detected(h)) {
^
drivers/scsi/hpsa.c:5950:29: note: initialize the variable 'dev' to
silence this warning
struct hpsa_scsi_dev_t *dev;
   ^
= NULL
1 warning generated.

dev is potentially used uninitialized in the return_reset_status block
for a NULL check if the first 'if (lockup_detected(h))' is taken, as
dev is initialized right after that block. Initialize dev to NULL in
its declaration so that it can be safely checked within the
return_reset_status block.

Fixes: 14991a5bade5 ("scsi: hpsa: correct device resets")
Link: https://github.com/ClangBuiltLinux/linux/issues/492
Signed-off-by: Nathan Chancellor 
---
 drivers/scsi/hpsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index c560a4532733..ac8338b0571b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -5947,7 +5947,7 @@ static int hpsa_eh_device_reset_handler(struct scsi_cmnd 
*scsicmd)
int rc = SUCCESS;
int i;
struct ctlr_info *h;
-   struct hpsa_scsi_dev_t *dev;
+   struct hpsa_scsi_dev_t *dev = NULL;
u8 reset_type;
char msg[48];
unsigned long flags;
-- 
2.22.0.rc1

Re: [PATCH v3 1/3] thermal: rockchip: fix up the tsadc pinctrl setting error

[elaine.zhang]

hi, Heiko & Enric:

在 2019/5/22 下午8:27, Heiko Stuebner 写道:

Hi Enric,

Am Montag, 20. Mai 2019, 15:38:32 CEST schrieb Enric Balletbo Serra:

Hi all,

As pointed by [1] and [2] this commit, that now is upstream, breaks
veyron (rk3288) and kevin (rk3399) boards. The problem is especially
critical for veyron boards because they don't boot anymore.

I didn't look deep at the problem but I have some concerns about this
patch, see below.

[1] https://www.spinics.net/lists/linux-rockchip/msg24657.html
[2] https://www.spinics.net/lists/linux-rockchip/msg24735.html

Missatge de Daniel Lezcano  del dia dt., 30
d’abr. 2019 a les 15:39:

On 30/04/2019 12:09, Elaine Zhang wrote:

Explicitly use the pinctrl to set/unset the right mode
instead of relying on the pinctrl init mode.
And it requires setting the tshut polarity before select pinctrl.

When the temperature sensor mode is set to 0, it will automatically
reset the board via the Clock-Reset-Unit (CRU) if the over temperature
threshold is reached. However, when the pinctrl initializes, it does a
transition to "otp_out" which may lead the SoC restart all the time.

"otp_out" IO may be connected to the RESET circuit on the hardware.
If the IO is in the wrong state, it will trigger RESET.
(similar to the effect of pressing the RESET button)
which will cause the soc to restart all the time.

Signed-off-by: Elaine Zhang 

Reviewed-by: Daniel Lezcano 




---
  drivers/thermal/rockchip_thermal.c | 36 +---
  1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 9c7643d62ed7..6dc7fc516abf 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -172,6 +172,9 @@ struct rockchip_thermal_data {
   int tshut_temp;
   enum tshut_mode tshut_mode;
   enum tshut_polarity tshut_polarity;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *gpio_state;
+ struct pinctrl_state *otp_state;
  };

  /**
@@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
   return error;
   }

+ thermal->chip->control(thermal->regs, false);
+

That's the line that causes the hang. Commenting this makes the veyron
boot again. Probably this needs to go after chip->initialize?

It needs to go after the clk_enable calls.
At this point the tsadc may still be unclocked.


The clk is enable by default.


The reason for this modification:

The otp Pin polarity setting for tsadc must be set when tsadc is turned off.

The order:

Close the tsadc->Set the otp pin polarity ->Set the pinctrl->initialize 
the tsadc->Open the tsadc



As for the problem you mentioned, I guess: The default polarity of otp 
does not match the default state, that is, the otp is triggered by 
default, and then the reset circuit of the hardware takes effect and is 
restarted all the time.

Modification:
1. For this hardware, otp pin default state is modified.
2. The mode of using CRU is rockchip,hw-tshut-mode = <0> in DTS;
/* tshut mode 0:CRU 1:GPIO */

Recommended use method 2. You can try it.




   error = clk_prepare_enable(thermal->clk);
   if (error) {
   dev_err(>dev, "failed to enable converter clock: %d\n",
@@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
   thermal->chip->initialize(thermal->grf, thermal->regs,
 thermal->tshut_polarity);

+ if (thermal->tshut_mode == TSHUT_MODE_GPIO) {
+ thermal->pinctrl = devm_pinctrl_get(>dev);
+ if (IS_ERR(thermal->pinctrl)) {
+ dev_err(>dev, "failed to find thermal pinctrl\n");
+ return PTR_ERR(thermal->pinctrl);
+ }
+
+ thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl,
+"gpio");

Shouldn't this mode be documented properly in the binding first?

More importantly, it should be _backwards-compatible_, aka work with
old devicetrees without that property and not break thermal handling for
them entirely.
If need  _backwards-compatible_,  It's can't return 
PTR_ERR(thermal->pinctrl) when get


devm_pinctrl_get failed.




The binding [3] talks about init, default and sleep states but *not*
gpio and otpout. The patch series looks incomplete to me or not using
the proper names.

[3] 
https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt


+ if (IS_ERR_OR_NULL(thermal->gpio_state)) {
+ dev_err(>dev, "failed to find thermal gpio 
state\n");
+ return -EINVAL;
+ }
+
+ thermal->otp_state = pinctrl_lookup_state(thermal->pinctrl,
+   "otpout");
+ if (IS_ERR_OR_NULL(thermal->otp_state)) {
+ dev_err(>dev, "failed to 

Re: [PATCH 1/6] staging: kpc2000: make kconfig symbol 'KPC2000' select dependencies

[Geordan Neukum]

On Wed, May 22, 2019 at 12:27 PM Greg Kroah-Hartman
 wrote:
> depends on is better than select.  There's a change to depend on UIO for
> this code already in my -linus branch which will show up in Linus's tree
> in a week or so.

Noted on both accounts. Thanks for the feedback and sorry for the
inconvenience on the latter.

> Are you sure we need MFD_CORE as well for this code?

I noticed the build issue when working locally. I was doing
something along the lines of: 'make distclean && make x86_64_defconfig',
selecting 'CONFIG_KPC2000' and 'CONFIG_UIO' via menuconfig, then
running a good old 'make'. From make, I received an error along the
lines of:

ERROR: "mfd_remove_devices"
[drivers/staging/kpc2000/kpc2000/kpc2000.ko] undefined!
ERROR: "mfd_add_devices" [drivers/staging/kpc2000/kpc2000/kpc2000.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
make: *** [Makefile:1290: modules] Error 2

which appears to indicate that those two symbols are undefined. When
I looked, it appeared that those symbols were exported from the
mfd-core which is why I also threw in a select for that Kconfig
symbol. Assuming that I didn't do something silly above, I'd be happy
to submit a new patch (with only a depends on for MFD_CORE) as I
continue trying to fix up the i2c driver.

>Why hasn't that been seen on any build errors?

To be honest, I can't say that I'm familiar with all of the different
build bots out there so I can't even begin to speculate on that one.
If someone could point me in the right direction there, I'd be happy
to investigate further.

Thanks again for your feedback all,
Geordan Neukum

Re: [PATCH V1 00/12] LP0 entry and exit support for Tegra210

[Sowjanya Komatineni]

HI All

Sorry. Please ignore this as it was sent out accidentally

thanks

sowjanya

On 5/22/19 6:28 PM, Sowjanya Komatineni wrote:

This patch series includes Tegra210 deepsleep or LP0 support with
deep sleep exit through RTC alarm wake and power button wake events.

This series also includes save and restore of PLLs, clocks, OSC contexts
for basic LP0 exit.

This patch series is doesn't support for 100% suspend/resume to fully
functional state and we are working on some more drivers suspend and
resume implementations.

Sowjanya Komatineni (12):
   irqchip: tegra: do not disable COP IRQ during suspend
   pinctrl: tegra: add suspend and resume support
   clk: tegra: save and restore PLLs state for system
   clk: tegra: add support for peripheral clock suspend and resume
   clk: tegra: add support for OSC clock resume
   clk: tegra: add suspend resume support for DFLL clock
   clk: tegra: support for Tegra210 clocks suspend-resume
   soc/tegra: pmc: allow support for more tegra wake models
   soc/tegra: pmc: add pmc wake support for tegra210
   gpio: tegra: implement wake event support for Tegra210 and prior GPIO
   soc/tegra: pmc: configure tegra deep sleep control settings
   arm64: tegra: enable wake from deep sleep on RTC alarm.

  arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi |   7 +
  arch/arm64/boot/dts/nvidia/tegra210.dtsi   |   5 +-
  drivers/clk/tegra/clk-dfll.c   |  82 ++
  drivers/clk/tegra/clk-dfll.h   |   2 +
  drivers/clk/tegra/clk-divider.c|  19 ++
  drivers/clk/tegra/clk-pll-out.c|  25 ++
  drivers/clk/tegra/clk-pll.c| 220 --
  drivers/clk/tegra/clk-tegra-fixed.c|  15 +
  drivers/clk/tegra/clk-tegra210.c   | 382 +
  drivers/clk/tegra/clk.c|  74 -
  drivers/clk/tegra/clk.h|  18 ++
  drivers/gpio/gpio-tegra.c  | 109 ++-
  drivers/irqchip/irq-tegra.c|  10 +-
  drivers/pinctrl/tegra/pinctrl-tegra.c  |  68 -
  drivers/pinctrl/tegra/pinctrl-tegra.h  |   3 +
  drivers/pinctrl/tegra/pinctrl-tegra114.c   |   1 +
  drivers/pinctrl/tegra/pinctrl-tegra124.c   |   1 +
  drivers/pinctrl/tegra/pinctrl-tegra20.c|   1 +
  drivers/pinctrl/tegra/pinctrl-tegra210.c   |   1 +
  drivers/pinctrl/tegra/pinctrl-tegra30.c|   1 +
  drivers/soc/tegra/pmc.c| 159 +-
  21 files changed, 1167 insertions(+), 36 deletions(-)

[PATCH V1 00/12] LP0 entry and exit support for Tegra210

[Sowjanya Komatineni]

This patch series includes Tegra210 deepsleep or LP0 support with
deep sleep exit through RTC alarm wake and power button wake events.

This series also includes save and restore of PLLs, clocks, OSC contexts
for basic LP0 exit.

This patch series is doesn't support for 100% suspend/resume to fully
functional state and we are working on some more drivers suspend and
resume implementations.

Sowjanya Komatineni (12):
  irqchip: tegra: do not disable COP IRQ during suspend
  pinctrl: tegra: add suspend and resume support
  clk: tegra: save and restore PLLs state for system
  clk: tegra: add support for peripheral clock suspend and resume
  clk: tegra: add support for OSC clock resume
  clk: tegra: add suspend resume support for DFLL clock
  clk: tegra: support for Tegra210 clocks suspend-resume
  soc/tegra: pmc: allow support for more tegra wake models
  soc/tegra: pmc: add pmc wake support for tegra210
  gpio: tegra: implement wake event support for Tegra210 and prior GPIO
  soc/tegra: pmc: configure tegra deep sleep control settings
  arm64: tegra: enable wake from deep sleep on RTC alarm.

 arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi |   7 +
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   |   5 +-
 drivers/clk/tegra/clk-dfll.c   |  82 ++
 drivers/clk/tegra/clk-dfll.h   |   2 +
 drivers/clk/tegra/clk-divider.c|  19 ++
 drivers/clk/tegra/clk-pll-out.c|  25 ++
 drivers/clk/tegra/clk-pll.c| 220 --
 drivers/clk/tegra/clk-tegra-fixed.c|  15 +
 drivers/clk/tegra/clk-tegra210.c   | 382 +
 drivers/clk/tegra/clk.c|  74 -
 drivers/clk/tegra/clk.h|  18 ++
 drivers/gpio/gpio-tegra.c  | 109 ++-
 drivers/irqchip/irq-tegra.c|  10 +-
 drivers/pinctrl/tegra/pinctrl-tegra.c  |  68 -
 drivers/pinctrl/tegra/pinctrl-tegra.h  |   3 +
 drivers/pinctrl/tegra/pinctrl-tegra114.c   |   1 +
 drivers/pinctrl/tegra/pinctrl-tegra124.c   |   1 +
 drivers/pinctrl/tegra/pinctrl-tegra20.c|   1 +
 drivers/pinctrl/tegra/pinctrl-tegra210.c   |   1 +
 drivers/pinctrl/tegra/pinctrl-tegra30.c|   1 +
 drivers/soc/tegra/pmc.c| 159 +-
 21 files changed, 1167 insertions(+), 36 deletions(-)

-- 
2.7.4

[PATCH V1] spi: tegra114: set master cleanup and also invoke it on probe error

[Sowjanya Komatineni]

This patch sets master cleanup and also invokes tegra spi clean on
tegra spi probe failure to release tegra spi client data.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/spi/spi-tegra114.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 253a7f182fc9..15f9368fc0f8 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -966,6 +966,8 @@ static int tegra_spi_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(tspi->dev);
if (ret < 0) {
dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
+   if (cdata)
+   tegra_spi_cleanup(spi);
return ret;
}
 
@@ -1331,6 +1333,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
SPI_TX_DUAL | SPI_RX_DUAL | SPI_3WIRE;
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
master->setup = tegra_spi_setup;
+   master->cleanup = tegra_spi_cleanup;
master->transfer_one_message = tegra_spi_transfer_one_message;
master->set_cs_timing = tegra_spi_set_hw_cs_timing;
master->num_chipselect = MAX_CHIP_SELECT;
-- 
2.7.4

memory leak in new_inode_pseudo

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:f49aa1de Merge tag 'for-5.2-rc1-tag' of git://git.kernel.o..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12dccd9ca0
kernel config:  https://syzkaller.appspot.com/x/.config?x=61dd9e15a761691d
dashboard link: https://syzkaller.appspot.com/bug?extid=111cb28d9f583693aefa
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1587839ca0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16fdb38ca0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+111cb28d9f583693a...@syzkaller.appspotmail.com

e list of known hosts.
executing program
BUG: memory leak
unreferenced object 0x888121bdfd00 (size 632):
  comm "syz-executor073", pid 7035, jiffies 4294943279 (age 8.130s)
  hex dump (first 32 bytes):
01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  
80 1e b6 1f 81 88 ff ff 00 00 00 00 00 00 00 00  
  backtrace:
[<88b15f0d>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:55 [inline]

[<88b15f0d>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<88b15f0d>] slab_alloc mm/slab.c:3326 [inline]
[<88b15f0d>] kmem_cache_alloc+0x134/0x270 mm/slab.c:3488
[<1a541de3>] sock_alloc_inode+0x1d/0xe0 net/socket.c:252
[<226aca0e>] alloc_inode+0x2c/0xe0 fs/inode.c:226
[<54963a4b>] new_inode_pseudo+0x18/0x70 fs/inode.c:915
[] sock_alloc+0x1c/0x90 net/socket.c:575
[<0e50448f>] __sock_create+0x8f/0x250 net/socket.c:1394
[<248d5219>] sock_create_kern+0x3b/0x50 net/socket.c:1499
[<81cd440d>] io_uring_get_fd fs/io_uring.c:2997 [inline]
[<81cd440d>] io_uring_create fs/io_uring.c:3080 [inline]
[<81cd440d>] io_uring_setup+0x4ea/0x990 fs/io_uring.c:3128
[] __do_sys_io_uring_setup fs/io_uring.c:3141 [inline]
[] __se_sys_io_uring_setup fs/io_uring.c:3138 [inline]
[] __x64_sys_io_uring_setup+0x1a/0x20  
fs/io_uring.c:3138
[<72749d9e>] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:301

[<53106e40>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0x88811fb61e80 (size 64):
  comm "syz-executor073", pid 7035, jiffies 4294943279 (age 8.130s)
  hex dump (first 32 bytes):
00 00 00 00 81 88 ff ff 88 1e b6 1f 81 88 ff ff  
88 1e b6 1f 81 88 ff ff 00 00 00 00 00 00 00 00  
  backtrace:
[<8c8eddf3>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:55 [inline]

[<8c8eddf3>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<8c8eddf3>] slab_alloc mm/slab.c:3326 [inline]
[<8c8eddf3>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<5afcf70e>] kmalloc include/linux/slab.h:547 [inline]
[<5afcf70e>] sock_alloc_inode+0x44/0xe0 net/socket.c:255
[<226aca0e>] alloc_inode+0x2c/0xe0 fs/inode.c:226
[<54963a4b>] new_inode_pseudo+0x18/0x70 fs/inode.c:915
[] sock_alloc+0x1c/0x90 net/socket.c:575
[<0e50448f>] __sock_create+0x8f/0x250 net/socket.c:1394
[<248d5219>] sock_create_kern+0x3b/0x50 net/socket.c:1499
[<81cd440d>] io_uring_get_fd fs/io_uring.c:2997 [inline]
[<81cd440d>] io_uring_create fs/io_uring.c:3080 [inline]
[<81cd440d>] io_uring_setup+0x4ea/0x990 fs/io_uring.c:3128
[] __do_sys_io_uring_setup fs/io_uring.c:3141 [inline]
[] __se_sys_io_uring_setup fs/io_uring.c:3138 [inline]
[] __x64_sys_io_uring_setup+0x1a/0x20  
fs/io_uring.c:3138
[<72749d9e>] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:301

[<53106e40>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0x88811dd21c08 (size 56):
  comm "syz-executor073", pid 7035, jiffies 4294943279 (age 8.130s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
30 fd bd 21 81 88 ff ff 20 1c d2 1d 81 88 ff ff  0..! ...
  backtrace:
[<88b15f0d>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:55 [inline]

[<88b15f0d>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<88b15f0d>] slab_alloc mm/slab.c:3326 [inline]
[<88b15f0d>] kmem_cache_alloc+0x134/0x270 mm/slab.c:3488
[] kmem_cache_zalloc include/linux/slab.h:732 [inline]
[] lsm_inode_alloc security/security.c:523 [inline]
[] security_inode_alloc+0x33/0xb0  
security/security.c:876

[<93ac97c3>] inode_init_always+0x108/0x200 fs/inode.c:168
[<6cedb4e8>] alloc_inode+0x49/0xe0 

[PATCH] regulator: max77650: Move max77651_SBB1_desc's declaration down

[Nathan Chancellor]

Clang warns:

drivers/regulator/max77650-regulator.c:32:39: warning: tentative
definition of variable with internal linkage has incomplete non-array
type 'struct max77650_regulator_desc'
[-Wtentative-definition-incomplete-type]
static struct max77650_regulator_desc max77651_SBB1_desc;
  ^
drivers/regulator/max77650-regulator.c:32:15: note: forward declaration
of 'struct max77650_regulator_desc'
static struct max77650_regulator_desc max77651_SBB1_desc;
  ^
1 warning generated.

Move max77651_SBB1_desc's declaration below max77650_regulator_desc's
definition so this warning does not happen.

Fixes: 3df4235ac41c ("regulator: max77650: Convert MAX77651 SBB1 to pickable 
linear range")
Link: https://github.com/ClangBuiltLinux/linux/issues/491
Signed-off-by: Nathan Chancellor 
---
 drivers/regulator/max77650-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max77650-regulator.c 
b/drivers/regulator/max77650-regulator.c
index ecf8cf7aad20..e3b28fc68cdb 100644
--- a/drivers/regulator/max77650-regulator.c
+++ b/drivers/regulator/max77650-regulator.c
@@ -29,8 +29,6 @@
 
 #define MAX77650_REGULATOR_CURR_LIM_MASK   GENMASK(7, 6)
 
-static struct max77650_regulator_desc max77651_SBB1_desc;
-
 enum {
MAX77650_REGULATOR_ID_LDO = 0,
MAX77650_REGULATOR_ID_SBB0,
@@ -45,6 +43,8 @@ struct max77650_regulator_desc {
unsigned int regB;
 };
 
+static struct max77650_regulator_desc max77651_SBB1_desc;
+
 static const unsigned int max77651_sbb1_volt_range_sel[] = {
0x0, 0x1, 0x2, 0x3
 };
-- 
2.22.0.rc1

Re: [PATCH 5/5] mm/hmm: Fix mm stale reference use in hmm_free()

[Jason Gunthorpe]

On Wed, May 22, 2019 at 05:54:17PM -0700, Ralph Campbell wrote:
> 
> On 5/22/19 4:36 PM, Jason Gunthorpe wrote:
> > On Mon, May 06, 2019 at 04:35:14PM -0700, rcampb...@nvidia.com wrote:
> > > From: Ralph Campbell 
> > > 
> > > The last reference to struct hmm may be released long after the mm_struct
> > > is destroyed because the struct hmm_mirror memory may be part of a
> > > device driver open file private data pointer. The file descriptor close
> > > is usually after the mm_struct is destroyed in do_exit(). This is a good
> > > reason for making struct hmm a kref_t object [1] since its lifetime spans
> > > the life time of mm_struct and struct hmm_mirror.
> > 
> > > The fix is to not use hmm->mm in hmm_free() and to clear mm->hmm and
> > > hmm->mm pointers in hmm_destroy() when the mm_struct is
> > > destroyed.
> > 
> > I think the right way to fix this is to have the struct hmm hold a
> > mmgrab() on the mm so its memory cannot go away until all of the hmm
> > users release the struct hmm, hmm_ranges/etc
> > 
> > Then we can properly use mmget_not_zero() instead of the racy/abnormal
> > 'if (hmm->xmm == NULL || hmm->dead)' pattern (see the other
> > thread). Actually looking at this, all these tests look very
> > questionable. If we hold the mmget() for the duration of the range
> > object, as Jerome suggested, then they all get deleted.
> > 
> > That just leaves mmu_notifier_unregister_no_relase() as the remaining
> > user of hmm->mm (everyone else is trying to do range->mm) - and it
> > looks like it currently tries to call
> > mmu_notifier_unregister_no_release on a NULL hmm->mm and crashes :(
> > 
> > Holding the mmgrab fixes this as we can safely call
> > mmu_notifier_unregister_no_relase() post exit_mmap on a grab'd mm.
> > 
> > Also we can delete the hmm_mm_destroy() intrustion into fork.c as it
> > can't be called when the mmgrab is active.
> > 
> > This is the basic pattern we used in ODP when working with mmu
> > notifiers, I don't know why hmm would need to be different.
> > 
> > > index 2aa75dbed04a..4e42c282d334 100644
> > > +++ b/mm/hmm.c
> > > @@ -43,8 +43,10 @@ static inline struct hmm *mm_get_hmm(struct mm_struct 
> > > *mm)
> > >   {
> > >   struct hmm *hmm = READ_ONCE(mm->hmm);
> > > - if (hmm && kref_get_unless_zero(>kref))
> > > + if (hmm && !hmm->dead) {
> > > + kref_get(>kref);
> > >   return hmm;
> > > + }
> > 
> > hmm->dead and mm->hmm are not being read under lock, so this went from
> > something almost thread safe to something racy :(
> > 
> > > @@ -53,25 +55,28 @@ static inline struct hmm *mm_get_hmm(struct mm_struct 
> > > *mm)
> > >* hmm_get_or_create - register HMM against an mm (HMM internal)
> > >*
> > >* @mm: mm struct to attach to
> > > - * Returns: returns an HMM object, either by referencing the existing
> > > - *  (per-process) object, or by creating a new one.
> > > + * Return: an HMM object reference, either by referencing the existing
> > > + * (per-process) object, or by creating a new one.
> > >*
> > > - * This is not intended to be used directly by device drivers. If mm 
> > > already
> > > - * has an HMM struct then it get a reference on it and returns it. 
> > > Otherwise
> > > - * it allocates an HMM struct, initializes it, associate it with the mm 
> > > and
> > > - * returns it.
> > > + * If the mm already has an HMM struct then return a new reference to it.
> > > + * Otherwise, allocate an HMM struct, initialize it, associate it with 
> > > the mm,
> > > + * and return a new reference to it. If the return value is not NULL,
> > > + * the caller is responsible for calling hmm_put().
> > >*/
> > >   static struct hmm *hmm_get_or_create(struct mm_struct *mm)
> > >   {
> > > - struct hmm *hmm = mm_get_hmm(mm);
> > > - bool cleanup = false;
> > > + struct hmm *hmm = mm->hmm;
> > > - if (hmm)
> > > - return hmm;
> > > + if (hmm) {
> > > + if (hmm->dead)
> > > + goto error;
> > 
> > Create shouldn't fail just because it is racing with something doing
> > destroy
> > 
> > The flow should be something like:
> > 
> > spin_lock(>page_table_lock); // or write side mmap_sem if you prefer
> > if (mm->hmm)
> > if (kref_get_unless_zero(mm->hmm))
> >  return mm->hmm;
> > mm->hmm = NULL
> > 
> > 
> > > + goto out;
> > > + }
> > >   hmm = kmalloc(sizeof(*hmm), GFP_KERNEL);
> > >   if (!hmm)
> > > - return NULL;
> > > + goto error;
> > > +
> > >   init_waitqueue_head(>wq);
> > >   INIT_LIST_HEAD(>mirrors);
> > >   init_rwsem(>mirrors_sem);
> > > @@ -83,47 +88,32 @@ static struct hmm *hmm_get_or_create(struct mm_struct 
> > > *mm)
> > >   hmm->dead = false;
> > >   hmm->mm = mm;
> > > - spin_lock(>page_table_lock);
> > > - if (!mm->hmm)
> > > - mm->hmm = hmm;
> > > - else
> > > - cleanup = true;
> > > - spin_unlock(>page_table_lock);
> > 
> > BTW, Jerome this needs 

Re: [PATCH v2 0/5] 32-bit Meson: add the canvas module

[Kevin Hilman]

Martin Blumenstingl  writes:

> This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas
> IP is used by the video decoder hardware as well as the VPU (video
> output) hardware.
>
> Neither the VPU nor the video decoder driver support the 32-bit SoCs
> yet. However, we can still add the canvas module to have it available
> once these drivers gain support for the older SoCs.
>
> I have tested this on my Meson8m2 board by hacking the VPU driver to
> not re-initialize the VPU (and to use the configuration set by u-boot).
> With that hack I could get some image out of the CVBS connector. No
> changes to the canvas driver were required.
>
> Due to lack of hardware I could not test Meson8, but I'm following (as
> always) what the Amlogic 3.10 vendor kernel uses.
> Meson8b is also not tested because u-boot of my EC-100 doesn't have
> video output enabled (so I couldn't use the same hack I used on my
> Meson8m2 board).

Queued for v5.3...

> Martin Blumenstingl (5):
>   dt-bindings: soc: amlogic: canvas: document support for Meson8/8b/8m2
>   soc: amlogic: canvas: add support for Meson8, Meson8b and Meson8m2

these two in v5.3/drivers

>   ARM: dts: meson8: add the canvas module
>   ARM: dts: meson8m2: update the offset of the canvas module
>   ARM: dts: meson8b: add the canvas module

and these 3 in v5.3/dt.

Thanks,

Kevin

[A General Question] What should I do after getting Reviewed-by from a maintainer?

[Gen Zhang]

Hi Andrew,
I am starting submitting patches these days and got some patches 
"Reviewed-by" from maintainers. After checking the 
submitting-patches.html, I figured out what "Reviewed-by" means. But I
didn't get the guidance on what to do after getting "Reviewed-by".
Am I supposed to send this patch to more maintainers? Or something else?
Thanks
Gen

Re: [PATCH V5 4/4] spi: tegra114: add support for TX and RX trimmers

[Sowjanya Komatineni]

Hi Nathan

Thanks for finding it. I missed to set it to master cleanup when I 
updated the patch.


Will send the patch fixing this.

Thanks

Sowjanya

On 5/22/19 6:02 PM, Nathan Chancellor wrote:

Hi Sowjanya,

On Mon, May 13, 2019 at 10:03:55PM -0700, Sowjanya Komatineni wrote:

Tegra SPI master controller has programmable trimmers to adjust the
data with respect to the clock.

These trimmers are programmed in TX_CLK_TAP_DELAY and RX_CLK_TAP_DELAY
fields of COMMAND2 register.

SPI TX trimmer is to adjust the outgoing data with respect to the
outgoing clock and SPI RX trimmer is to adjust the loopback clock with
respect to the incoming data from the slave device.

These trimmers vary based on trace lengths of the platform design for
each of the slaves on the SPI bus and optimal value programmed is from
the platform validation across PVT.

This patch adds support for configuring TX and RX clock delay trimmers
through the device tree properties.

Signed-off-by: Sowjanya Komatineni 
---
  drivers/spi/spi-tegra114.c | 67 --
  1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index e59ff7c1cee6..253a7f182fc9 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c




+static void tegra_spi_cleanup(struct spi_device *spi)
+{
+   struct tegra_spi_client_data *cdata = spi->controller_data;
+
+   spi->controller_data = NULL;
+   if (spi->dev.of_node)
+   kfree(cdata);
+}
+

This function is not called anywhere and it is marked as static so it
triggers an unused function warning. Was that intentional?

drivers/spi/spi-tegra114.c:938:13: warning: unused function 'tegra_spi_cleanup' 
[-Wunused-function]
static void tegra_spi_cleanup(struct spi_device *spi)
 ^
1 warning generated.

Cheers,
Nathan

Re: [PATCH 3/3] arm64: dts: imx8mq: add clock for SNVS RTC node

[Shawn Guo]

On Wed, May 15, 2019 at 01:09:36AM +, Anson Huang wrote:
> i.MX8MQ has clock gate for SNVS module, add clock info to SNVS
> RTC node for clock management.
> 
> Signed-off-by: Anson Huang 

This one still has problem with encoding and thus cannot be applied.
Here is what I get, and there is '=20' in the patch content.

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dt=
s/freescale/imx8mq.dtsi
index e5f3133..b706de8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -438,6 +438,8 @@
offset =3D <0x34>;
interrupts =3D ,
;
+   clocks =3D < IMX8MQ_CLK_SNVS_ROOT>;
+   clock-names =3D "snvs-rtc";
};
};
=20
--=20
2.7.4

Re: [PATCH V5 4/4] spi: tegra114: add support for TX and RX trimmers

[Nathan Chancellor]

Hi Sowjanya,

On Mon, May 13, 2019 at 10:03:55PM -0700, Sowjanya Komatineni wrote:
> Tegra SPI master controller has programmable trimmers to adjust the
> data with respect to the clock.
> 
> These trimmers are programmed in TX_CLK_TAP_DELAY and RX_CLK_TAP_DELAY
> fields of COMMAND2 register.
> 
> SPI TX trimmer is to adjust the outgoing data with respect to the
> outgoing clock and SPI RX trimmer is to adjust the loopback clock with
> respect to the incoming data from the slave device.
> 
> These trimmers vary based on trace lengths of the platform design for
> each of the slaves on the SPI bus and optimal value programmed is from
> the platform validation across PVT.
> 
> This patch adds support for configuring TX and RX clock delay trimmers
> through the device tree properties.
> 
> Signed-off-by: Sowjanya Komatineni 
> ---
>  drivers/spi/spi-tegra114.c | 67 
> --
>  1 file changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
> index e59ff7c1cee6..253a7f182fc9 100644
> --- a/drivers/spi/spi-tegra114.c
> +++ b/drivers/spi/spi-tegra114.c



> +static void tegra_spi_cleanup(struct spi_device *spi)
> +{
> + struct tegra_spi_client_data *cdata = spi->controller_data;
> +
> + spi->controller_data = NULL;
> + if (spi->dev.of_node)
> + kfree(cdata);
> +}
> +

This function is not called anywhere and it is marked as static so it
triggers an unused function warning. Was that intentional?

drivers/spi/spi-tegra114.c:938:13: warning: unused function 'tegra_spi_cleanup' 
[-Wunused-function]
static void tegra_spi_cleanup(struct spi_device *spi)
^
1 warning generated.

Cheers,
Nathan

Re: Linux Testing Microconference at LPC

[Steven Rostedt]

On Wed, 22 May 2019 20:58:47 -0400
Steven Rostedt  wrote:

> You have till the end of today to submit a Refereed talk if you want to
> present. Otherwise, Microconferences should only have 5 to 10 minutes
> to present what they want to discuss before a discussion should
> proceed. If you need more than 10 minutes to give your point, then you
> need to try to get a Refereed talk in, and that will give you a full 40
> minutes.

I just found out that we are extending the deadline by one week. You
still have time, but you had better hurry!

-- Steve

Re: [PATCH net-next] hv_sock: perf: loop in send() to maximize bandwidth

[David Miller]

From: Sunil Muthuswamy 
Date: Wed, 22 May 2019 23:10:44 +

> Currently, the hv_sock send() iterates once over the buffer, puts data into
> the VMBUS channel and returns. It doesn't maximize on the case when there
> is a simultaneous reader draining data from the channel. In such a case,
> the send() can maximize the bandwidth (and consequently minimize the cpu
> cycles) by iterating until the channel is found to be full.
> 
> Perf data:
> Total Data Transfer: 10GB/iteration
> Single threaded reader/writer, Linux hvsocket writer with Windows hvsocket
> reader
> Packet size: 64KB
> CPU sys time was captured using the 'time' command for the writer to send
> 10GB of data.
> 'Send Buffer Loop' is with the patch applied.
> The values below are over 10 iterations.
 ...
> Observation:
> 1. The avg throughput doesn't really change much with this change for this
> scenario. This is most probably because the bottleneck on throughput is
> somewhere else.
> 2. The average system (or kernel) cpu time goes down by 10%+ with this
> change, for the same amount of data transfer.
> 
> Signed-off-by: Sunil Muthuswamy 

Applied.

Re: [PATCH net-next] hv_sock: perf: Allow the socket buffer size options to influence the actual socket buffers

[David Miller]

From: Sunil Muthuswamy 
Date: Wed, 22 May 2019 22:56:07 +

> Currently, the hv_sock buffer size is static and can't scale to the
> bandwidth requirements of the application. This change allows the
> applications to influence the socket buffer sizes using the SO_SNDBUF and
> the SO_RCVBUF socket options.
> 
> Few interesting points to note:
> 1. Since the VMBUS does not allow a resize operation of the ring size, the
> socket buffer size option should be set prior to establishing the
> connection for it to take effect.
> 2. Setting the socket option comes with the cost of that much memory being
> reserved/allocated by the kernel, for the lifetime of the connection.
> 
> Perf data:
> Total Data Transfer: 1GB
> Single threaded reader/writer
> Results below are summarized over 10 iterations.
 ...
> Signed-off-by: Sunil Muthuswamy 

Applied.

Re: [PATCH 2/3] clk: imx8mq: add SNVS clock to clock tree

[Shawn Guo]

On Wed, May 15, 2019 at 01:09:30AM +, Anson Huang wrote:
> i.MX8MQ has clock gate for SNVS module, add it into clock tree
> for SNVS RTC driver to manage.
> 
> Signed-off-by: Anson Huang 

Applied, thanks.