[-mm PATCH] docs/vm: Update ZONE_DEVICE memory model documentation

[Dan Williams]

Mike notes that Sphinx needs a newline before the start of a bulleted
list, and v10 of the subsection patch set changed the subsection size
from an arch-variable 'PMD_SIZE' to a constant 2MB.

Cc: Jonathan Corbet 
Reported-by: Mike Rapoport 
Signed-off-by: Dan Williams 
---
Hi Andrew,

Another small fixup to fold on top of the subsection series. Thanks to
Mike for the build test, I also caught that the doc was out of date.

 Documentation/vm/memory-model.rst |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/vm/memory-model.rst 
b/Documentation/vm/memory-model.rst
index e0af47e02e78..58a12376b7df 100644
--- a/Documentation/vm/memory-model.rst
+++ b/Documentation/vm/memory-model.rst
@@ -205,10 +205,11 @@ subject to its memory ranges being exposed through the 
sysfs memory
 hotplug api on memory block boundaries. The implementation relies on
 this lack of user-api constraint to allow sub-section sized memory
 ranges to be specified to :c:func:`arch_add_memory`, the top-half of
-memory hotplug. Sub-section support allows for `PMD_SIZE` as the minimum
-alignment granularity for :c:func:`devm_memremap_pages`.
+memory hotplug. Sub-section support allows for 2MB as the cross-arch
+common alignment granularity for :c:func:`devm_memremap_pages`.
 
 The users of `ZONE_DEVICE` are:
+
 * pmem: Map platform persistent memory to be used as a direct-I/O target
   via DAX mappings.
 

linux-next: manual merge of the kvms390 tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvms390 tree got a conflict in:

  tools/testing/selftests/kvm/Makefile

between commit:

  61cfcd545e42 ("kvm: tests: Sort tests in the Makefile alphabetically")

from Linus' tree and commits:

  ee1563f42856 ("KVM: selftests: Add the sync_regs test for s390x")
  49fe9a5d1638 ("KVM: selftests: Move kvm_create_max_vcpus test to generic 
code")

from the kvms390 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/kvm/Makefile
index 62afd0b43074,0d7265da1583..
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@@ -10,25 -10,29 +10,30 @@@ UNAME_M := $(shell uname -m
  LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/ucall.c 
lib/sparsebit.c
  LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c
  LIBKVM_aarch64 = lib/aarch64/processor.c
+ LIBKVM_s390x = lib/s390x/processor.c
  
 -TEST_GEN_PROGS_x86_64 = x86_64/platform_info_test
 -TEST_GEN_PROGS_x86_64 += x86_64/set_sregs_test
 -TEST_GEN_PROGS_x86_64 += x86_64/sync_regs_test
 -TEST_GEN_PROGS_x86_64 += x86_64/vmx_tsc_adjust_test
 -TEST_GEN_PROGS_x86_64 += x86_64/cr4_cpuid_sync_test
 -TEST_GEN_PROGS_x86_64 += x86_64/state_test
 +TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test
  TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test
  TEST_GEN_PROGS_x86_64 += x86_64/hyperv_cpuid
- TEST_GEN_PROGS_x86_64 += x86_64/kvm_create_max_vcpus
 -TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test
 +TEST_GEN_PROGS_x86_64 += x86_64/mmio_warning_test
 +TEST_GEN_PROGS_x86_64 += x86_64/platform_info_test
 +TEST_GEN_PROGS_x86_64 += x86_64/set_sregs_test
  TEST_GEN_PROGS_x86_64 += x86_64/smm_test
 +TEST_GEN_PROGS_x86_64 += x86_64/state_test
 +TEST_GEN_PROGS_x86_64 += x86_64/sync_regs_test
 +TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test
  TEST_GEN_PROGS_x86_64 += x86_64/vmx_set_nested_state_test
 -TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus
 -TEST_GEN_PROGS_x86_64 += dirty_log_test
 +TEST_GEN_PROGS_x86_64 += x86_64/vmx_tsc_adjust_test
  TEST_GEN_PROGS_x86_64 += clear_dirty_log_test
 +TEST_GEN_PROGS_x86_64 += dirty_log_test
++TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus
  
 -TEST_GEN_PROGS_aarch64 += dirty_log_test
  TEST_GEN_PROGS_aarch64 += clear_dirty_log_test
 +TEST_GEN_PROGS_aarch64 += dirty_log_test
+ TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus
+ 
+ TEST_GEN_PROGS_s390x += s390x/sync_regs_test
+ TEST_GEN_PROGS_s390x += kvm_create_max_vcpus
  
  TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M))
  LIBKVM += $(LIBKVM_$(UNAME_M))


pgp6Oj3WrKZ9E.pgp
Description: OpenPGP digital signature

Re: [PATCH 3/6] usb: bdc: driver may fail to get USB PHY

[Chunfeng Yun]

On Thu, 2019-06-20 at 17:09 -0400, Al Cooper wrote:
> Initialization order is important for the USB PHY and the PHY clients.
> The init order is based on the build order of the drivers in the
> makefiles and the PHY drivers are built early to help with
> dependencies, but the new SCMI based clock subsystem has the side
> effect of making some additional drivers DEFER until the clock
> is ready. This is causing the USB PHY driver to defer which is causing
> some PHY clients to fail when they try to get the PHY. The fix is to have
> the client driver return DEFER when it's "get phy" routine returns DEFER.
> 
> Signed-off-by: Al Cooper 
> ---
>  drivers/usb/gadget/udc/bdc/bdc_core.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
> b/drivers/usb/gadget/udc/bdc/bdc_core.c
> index 11a43de6c1c6..c794890d785b 100644
> --- a/drivers/usb/gadget/udc/bdc/bdc_core.c
> +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
> @@ -543,9 +543,13 @@ static int bdc_probe(struct platform_device *pdev)
>   dev, dev->of_node, phy_num);
>   if (IS_ERR(bdc->phys[phy_num])) {
>   ret = PTR_ERR(bdc->phys[phy_num]);
> + if (ret == -EPROBE_DEFER) {
> + dev_dbg(bdc->dev, "DEFER, waiting for PHY\n");
why not disable clock here? when re-probe, will enable clock again.
to me, no need check -EPROBE_DEFFER.
> + return ret;
> + }

>   dev_err(bdc->dev,
>   "BDC phy specified but not found:%d\n", ret);
> - return ret;
> + goto clk_cleanup;
>   }
>   }
>  

[PATCH] powerpc/powernv: Rename pe_level_printk to pe_printk and embed KERN_LEVEL in format

[Joe Perches]

Remove the separate KERN_ from each pe_level_printk and
instead add the KERN_ to the format.

pfix in pe_level_printk could also be used uninitialized so
add a new else and set pfx to the hex value of pe->flags.

Rename pe_level_printk to pe_printk and update the pe_
macros.

Signed-off-by: Joe Perches 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 14 --
 arch/powerpc/platforms/powernv/pci.h  | 11 +--
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 10cc42b9e541..60fc36ae626a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -50,15 +50,23 @@
 static const char * const pnv_phb_names[] = { "IODA1", "IODA2", "NPU_NVLINK",
  "NPU_OCAPI" };
 
-void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
-   const char *fmt, ...)
+void pe_printk(const struct pnv_ioda_pe *pe, const char *fmt, ...)
 {
struct va_format vaf;
va_list args;
char pfix[32];
+   char level[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
 
va_start(args, fmt);
 
+   while (printk_get_level(fmt)) {
+   size_t size = printk_skip_level(fmt) - fmt;
+
+   memcpy(level, fmt,  size);
+   level[size] = '\0';
+   fmt += size;
+   }
+
vaf.fmt = fmt;
vaf.va = 
 
@@ -74,6 +82,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const char 
*level,
(pe->rid & 0xff00) >> 8,
PCI_SLOT(pe->rid), PCI_FUNC(pe->rid));
 #endif /* CONFIG_PCI_IOV*/
+   else
+   sprintf(pfix, "(flags: 0x%lx)", pe->flags);
 
printk("%spci %s: [PE# %.2x] %pV",
   level, pfix, pe->pe_number, );
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index be26ab3d99e0..870b21f55b3f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -205,15 +205,14 @@ extern unsigned long pnv_pci_ioda2_get_table_size(__u32 
page_shift,
__u64 window_size, __u32 levels);
 extern int pnv_eeh_post_init(void);
 
-__printf(3, 4)
-extern void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
-   const char *fmt, ...);
+__printf(2, 3)
+extern void pe_printk(const struct pnv_ioda_pe *pe, const char *fmt, ...);
 #define pe_err(pe, fmt, ...)   \
-   pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
+   pe_printk(pe, KERN_ERR fmt, ##__VA_ARGS__)
 #define pe_warn(pe, fmt, ...)  \
-   pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
+   pe_printk(pe, KERN_WARNING fmt, ##__VA_ARGS__)
 #define pe_info(pe, fmt, ...)  \
-   pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
+   pe_printk(pe, KERN_INFO fmt, ##__VA_ARGS__)
 
 /* Nvlink functions */
 extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);

Re: Kirkwood PCI Express and bridges

[Thomas Petazzoni]

Hello Chris,

On Fri, 21 Jun 2019 04:03:27 +
Chris Packham  wrote:

> I'm in the process of updating the kernel version used on our products 
> from 4.4 -> 5.1.
> 
> We have one product that uses a Kirkwood CPU, IDT PCI bridge and Marvell 
> Switch ASIC. The Switch ASIC presents as multiple PCI devices.
> 
> The hardware setup looks like this
> __
> [ Kirkwood ] --- [ IDT 5T5 ] ---+---  |  |
>  +---  |  Switch  |
>  +---  |  |
>  +---  |__|
> 
> On the 4.4 based kernel things are fine
> 
> [root@awplus flash]# lspci -t
> -[:00]---01.0-[01-06]00.0-[02-06]--+-02.0-[03]00.0
> +-03.0-[04]00.0
> +-04.0-[05]00.0
> \-05.0-[06]00.0
> 
> But on the 5.1 based kernel things get a little weird
> 
> [root@awplus flash]# lspci -t
> -[:00]---01.0-[01-06]--+-00.0-[02-06]--
> +-01.0
> +-02.0-[02-06]--
> +-03.0-[02-06]--
> +-04.0-[02-06]--
> +-05.0-[02-06]--
> +-06.0-[02-06]--
> +-07.0-[02-06]--
> +-08.0-[02-06]--
> +-09.0-[02-06]--
> +-0a.0-[02-06]--
> +-0b.0-[02-06]--
> +-0c.0-[02-06]--
> +-0d.0-[02-06]--
> +-0e.0-[02-06]--
> +-0f.0-[02-06]--
> +-10.0-[02-06]--
> +-11.0-[02-06]--
> +-12.0-[02-06]--
> +-13.0-[02-06]--
> +-14.0-[02-06]--
> +-15.0-[02-06]--
> +-16.0-[02-06]--
> +-17.0-[02-06]--
> +-18.0-[02-06]--
> +-19.0-[02-06]--
> +-1a.0-[02-06]--
> +-1b.0-[02-06]--
> +-1c.0-[02-06]--
> +-1d.0-[02-06]--
> +-1e.0-[02-06]--
> \-1f.0-[02-06]--+-02.0-[03]00.0
> +-03.0-[04]00.0
> +-04.0-[05]00.0
> \-05.0-[06]00.0
> 
> 
> I'll start bisecting to see where things started going wrong. I just 
> wondered if this rings any bells for anyone.

I am almost sure that the culprit is
1f08673eef1236f7d02d93fcf596bb8531ef0d12 ("PCI: mvebu: Convert to PCI
emulated bridge config space").

I still think it makes sense to share the bridge emulation code between
the mvebu and aardvark drivers, but this sharing has required making
the code very different, with lots of subtle differences in behavior in
how registers are emulated.

Unfortunately, I don't have access to one of these complicated PCI
setup with a HW switch on the way, so I couldn't test this kind of
setups.

Do you mind helping with figuring out what the issues are ? That would
be really nice.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V4 1/2] PCI: dwc: Add API support to de-initialize host

[Vidya Sagar]

On 6/20/2019 10:22 PM, Lorenzo Pieralisi wrote:

On Wed, Jun 19, 2019 at 10:41:26AM +0530, Kishon Vijay Abraham I wrote:

Hi Lorenzo,

On 18/06/19 7:58 PM, Lorenzo Pieralisi wrote:

On Tue, Jun 18, 2019 at 04:21:17PM +0530, Vidya Sagar wrote:

[...]


2) It is not related to this patch but I fail to see the reasoning
 behind the __ in __dw_pci_read_dbi(), there is no no-underscore
 equivalent so its definition is somewhat questionable, maybe
 we should clean-it up (for dbi2 alike).

Separate no-underscore versions are present in pcie-designware.h for
each width (i.e. l/w/b) as inline and are calling __ versions passing
size as argument.


I understand - the __ prologue was added in b50b2db266d8 maybe
Kishon can help us understand the __ rationale.

I am happy to merge it as is, I was just curious about the
__ annotation (not related to this patch).


In commit b50b2db266d8a8c303e8d88590 ("PCI: dwc: all: Modify dbi accessors to
take dbi_base as argument"), dbi accessors was modified to take dbi_base as
argument (since we wanted to write to dbics2 address space). We didn't want to
change all the drivers invoking dbi accessors to pass the dbi_base. So we added
"__" variant to take dbi_base as argument and the drivers continued to invoke
existing dbi accessors which in-turn invoked "__" version with dbi_base as
argument.

I agree there could be some cleanup since in commit
a509d7d9af5ebf86ffbefa98e49761d ("PCI: dwc: all: Modify dbi accessors to access
data of 4/2/1 bytes"), we modified __dw_pcie_readl_dbi() to
__dw_pcie_write_dbi() when it could have been directly modified to
dw_pcie_write_dbi().


Thanks. Vidya can do it as a preliminary patch, I will merge then
code to export the symbols.

Lorenzo


Do you want me to make the change that removes "__" as part of 2/2 patch itself 
and
then send V5 or as a separate patch?

Vidya Sagar

Re: [PATCH 2/6] usb: bdc: Cleanup clock support

[Chunfeng Yun]

On Thu, 2019-06-20 at 17:09 -0400, Al Cooper wrote:
> - Fix driver to defer on clk_get defer
> 
> Signed-off-by: Al Cooper 
> ---
>  drivers/usb/gadget/udc/bdc/bdc_core.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
> b/drivers/usb/gadget/udc/bdc/bdc_core.c
> index ccbd1d34eb2a..11a43de6c1c6 100644
> --- a/drivers/usb/gadget/udc/bdc/bdc_core.c
> +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
> @@ -490,8 +490,14 @@ static int bdc_probe(struct platform_device *pdev)
>  
>   dev_dbg(dev, "%s()\n", __func__);
>  
> + bdc = devm_kzalloc(dev, sizeof(*bdc), GFP_KERNEL);
> + if (!bdc)
> + return -ENOMEM;
> +
>   clk = devm_clk_get(dev, "sw_usbd");
>   if (IS_ERR(clk)) {
> + if (PTR_ERR(clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
what about using devm_clk_get_optional()?

>   dev_info(dev, "Clock not found in Device Tree\n");
>   clk = NULL;
>   }
> @@ -501,11 +507,6 @@ static int bdc_probe(struct platform_device *pdev)
>   dev_err(dev, "could not enable clock\n");
>   return ret;
>   }
> -
> - bdc = devm_kzalloc(dev, sizeof(*bdc), GFP_KERNEL);
> - if (!bdc)
> - return -ENOMEM;
> -
>   bdc->clk = clk;
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -551,7 +552,7 @@ static int bdc_probe(struct platform_device *pdev)
>   ret = bdc_phy_init(bdc);
>   if (ret) {
>   dev_err(bdc->dev, "BDC phy init failure:%d\n", ret);
> - return ret;
> + goto clk_cleanup;
>   }
>  
>   temp = bdc_readl(bdc->regs, BDC_BDCCAP1);
> @@ -583,6 +584,8 @@ static int bdc_probe(struct platform_device *pdev)
>   bdc_hw_exit(bdc);
>  phycleanup:
>   bdc_phy_exit(bdc);
> +clk_cleanup:
> + clk_disable_unprepare(bdc->clk);
>   return ret;
>  }
>  

Re: [PATCH V33 01/30] security: Support early LSMs

[Andy Lutomirski]

On Thu, Jun 20, 2019 at 6:22 PM Matthew Garrett
 wrote:
>
> The lockdown module is intended to allow for kernels to be locked down
> early in boot - sufficiently early that we don't have the ability to
> kmalloc() yet. Add support for early initialisation of some LSMs, and
> then add them to the list of names when we do full initialisation later.

I'm confused.  What does it even mean to lock down the kernel before
we're ready to run userspace code?  We can't possibly be attacked by
user code before there is any to attack us.

Am I missing something here?

--Andy

Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode

[Andy Lutomirski]

On Thu, Jun 20, 2019 at 6:21 PM Matthew Garrett
 wrote:
>
> From: David Howells 
>
> There are some bpf functions can be used to read kernel memory:
> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
> private keys in kernel memory (e.g. the hibernation image signing key) to
> be read by an eBPF program and kernel memory to be altered without
> restriction. Disable them if the kernel has been locked down in
> confidentiality mode.

This patch exemplifies why I don't like this approach:

> @@ -97,6 +97,7 @@ enum lockdown_reason {
> LOCKDOWN_INTEGRITY_MAX,
> LOCKDOWN_KCORE,
> LOCKDOWN_KPROBES,
> +   LOCKDOWN_BPF,
> LOCKDOWN_CONFIDENTIALITY_MAX,

> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -33,6 +33,7 @@ static char 
> *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> [LOCKDOWN_INTEGRITY_MAX] = "integrity",
> [LOCKDOWN_KCORE] = "/proc/kcore access",
> [LOCKDOWN_KPROBES] = "use of kprobes",
> +   [LOCKDOWN_BPF] = "use of bpf",
> [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",

The text here says "use of bpf", but what this patch is *really* doing
is locking down use of BPF to read kernel memory.  If the details
change, then every LSM needs to get updated, and we risk breaking user
policies that are based on LSMs that offer excessively fine
granularity.

I'd be more comfortable if the LSM only got to see "confidentiality"
or "integrity".

--Andy

Re: selftests: bpf: test_libbpf.sh failed at file test_l4lb.o

[Andrii Nakryiko]

On Thu, Jun 20, 2019 at 1:08 AM Naresh Kamboju
 wrote:
>
> selftests: bpf test_libbpf.sh failed running Linux -next kernel
> 20190618 and 20190619.
>
> Here is the log from x86_64,
> # selftests bpf test_libbpf.sh
> bpf: test_libbpf.sh_ #
> # [0] libbpf BTF is required, but is missing or corrupted.

You need at least clang-9.0.0 (not yet released) to run some of these
tests successfully, as they rely on Clang's support for
BTF_KIND_VAR/BTF_KIND_DATASEC.

> libbpf: BTF_is #
> # test_libbpf failed at file test_l4lb.o
> failed: at_file #
> # selftests test_libbpf [FAILED]
> test_libbpf: [FAILED]_ #
> [FAIL] 29 selftests bpf test_libbpf.sh
> selftests: bpf_test_libbpf.sh [FAIL]
>
> Full test log,
> https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190619/testrun/781777/log
>
> Test results comparison,
> https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_libbpf.sh
>
> Good linux -next tag: next-20190617
> Bad linux -next tag: next-20190618
> git branch master
> git commit1c6b40509daf5190b1fd2c758649f7df1da4827b
> git repo
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
> Best regards
> Naresh Kamboju

Re: [PATCH][next] libbpf: fix spelling mistake "conflictling" -> "conflicting"

[Andrii Nakryiko]

On Wed, Jun 19, 2019 at 9:28 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> There are several spelling mistakes in pr_warning messages. Fix these.
>
> Signed-off-by: Colin Ian King 
> ---

Oh, the beauty of copy/pasting same typo 4 times :)

Thanks for fixing! Can you please re-submit with [PATCH bpf-next]
subject prefix, as it's intended for bpf-next tree. With that:

Acked-by: Andrii Nakryiko 

>  tools/lib/bpf/libbpf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

[PATCH] arm64: defconfig: Enable CONFIG_KEYBOARD_SNVS_PWRKEY as module

[Anson . Huang]

From: Anson Huang 

Enable CONFIG_KEYBOARD_SNVS_PWRKEY as module to support i.MX8M
series SoCs' power key.

Signed-off-by: Anson Huang 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 29f7768..3c17f6e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -291,6 +291,7 @@ CONFIG_WLCORE_SDIO=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_ADC=m
 CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_SNVS_PWRKEY=m
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=m
-- 
2.7.4

Re: [PATCH 1/2] pinctrl: mediatek: Ignore interrupts that are wake only during resume

[Sean Wang]

Hi Nicolas,

On Sun, Apr 28, 2019 at 8:55 PM Nicolas Boichat  wrote:
>
> Before suspending, mtk-eint would set the interrupt mask to the
> one in wake_mask. However, some of these interrupts may not have a
> corresponding interrupt handler, or the interrupt may be disabled.
>
> On resume, the eint irq handler would trigger nevertheless,
> and irq/pm.c:irq_pm_check_wakeup would be called, which would
> try to call irq_disable. However, if the interrupt is not enabled
> (irqd_irq_disabled(>irq_data) is true), the call does nothing,
> and the interrupt is left enabled in the eint driver.
>
> Especially for level-sensitive interrupts, this will lead to an
> interrupt storm on resume.
>
> If we detect that an interrupt is only in wake_mask, but not in
> cur_mask, we can just mask it out immediately (as mtk_eint_resume
> would do anyway at a later stage in the resume sequence, when
> restoring cur_mask).
>
> Fixes: bf22ff45bed ("genirq: Avoid unnecessary low level irq function calls")
> Signed-off-by: Nicolas Boichat 

Acked-by: Sean Wang 

> ---
>  drivers/pinctrl/mediatek/mtk-eint.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c 
> b/drivers/pinctrl/mediatek/mtk-eint.c
> index f464f8cd274b75c..737385e86beb807 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -318,7 +318,7 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
> struct irq_chip *chip = irq_desc_get_chip(desc);
> struct mtk_eint *eint = irq_desc_get_handler_data(desc);
> unsigned int status, eint_num;
> -   int offset, index, virq;
> +   int offset, mask_offset, index, virq;
> void __iomem *reg =  mtk_eint_get_offset(eint, 0, eint->regs->stat);
> int dual_edge, start_level, curr_level;
>
> @@ -328,10 +328,24 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
> status = readl(reg);
> while (status) {
> offset = __ffs(status);
> +   mask_offset = eint_num >> 5;
> index = eint_num + offset;
> virq = irq_find_mapping(eint->domain, index);
> status &= ~BIT(offset);
>
> +   /*
> +* If we get an interrupt on pin that was only 
> required
> +* for wake (but no real interrupt requested), mask 
> the
> +* interrupt (as would mtk_eint_resume do anyway later
> +* in the resume sequence).
> +*/
> +   if (eint->wake_mask[mask_offset] & BIT(offset) &&
> +   !(eint->cur_mask[mask_offset] & BIT(offset))) {
> +   writel_relaxed(BIT(offset), reg -
> +   eint->regs->stat +
> +   eint->regs->mask_set);
> +   }
> +
> dual_edge = eint->dual_edge[index];
> if (dual_edge) {
> /*
> --
> 2.21.0.593.g511ec345e18-goog
>

Re: [PATCH 1/5] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM

[Vinod Koul]

On 20-06-19, 21:12, Christian Lamparter wrote:
> On Thursday, June 20, 2019 7:03:58 PM CEST Vinod Koul wrote:
> > On 20-06-19, 14:19, Greg Kroah-Hartman wrote:
> > > On Thu, Jun 20, 2019 at 03:51:50PM +0530, Vinod Koul wrote:
> > > > From: Christian Lamparter 
> > > > 
> > > > This patch adds a firmware loader for the uPD720201K8-711-BAC-A
> > > > and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> > > > in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
> > > > devices which need the firmware loader on page 2 in order to
> > > > work as they "do not support the External ROM".
> > > > 
> > > > The "Firmware Download Sequence" is describe in chapter
> > > > "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131.
> > > > 
> > > > The firmware "K2013080.mem" is available from a USB3.0 Host to
> > > > PCIe Adapter (PP2U-E card) "Firmware download" archive. An
> > > > alternative version can be sourced from Netgear's WNDR4700 GPL
> > > > archives.
> > > > 
> > > > The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3
> > > > (2012-06-15) state that the firmware is for the following devices:
> > > >  - uPD720201 ES 2.0 sample whose revision ID is 2.
> > > >  - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> > > >  - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
> > > > 
> > > > If someone from Renesas is listening: It would be great, if these
> > > > firmwares could be added to linux-firmware.git.
> > > 
> > > That paragraph does not need to be in the changelog :)
> > 
> > Sure will drop :)
> 
> ... those this mean that there is a firmware now? Do you have a link to it?

Unfortunately it is not public yet!

> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > 
> > > asm/ in a driver?  Are you sure???
> > 
> > Not sure :D, will check and remove
> 
> I think, as long as there is a "get_unaligned_le16" defined somewhere
> it should be fine.
> 
> This was a loong ago, the loader was developped on a PowerPC 464, but
> from what I remember it was checkpatch that didn't like the "unaligned"
> poking around in the firmware below.

It seems we have this in include/linux/unaligned/access_ok.h, so I will
add that instead

> > > > +static int renesas_fw_download_image(struct pci_dev *dev,
> > > > +const u32 *fw,
> > > > +size_t step)
> > > > +{
> > > > +   size_t i;
> > > > +   int err;
> > > > +   u8 fw_status;
> > > > +   bool data0_or_data1;
> > > > +
> > > > +   /*
> > > > +* The hardware does alternate between two 32-bit pages.
> > > > +* (This is because each row of the firmware is 8 bytes).
> > > > +*
> > > > +* for even steps we use DATA0, for odd steps DATA1.
> > > > +*/
> > > > +   data0_or_data1 = (step & 1) == 1;
> > > > +
> > > > +   /* step+1. Read "Set DATAX" and confirm it is cleared. */
> > > > +   for (i = 0; i < 1; i++) {
> > > > +   err = pci_read_config_byte(dev, 0xF5, _status);
> > > > +   if (err)
> > > > +   return pcibios_err_to_errno(err);
> > > > +   if (!(fw_status & BIT(data0_or_data1)))
> > > > +   break;
> > > > +
> > > > +   udelay(1);
> > > > +   }
> > > > +   if (i == 1)
> > > > +   return -ETIMEDOUT;
> > > > +
> > > > +   /*
> > > > +* step+2. Write FW data to "DATAX".
> > > > +* "LSB is left" => force little endian
> > > > +*/
> > > > +   err = pci_write_config_dword(dev, data0_or_data1 ? 0xFC : 0xF8,
> > > > +(__force u32) 
> > > > cpu_to_le32(fw[step]));
> > > > +   if (err)
> > > > +   return pcibios_err_to_errno(err);
> > > > +
> > > > +   udelay(100);
> > > > +
> > > > +   /* step+3. Set "Set DATAX". */
> > > > +   err = pci_write_config_byte(dev, 0xF5, BIT(data0_or_data1));
> > > > +   if (err)
> > > > +   return pcibios_err_to_errno(err);
> > > > +
> > > 
> > > Shouldn't you just do a read after the write to be sure the write
> > > actually went out on the wire?  Then you shouldn't have to do the
> > > udelay, right?
> > 
> > Well I am not sure that is how it works. The register is a DATA register
> > on the controller. We are writing to the memory of the controller here
> > and after writing DATA0 and DATA1 we check the Set DATA0 & Set DATA1
> > bits and write subsequenly only when controller is ready to accept more
> > data.
> > 
> > I do recall at least for ROM load (writing to NOR flash attached to
> > controller), we need to wait considerably more before the SetData0/1 was
> > set and ready for subsequent write
> 
> OffTopic: There's some leeway here. From what I remember you could just push
> the data through DATA0 and cut down on the logic. But this was slower than
> using both DATA0 

Re: [PATCH v7 1/5] Input: elan_i2c: Export the device id whitelist

[Dmitry Torokhov]

Hi Jeffrey,

On Thu, Jun 20, 2019 at 7:33 AM Jeffrey Hugo  wrote:
>  #ifdef CONFIG_OF
> -static const struct of_device_id elan_of_match[] = {
> -   { .compatible = "elan,ekth3000" },
> -   { /* sentinel */ }
> -};

I think OF IDs should stay in this file since we agreed HID will not
be checking them.

>  MODULE_DEVICE_TABLE(of, elan_of_match);
>  #endif
>
> diff --git a/include/linux/input/elan-i2c-ids.h 
> b/include/linux/input/elan-i2c-ids.h
> new file mode 100644
> index ..8130bbebbdda
> --- /dev/null
> +++ b/include/linux/input/elan-i2c-ids.h
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Elan I2C Touchpad devide whitelist

s/devide/device/

> + *
> + * Copyright (C) 2019 Jeffrey Hugo.  All rights reserved.

This just moves the code around. If anything I'd say it should keep
the original Elan copyright.

Thanks.

-- 
Dmitry

[PATCH v2 1/1] staging: media: fix style problem

[Aliasgar Surti]

From: Aliasgar Surti 

checkpatch reported "WARNING: line over 80 characters".
This patch fixes the warning for file davinci_vpfe/dm365_isif.c

Signed-off-by: Aliasgar Surti 
---
Changes in v2:
- Fixed styling as per suggestion in comments
 
 drivers/staging/media/davinci_vpfe/dm365_isif.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c 
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 46fd818..e9c8de1 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -532,7 +532,8 @@ static int isif_validate_dfc_params(const struct 
vpfe_isif_dfc *dfc)
 #define DM365_ISIF_MAX_CLVSV   0x1fff
 #define DM365_ISIF_MAX_HEIGHT_BLACK_REGION 0x1fff
 
-static int isif_validate_bclamp_params(const struct vpfe_isif_black_clamp 
*bclamp)
+static int
+isif_validate_bclamp_params(const struct vpfe_isif_black_clamp *bclamp)
 {
int err = -EINVAL;
 
@@ -593,7 +594,8 @@ isif_validate_raw_params(const struct vpfe_isif_raw_config 
*params)
return isif_validate_bclamp_params(>bclamp);
 }
 
-static int isif_set_params(struct v4l2_subdev *sd, const struct 
vpfe_isif_raw_config *params)
+static int isif_set_params(struct v4l2_subdev *sd,
+  const struct vpfe_isif_raw_config *params)
 {
struct vpfe_isif_device *isif = v4l2_get_subdevdata(sd);
int ret = -EINVAL;
-- 
2.7.4

Hi Dear,

[Mrs felicia william]

Hello,

Compliment of the day to you.

I am Mrs felicia william; I am sending this brief letter to solicit
your partnership to transfer $19.5 million US Dollars. I shall send
you more information and procedures when I receive positive response
from you. please send me a message in my Email box and here is
my(mrsfeliciawillam...@gmail.com)

Thanks
Best Regards,
Mrs felicia william

Re: [PATCH 2/2] pinctrl: mediatek: Update cur_mask in mask/mask ops

[Sean Wang]

Hi, Nicolas

On Sun, Apr 28, 2019 at 8:55 PM Nicolas Boichat  wrote:
>
> During suspend/resume, mtk_eint_mask may be called while
> wake_mask is active. For example, this happens if a wake-source
> with an active interrupt handler wakes the system:
> irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
> that it can be handled later on in the resume flow.
>
> However, this may happen before mtk_eint_do_resume is called:
> in this case, wake_mask is loaded, and cur_mask is restored
> from an older copy, re-enabling the interrupt, and causing
> an interrupt storm (especially for level interrupts).
>
> Instead, we just record mask/unmask changes in cur_mask. This
> also avoids the need to read the current mask in eint_do_suspend,
> and we can remove mtk_eint_chip_read_mask function.
>

The change is worth rewording the commit message you added above as an instance
and adding Fixes tag as a fixup to mean you're fixing the existing
problem in the driver.

And then Acked-by: Sean Wang 

> Signed-off-by: Nicolas Boichat 
> ---
>  drivers/pinctrl/mediatek/mtk-eint.c | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c 
> b/drivers/pinctrl/mediatek/mtk-eint.c
> index 737385e86beb807..7e526bcf5e0b55c 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_set);
>
> +   eint->cur_mask[d->hwirq >> 5] &= ~mask;
> +
> writel(mask, reg);
>  }
>
> @@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_clr);
>
> +   eint->cur_mask[d->hwirq >> 5] |= mask;
> +
> writel(mask, reg);
>
> if (eint->dual_edge[d->hwirq])
> @@ -217,19 +221,6 @@ static void mtk_eint_chip_write_mask(const struct 
> mtk_eint *eint,
> }
>  }
>
> -static void mtk_eint_chip_read_mask(const struct mtk_eint *eint,
> -   void __iomem *base, u32 *buf)
> -{
> -   int port;
> -   void __iomem *reg;
> -
> -   for (port = 0; port < eint->hw->ports; port++) {
> -   reg = base + eint->regs->mask + (port << 2);
> -   buf[port] = ~readl_relaxed(reg);
> -   /* Mask is 0 when irq is enabled, and 1 when disabled. */
> -   }
> -}
> -
>  static int mtk_eint_irq_request_resources(struct irq_data *d)
>  {
> struct mtk_eint *eint = irq_data_get_irq_chip_data(d);
> @@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
>
>  int mtk_eint_do_suspend(struct mtk_eint *eint)
>  {
> -   mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask);
> mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
>
> return 0;
> --
> 2.21.0.593.g511ec345e18-goog
>

Benötigen Sie einen dringenden Kredit?

[Ocean Finance]

--
Schönen Tag.
Benötigen Sie einen dringenden Kredit?

Wir bieten Unternehmen Darlehensdienstleistungen für 
Geschäftserweiterungen, Investitionen und Projekte an. Darüber hinaus 
bieten wir Privatkredite mit einem Zinssatz von 1,3% an. Wenn Sie sich 
jetzt bewerben, können Sie Ihre Transaktion innerhalb von 48/72 Stunden 
umgehend genehmigen lassen.


    Wenn Sie also interessiert sind, sollten Sie uns Ihre 
Bewerbungsdaten für eine dringende Antwort zusenden, um weitere 
Informationen an Sie zurückzusenden.



Vollständiger Name:..
Land:
Darlehensbetrag: 
Leihdauer: ..
Darlehen Zweck:...
Telefonnummer:...

Wir erwarten Ihre schnelle Antwort.

Freundliche Grüße.

Harris Cooper
Kundendienst / Berater

Ocean Finance
Think Park, Mosley Road, Trafford Park,
Manchester M17 1FQ, United Kingdom.

Re: [PATCH V33 27/30] lockdown: Print current->comm in restriction messages

[Kees Cook]

On Thu, Jun 20, 2019 at 06:19:38PM -0700, Matthew Garrett wrote:
> Print the content of current->comm in messages generated by lockdown to
> indicate a restriction that was hit.  This makes it a bit easier to find
> out what caused the message.
> 
> The message now patterned something like:
> 
> Lockdown: :  is restricted; see man kernel_lockdown.7
> 
> Signed-off-by: David Howells 
> Signed-off-by: Matthew Garrett 
> ---
>  security/lockdown/lockdown.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index 14edc475d75c..408f0048f8a2 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -80,8 +80,8 @@ early_param("lockdown", lockdown_param);
>  static int lockdown_is_locked_down(enum lockdown_reason what)
>  {
>   if ((kernel_locked_down >= what) && lockdown_reasons[what])
> - pr_notice("Lockdown: %s is restricted; see man 
> kernel_lockdown.7\n",
> -   lockdown_reasons[what]);
> + pr_notice("Lockdown: %s: %s is restricted; see man 
> kernel_lockdown.7\n",
> +   current->comm, lockdown_reasons[what]);
>   return (kernel_locked_down >= what);
>  }

Maybe needs ratelimiting?

>  
> -- 
> 2.22.0.410.gd8fdbe21b5-goog
> 

-- 
Kees Cook

Kirkwood PCI Express and bridges

[Chris Packham]

Hi All,

I'm in the process of updating the kernel version used on our products 
from 4.4 -> 5.1.

We have one product that uses a Kirkwood CPU, IDT PCI bridge and Marvell 
Switch ASIC. The Switch ASIC presents as multiple PCI devices.

The hardware setup looks like this
__
[ Kirkwood ] --- [ IDT 5T5 ] ---+---  |  |
 +---  |  Switch  |
 +---  |  |
 +---  |__|

On the 4.4 based kernel things are fine

[root@awplus flash]# lspci -t
-[:00]---01.0-[01-06]00.0-[02-06]--+-02.0-[03]00.0
+-03.0-[04]00.0
+-04.0-[05]00.0
\-05.0-[06]00.0

But on the 5.1 based kernel things get a little weird

[root@awplus flash]# lspci -t
-[:00]---01.0-[01-06]--+-00.0-[02-06]--
+-01.0
+-02.0-[02-06]--
+-03.0-[02-06]--
+-04.0-[02-06]--
+-05.0-[02-06]--
+-06.0-[02-06]--
+-07.0-[02-06]--
+-08.0-[02-06]--
+-09.0-[02-06]--
+-0a.0-[02-06]--
+-0b.0-[02-06]--
+-0c.0-[02-06]--
+-0d.0-[02-06]--
+-0e.0-[02-06]--
+-0f.0-[02-06]--
+-10.0-[02-06]--
+-11.0-[02-06]--
+-12.0-[02-06]--
+-13.0-[02-06]--
+-14.0-[02-06]--
+-15.0-[02-06]--
+-16.0-[02-06]--
+-17.0-[02-06]--
+-18.0-[02-06]--
+-19.0-[02-06]--
+-1a.0-[02-06]--
+-1b.0-[02-06]--
+-1c.0-[02-06]--
+-1d.0-[02-06]--
+-1e.0-[02-06]--
\-1f.0-[02-06]--+-02.0-[03]00.0
+-03.0-[04]00.0
+-04.0-[05]00.0
\-05.0-[06]00.0


I'll start bisecting to see where things started going wrong. I just 
wondered if this rings any bells for anyone.

The startup output also seems to be quite unhappy

Detected board: alliedtelesis,SBx81GC40
Booting into Linux kernel ...
** 143 printk messages dropped **
pci :01:19.0: PME# supported from D0 D3hot D3cold
pci :01:1a.0: [111d:803c] type 01 class 0x060400
pci :01:1a.0: PME# supported from D0 D3hot D3cold
pci :01:1b.0: [111d:803c] type 01 class 0x060400
pci :01:1b.0: PME# supported from D0 D3hot D3cold
pci :01:1c.0: [111d:803c] type 01 class 0x060400
pci :01:1c.0: PME# supported from D0 D3hot D3cold
pci :01:1d.0: [111d:803c] type 01 class 0x060400
pci :01:1d.0: PME# supported from D0 D3hot D3cold
pci :01:1e.0: [111d:803c] type 01 class 0x060400
pci :01:1e.0: PME# supported from D0 D3hot D3cold
pci :01:1f.0: [111d:803c] type 01 class 0x060400
pci :01:1f.0: PME# supported from D0 D3hot D3cold
PCI: bus1: Fast back to back transfers disabled
pci :01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:07.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:08.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:09.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0a.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0b.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0c.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0d.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0e.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:0f.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:10.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:11.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:12.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:13.0: bridge 

Re: [PATCH 4.4 00/84] 4.4.183-stable review

[Naresh Kamboju]

On Thu, 20 Jun 2019 at 23:28, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.4.183 release.
> There are 84 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 22 Jun 2019 05:42:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.183-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.183-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 847c345985fd296caa81af3820e8185f0d716159
git describe: v4.4.182-85-g847c345985fd
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.182-85-g847c345985fd


No regressions (compared to build v4.4.182)

No fixes (compared to build v4.4.182)

Ran 20007 total tests in the following environments and test suites.

Environments
--
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* prep-tmp-disk
* spectre-meltdown-checker-test
* kvm-unit-tests
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Summary


kernel: 4.4.183-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.183-rc1-hikey-20190620-466
git commit: 3e8bd9046c869be462eabbeff74037861c7b2c22
git describe: 4.4.183-rc1-hikey-20190620-466
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.183-rc1-hikey-20190620-466


No regressions (compared to build 4.4.183-rc1-hikey-20190620-465)

No fixes (compared to build 4.4.183-rc1-hikey-20190620-465)

Ran 1550 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance

-- 
Linaro LKFT
https://lkft.linaro.org

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

[Stephen Rothwell]

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "css_next_descendant_pre" [block/bfq.ko] undefined!

Probably caused by commit

  8060c47ba853 ("block: rename CONFIG_DEBUG_BLK_CGROUP to 
CONFIG_BFQ_CGROUP_DEBUG")

I have used the block tree from next-20190620 for today.

-- 
Cheers,
Stephen Rothwell


pgp1Pqmsac90w.pgp
Description: OpenPGP digital signature

Re: [PATCH 5.1 00/98] 5.1.13-stable review

[Naresh Kamboju]

On Thu, 20 Jun 2019 at 23:44, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.1.13 release.
> There are 98 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 22 Jun 2019 05:42:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.13-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.1.13-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.1.y
git commit: 10bbe23e94c5975292d0a3ff74893d1625c1e07c
git describe: v5.1.12-99-g10bbe23e94c5
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.12-99-g10bbe23e94c5

No regressions (compared to build v5.1.12)

No fixes (compared to build v5.1.12)

Ran 24447 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.19 00/61] 4.19.54-stable review

[Naresh Kamboju]

On Thu, 20 Jun 2019 at 23:40, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.54 release.
> There are 61 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 22 Jun 2019 05:42:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.54-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.54-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 8661e38ef458269230688e503c5a1c50232e5fa2
git describe: v4.19.53-62-g8661e38ef458
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.53-62-g8661e38ef458


No regressions (compared to build v4.19.53)

No fixes (compared to build v4.19.53)

Ran 23617 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH] net: fddi: skfp: remove generic PCI defines from skfbi.h

[kbuild test robot]

Hi Puranjay,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v5.2-rc5 next-20190620]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Puranjay-Mohan/net-fddi-skfp-remove-generic-PCI-defines-from-skfbi-h/20190621-081729
config: x86_64-randconfig-s4-06211045 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from drivers/net/fddi/skfp/drvfbi.c:17:0:
   drivers/net/fddi/skfp/drvfbi.c: In function 'card_start':
>> drivers/net/fddi/skfp/drvfbi.c:130:21: error: 'PCI_REV_ID' undeclared (first 
>> use in this function); did you mean 'PCI_DEV_ID0'?
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
^
   drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
#define inp(p)  ioread8(p)
^
   drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
#define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
 ^~~~
   drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
  ^
   drivers/net/fddi/skfp/drvfbi.c:130:21: note: each undeclared identifier is 
reported only once for each function it appears in
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
^
   drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
#define inp(p)  ioread8(p)
^
   drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
#define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
 ^~~~
   drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
  ^

vim +130 drivers/net/fddi/skfp/drvfbi.c

^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16  @17  #include 
"h/types.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   18  #include 
"h/fddi.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   19  #include 
"h/smc.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   20  #include 
"h/supern_2.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   21  #include 
"h/skfbiinc.h"
bc63eb9c drivers/net/skfp/drvfbi.c Akinobu Mita   2006-12-19   22  #include 

^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   23  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   24  #ifndef  
lint
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   25  static const 
char ID_sccs[] = "@(#)drvfbi.c  1.63 99/02/11 (C) SK " ;
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   26  #endif
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   27  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   28  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   29   * PCM 
active state
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   30   */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   31  #define 
PC8_ACTIVE   8
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   32  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   33  #define  
LED_Y_ON0x11/* Used for ring up/down indication */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   34  #define  
LED_Y_OFF   0x10
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   35  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   36  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   37  #define 
MS2BCLK(x)   ((x)*12500L)
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   38  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   39  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   40   * valid 
configuration values are:
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   41   */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   42  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   43  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   44   *   
xPOS_ID:
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   45   *   |   
\  /
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   46   *   |   
 \/
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   47   *   |   
  - the patched POS_ID of the Adapter
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   48   *   |   

[PATCH] dt-binding: mmc: rename tmio_mmc.txt to renesas_sdhi.txt

[Masahiro Yamada]

As commit b6147490e6aa ("mmc: tmio: split core functionality, DMA and
MFD glue") said, these MMC controllers use the IP from Panasonic.

TMIO (Toshiba Mobile IO) MMC was the first upstreamed user of this IP.
The common driver code was split and expanded as 'tmio-mmc-core', then
it become historical misnomer since 'tmio' is not the name of this IP
in the first place.

In the discussion [1], we decide to keep calling these MMC variants
'TMIO MMC' at least in Linux driver level because renaming all of them
is a big churn.

However, DT should not be oriented to a particular project even though
it is developed in Linux communities.

Let's stop exporting this unfortunate things to other projects, where
there is no good reason to call this "TMIO". Rename the file to
renesas_sdhi.txt. In fact, all the information in this file is specific
to the Renesas platform.

This commit also removes the first paragraph entirely. The DT-binding
should describe the hardware. It is really strange to talk about Linux
driver internals such as how the drivers are probed, how platform data
are handed off, etc.

[1] https://www.spinics.net/lists/linux-mmc/msg46952.html

Signed-off-by: Masahiro Yamada 
---

I sent this before, but it was dismissed somehow.
I am resending this.


 .../bindings/mmc/{tmio_mmc.txt => renesas_sdhi.txt}   | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)
 rename Documentation/devicetree/bindings/mmc/{tmio_mmc.txt => 
renesas_sdhi.txt} (87%)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/renesas_sdhi.txt
similarity index 87%
rename from Documentation/devicetree/bindings/mmc/tmio_mmc.txt
rename to Documentation/devicetree/bindings/mmc/renesas_sdhi.txt
index 2b4f17ca9087..dd08d038a65c 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/renesas_sdhi.txt
@@ -1,13 +1,4 @@
-* Toshiba Mobile IO SD/MMC controller
-
-The tmio-mmc driver doesn't probe its devices actively, instead its binding to
-devices is managed by either MFD drivers or by the sh_mobile_sdhi platform
-driver. Those drivers supply the tmio-mmc driver with platform data, that 
either
-describe hardware capabilities, known to them, or are obtained by them from
-their own platform data or from their DT information. In the latter case all
-compulsory and any optional properties, common to all SD/MMC drivers, as
-described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
-optional bindings can be used.
+* Renesas SDHI SD/MMC controller
 
 Required properties:
 - compatible: should contain one or more of the following:
-- 
2.17.1

Re: [PATCH 4.14 00/45] 4.14.129-stable review

[Naresh Kamboju]

On Thu, 20 Jun 2019 at 23:39, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.14.129 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 22 Jun 2019 05:42:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.129-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.129-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 7741fd984e5da7edc8b42719cac2db8d8f56b9a3
git describe: v4.14.128-46-g7741fd984e5d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.128-46-g7741fd984e5d


No regressions (compared to build v4.14.128)

No fixes (compared to build v4.14.128)


Ran 23866 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH V33 04/30] Enforce module signatures if the kernel is locked down

[Kees Cook]

On Thu, Jun 20, 2019 at 06:19:15PM -0700, Matthew Garrett wrote:
> From: David Howells 
> 
> If the kernel is locked down, require that all modules have valid
> signatures that we can verify.
> 
> I have adjusted the errors generated:
> 
>  (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
>  ENOKEY), then:
> 
>  (a) If signatures are enforced then EKEYREJECTED is returned.
> 
>  (b) If there's no signature or we can't check it, but the kernel is
>locked down then EPERM is returned (this is then consistent with
>other lockdown cases).
> 
>  (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
>  the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
>  return the error we got.
> 
> Note that the X.509 code doesn't check for key expiry as the RTC might not
> be valid or might not have been transferred to the kernel's clock yet.
> 
>  [Modified by Matthew Garrett to remove the IMA integration. This will
>   be replaced with integration with the IMA architecture policy
>   patchset.]
> 
> Signed-off-by: David Howells 
> Signed-off-by: Matthew Garrett 
> Cc: Jessica Yu 
> ---
>  include/linux/security.h |  1 +
>  kernel/module.c  | 39 +---
>  security/lockdown/lockdown.c |  1 +
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/security.h b/include/linux/security.h
> index a86a7739ca24..a7612b03b42a 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -82,6 +82,7 @@ enum lsm_event {
>   */
>  enum lockdown_reason {
>   LOCKDOWN_NONE,
> + LOCKDOWN_MODULE_SIGNATURE,
>   LOCKDOWN_INTEGRITY_MAX,
>   LOCKDOWN_CONFIDENTIALITY_MAX,
>  };
> diff --git a/kernel/module.c b/kernel/module.c
> index 0b9aa8ab89f0..780e9605ff88 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2763,8 +2763,9 @@ static inline void kmemleak_load_module(const struct 
> module *mod,
>  #ifdef CONFIG_MODULE_SIG
>  static int module_sig_check(struct load_info *info, int flags)
>  {
> - int err = -ENOKEY;
> + int err = -ENODATA;
>   const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> + const char *reason;
>   const void *mod = info->hdr;
>  
>   /*
> @@ -2779,16 +2780,40 @@ static int module_sig_check(struct load_info *info, 
> int flags)
>   err = mod_verify_sig(mod, info);
>   }
>  
> - if (!err) {
> + switch (err) {
> + case 0:
>   info->sig_ok = true;
>   return 0;
> - }
>  
> - /* Not having a signature is only an error if we're strict. */
> - if (err == -ENOKEY && !is_module_sig_enforced())
> - err = 0;
> + /* We don't permit modules to be loaded into trusted kernels
> +  * without a valid signature on them, but if we're not
> +  * enforcing, certain errors are non-fatal.
> +  */
> + case -ENODATA:
> + reason = "Loading of unsigned module";
> + goto decide;
> + case -ENOPKG:
> + reason = "Loading of module with unsupported crypto";
> + goto decide;
> + case -ENOKEY:
> + reason = "Loading of module with unavailable key";
> + decide:
> + if (is_module_sig_enforced()) {
> + pr_notice("%s is rejected\n", reason);
> + return -EKEYREJECTED;
> + }
>  
> - return err;
> + if (security_is_locked_down(LOCKDOWN_MODULE_SIGNATURE))
> + return -EPERM;

LSM hooks should return the desired error code. Here and in all the
other patches, I'd expect to see stuff like:

ret = security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
if (ret)
return ret;


> + return 0;
> +
> + /* All other errors are fatal, including nomem, unparseable
> +  * signatures and signature check failures - even if signatures
> +  * aren't required.
> +  */
> + default:
> + return err;
> + }
>  }
>  #else /* !CONFIG_MODULE_SIG */
>  static int module_sig_check(struct load_info *info, int flags)
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index 1ecb2eecb245..08abd7e6609b 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -18,6 +18,7 @@ static enum lockdown_reason kernel_locked_down;
>  
>  static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>   [LOCKDOWN_NONE] = "none",
> + [LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
>   [LOCKDOWN_INTEGRITY_MAX] = "integrity",
>   [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
>  };
> -- 
> 2.22.0.410.gd8fdbe21b5-goog
> 

-- 
Kees Cook

Re: [PATCH V33 03/30] security: Add a static lockdown policy LSM

[Kees Cook]

On Thu, Jun 20, 2019 at 06:19:14PM -0700, Matthew Garrett wrote:
> While existing LSMs can be extended to handle lockdown policy,
> distributions generally want to be able to apply a straightforward
> static policy. This patch adds a simple LSM that can be configured to
> reject either integrity or all lockdown queries, and can be configured
> at runtime (through securityfs), boot time (via a kernel parameter) or
> build time (via a kconfig option). Based on initial code by David
> Howells.
> 
> Signed-off-by: Matthew Garrett 
> Cc: David Howells 
> ---
>  .../admin-guide/kernel-parameters.txt |   9 +
>  include/linux/security.h  |   4 +
>  security/Kconfig  |   3 +-
>  security/Makefile |   2 +
>  security/lockdown/Kconfig |  46 +
>  security/lockdown/Makefile|   1 +
>  security/lockdown/lockdown.c  | 168 ++
>  7 files changed, 232 insertions(+), 1 deletion(-)
>  create mode 100644 security/lockdown/Kconfig
>  create mode 100644 security/lockdown/Makefile
>  create mode 100644 security/lockdown/lockdown.c
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 2b8ee90bb644..fa336f6cd5bc 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2239,6 +2239,15 @@
>   lockd.nlm_udpport=M [NFS] Assign UDP port.
>   Format: 
>  
> + lockdown=   [SECURITY]
> + { integrity | confidentiality }
> + Enable the kernel lockdown feature. If set to
> + integrity, kernel features that allow userland to
> + modify the running kernel are disabled. If set to
> + confidentiality, kernel features that allow userland
> + to extract confidential information from the kernel
> + are also disabled.
> +
>   locktorture.nreaders_stress= [KNL]
>   Set the number of locking read-acquisition kthreads.
>   Defaults to being automatically set based on the
> diff --git a/include/linux/security.h b/include/linux/security.h
> index b75941c811e6..a86a7739ca24 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -76,6 +76,10 @@ enum lsm_event {
>   LSM_POLICY_CHANGE,
>  };
>  
> +/*
> + *  If you add to this, remember to extend lockdown_reasons in
> + *  security/lockdown/lockdown.c.
> + */

Best to add something like:

BUILD_BUG_ON(ARRAY_SIZE(lockdown_reasons), LOCKDOWN_CONFIDENTIALLY_MAX);

to actually enforce this.

>  enum lockdown_reason {
>   LOCKDOWN_NONE,
>   LOCKDOWN_INTEGRITY_MAX,
> diff --git a/security/Kconfig b/security/Kconfig
> index 1d6463fb1450..c35aa72103df 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -236,12 +236,13 @@ source "security/apparmor/Kconfig"
>  source "security/loadpin/Kconfig"
>  source "security/yama/Kconfig"
>  source "security/safesetid/Kconfig"
> +source "security/lockdown/Kconfig"
>  
>  source "security/integrity/Kconfig"
>  
>  config LSM
>   string "Ordered list of enabled LSMs"
> - default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
> + default 
> "lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"

Is this needed? It seems like the early LSMs are totally ignored for
ordering?

>   help
> A comma-separated list of LSMs, in initialization order.
> Any LSMs left off this list will be ignored. This can be
> diff --git a/security/Makefile b/security/Makefile
> index c598b904938f..be1dd9d2cb2f 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -11,6 +11,7 @@ subdir-$(CONFIG_SECURITY_APPARMOR)  += apparmor
>  subdir-$(CONFIG_SECURITY_YAMA)   += yama
>  subdir-$(CONFIG_SECURITY_LOADPIN)+= loadpin
>  subdir-$(CONFIG_SECURITY_SAFESETID)+= safesetid
> +subdir-$(CONFIG_SECURITY_LOCKDOWN_LSM)   += lockdown
>  
>  # always enable default capabilities
>  obj-y+= commoncap.o
> @@ -27,6 +28,7 @@ obj-$(CONFIG_SECURITY_APPARMOR) += apparmor/
>  obj-$(CONFIG_SECURITY_YAMA)  += yama/
>  obj-$(CONFIG_SECURITY_LOADPIN)   += loadpin/
>  obj-$(CONFIG_SECURITY_SAFESETID)   += safesetid/
> +obj-$(CONFIG_SECURITY_LOCKDOWN_LSM)  += lockdown/
>  obj-$(CONFIG_CGROUP_DEVICE)  += device_cgroup.o
>  
>  # Object integrity file lists
> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> new file mode 100644
> index ..431cd2b9a14e
> --- /dev/null
> +++ b/security/lockdown/Kconfig
> @@ -0,0 +1,46 @@
> +config SECURITY_LOCKDOWN_LSM
> + bool "Basic module for enforcing kernel lockdown"
> + depends on SECURITY
> + help
> +   Build support 

Re: [PATCH] net: fddi: skfp: remove generic PCI defines from skfbi.h

[Puranjay Mohan]

On Fri, Jun 21, 2019 at 10:35:04AM +0800, kbuild test robot wrote:
> Hi Puranjay,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on net/master]
> [also build test ERROR on v5.2-rc5 next-20190620]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Puranjay-Mohan/net-fddi-skfp-remove-generic-PCI-defines-from-skfbi-h/20190621-081729
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=sparc64 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from drivers/net/fddi/skfp/drvfbi.c:17:0:
>drivers/net/fddi/skfp/drvfbi.c: In function 'card_start':
> >> drivers/net/fddi/skfp/drvfbi.c:130:21: error: 'PCI_REV_ID' undeclared 
> >> (first use in this function); did you mean 'PCI_DEVID'?
>  rev_id = inp(PCI_C(PCI_REV_ID)) ;
> ^
>drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
> #define inp(p)  ioread8(p)
> ^
> >> drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
> #define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
>  ^~~~
> >> drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
>  rev_id = inp(PCI_C(PCI_REV_ID)) ;
>   ^
>drivers/net/fddi/skfp/drvfbi.c:130:21: note: each undeclared identifier is 
> reported only once for each function it appears in
>  rev_id = inp(PCI_C(PCI_REV_ID)) ;
> ^
>drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
> #define inp(p)  ioread8(p)
> ^
> >> drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
> #define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
>  ^~~~
> >> drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
>  rev_id = inp(PCI_C(PCI_REV_ID)) ;
>   ^
> 
> vim +130 drivers/net/fddi/skfp/drvfbi.c
> 
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16  @17  #include 
> "h/types.h"
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   18  #include 
> "h/fddi.h"
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   19  #include 
> "h/smc.h"
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   20  #include 
> "h/supern_2.h"
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   21  #include 
> "h/skfbiinc.h"
> bc63eb9c drivers/net/skfp/drvfbi.c Akinobu Mita   2006-12-19   22  #include 
> 
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   23  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   24  #ifndef
> lint
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   25  static 
> const char ID_sccs[] = "@(#)drvfbi.c1.63 99/02/11 (C) SK " ;
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   26  #endif
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   27  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   28  /*
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   29   * PCM 
> active state
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   30   */
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   31  #define 
> PC8_ACTIVE 8
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   32  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   33  #define
> LED_Y_ON0x11/* Used for ring up/down indication */
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   34  #define
> LED_Y_OFF   0x10
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   35  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   36  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   37  #define 
> MS2BCLK(x) ((x)*12500L)
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   38  
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   39  /*
> ^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   40 

[PATCH] staging: ks7010: Fix build error

[YueHaibing]

when CRYPTO is m and KS7010 is y, building fails:

drivers/staging/ks7010/ks_hostif.o: In function `michael_mic.constprop.13':
ks_hostif.c:(.text+0x560): undefined reference to `crypto_alloc_shash'
ks_hostif.c:(.text+0x580): undefined reference to `crypto_shash_setkey'
ks_hostif.c:(.text+0x5e0): undefined reference to `crypto_destroy_tfm'
ks_hostif.c:(.text+0x614): undefined reference to `crypto_shash_update'
ks_hostif.c:(.text+0x62c): undefined reference to `crypto_shash_update'
ks_hostif.c:(.text+0x648): undefined reference to `crypto_shash_finup'

select CRYPTO and CRYPTO_HASH to fix this.

Reported-by: Hulk Robot 
Fixes: 8b523f20417d ("staging: ks7010: removed custom Michael MIC 
implementation.")
Signed-off-by: YueHaibing 
---
 drivers/staging/ks7010/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/ks7010/Kconfig b/drivers/staging/ks7010/Kconfig
index 0987fdc..6a20e64 100644
--- a/drivers/staging/ks7010/Kconfig
+++ b/drivers/staging/ks7010/Kconfig
@@ -5,6 +5,8 @@ config KS7010
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
+   select CRYPTO
+   select CRYPTO_HASH
help
  This is a driver for KeyStream KS7010 based SDIO WIFI cards. It is
  found on at least later Spectec SDW-821 (FCC-ID "S2Y-WLAN-11G-K" only,
-- 
2.7.4

Re: [PATCH -next] ASoC: SOF: Intel: hda: remove duplicated include from hda.c

[Pierre-Louis Bossart]

On 6/20/19 4:57 PM, YueHaibing wrote:

Remove duplicated include.

Signed-off-by: YueHaibing 


Acked-by: Pierre-Louis Bossart 


---
  sound/soc/sof/intel/hda.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
index 51c1c1787de7..7f665392618f 100644
--- a/sound/soc/sof/intel/hda.c
+++ b/sound/soc/sof/intel/hda.c
@@ -19,7 +19,6 @@
  #include 
  
  #include 

-#include 
  #include 
  #include 
  #include "../ops.h"

Re: [PATCH V33 02/30] security: Add a "locked down" LSM hook

[Kees Cook]

On Thu, Jun 20, 2019 at 06:19:13PM -0700, Matthew Garrett wrote:
> Add a mechanism to allow LSMs to make a policy decision around whether
> kernel functionality that would allow tampering with or examining the
> runtime state of the kernel should be permitted.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  include/linux/lsm_hooks.h |  2 ++
>  include/linux/security.h  | 11 +++
>  security/security.c   |  6 ++
>  3 files changed, 19 insertions(+)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 66fd1eac7a32..df2aebc99838 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1790,6 +1790,7 @@ union security_list_options {
>   int (*bpf_prog_alloc_security)(struct bpf_prog_aux *aux);
>   void (*bpf_prog_free_security)(struct bpf_prog_aux *aux);
>  #endif /* CONFIG_BPF_SYSCALL */
> + int (*locked_down)(enum lockdown_reason what);
>  };
>  
>  struct security_hook_heads {
> @@ -2027,6 +2028,7 @@ struct security_hook_heads {
>   struct hlist_head bpf_prog_alloc_security;
>   struct hlist_head bpf_prog_free_security;
>  #endif /* CONFIG_BPF_SYSCALL */
> + struct hlist_head locked_down;
>  } __randomize_layout;
>  
>  /*
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 1bb6fb2f1523..b75941c811e6 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -76,6 +76,12 @@ enum lsm_event {
>   LSM_POLICY_CHANGE,
>  };
>  
> +enum lockdown_reason {
> + LOCKDOWN_NONE,
> + LOCKDOWN_INTEGRITY_MAX,
> + LOCKDOWN_CONFIDENTIALITY_MAX,
> +};
> +
>  /* These functions are in security/commoncap.c */
>  extern int cap_capable(const struct cred *cred, struct user_namespace *ns,
>  int cap, unsigned int opts);
> @@ -389,6 +395,7 @@ void security_inode_invalidate_secctx(struct inode 
> *inode);
>  int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
>  int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
>  int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
> +int security_is_locked_down(enum lockdown_reason what);

bikeshed: can this just be called "security_locked_down" without the
"is"?

-Kees

>  #else /* CONFIG_SECURITY */
>  
>  static inline int call_lsm_notifier(enum lsm_event event, void *data)
> @@ -1189,6 +1196,10 @@ static inline int security_inode_getsecctx(struct 
> inode *inode, void **ctx, u32
>  {
>   return -EOPNOTSUPP;
>  }
> +static inline int security_is_locked_down(enum lockdown_reason what)
> +{
> + return 0;
> +}
>  #endif   /* CONFIG_SECURITY */
>  
>  #ifdef CONFIG_SECURITY_NETWORK
> diff --git a/security/security.c b/security/security.c
> index 2a6672c9e72f..17c17d4d8552 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2378,3 +2378,9 @@ void security_bpf_prog_free(struct bpf_prog_aux *aux)
>   call_void_hook(bpf_prog_free_security, aux);
>  }
>  #endif /* CONFIG_BPF_SYSCALL */
> +
> +int security_is_locked_down(enum lockdown_reason what)
> +{
> + return call_int_hook(locked_down, 0, what);
> +}
> +EXPORT_SYMBOL(security_is_locked_down);
> -- 
> 2.22.0.410.gd8fdbe21b5-goog
> 

-- 
Kees Cook

Re: [PATCH V33 01/30] security: Support early LSMs

[Kees Cook]

On Thu, Jun 20, 2019 at 06:19:12PM -0700, Matthew Garrett wrote:
> The lockdown module is intended to allow for kernels to be locked down
> early in boot - sufficiently early that we don't have the ability to
> kmalloc() yet. Add support for early initialisation of some LSMs, and
> then add them to the list of names when we do full initialisation later.

So, if I'm reading correctly, these "early LSMs":

- start up before even boot parameter parsing has happened
- have their position in the LSM ordering ignored
- are initialized in boot order
- cannot use kmalloc, as well as probably lots of other things

> 
> Signed-off-by: Matthew Garrett 
> ---
>  include/asm-generic/vmlinux.lds.h |  8 +-
>  include/linux/lsm_hooks.h |  6 
>  include/linux/security.h  |  1 +
>  init/main.c   |  1 +
>  security/security.c   | 48 +--
>  5 files changed, 54 insertions(+), 10 deletions(-)
> 
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index f8f6f04c4453..e1963352fdb6 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -208,8 +208,13 @@
>   __start_lsm_info = .;   \
>   KEEP(*(.lsm_info.init)) \
>   __end_lsm_info = .;
> +#define EARLY_LSM_TABLE(). = ALIGN(8);   \
> + __start_early_lsm_info = .; \
> + KEEP(*(.early_lsm_info.init))   \
> + __end_early_lsm_info = .;
>  #else
>  #define LSM_TABLE()
> +#define EARLY_LSM_TABLE()
>  #endif
>  
>  #define ___OF_TABLE(cfg, name)   _OF_TABLE_##cfg(name)
> @@ -610,7 +615,8 @@
>   ACPI_PROBE_TABLE(irqchip)   \
>   ACPI_PROBE_TABLE(timer) \
>   EARLYCON_TABLE()\
> - LSM_TABLE()
> + LSM_TABLE() \
> + EARLY_LSM_TABLE()
>  
>  #define INIT_TEXT\
>   *(.init.text .init.text.*)  \
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index a240a3fc5fc4..66fd1eac7a32 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2085,12 +2085,18 @@ struct lsm_info {
>  };
>  
>  extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
> +extern struct lsm_info __start_early_lsm_info[], __end_early_lsm_info[];
>  
>  #define DEFINE_LSM(lsm)  
> \
>   static struct lsm_info __lsm_##lsm  \
>   __used __section(.lsm_info.init)\
>   __aligned(sizeof(unsigned long))
>  
> +#define DEFINE_EARLY_LSM(lsm)
> \
> + static struct lsm_info __early_lsm_##lsm\
> + __used __section(.early_lsm_info.init)  \
> + __aligned(sizeof(unsigned long))
> +
>  #ifdef CONFIG_SECURITY_SELINUX_DISABLE
>  /*
>   * Assuring the safety of deleting a security module is up to
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 49f2685324b0..1bb6fb2f1523 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -194,6 +194,7 @@ int unregister_lsm_notifier(struct notifier_block *nb);
>  
>  /* prototypes */
>  extern int security_init(void);
> +extern int early_security_init(void);
>  
>  /* Security operations */
>  int security_binder_set_context_mgr(struct task_struct *mgr);
> diff --git a/init/main.c b/init/main.c
> index 598e278b46f7..f3faeb89c75f 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -563,6 +563,7 @@ asmlinkage __visible void __init start_kernel(void)
>   boot_cpu_init();
>   page_address_init();
>   pr_notice("%s", linux_banner);
> + early_security_init();
>   setup_arch(_line);
>   /*
>* Set up the the initial canary and entropy after arch
> diff --git a/security/security.c b/security/security.c
> index 23cbb1a295a3..2a6672c9e72f 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -37,6 +37,7 @@
>  
>  /* How many LSMs were built into the kernel? */
>  #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
> +#define EARLY_LSM_COUNT (__end_early_lsm_info - __start_early_lsm_info)
>  
>  struct security_hook_heads security_hook_heads __lsm_ro_after_init;
>  static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
> @@ -281,6 +282,8 @@ static void __init ordered_lsm_parse(const char *order, 
> const char *origin)
>  static void __init lsm_early_cred(struct cred *cred);
>  static void __init lsm_early_task(struct task_struct *task);
>  
> +static int 

Re: [PATCH] dmaengine: tegra210-adma: fix transfer failure

[Sameer Pujar]

On 6/20/2019 10:13 PM, Jon Hunter wrote:

On 20/06/2019 17:15, Sameer Pujar wrote:

 From Tegra186 onwards OUTSTANDING_REQUESTS field is added in channel
configuration register (bits 7:4). ADMA allows a maximum of 8 reads
to source and that many writes to target memory be outstanding at any
given point of time. If this field is not programmed, DMA transfers
fail to happen.

BTW, I am not sure I follow the above. You say a max of 8 reads to the
source, however, the field we are programming can have a value of up to
15. So does that mean this field should only be programmed with a max of 8?

Yes. As per spec. ADMA allows max value of 8.

Thanks
Jon

Re: [PATCH] dmaengine: tegra210-adma: fix transfer failure

[Sameer Pujar]

On 6/20/2019 10:07 PM, Jon Hunter wrote:

On 20/06/2019 17:15, Sameer Pujar wrote:

 From Tegra186 onwards OUTSTANDING_REQUESTS field is added in channel
configuration register (bits 7:4). ADMA allows a maximum of 8 reads
to source and that many writes to target memory be outstanding at any
given point of time. If this field is not programmed, DMA transfers
fail to happen.

Thus added 'ch_pending_req' member in chip data structure and the
same is populated with maximum allowed pending requests. Since the
field is not applicable to Tegra210, mentioned bit fields are unused
and hence the member is initialized with 0.

Fixes: 433de642a76c ("dmaengine: tegra210-adma: add support for 
Tegra186/Tegra194")

Signed-off-by: Sameer Pujar 
---
  drivers/dma/tegra210-adma.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 17ea4dd99..8d291cf 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -96,6 +96,7 @@ struct tegra_adma;
   * @ch_req_tx_shift: Register offset for AHUB transmit channel select.
   * @ch_req_rx_shift: Register offset for AHUB receive channel select.
   * @ch_base_offset: Register offset of DMA channel registers.
+ * @ch_pending_req: Outstaning DMA requests for a channel.
   * @ch_fifo_ctrl: Default value for channel FIFO CTRL register.
   * @ch_req_mask: Mask for Tx or Rx channel select.
   * @ch_req_max: Maximum number of Tx or Rx channels available.
@@ -109,6 +110,7 @@ struct tegra_adma_chip_data {
unsigned int ch_req_tx_shift;
unsigned int ch_req_rx_shift;
unsigned int ch_base_offset;
+   unsigned int ch_pending_req;
unsigned int ch_fifo_ctrl;
unsigned int ch_req_mask;
unsigned int ch_req_max;
@@ -613,6 +615,7 @@ static int tegra_adma_set_xfer_params(struct 
tegra_adma_chan *tdc,
 ADMA_CH_CTRL_FLOWCTRL_EN;
ch_regs->config |= cdata->adma_get_burst_config(burst_size);
ch_regs->config |= ADMA_CH_CONFIG_WEIGHT_FOR_WRR(1);
+   ch_regs->config |= cdata->ch_pending_req;
ch_regs->fifo_ctrl = cdata->ch_fifo_ctrl;
ch_regs->tc = desc->period_len & ADMA_CH_TC_COUNT_MASK;
  
@@ -797,6 +800,7 @@ static const struct tegra_adma_chip_data tegra210_chip_data = {

.ch_req_tx_shift= 28,
.ch_req_rx_shift= 24,
.ch_base_offset = 0,
+   .ch_pending_req = 0,
.ch_fifo_ctrl   = TEGRA210_FIFO_CTRL_DEFAULT,
.ch_req_mask= 0xf,
.ch_req_max = 10,
@@ -811,6 +815,7 @@ static const struct tegra_adma_chip_data tegra186_chip_data 
= {
.ch_req_tx_shift= 27,
.ch_req_rx_shift= 22,
.ch_base_offset = 0x1,
+   .ch_pending_req = (8 << 4),

So given that this is a value and a shift, I think that we should add a
proper definition like we have for TEGRA186_FIFO_CTRL_DEFAULT below.

I can add.



.ch_fifo_ctrl   = TEGRA186_FIFO_CTRL_DEFAULT,
.ch_req_mask= 0x1f,
.ch_req_max = 20,


Please group your patches into a series if you have more than one for a
given driver.
The other ADMA related change is in Kconfig and a simple change. Current 
patch can go through some review

cycles. Hence didn't want to delay the other patch.

Cheers
Jon

[PATCH v2 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

[Gwendal Grignou]

To allow cros_ec iio core library to be used with legacy device, add a
vector to rotate sensor data if necessary: legacy devices are not
reporting data in HTML5/Android sensor referential.

On veyron minnie, check chrome detect tablet mode and rotate
screen in tablet mode.

Signed-off-by: Gwendal Grignou 
---
 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 4 
 include/linux/iio/common/cros_ec_sensors_core.h   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c 
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index 719a0df5aeeb..e8a4d78659c8 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
}
state->type = state->resp->info.type;
state->loc = state->resp->info.location;
+
+   /* Set sign vector, only used for backward compatibility. */
+   memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
}
 
return 0;
@@ -254,6 +257,7 @@ static int cros_ec_sensors_read_data_unsafe(struct iio_dev 
*indio_dev,
if (ret < 0)
return ret;
 
+   *data *= st->sign[i];
data++;
}
 
diff --git a/include/linux/iio/common/cros_ec_sensors_core.h 
b/include/linux/iio/common/cros_ec_sensors_core.h
index ce16445411ac..a1c85ad4df91 100644
--- a/include/linux/iio/common/cros_ec_sensors_core.h
+++ b/include/linux/iio/common/cros_ec_sensors_core.h
@@ -71,6 +71,7 @@ struct cros_ec_sensors_core_state {
enum motionsensor_location loc;
 
s16 calib[CROS_EC_SENSOR_MAX_AXIS];
+   s8 sign[CROS_EC_SENSOR_MAX_AXIS];
 
u8 samples[CROS_EC_SAMPLE_SIZE];
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH v2 2/2] iio: cros_ec : Extend legacy support to ARM device

[Gwendal Grignou]

Add support to ARM based devices, that lack LPC access code.
Allow cros-ec-accel-legacy to use cros-ec-sensors-core, add specific
command to capture sensor data.

On veyron minnie, check chrome detect tablet mode and rotate
screen in tablet mode.
Check only a subset of the attributes are presented.

Signed-off-by: Gwendal Grignou 
---
 drivers/iio/accel/Kconfig|   4 +-
 drivers/iio/accel/cros_ec_accel_legacy.c | 350 +--
 2 files changed, 79 insertions(+), 275 deletions(-)

diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 62a970a20219..7d0848f9ea45 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -201,9 +201,7 @@ config HID_SENSOR_ACCEL_3D
 
 config IIO_CROS_EC_ACCEL_LEGACY
tristate "ChromeOS EC Legacy Accelerometer Sensor"
-   select IIO_BUFFER
-   select IIO_TRIGGERED_BUFFER
-   select CROS_EC_LPC_REGISTER_DEVICE
+   depends on IIO_CROS_EC_SENSORS_CORE
help
  Say yes here to get support for accelerometers on Chromebook using
  legacy EC firmware.
diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c 
b/drivers/iio/accel/cros_ec_accel_legacy.c
index 46bb2e421bb9..575d7e4c685c 100644
--- a/drivers/iio/accel/cros_ec_accel_legacy.c
+++ b/drivers/iio/accel/cros_ec_accel_legacy.c
@@ -5,13 +5,14 @@
  * Copyright 2017 Google, Inc
  *
  * This driver uses the memory mapper cros-ec interface to communicate
- * with the Chrome OS EC about accelerometer data.
+ * with the Chrome OS EC about accelerometer data or older commands.
  * Accelerometer access is presented through iio sysfs.
  */
 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,160 +26,41 @@
 
 #define DRV_NAME   "cros-ec-accel-legacy"
 
+#define CROS_EC_SENSOR_LEGACY_NUM 2
 /*
  * Sensor scale hard coded at 10 bits per g, computed as:
  * g / (2^10 - 1) = 0.009586168; with g = 9.80665 m.s^-2
  */
 #define ACCEL_LEGACY_NSCALE 9586168
 
-/* Indices for EC sensor values. */
-enum {
-   X,
-   Y,
-   Z,
-   MAX_AXIS,
-};
-
-/* State data for cros_ec_accel_legacy iio driver. */
-struct cros_ec_accel_legacy_state {
-   struct cros_ec_device *ec;
-
-   /*
-* Array holding data from a single capture. 2 bytes per channel
-* for the 3 channels plus the timestamp which is always last and
-* 8-bytes aligned.
-*/
-   s16 capture_data[8];
-   s8 sign[MAX_AXIS];
-   u8 sensor_num;
-};
-
-static int ec_cmd_read_u8(struct cros_ec_device *ec, unsigned int offset,
- u8 *dest)
-{
-   return ec->cmd_readmem(ec, offset, 1, dest);
-}
-
-static int ec_cmd_read_u16(struct cros_ec_device *ec, unsigned int offset,
-  u16 *dest)
-{
-   __le16 tmp;
-   int ret = ec->cmd_readmem(ec, offset, 2, );
-
-   *dest = le16_to_cpu(tmp);
-
-   return ret;
-}
-
-/**
- * read_ec_until_not_busy() - Read from EC status byte until it reads not busy.
- * @st: Pointer to state information for device.
- *
- * This function reads EC status until its busy bit gets cleared. It does not
- * wait indefinitely and returns -EIO if the EC status is still busy after a
- * few hundreds milliseconds.
- *
- * Return: 8-bit status if ok, -EIO on error
- */
-static int read_ec_until_not_busy(struct cros_ec_accel_legacy_state *st)
-{
-   struct cros_ec_device *ec = st->ec;
-   u8 status;
-   int attempts = 0;
-
-   ec_cmd_read_u8(ec, EC_MEMMAP_ACC_STATUS, );
-   while (status & EC_MEMMAP_ACC_STATUS_BUSY_BIT) {
-   /* Give up after enough attempts, return error. */
-   if (attempts++ >= 50)
-   return -EIO;
-
-   /* Small delay every so often. */
-   if (attempts % 5 == 0)
-   msleep(25);
-
-   ec_cmd_read_u8(ec, EC_MEMMAP_ACC_STATUS, );
-   }
-
-   return status;
-}
-
-/**
- * read_ec_accel_data_unsafe() - Read acceleration data from EC shared memory.
- * @st:Pointer to state information for device.
- * @scan_mask: Bitmap of the sensor indices to scan.
- * @data:  Location to store data.
- *
- * This is the unsafe function for reading the EC data. It does not guarantee
- * that the EC will not modify the data as it is being read in.
- */
-static void read_ec_accel_data_unsafe(struct cros_ec_accel_legacy_state *st,
- unsigned long scan_mask, s16 *data)
-{
-   int i = 0;
-   int num_enabled = bitmap_weight(_mask, MAX_AXIS);
-
-   /* Read all sensors enabled in scan_mask. Each value is 2 bytes. */
-   while (num_enabled--) {
-   i = find_next_bit(_mask, MAX_AXIS, i);
-   ec_cmd_read_u16(st->ec,
-   EC_MEMMAP_ACC_DATA +
-   sizeof(s16) *
-   (1 + i + st->sensor_num * MAX_AXIS),
-   data);
-   

[PATCH 0/2] Support accelerometers for veyron_minnie

[Gwendal Grignou]

veyron_minnie - ASUS Chromebook Flip C100PA - embedded controller
controls two accelerometers, one in the lid, one in the base.
However, the EC firmware does not follow the new interface that
cros_ec_accel driver use.
Extend the legacy driver used on glimmer - Lenovo ThinkPad 11e
Chromebook - to veyron_minnie.
veyron_minnie being ARM based, issue command over the I2C bus to the EC
instead of relying on the shared registers over LPC.

Gwendal Grignou (2):
  iio: cros_ec: Add sign vector in core for backward compatibility
  iio: cros_ec : Extend legacy support to ARM device

Changes in v2:
- Readd empty line to reduce amount of change in patch.
- Remove Keywords used by ChromeOS commit queue.

 drivers/iio/accel/Kconfig |   4 +-
 drivers/iio/accel/cros_ec_accel_legacy.c  | 350 --
 .../cros_ec_sensors/cros_ec_sensors_core.c|   4 +
 .../linux/iio/common/cros_ec_sensors_core.h   |   1 +
 4 files changed, 84 insertions(+), 275 deletions(-)

-- 
2.22.0.410.gd8fdbe21b5-goog

Re: [PATCH] net: fddi: skfp: remove generic PCI defines from skfbi.h

[kbuild test robot]

Hi Puranjay,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v5.2-rc5 next-20190620]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Puranjay-Mohan/net-fddi-skfp-remove-generic-PCI-defines-from-skfbi-h/20190621-081729
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/net/fddi/skfp/drvfbi.c:17:0:
   drivers/net/fddi/skfp/drvfbi.c: In function 'card_start':
>> drivers/net/fddi/skfp/drvfbi.c:130:21: error: 'PCI_REV_ID' undeclared (first 
>> use in this function); did you mean 'PCI_DEVID'?
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
^
   drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
#define inp(p)  ioread8(p)
^
>> drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
#define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
 ^~~~
>> drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
  ^
   drivers/net/fddi/skfp/drvfbi.c:130:21: note: each undeclared identifier is 
reported only once for each function it appears in
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
^
   drivers/net/fddi/skfp/h/types.h:28:25: note: in definition of macro 'inp'
#define inp(p)  ioread8(p)
^
>> drivers/net/fddi/skfp/h/skfbi.h:916:18: note: in expansion of macro 'ADDR'
#define PCI_C(a) ADDR(B3_CFG_SPC + (a)) /* PCI Config Space */
 ^~~~
>> drivers/net/fddi/skfp/drvfbi.c:130:15: note: in expansion of macro 'PCI_C'
 rev_id = inp(PCI_C(PCI_REV_ID)) ;
  ^

vim +130 drivers/net/fddi/skfp/drvfbi.c

^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16  @17  #include 
"h/types.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   18  #include 
"h/fddi.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   19  #include 
"h/smc.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   20  #include 
"h/supern_2.h"
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   21  #include 
"h/skfbiinc.h"
bc63eb9c drivers/net/skfp/drvfbi.c Akinobu Mita   2006-12-19   22  #include 

^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   23  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   24  #ifndef  
lint
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   25  static const 
char ID_sccs[] = "@(#)drvfbi.c  1.63 99/02/11 (C) SK " ;
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   26  #endif
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   27  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   28  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   29   * PCM 
active state
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   30   */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   31  #define 
PC8_ACTIVE   8
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   32  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   33  #define  
LED_Y_ON0x11/* Used for ring up/down indication */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   34  #define  
LED_Y_OFF   0x10
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   35  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   36  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   37  #define 
MS2BCLK(x)   ((x)*12500L)
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   38  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   39  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   40   * valid 
configuration values are:
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   41   */
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   42  
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   43  /*
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   44   *   
xPOS_ID:
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   45   *   |   
\  /
^1da177e drivers/net/skfp/drvfbi.c Linus Torvalds 2005-04-16   46   *   |   
 \/
^1da177e drivers/net/

Re: [PATCH v2] mm: memcg/slab: properly handle kmem_caches reparented to root_mem_cgroup

[Shakeel Butt]

On Thu, Jun 20, 2019 at 2:35 PM Roman Gushchin  wrote:
>
> As a result of reparenting a kmem_cache might belong to the root
> memory cgroup. It happens when a top-level memory cgroup is removed,
> and all associated kmem_caches are reparented to the root memory
> cgroup.
>
> The root memory cgroup is special, and requires a special handling.
> Let's make sure that we don't try to charge or uncharge it,
> and we handle system-wide vmstats exactly as for root kmem_caches.
>
> Note, that we still need to alter the kmem_cache reference counter,
> so that the kmem_cache can be released properly.
>
> The issue was discovered by running CRIU tests; the following warning
> did appear:
>
> [  381.345960] WARNING: CPU: 0 PID: 11655 at mm/page_counter.c:62
> page_counter_cancel+0x26/0x30
> [  381.345992] Modules linked in:
> [  381.345998] CPU: 0 PID: 11655 Comm: kworker/0:8 Not tainted
> 5.2.0-rc5-next-20190618+ #1
> [  381.346001] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [  381.346010] Workqueue: memcg_kmem_cache kmemcg_workfn
> [  381.346013] RIP: 0010:page_counter_cancel+0x26/0x30
> [  381.346017] Code: 1f 44 00 00 0f 1f 44 00 00 48 89 f0 53 48 f7 d8
> f0 48 0f c1 07 48 29 f0 48 89 c3 48 89 c6 e8 61 ff ff ff 48 85 db 78
> 02 5b c3 <0f> 0b 5b c3 66 0f 1f 44 00 00 0f 1f 44 00 00 48 85 ff 74 41
> 41 55
> [  381.346019] RSP: 0018:b3b34319f990 EFLAGS: 00010086
> [  381.346022] RAX: fffc RBX: fffc RCX: 
> 0004
> [  381.346024] RDX:  RSI: fffc RDI: 
> 9c2cd7165270
> [  381.346026] RBP: 0004 R08:  R09: 
> 0001
> [  381.346028] R10: 00c8 R11: 9c2cd684e660 R12: 
> fffc
> [  381.346030] R13: 0002 R14: 0006 R15: 
> 9c2c8ce1f200
> [  381.346033] FS:  () GS:9c2cd820()
> knlGS:
> [  381.346039] CS:  0010 DS:  ES:  CR0: 80050033
> [  381.346041] CR2: 007be000 CR3: 0001cdbfc005 CR4: 
> 001606f0
> [  381.346043] DR0:  DR1:  DR2: 
> 
> [  381.346045] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  381.346047] Call Trace:
> [  381.346054]  page_counter_uncharge+0x1d/0x30
> [  381.346065]  __memcg_kmem_uncharge_memcg+0x39/0x60
> [  381.346071]  __free_slab+0x34c/0x460
> [  381.346079]  deactivate_slab.isra.80+0x57d/0x6d0
> [  381.346088]  ? add_lock_to_list.isra.36+0x9c/0xf0
> [  381.346095]  ? __lock_acquire+0x252/0x1410
> [  381.346106]  ? cpumask_next_and+0x19/0x20
> [  381.346110]  ? slub_cpu_dead+0xd0/0xd0
> [  381.346113]  flush_cpu_slab+0x36/0x50
> [  381.346117]  ? slub_cpu_dead+0xd0/0xd0
> [  381.346125]  on_each_cpu_mask+0x51/0x70
> [  381.346131]  ? ksm_migrate_page+0x60/0x60
> [  381.346134]  on_each_cpu_cond_mask+0xab/0x100
> [  381.346143]  __kmem_cache_shrink+0x56/0x320
> [  381.346150]  ? ret_from_fork+0x3a/0x50
> [  381.346157]  ? unwind_next_frame+0x73/0x480
> [  381.346176]  ? __lock_acquire+0x252/0x1410
> [  381.346188]  ? kmemcg_workfn+0x21/0x50
> [  381.346196]  ? __mutex_lock+0x99/0x920
> [  381.346199]  ? kmemcg_workfn+0x21/0x50
> [  381.346205]  ? kmemcg_workfn+0x21/0x50
> [  381.346216]  __kmemcg_cache_deactivate_after_rcu+0xe/0x40
> [  381.346220]  kmemcg_cache_deactivate_after_rcu+0xe/0x20
> [  381.346223]  kmemcg_workfn+0x31/0x50
> [  381.346230]  process_one_work+0x23c/0x5e0
> [  381.346241]  worker_thread+0x3c/0x390
> [  381.346248]  ? process_one_work+0x5e0/0x5e0
> [  381.346252]  kthread+0x11d/0x140
> [  381.346255]  ? kthread_create_on_node+0x60/0x60
> [  381.346261]  ret_from_fork+0x3a/0x50
> [  381.346275] irq event stamp: 10302
> [  381.346278] hardirqs last  enabled at (10301): []
> _raw_spin_unlock_irq+0x29/0x40
> [  381.346282] hardirqs last disabled at (10302): []
> on_each_cpu_mask+0x49/0x70
> [  381.346287] softirqs last  enabled at (10262): []
> cgroup_idr_replace+0x3a/0x50
> [  381.346290] softirqs last disabled at (10260): []
> cgroup_idr_replace+0x1d/0x50
> [  381.346293] ---[ end trace b324ba73eb3659f0 ]---
>
> v2: fixed return value from memcg_charge_slab(), spotted by Shakeel
>
> Reported-by: Andrei Vagin 
> Signed-off-by: Roman Gushchin 

Reviewed-by: Shakeel Butt 

> Cc: Christoph Lameter 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Shakeel Butt 
> Cc: Vladimir Davydov 
> Cc: Waiman Long 
> Cc: David Rientjes 
> Cc: Joonsoo Kim 
> Cc: Pekka Enberg 
> ---
>  mm/slab.h | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/mm/slab.h b/mm/slab.h
> index a4c9b9d042de..a62372d0f271 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -294,8 +294,12 @@ static __always_inline int memcg_charge_slab(struct page 
> *page,
> memcg = parent_mem_cgroup(memcg);
> rcu_read_unlock();
>
> -   if (unlikely(!memcg))
> -   return true;
> +   if 

Re: [PATCH 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

[Gwendal Grignou]

On Thu, Jun 20, 2019 at 2:46 PM Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Jun 20, 2019 at 11:53 AM Gwendal Grignou  wrote:
> >
> > To allow cros_ec iio core library to be used with legacy device, add a
> > vector to rotate sensor data if necessary: legacy devices are not
> > reporting data in HTML5/Android sensor referential.
> >
> > TEST=On veyron minnie, check chrome detect tablet mode and rotate
> > screen in tablet mode.
>
> TEST= doesn't belong in an upstream patch.
>
>
> > Signed-off-by: Gwendal Grignou 
> > ---
> >  drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 5 -
> >  include/linux/iio/common/cros_ec_sensors_core.h   | 1 +
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c 
> > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > index 719a0df5aeeb..1b2e7a8242ad 100644
> > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > @@ -66,8 +66,10 @@ int cros_ec_sensors_core_init(struct platform_device 
> > *pdev,
> > }
> > state->type = state->resp->info.type;
> > state->loc = state->resp->info.location;
> > -   }
> >
> > +   /* Set sign vector, only used for backward compatibility. */
> > +   memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
> > +   }
> > return 0;
>
> Normally there's a blank line before the "return".  There was before
> your patch.  Why did you remove it?  It'll make your diff cleaner if
> you keep it.
Will fix these issues in next patch.
>
> Also, should you be basing your patch atop +Fabien's series?  I notice
> you got a conflict when you picked this into the Chrome OS tree, but
> maybe you wouldn't have if you had based atop
>  AKA
> 
I did not based on top of Fabien's patches because this change is
orthogonal to Fabien's. Moreover a new set of patches is needed as the
attributes added (min_freq, max_freq) do not match the current sysfs
ABI.

Gwendal.
>
>
> -Doug

Re: [PATCH 4.9 000/117] 4.9.183-stable review

[Naresh Kamboju]

On Thu, 20 Jun 2019 at 23:33, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.9.183 release.
> There are 117 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 22 Jun 2019 05:42:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.183-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.183-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: b2977e94f62a4008b6cc418f3af3c1a04ddb8ce3
git describe: v4.9.182-118-gb2977e94f62a
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.182-118-gb2977e94f62a


No regressions (compared to build v4.9.182)

No fixes (compared to build v4.9.182)


Ran 23588 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* prep-tmp-disk

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH] FDDI: defza: Include linux/io-64-nonatomic-lo-hi.h

[Maciej W. Rozycki]

On Thu, 20 Jun 2019, Paul Burton wrote:

> Maciej, David, if you'd be happy to provide an Ack so that I can take
> this through the mips-next branch that would be great; that'll let me
> apply it prior to the asm/io.h change.

Acked-by: Maciej W. Rozycki 

 Sure, thanks for doing this work.

  Maciej

[PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

[Finn Thain]

Some machines store local time in the Real Time Clock. The hard-coded
"UTC" string is wrong on those machines so just omit that string.
Update the log parser so it doesn't require the string "UTC".

Signed-off-by: Finn Thain 
---
 drivers/rtc/hctosys.c | 2 +-
 tools/power/pm-graph/bootgraph.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index ff2092a0d38c..2270eca23203 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
 
err = do_settimeofday64();
 
-   dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
+   dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
 , (long long)tv64.tv_sec);
 
 err_read:
diff --git a/tools/power/pm-graph/bootgraph.py 
b/tools/power/pm-graph/bootgraph.py
index 6dae57041537..5a045d1cb879 100755
--- a/tools/power/pm-graph/bootgraph.py
+++ b/tools/power/pm-graph/bootgraph.py
@@ -333,7 +333,7 @@ def parseKernelLog():
if(not sysvals.stamp['kernel']):
sysvals.stamp['kernel'] = 
sysvals.kernelVersion(msg)
continue
-   m = re.match('.* setting system clock to (?P.*) UTC.*', msg)
+   m = re.match('.* setting system clock to (?P.*) (?:UTC 
)?\(.*', msg)
if(m):
bt = datetime.strptime(m.group('t'), '%Y-%m-%d 
%H:%M:%S')
bt = bt - timedelta(seconds=int(ktime))
-- 
2.21.0

[GIT PULL] SMB3 Fixes

[Steve French]

Please pull the following changes since commit
d1fdb6d8f6a4109a4263176c84b899076a5f8008:

  Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)

are available in the Git repository at:

  git://git.samba.org/sfrench/cifs-2.6.git tags/5.2-rc5-smb3-fixes

for you to fetch changes up to 61cabc7b0a5cf0d3c532cfa96594c801743fe7f6:

  cifs: fix GlobalMid_Lock bug in cifs_reconnect (2019-06-17 16:27:02 -0500)


four small SMB3 fixes, all for stable


Ronnie Sahlberg (3):
  cifs: fix panic in smb2_reconnect
  cifs: add spinlock for the openFileList to cifsInodeInfo
  cifs: fix GlobalMid_Lock bug in cifs_reconnect

Steve French (1):
  SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write

 fs/cifs/cifsfs.c   |  1 +
 fs/cifs/cifsglob.h |  5 +
 fs/cifs/connect.c  |  2 ++
 fs/cifs/file.c |  8 ++--
 fs/cifs/smb2maperror.c |  2 +-
 fs/cifs/smb2pdu.c  | 10 +-
 6 files changed, 24 insertions(+), 4 deletions(-)


-- 
Thanks,

Steve

Re: [PATCH] soc: aspeed: lpc-ctrl: Fix probe error handling

[Andrew Jeffery]

On Thu, 20 Jun 2019, at 18:47, Joel Stanley wrote:
> gcc warns that a mising "flash" phandle node leads to undefined
> behavior later:
> 
> drivers/soc/aspeed/aspeed-lpc-ctrl.c: In function 
> 'aspeed_lpc_ctrl_probe':
> drivers/soc/aspeed/aspeed-lpc-ctrl.c:201:18: error: '*((void 
> *)+8)' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> 
> Only set the flash base and size if we find a phandle in the device
> tree.

Ugh, yeah. Not sure how I missed that. Thanks for fixing it.

Reviewed-by: Andrew Jeffery 

> 
> Reported-by: Arnd Bergmann 
> Signed-off-by: Joel Stanley 
> ---
>  drivers/soc/aspeed/aspeed-lpc-ctrl.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c 
> b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> index aca13779764a..eee26c2d8b52 100644
> --- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> +++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> @@ -223,10 +223,11 @@ static int aspeed_lpc_ctrl_probe(struct 
> platform_device *pdev)
>   dev_err(dev, "Couldn't address to resource for 
> flash\n");
>   return rc;
>   }
> +
> + lpc_ctrl->pnor_size = resource_size();
> + lpc_ctrl->pnor_base = resm.start;
>   }
>  
> - lpc_ctrl->pnor_size = resource_size();
> - lpc_ctrl->pnor_base = resm.start;
>  
>   dev_set_drvdata(>dev, lpc_ctrl);
>  
> -- 
> 2.20.1
> 
>

Re: [PATCH v2] RISC-V: Break load reservations during switch_to

[Palmer Dabbelt]

On Wed, 19 Jun 2019 00:36:01 PDT (-0700), mark.rutl...@arm.com wrote:

On Fri, Jun 07, 2019 at 03:22:22PM -0700, Palmer Dabbelt wrote:

The comment describes why in detail.  This was found because QEMU never
gives up load reservations, the issue is unlikely to manifest on real
hardware.

Thanks to Carlos Eduardo for finding the bug!



@@ -330,6 +330,17 @@ ENTRY(__switch_to)
add   a3, a0, a4
add   a4, a1, a4
REG_S ra,  TASK_THREAD_RA_RA(a3)
+   /*
+* The Linux ABI allows programs to depend on load reservations being
+* broken on context switches, but the ISA doesn't require that the
+* hardware ever breaks a load reservation.  The only way to break a
+* load reservation is with a store conditional, so we emit one here.
+* Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we
+* know this will always fail, but just to be on the safe side this
+* writes the same value that was unconditionally written by the
+* previous instruction.
+*/


I suspect that you need to do the same as 32-bit ARM, and clear this in
your exception return path, rather than in __switch_to, since handlers
for interrupts and other exceptions could leave a dangling reservation.

For ARM, the architecture permits a store-exclusive to succeed even if
the address differed from the load-exclusive. I don't know if the same
applies here, but regardless I believe the case above applies if an IRQ
is taken from kernel context, since the handler can manipulate the same
variable as the interrupted code.


RISC-V has the same constraint: an LR can cause the subsequent SC on any
address to succeed.  When writing the patch I thought they had to have matching
addresses, v4 should have a correct comment (assuming I've managed to send it,
I'm on my third continent this week so I'm a bit out of it).

I'd considered breaking reservations on trap entry, but decided it wasn't
necessary.  I hadn't considered doing this on trap exit, but I don't see a
difference so I might be missing something.  The case that I see as an issue is
when a trap comes in the middle of an LR/SC sequence, which boils down to three
cases:

* The trap handler doesn't contend with the LR/SC sequence in any way, in which
 case it's fine for the sequence to succeed.
* The trap handler contends by doing its own LR/SC sequence.  Since the trap
 handler must execute completely before returning control back the parent, we
 know the SC in the trap handler will execute.  Thus there is no way the SC in
 the parent can pair with the LR in the trap handler.  This applies even when
 traps are nested.
* The trap handler contends by performing a regular store to the same address
 as the LR that was interrupted.  In this case the SC must fail, and while I
 assumed that the store would cause that failure the ISA manual doesn't appear
 to require that behavior -- it does allow the SC to always fail in that case,
 but it doesn't mandate it always fails (which is how I got confused).

Assuming the ISA manual is correct in not specifying that stores within an
LR/SC sequence break the load reservations, then I think we do need to break
load reservations on all traps.  I'll go check with the ISA people, but now
that I've noticed it this does seem somewhat reasonable -- essentially it lets
LR just take a line exclusively, SC to succeed only on already exclusively held
lines, and doesn't impose any extra constraints on regular memory operations.

I don't see any reason that breaking reservations on entry as opposed to exit
would be incorrect.  I feel like doing this on entry is a better bet, as we're
already doing a bunch of stores there so I don't need to bring an additional
cache line in for writing.  These lines would be on the kernel stack so it's
unlikely anyone else has them for writing anyway, so maybe it just doesn't
matter.  The only issue I can think of here is that there might be something
tricky for implementations to handle WRT the regular store -> store conditional
forwarding, as that's a pattern that is unlikely to manifest on regular code
but is now in a high performance path.  The regular load -> store conditional
may be easier to handle, and since this is done on the kernel stack it's
unlikely that upgrading a line for writing would be an expensive operation
anyway.

LMK if I'm missing something, otherwise I'll spin another version of the patch
to break reservations on trap entry.

Re: [PATCH 2/4] powerpc/powernv: remove the unused tunneling exports

[Oliver O'Halloran]

On Thu, May 23, 2019 at 5:51 PM Christoph Hellwig  wrote:
>
> These have been unused ever since they've been added to the kernel.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/powerpc/include/asm/pnv-pci.h|  4 --
>  arch/powerpc/platforms/powernv/pci-ioda.c |  4 +-
>  arch/powerpc/platforms/powernv/pci.c  | 71 ---
>  arch/powerpc/platforms/powernv/pci.h  |  1 -
>  4 files changed, 3 insertions(+), 77 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pnv-pci.h 
> b/arch/powerpc/include/asm/pnv-pci.h
> index 9fcb0bc462c6..1ab4b0111abc 100644
> --- a/arch/powerpc/include/asm/pnv-pci.h
> +++ b/arch/powerpc/include/asm/pnv-pci.h
> @@ -27,12 +27,8 @@ extern int pnv_pci_get_power_state(uint64_t id, uint8_t 
> *state);
>  extern int pnv_pci_set_power_state(uint64_t id, uint8_t state,
>struct opal_msg *msg);
>
> -extern int pnv_pci_enable_tunnel(struct pci_dev *dev, uint64_t *asnind);
> -extern int pnv_pci_disable_tunnel(struct pci_dev *dev);
>  extern int pnv_pci_set_tunnel_bar(struct pci_dev *dev, uint64_t addr,
>   int enable);
> -extern int pnv_pci_get_as_notify_info(struct task_struct *task, u32 *lpid,
> - u32 *pid, u32 *tid);

IIRC as-notify was for CAPI which has an in-tree driver (cxl). Fred or
Andrew (+cc), what's going on with this? Will it ever see the light of
day?

>  int pnv_phb_to_cxl_mode(struct pci_dev *dev, uint64_t mode);
>  int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
>unsigned int virq);
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 126602b4e399..6b0caa2d0425 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -54,6 +54,8 @@
>  static const char * const pnv_phb_names[] = { "IODA1", "IODA2", "NPU_NVLINK",
>   "NPU_OCAPI" };
>
> +static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable);
> +
>  void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
> const char *fmt, ...)
>  {
> @@ -2360,7 +2362,7 @@ static long pnv_pci_ioda2_set_window(struct 
> iommu_table_group *table_group,
> return 0;
>  }
>
> -void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
> +static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
>  {
> uint16_t window_id = (pe->pe_number << 1 ) + 1;
> int64_t rc;
> diff --git a/arch/powerpc/platforms/powernv/pci.c 
> b/arch/powerpc/platforms/powernv/pci.c
> index 8d28f2932c3b..fc69f5611020 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -868,54 +868,6 @@ struct device_node *pnv_pci_get_phb_node(struct pci_dev 
> *dev)
>  }
>  EXPORT_SYMBOL(pnv_pci_get_phb_node);
>
> -int pnv_pci_enable_tunnel(struct pci_dev *dev, u64 *asnind)
> -{
> -   struct device_node *np;
> -   const __be32 *prop;
> -   struct pnv_ioda_pe *pe;
> -   uint16_t window_id;
> -   int rc;
> -
> -   if (!radix_enabled())
> -   return -ENXIO;
> -
> -   if (!(np = pnv_pci_get_phb_node(dev)))
> -   return -ENXIO;
> -
> -   prop = of_get_property(np, "ibm,phb-indications", NULL);
> -   of_node_put(np);
> -
> -   if (!prop || !prop[1])
> -   return -ENXIO;
> -
> -   *asnind = (u64)be32_to_cpu(prop[1]);
> -   pe = pnv_ioda_get_pe(dev);
> -   if (!pe)
> -   return -ENODEV;
> -
> -   /* Increase real window size to accept as_notify messages. */
> -   window_id = (pe->pe_number << 1 ) + 1;
> -   rc = opal_pci_map_pe_dma_window_real(pe->phb->opal_id, pe->pe_number,
> -window_id, pe->tce_bypass_base,
> -(uint64_t)1 << 48);
> -   return opal_error_code(rc);
> -}
> -EXPORT_SYMBOL_GPL(pnv_pci_enable_tunnel);
> -
> -int pnv_pci_disable_tunnel(struct pci_dev *dev)
> -{
> -   struct pnv_ioda_pe *pe;
> -
> -   pe = pnv_ioda_get_pe(dev);
> -   if (!pe)
> -   return -ENODEV;
> -
> -   /* Restore default real window size. */
> -   pnv_pci_ioda2_set_bypass(pe, true);
> -   return 0;
> -}
> -EXPORT_SYMBOL_GPL(pnv_pci_disable_tunnel);
> -
>  int pnv_pci_set_tunnel_bar(struct pci_dev *dev, u64 addr, int enable)
>  {
> __be64 val;
> @@ -970,29 +922,6 @@ int pnv_pci_set_tunnel_bar(struct pci_dev *dev, u64 
> addr, int enable)
>  }
>  EXPORT_SYMBOL_GPL(pnv_pci_set_tunnel_bar);
>
> -#ifdef CONFIG_PPC64/* for thread.tidr */
> -int pnv_pci_get_as_notify_info(struct task_struct *task, u32 *lpid, u32 *pid,
> -  u32 *tid)
> -{
> -   struct mm_struct *mm = NULL;
> -
> -   if (task == NULL)
> -   return -EINVAL;
> -
> -   

[PATCH] perf-script: assume native_arch for pipe mode

[Song Liu]

In pipe mode, session->header.env.arch is not populated until the events
are processed. Therefore, the following command crashes:

   perf record -o - | perf script

(gdb) bt

It fails when we try to compare env.arch against uts.machine:

if (!strcmp(uts.machine, session->header.env.arch) ||
(!strcmp(uts.machine, "x86_64") &&
 !strcmp(session->header.env.arch, "i386")))
native_arch = true;

In pipe mode, it is tricky to find env.arch at this stage. To keep it
simple, let's just assume native_arch is always true for pipe mode.

Cc: sta...@vger.kernel.org #v5.1+
Fixes: 3ab481a1cfe1 ("perf script: Support insn output for normal samples")
Reported-by: David Carrillo Cisneros 
Signed-off-by: Song Liu 
---
 tools/perf/builtin-script.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 61f00055476a..3355af25e7d0 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -3733,7 +3733,8 @@ int cmd_script(int argc, const char **argv)
goto out_delete;
 
uname();
-   if (!strcmp(uts.machine, session->header.env.arch) ||
+   if (data.is_pipe ||  /* assume pipe_mode indicates native_arch */
+   !strcmp(uts.machine, session->header.env.arch) ||
(!strcmp(uts.machine, "x86_64") &&
 !strcmp(session->header.env.arch, "i386")))
native_arch = true;
-- 
2.17.1

[PATCH v2] sched/isolation: Prefer housekeeping cpu in local node

[Wanpeng Li]

From: Wanpeng Li 

In real product setup, there will be houseeking cpus in each nodes, it 
is prefer to do housekeeping from local node, fallback to global online 
cpumask if failed to find houseeking cpu from local node.

Cc: Ingo Molnar  
Cc: Peter Zijlstra 
Cc: Frederic Weisbecker 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * introduce sched_numa_find_closest

 kernel/sched/isolation.c | 12 ++--
 kernel/sched/sched.h |  5 ++---
 kernel/sched/topology.c  | 14 ++
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 123ea07..589afba 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -16,9 +16,17 @@ static unsigned int housekeeping_flags;
 
 int housekeeping_any_cpu(enum hk_flags flags)
 {
-   if (static_branch_unlikely(_overridden))
-   if (housekeeping_flags & flags)
+   int cpu;
+
+   if (static_branch_unlikely(_overridden)) {
+   if (housekeeping_flags & flags) {
+   cpu = sched_numa_find_closest(housekeeping_mask, 
smp_processor_id());
+   if (cpu < nr_cpu_ids)
+   return cpu;
+
return cpumask_any_and(housekeeping_mask, 
cpu_online_mask);
+   }
+   }
return smp_processor_id();
 }
 EXPORT_SYMBOL_GPL(housekeeping_any_cpu);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b08dee2..0db7431 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1212,9 +1212,6 @@ enum numa_topology_type {
 extern enum numa_topology_type sched_numa_topology_type;
 extern int sched_max_numa_distance;
 extern bool find_numa_distance(int distance);
-#endif
-
-#ifdef CONFIG_NUMA
 extern void sched_init_numa(void);
 extern void sched_domains_numa_masks_set(unsigned int cpu);
 extern void sched_domains_numa_masks_clear(unsigned int cpu);
@@ -1224,6 +1221,8 @@ static inline void sched_domains_numa_masks_set(unsigned 
int cpu) { }
 static inline void sched_domains_numa_masks_clear(unsigned int cpu) { }
 #endif
 
+extern int sched_numa_find_closest(const struct cpumask *cpus, int cpu);
+
 #ifdef CONFIG_NUMA_BALANCING
 /* The regions in numa_faults array from task_struct */
 enum numa_faults_stats {
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 63184cf..3d3fb04 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1726,6 +1726,20 @@ void sched_domains_numa_masks_clear(unsigned int cpu)
 
 #endif /* CONFIG_NUMA */
 
+int sched_numa_find_closest(const struct cpumask *cpus, int cpu)
+{
+#ifdef CONFIG_NUMA
+   int i, j = cpu_to_node(cpu);
+
+   for (i = 0; i < sched_domains_numa_levels; i++) {
+   cpu = cpumask_any_and(cpus, sched_domains_numa_masks[i][j]);
+   if (cpu < nr_cpu_ids)
+   return cpu;
+   }
+#endif
+   return nr_cpu_ids;
+}
+
 static int __sdt_alloc(const struct cpumask *cpu_map)
 {
struct sched_domain_topology_level *tl;
-- 
2.7.4

Re: [PATCH v4 2/5] KVM: LAPIC: inject lapic timer interrupt by posted interrupt

[Wanpeng Li]

On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti  wrote:
>
> Hi Li,
>
> On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> > On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti  wrote:
> > >
> > > On Mon, Jun 17, 2019 at 07:24:44PM +0800, Wanpeng Li wrote:
> > > > From: Wanpeng Li 
> > > >
> > > > Dedicated instances are currently disturbed by unnecessary jitter due
> > > > to the emulated lapic timers fire on the same pCPUs which vCPUs 
> > > > resident.
> > > > There is no hardware virtual timer on Intel for guest like ARM. Both
> > > > programming timer in guest and the emulated timer fires incur vmexits.
> > > > This patch tries to avoid vmexit which is incurred by the emulated
> > > > timer fires in dedicated instance scenario.
> > > >
> > > > When nohz_full is enabled in dedicated instances scenario, the emulated
> > > > timers can be offload to the nearest busy housekeeping cpus since APICv
> > > > is really common in recent years. The guest timer interrupt is injected
> > > > by posted-interrupt which is delivered by housekeeping cpu once the 
> > > > emulated
> > > > timer fires.
> > > >
> > > > The host admin should fine tuned, e.g. dedicated instances scenario w/
> > > > nohz_full cover the pCPUs which vCPUs resident, several pCPUs surplus
> > > > for busy housekeeping, disable mwait/hlt/pause vmexits to keep in 
> > > > non-root
> > > > mode, ~3% redis performance benefit can be observed on Skylake server.
> > > >
> > > > w/o patch:
> > > >
> > > > VM-EXIT  Samples  Samples%  Time%   Min Time  Max Time   
> > > > Avg time
> > > >
> > > > EXTERNAL_INTERRUPT4291649.43%   39.30%   0.47us   106.09us   
> > > > 0.71us ( +-   1.09% )
> > > >
> > > > w/ patch:
> > > >
> > > > VM-EXIT  Samples  Samples%  Time%   Min Time  Max Time  
> > > >Avg time
> > > >
> > > > EXTERNAL_INTERRUPT6871 9.29% 2.96%   0.44us57.88us   
> > > > 0.72us ( +-   4.02% )
> > > >
> > > > Cc: Paolo Bonzini 
> > > > Cc: Radim Krčmář 
> > > > Cc: Marcelo Tosatti 
> > > > Signed-off-by: Wanpeng Li 
> > > > ---
> > > >  arch/x86/kvm/lapic.c| 33 ++---
> > > >  arch/x86/kvm/lapic.h|  1 +
> > > >  arch/x86/kvm/vmx/vmx.c  |  3 ++-
> > > >  arch/x86/kvm/x86.c  |  5 +
> > > >  arch/x86/kvm/x86.h  |  2 ++
> > > >  include/linux/sched/isolation.h |  2 ++
> > > >  kernel/sched/isolation.c|  6 ++
> > > >  7 files changed, 44 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > > > index 87ecb56..9c5 100644
> > > > --- a/arch/x86/kvm/lapic.c
> > > > +++ b/arch/x86/kvm/lapic.c
> > > > @@ -122,6 +122,13 @@ static inline u32 kvm_x2apic_id(struct kvm_lapic 
> > > > *apic)
> > > >   return apic->vcpu->vcpu_id;
> > > >  }
> > > >
> > > > +bool posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > > > +{
> > > > + return pi_inject_timer && kvm_vcpu_apicv_active(vcpu) &&
> > > > + kvm_hlt_in_guest(vcpu->kvm);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(posted_interrupt_inject_timer);
> > >
> > > Paolo, can you explain the reasoning behind this?
> > >
> > > Should not be necessary...

https://lkml.org/lkml/2019/6/5/436  "Here you need to check
kvm_halt_in_guest, not kvm_mwait_in_guest, because you need to go
through kvm_apic_expired if the guest needs to be woken up from
kvm_vcpu_block."

I think we can still be woken up from kvm_vcpu_block() if pir is set.

Regards,
Wanpeng Li

Re: [PATCH] sched/isolation: Prefer housekeeping cpu in local node

[Wanpeng Li]

On Thu, 20 Jun 2019 at 20:38, Peter Zijlstra  wrote:
>
> On Thu, Jun 20, 2019 at 07:36:54PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li 
> >
> > In real product setup, there will be houseeking cpus in each nodes, it
> > is prefer to do housekeeping from local node, fallback to global online
> > cpumask if failed to find houseeking cpu from local node.
> >
> > Cc: Ingo Molnar 
> > Cc: Peter Zijlstra 
> > Cc: Frederic Weisbecker 
> > Signed-off-by: Wanpeng Li 
> > ---
> >  kernel/sched/isolation.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> > index 123ea07..9eb6805 100644
> > --- a/kernel/sched/isolation.c
> > +++ b/kernel/sched/isolation.c
> > @@ -16,9 +16,16 @@ static unsigned int housekeeping_flags;
> >
> >  int housekeeping_any_cpu(enum hk_flags flags)
> >  {
> > + int cpu;
> > +
> >   if (static_branch_unlikely(_overridden))
> > - if (housekeeping_flags & flags)
> > - return cpumask_any_and(housekeeping_mask, 
> > cpu_online_mask);
> > + if (housekeeping_flags & flags) {
> > + cpu = cpumask_any_and(housekeeping_mask, 
> > cpu_cpu_mask(smp_processor_id()));
> > + if (cpu < nr_cpu_ids)
> > + return cpu;
> > + else
> > + return cpumask_any_and(housekeeping_mask, 
> > cpu_online_mask);
> > + }
> >   return smp_processor_id();
> >  }
> >  EXPORT_SYMBOL_GPL(housekeeping_any_cpu);
>
> Why not something like so? IIRC there's more places that want this, but
> I can't seem to remember quite where.

Good point, do it in v2. Btw, could you have a look this patch?
https://lkml.org/lkml/2019/6/17/1723

Regards,
Wanpeng Li

Re: [PATCH 4/4] powerpc/powernv: remove the unused vas_win_paste_addr and vas_win_id functions

[Oliver O'Halloran]

On Thu, May 23, 2019 at 5:56 PM Christoph Hellwig  wrote:
>
> These two function have never been used since they were added to the
> kernel.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/powerpc/include/asm/vas.h  | 10 --
>  arch/powerpc/platforms/powernv/vas-window.c | 19 ---
>  arch/powerpc/platforms/powernv/vas.h| 20 
>  3 files changed, 49 deletions(-)

Sukadev (+cc), what's the reason this is not being used?

IIRC the VAS hardware on P9 had some issues, but I don't know any of
the details.

> diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
> index 771456227496..9b5b7261df7b 100644
> --- a/arch/powerpc/include/asm/vas.h
> +++ b/arch/powerpc/include/asm/vas.h
> @@ -167,14 +167,4 @@ int vas_copy_crb(void *crb, int offset);
>   */
>  int vas_paste_crb(struct vas_window *win, int offset, bool re);
>
> -/*
> - * Return a system-wide unique id for the VAS window @win.
> - */
> -extern u32 vas_win_id(struct vas_window *win);
> -
> -/*
> - * Return the power bus paste address associated with @win so the caller
> - * can map that address into their address space.
> - */
> -extern u64 vas_win_paste_addr(struct vas_window *win);
>  #endif /* __ASM_POWERPC_VAS_H */
> diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
> b/arch/powerpc/platforms/powernv/vas-window.c
> index e59e0e60e5b5..e48c44cb3a16 100644
> --- a/arch/powerpc/platforms/powernv/vas-window.c
> +++ b/arch/powerpc/platforms/powernv/vas-window.c
> @@ -44,16 +44,6 @@ static void compute_paste_address(struct vas_window 
> *window, u64 *addr, int *len
> pr_debug("Txwin #%d: Paste addr 0x%llx\n", winid, *addr);
>  }
>
> -u64 vas_win_paste_addr(struct vas_window *win)
> -{
> -   u64 addr;
> -
> -   compute_paste_address(win, , NULL);
> -
> -   return addr;
> -}
> -EXPORT_SYMBOL(vas_win_paste_addr);
> -
>  static inline void get_hvwc_mmio_bar(struct vas_window *window,
> u64 *start, int *len)
>  {
> @@ -1268,12 +1258,3 @@ int vas_win_close(struct vas_window *window)
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(vas_win_close);
> -
> -/*
> - * Return a system-wide unique window id for the window @win.
> - */
> -u32 vas_win_id(struct vas_window *win)
> -{
> -   return encode_pswid(win->vinst->vas_id, win->winid);
> -}
> -EXPORT_SYMBOL_GPL(vas_win_id);
> diff --git a/arch/powerpc/platforms/powernv/vas.h 
> b/arch/powerpc/platforms/powernv/vas.h
> index f5493dbdd7ff..551affaddd59 100644
> --- a/arch/powerpc/platforms/powernv/vas.h
> +++ b/arch/powerpc/platforms/powernv/vas.h
> @@ -448,26 +448,6 @@ static inline u64 read_hvwc_reg(struct vas_window *win,
> return in_be64(win->hvwc_map+reg);
>  }
>
> -/*
> - * Encode/decode the Partition Send Window ID (PSWID) for a window in
> - * a way that we can uniquely identify any window in the system. i.e.
> - * we should be able to locate the 'struct vas_window' given the PSWID.
> - *
> - * BitsUsage
> - * 0:7 VAS id (8 bits)
> - * 8:15Unused, 0 (3 bits)
> - * 16:31   Window id (16 bits)
> - */
> -static inline u32 encode_pswid(int vasid, int winid)
> -{
> -   u32 pswid = 0;
> -
> -   pswid |= vasid << (31 - 7);
> -   pswid |= winid;
> -
> -   return pswid;
> -}
> -
>  static inline void decode_pswid(u32 pswid, int *vasid, int *winid)
>  {
> if (vasid)
> --
> 2.20.1
>

[PATCH V33 01/30] security: Support early LSMs

[Matthew Garrett]

The lockdown module is intended to allow for kernels to be locked down
early in boot - sufficiently early that we don't have the ability to
kmalloc() yet. Add support for early initialisation of some LSMs, and
then add them to the list of names when we do full initialisation later.

Signed-off-by: Matthew Garrett 
---
 include/asm-generic/vmlinux.lds.h |  8 +-
 include/linux/lsm_hooks.h |  6 
 include/linux/security.h  |  1 +
 init/main.c   |  1 +
 security/security.c   | 48 +--
 5 files changed, 54 insertions(+), 10 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index f8f6f04c4453..e1963352fdb6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -208,8 +208,13 @@
__start_lsm_info = .;   \
KEEP(*(.lsm_info.init)) \
__end_lsm_info = .;
+#define EARLY_LSM_TABLE()  . = ALIGN(8);   \
+   __start_early_lsm_info = .; \
+   KEEP(*(.early_lsm_info.init))   \
+   __end_early_lsm_info = .;
 #else
 #define LSM_TABLE()
+#define EARLY_LSM_TABLE()
 #endif
 
 #define ___OF_TABLE(cfg, name) _OF_TABLE_##cfg(name)
@@ -610,7 +615,8 @@
ACPI_PROBE_TABLE(irqchip)   \
ACPI_PROBE_TABLE(timer) \
EARLYCON_TABLE()\
-   LSM_TABLE()
+   LSM_TABLE() \
+   EARLY_LSM_TABLE()
 
 #define INIT_TEXT  \
*(.init.text .init.text.*)  \
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index a240a3fc5fc4..66fd1eac7a32 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2085,12 +2085,18 @@ struct lsm_info {
 };
 
 extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
+extern struct lsm_info __start_early_lsm_info[], __end_early_lsm_info[];
 
 #define DEFINE_LSM(lsm)
\
static struct lsm_info __lsm_##lsm  \
__used __section(.lsm_info.init)\
__aligned(sizeof(unsigned long))
 
+#define DEFINE_EARLY_LSM(lsm)  \
+   static struct lsm_info __early_lsm_##lsm\
+   __used __section(.early_lsm_info.init)  \
+   __aligned(sizeof(unsigned long))
+
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
  * Assuring the safety of deleting a security module is up to
diff --git a/include/linux/security.h b/include/linux/security.h
index 49f2685324b0..1bb6fb2f1523 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -194,6 +194,7 @@ int unregister_lsm_notifier(struct notifier_block *nb);
 
 /* prototypes */
 extern int security_init(void);
+extern int early_security_init(void);
 
 /* Security operations */
 int security_binder_set_context_mgr(struct task_struct *mgr);
diff --git a/init/main.c b/init/main.c
index 598e278b46f7..f3faeb89c75f 100644
--- a/init/main.c
+++ b/init/main.c
@@ -563,6 +563,7 @@ asmlinkage __visible void __init start_kernel(void)
boot_cpu_init();
page_address_init();
pr_notice("%s", linux_banner);
+   early_security_init();
setup_arch(_line);
/*
 * Set up the the initial canary and entropy after arch
diff --git a/security/security.c b/security/security.c
index 23cbb1a295a3..2a6672c9e72f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -37,6 +37,7 @@
 
 /* How many LSMs were built into the kernel? */
 #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
+#define EARLY_LSM_COUNT (__end_early_lsm_info - __start_early_lsm_info)
 
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
 static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
@@ -281,6 +282,8 @@ static void __init ordered_lsm_parse(const char *order, 
const char *origin)
 static void __init lsm_early_cred(struct cred *cred);
 static void __init lsm_early_task(struct task_struct *task);
 
+static int lsm_append(const char *new, char **result);
+
 static void __init ordered_lsm_init(void)
 {
struct lsm_info **lsm;
@@ -327,15 +330,11 @@ static void __init ordered_lsm_init(void)
kfree(ordered_lsms);
 }
 
-/**
- * security_init - initializes the security framework
- *
- * This should be called early in the kernel initialization sequence.
- */
-int __init security_init(void)
+int __init early_security_init(void)
 {
int i;
struct hlist_head *list = (struct hlist_head *) 

[PATCH V33 05/30] Restrict /dev/{mem,kmem,port} when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.

Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.

Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Cc: x...@kernel.org
---
 drivers/char/mem.c   | 4 +++-
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index b08dc50f9f26..1ee6cff43eea 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -29,8 +29,8 @@
 #include 
 #include 
 #include 
-
 #include 
+#include 
 
 #ifdef CONFIG_IA64
 # include 
@@ -786,6 +786,8 @@ static loff_t memory_lseek(struct file *file, loff_t 
offset, int orig)
 
 static int open_port(struct inode *inode, struct file *filp)
 {
+   if (security_is_locked_down(LOCKDOWN_DEV_MEM))
+   return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
 
diff --git a/include/linux/security.h b/include/linux/security.h
index a7612b03b42a..034a8d54687f 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -83,6 +83,7 @@ enum lsm_event {
 enum lockdown_reason {
LOCKDOWN_NONE,
LOCKDOWN_MODULE_SIGNATURE,
+   LOCKDOWN_DEV_MEM,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 08abd7e6609b..43a049b3b66a 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -19,6 +19,7 @@ static enum lockdown_reason kernel_locked_down;
 static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_NONE] = "none",
[LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
+   [LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 04/30] Enforce module signatures if the kernel is locked down

[Matthew Garrett]

From: David Howells 

If the kernel is locked down, require that all modules have valid
signatures that we can verify.

I have adjusted the errors generated:

 (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
 ENOKEY), then:

 (a) If signatures are enforced then EKEYREJECTED is returned.

 (b) If there's no signature or we can't check it, but the kernel is
 locked down then EPERM is returned (this is then consistent with
 other lockdown cases).

 (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
 the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
 return the error we got.

Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.

 [Modified by Matthew Garrett to remove the IMA integration. This will
  be replaced with integration with the IMA architecture policy
  patchset.]

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Cc: Jessica Yu 
---
 include/linux/security.h |  1 +
 kernel/module.c  | 39 +---
 security/lockdown/lockdown.c |  1 +
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index a86a7739ca24..a7612b03b42a 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -82,6 +82,7 @@ enum lsm_event {
  */
 enum lockdown_reason {
LOCKDOWN_NONE,
+   LOCKDOWN_MODULE_SIGNATURE,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/kernel/module.c b/kernel/module.c
index 0b9aa8ab89f0..780e9605ff88 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2763,8 +2763,9 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 #ifdef CONFIG_MODULE_SIG
 static int module_sig_check(struct load_info *info, int flags)
 {
-   int err = -ENOKEY;
+   int err = -ENODATA;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+   const char *reason;
const void *mod = info->hdr;
 
/*
@@ -2779,16 +2780,40 @@ static int module_sig_check(struct load_info *info, int 
flags)
err = mod_verify_sig(mod, info);
}
 
-   if (!err) {
+   switch (err) {
+   case 0:
info->sig_ok = true;
return 0;
-   }
 
-   /* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !is_module_sig_enforced())
-   err = 0;
+   /* We don't permit modules to be loaded into trusted kernels
+* without a valid signature on them, but if we're not
+* enforcing, certain errors are non-fatal.
+*/
+   case -ENODATA:
+   reason = "Loading of unsigned module";
+   goto decide;
+   case -ENOPKG:
+   reason = "Loading of module with unsupported crypto";
+   goto decide;
+   case -ENOKEY:
+   reason = "Loading of module with unavailable key";
+   decide:
+   if (is_module_sig_enforced()) {
+   pr_notice("%s is rejected\n", reason);
+   return -EKEYREJECTED;
+   }
 
-   return err;
+   if (security_is_locked_down(LOCKDOWN_MODULE_SIGNATURE))
+   return -EPERM;
+   return 0;
+
+   /* All other errors are fatal, including nomem, unparseable
+* signatures and signature check failures - even if signatures
+* aren't required.
+*/
+   default:
+   return err;
+   }
 }
 #else /* !CONFIG_MODULE_SIG */
 static int module_sig_check(struct load_info *info, int flags)
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 1ecb2eecb245..08abd7e6609b 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -18,6 +18,7 @@ static enum lockdown_reason kernel_locked_down;
 
 static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_NONE] = "none",
+   [LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 09/30] kexec_file: Restrict at runtime if the kernel is locked down

[Matthew Garrett]

From: Jiri Bohac 

When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down.

[Modified by David Howells to fit with modifications to the previous patch
 and to return -EPERM if the kernel is locked down for consistency with
 other lockdowns. Modified by Matthew Garrett to remove the IMA
 integration, which will be replaced by integrating with the IMA
 architecture policy patches.]

Signed-off-by: Jiri Bohac 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Reviewed-by: Jiri Bohac 
cc: ke...@lists.infradead.org
---
 kernel/kexec_file.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 67f3a866eabe..455f4fc794f3 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
}
 
ret = 0;
+
+   if (security_is_locked_down(LOCKDOWN_KEXEC)) {
+   ret = -EPERM;
+   goto out;
+   }
+
break;
 
/* All other errors are fatal, including nomem, unparseable
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 15/30] ACPI: Limit access to custom_method when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/custom_method.c | 4 
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index aa972dc5cb7e..5c684b09a2d1 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -29,6 +30,9 @@ static ssize_t cm_write(struct file *file, const char __user 
* user_buf,
struct acpi_table_header table;
acpi_status status;
 
+   if (security_is_locked_down(LOCKDOWN_ACPI_TABLES))
+   return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
diff --git a/include/linux/security.h b/include/linux/security.h
index 81c0968e485f..88d0f5d0cd87 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -89,6 +89,7 @@ enum lockdown_reason {
LOCKDOWN_PCI_ACCESS,
LOCKDOWN_IOPORT,
LOCKDOWN_MSR,
+   LOCKDOWN_ACPI_TABLES,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index a01301972290..bfc0e088aa85 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -25,6 +25,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_PCI_ACCESS] = "direct PCI access",
[LOCKDOWN_IOPORT] = "raw io port access",
[LOCKDOWN_MSR] = "raw MSR access",
+   [LOCKDOWN_ACPI_TABLES] = "modified ACPI tables",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 17/30] acpi: Disable ACPI table override if the kernel is locked down

[Matthew Garrett]

From: Linn Crosetto 

>From the kernel documentation (initrd_table_override.txt):

  If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
  to override nearly any ACPI table provided by the BIOS with an
  instrumented, modified one.

When lockdown is enabled, the kernel should disallow any unauthenticated
changes to kernel space.  ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/tables.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 8fccbe49612a..f8e7d70f07ee 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
@@ -539,6 +540,11 @@ void __init acpi_table_upgrade(void)
if (table_nr == 0)
return;
 
+   if (security_is_locked_down(LOCKDOWN_ACPI_TABLES)) {
+   pr_notice("kernel is locked down, ignoring table override\n");
+   return;
+   }
+
acpi_tables_addr =
memblock_find_in_range(0, ACPI_TABLE_UPGRADE_MAX_PHYS,
   all_tables_size, PAGE_SIZE);
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 22/30] Lock down /proc/kcore

[Matthew Garrett]

From: David Howells 

Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data. This is limited to lockdown
confidentiality mode and is still permitted in integrity mode.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 fs/proc/kcore.c  | 3 +++
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index d29d869abec1..b410a16b1960 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "internal.h"
 
@@ -545,6 +546,8 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 
 static int open_kcore(struct inode *inode, struct file *filp)
 {
+   if (security_is_locked_down(LOCKDOWN_KCORE))
+   return -EPERM;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
 
diff --git a/include/linux/security.h b/include/linux/security.h
index 89b7adfae525..6752584729e2 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -95,6 +95,7 @@ enum lockdown_reason {
LOCKDOWN_MODULE_PARAMETERS,
LOCKDOWN_MMIOTRACE,
LOCKDOWN_INTEGRITY_MAX,
+   LOCKDOWN_KCORE,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 215615e67237..80ff4a31d8aa 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -31,6 +31,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
+   [LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 20/30] Lock down module params that specify hardware parameters (eg. ioport)

[Matthew Garrett]

From: David Howells 

Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 include/linux/security.h |  1 +
 kernel/params.c  | 27 ++-
 security/lockdown/lockdown.c |  1 +
 3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index cb5d74f9b9ff..47ca04ac00f6 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -92,6 +92,7 @@ enum lockdown_reason {
LOCKDOWN_ACPI_TABLES,
LOCKDOWN_PCMCIA_CIS,
LOCKDOWN_TIOCSSERIAL,
+   LOCKDOWN_MODULE_PARAMETERS,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/kernel/params.c b/kernel/params.c
index ce89f757e6da..59544a2ec0b9 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_SYSFS
 /* Protects all built-in parameters, modules use their own param_lock */
@@ -108,13 +109,19 @@ bool parameq(const char *a, const char *b)
return parameqn(a, b, strlen(a)+1);
 }
 
-static void param_check_unsafe(const struct kernel_param *kp)
+static bool param_check_unsafe(const struct kernel_param *kp,
+  const char *doing)
 {
if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
pr_notice("Setting dangerous option %s - tainting kernel\n",
  kp->name);
add_taint(TAINT_USER, LOCKDEP_STILL_OK);
}
+
+   if (kp->flags & KERNEL_PARAM_FL_HWPARAM &&
+   security_is_locked_down(LOCKDOWN_MODULE_PARAMETERS))
+   return false;
+   return true;
 }
 
 static int parse_one(char *param,
@@ -144,8 +151,10 @@ static int parse_one(char *param,
pr_debug("handling %s with %p\n", param,
params[i].ops->set);
kernel_param_lock(params[i].mod);
-   param_check_unsafe([i]);
-   err = params[i].ops->set(val, [i]);
+   if (param_check_unsafe([i], doing))
+   err = params[i].ops->set(val, [i]);
+   else
+   err = -EPERM;
kernel_param_unlock(params[i].mod);
return err;
}
@@ -553,6 +562,12 @@ static ssize_t param_attr_show(struct module_attribute 
*mattr,
return count;
 }
 
+#ifdef CONFIG_MODULES
+#define mod_name(mod) (mod)->name
+#else
+#define mod_name(mod) "unknown"
+#endif
+
 /* sysfs always hands a nul-terminated string in buf.  We rely on that. */
 static ssize_t param_attr_store(struct module_attribute *mattr,
struct module_kobject *mk,
@@ -565,8 +580,10 @@ static ssize_t param_attr_store(struct module_attribute 
*mattr,
return -EPERM;
 
kernel_param_lock(mk->mod);
-   param_check_unsafe(attribute->param);
-   err = attribute->param->ops->set(buf, attribute->param);
+   if (param_check_unsafe(attribute->param, mod_name(mk->mod)))
+   err = attribute->param->ops->set(buf, attribute->param);
+   else
+   err = -EPERM;
kernel_param_unlock(mk->mod);
if (!err)
return len;
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index c6456f300220..0788d4805449 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -28,6 +28,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_ACPI_TABLES] = "modified ACPI tables",
[LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
[LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO",
+   [LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 18/30] Prohibit PCMCIA CIS storage when the kernel is locked down

[Matthew Garrett]

From: David Howells 

Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.

Suggested-by: Dominik Brodowski 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 drivers/pcmcia/cistpl.c  | 4 
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index ac0672b8dfca..fb54e262578c 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1578,6 +1579,9 @@ static ssize_t pccard_store_cis(struct file *filp, struct 
kobject *kobj,
struct pcmcia_socket *s;
int error;
 
+   if (security_is_locked_down(LOCKDOWN_PCMCIA_CIS))
+   return -EPERM;
+
s = to_socket(container_of(kobj, struct device, kobj));
 
if (off)
diff --git a/include/linux/security.h b/include/linux/security.h
index 88d0f5d0cd87..87c433f1e7db 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -90,6 +90,7 @@ enum lockdown_reason {
LOCKDOWN_IOPORT,
LOCKDOWN_MSR,
LOCKDOWN_ACPI_TABLES,
+   LOCKDOWN_PCMCIA_CIS,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index bfc0e088aa85..ced4ddbb36b4 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -26,6 +26,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_IOPORT] = "raw io port access",
[LOCKDOWN_MSR] = "raw MSR access",
[LOCKDOWN_ACPI_TABLES] = "modified ACPI tables",
+   [LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 21/30] x86/mmiotrace: Lock down the testmmiotrace module

[Matthew Garrett]

From: David Howells 

The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space. This is
a runtime check rather than buildtime in order to allow configurations
where the same kernel may be run in both locked down or permissive modes
depending on local policy.

Suggested-by: Thomas Gleixner 
Signed-off-by: David Howells 
cc: Thomas Gleixner 
cc: Steven Rostedt 
cc: Ingo Molnar 
cc: "H. Peter Anvin" 
cc: x...@kernel.org
---
 arch/x86/mm/testmmiotrace.c  | 3 +++
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index f6ae6830b341..a6b204f9f505 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -115,6 +115,9 @@ static int __init init(void)
 {
unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
 
+   if (security_is_locked_down(LOCKDOWN_MMIOTRACE))
+   return -EPERM;
+
if (mmio_address == 0) {
pr_err("you have to use the module argument mmio_address.\n");
pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU 
ARE DOING!\n");
diff --git a/include/linux/security.h b/include/linux/security.h
index 47ca04ac00f6..89b7adfae525 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -93,6 +93,7 @@ enum lockdown_reason {
LOCKDOWN_PCMCIA_CIS,
LOCKDOWN_TIOCSSERIAL,
LOCKDOWN_MODULE_PARAMETERS,
+   LOCKDOWN_MMIOTRACE,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 0788d4805449..215615e67237 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -29,6 +29,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
[LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO",
[LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
+   [LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 25/30] Lock down perf when in confidentiality mode

[Matthew Garrett]

From: David Howells 

Disallow the use of certain perf facilities that might allow userspace to
access kernel data.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
---
 include/linux/security.h | 1 +
 kernel/events/core.c | 5 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 7 insertions(+)

diff --git a/include/linux/security.h b/include/linux/security.h
index 8bf426cdd151..36a9daa13bb0 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -98,6 +98,7 @@ enum lockdown_reason {
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
LOCKDOWN_BPF,
+   LOCKDOWN_PERF,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 72d06e302e99..ac1045caa44d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10731,6 +10731,11 @@ SYSCALL_DEFINE5(perf_event_open,
return -EINVAL;
}
 
+   if ((attr.sample_type & PERF_SAMPLE_REGS_INTR) &&
+   security_is_locked_down(LOCKDOWN_PERF))
+   /* REGS_INTR can leak data, lockdown must prevent this */
+   return -EPERM;
+
/* Only privileged users can get physical addresses */
if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 0a3bbf1ba01d..14edc475d75c 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -34,6 +34,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
[LOCKDOWN_BPF] = "use of bpf",
+   [LOCKDOWN_PERF] = "unsafe use of perf",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 26/30] kexec: Allow kexec_file() with appropriate IMA policy when locked down

[Matthew Garrett]

Systems in lockdown mode should block the kexec of untrusted kernels.
For x86 and ARM we can ensure that a kernel is trustworthy by validating
a PE signature, but this isn't possible on other architectures. On those
platforms we can use IMA digital signatures instead. Add a function to
determine whether IMA has or will verify signatures for a given event type,
and if so permit kexec_file() even if the kernel is otherwise locked down.
This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set
in order to prevent an attacker from loading additional keys at runtime.

Signed-off-by: Matthew Garrett 
Acked-by: Mimi Zohar 
Cc: Dmitry Kasatkin 
Cc: linux-integr...@vger.kernel.org
---
 include/linux/ima.h |  9 ++
 kernel/kexec_file.c |  7 +++-
 security/integrity/ima/ima.h|  2 ++
 security/integrity/ima/ima_main.c   |  2 +-
 security/integrity/ima/ima_policy.c | 50 +
 5 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index dc12fbcf484c..c30954acc660 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -132,4 +132,13 @@ static inline int ima_inode_removexattr(struct dentry 
*dentry,
return 0;
 }
 #endif /* CONFIG_IMA_APPRAISE */
+
+#if defined(CONFIG_IMA_APPRAISE) && defined(CONFIG_INTEGRITY_TRUSTED_KEYRING)
+extern bool ima_appraise_signature(enum kernel_read_file_id func);
+#else
+static inline bool ima_appraise_signature(enum kernel_read_file_id func)
+{
+   return false;
+}
+#endif /* CONFIG_IMA_APPRAISE && CONFIG_INTEGRITY_TRUSTED_KEYRING */
 #endif /* _LINUX_IMA_H */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 455f4fc794f3..8134da6573c6 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -240,7 +240,12 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
 
ret = 0;
 
-   if (security_is_locked_down(LOCKDOWN_KEXEC)) {
+   /* If IMA is guaranteed to appraise a signature on the kexec
+* image, permit it even if the kernel is otherwise locked
+* down.
+*/
+   if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
+   security_is_locked_down(LOCKDOWN_KEXEC)) {
ret = -EPERM;
goto out;
}
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index d213e835c498..3bc62062cfe8 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -115,6 +115,8 @@ struct ima_kexec_hdr {
u64 count;
 };
 
+extern const int read_idmap[];
+
 #ifdef CONFIG_HAVE_IMA_KEXEC
 void ima_load_kexec_buffer(void);
 #else
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 357edd140c09..927fe889201a 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -473,7 +473,7 @@ int ima_read_file(struct file *file, enum 
kernel_read_file_id read_id)
return 0;
 }
 
-static const int read_idmap[READING_MAX_ID] = {
+const int read_idmap[READING_MAX_ID] = {
[READING_FIRMWARE] = FIRMWARE_CHECK,
[READING_FIRMWARE_PREALLOC_BUFFER] = FIRMWARE_CHECK,
[READING_MODULE] = MODULE_CHECK,
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index e0cc323f948f..8784449918e2 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1339,3 +1339,53 @@ int ima_policy_show(struct seq_file *m, void *v)
return 0;
 }
 #endif /* CONFIG_IMA_READ_POLICY */
+
+#if defined(CONFIG_IMA_APPRAISE) && defined(CONFIG_INTEGRITY_TRUSTED_KEYRING)
+/*
+ * ima_appraise_signature: whether IMA will appraise a given function using
+ * an IMA digital signature. This is restricted to cases where the kernel
+ * has a set of built-in trusted keys in order to avoid an attacker simply
+ * loading additional keys.
+ */
+bool ima_appraise_signature(enum kernel_read_file_id id)
+{
+   struct ima_rule_entry *entry;
+   bool found = false;
+   enum ima_hooks func;
+
+   if (id >= READING_MAX_ID)
+   return false;
+
+   func = read_idmap[id] ?: FILE_CHECK;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(entry, ima_rules, list) {
+   if (entry->action != APPRAISE)
+   continue;
+
+   /*
+* A generic entry will match, but otherwise require that it
+* match the func we're looking for
+*/
+   if (entry->func && entry->func != func)
+   continue;
+
+   /*
+* We require this to be a digital signature, not a raw IMA
+* hash.
+*/
+   if (entry->flags & IMA_DIGSIG_REQUIRED)
+   found = true;
+
+   /*
+* We've found 

[PATCH V33 23/30] Lock down tracing and perf kprobes when in confidentiality mode

[Matthew Garrett]

From: David Howells 

Disallow the creation of perf and ftrace kprobes when the kernel is
locked down in confidentiality mode by preventing their registration.
This prevents kprobes from being used to access kernel memory to steal
crypto data, but continues to allow the use of kprobes from signed
modules.

Reported-by: Alexei Starovoitov 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Cc: Naveen N. Rao 
Cc: Anil S Keshavamurthy 
Cc: da...@davemloft.net
Cc: Masami Hiramatsu 
---
 include/linux/security.h | 1 +
 kernel/trace/trace_kprobe.c  | 4 
 security/lockdown/lockdown.c | 1 +
 3 files changed, 6 insertions(+)

diff --git a/include/linux/security.h b/include/linux/security.h
index 6752584729e2..dae4aa83352c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -96,6 +96,7 @@ enum lockdown_reason {
LOCKDOWN_MMIOTRACE,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
+   LOCKDOWN_KPROBES,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5d5129b05df7..940ca20987aa 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace_dynevent.h"
 #include "trace_kprobe_selftest.h"
@@ -415,6 +416,9 @@ static int __register_trace_kprobe(struct trace_kprobe *tk)
 {
int i, ret;
 
+   if (security_is_locked_down(LOCKDOWN_KPROBES))
+   return -EPERM;
+
if (trace_probe_is_registered(>tp))
return -EINVAL;
 
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 80ff4a31d8aa..89ad853daec2 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -32,6 +32,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
+   [LOCKDOWN_KPROBES] = "use of kprobes",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 12/30] PCI: Lock down BAR access when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Acked-by: Bjorn Helgaas 
cc: linux-...@vger.kernel.org
---
 drivers/pci/pci-sysfs.c  |  9 +
 drivers/pci/proc.c   | 10 +-
 drivers/pci/syscall.c|  4 +++-
 include/linux/security.h |  1 +
 security/lockdown/lockdown.c |  1 +
 5 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 25794c27c7a4..00625267a5e4 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -904,6 +904,9 @@ static ssize_t pci_write_config(struct file *filp, struct 
kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
 
+   if (security_is_locked_down(LOCKDOWN_PCI_ACCESS))
+   return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1166,6 +1169,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct 
bin_attribute *attr,
enum pci_mmap_state mmap_type;
struct resource *res = >resource[bar];
 
+   if (security_is_locked_down(LOCKDOWN_PCI_ACCESS))
+   return -EPERM;
+
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
return -EINVAL;
 
@@ -1241,6 +1247,9 @@ static ssize_t pci_write_resource_io(struct file *filp, 
struct kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t off, size_t count)
 {
+   if (security_is_locked_down(LOCKDOWN_PCI_ACCESS))
+   return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
 }
 
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 6fa1627ce08d..56e438bbefa4 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pci.h"
 
@@ -117,6 +118,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const 
char __user *buf,
int size = dev->cfg_size;
int cnt;
 
+   if (security_is_locked_down(LOCKDOWN_PCI_ACCESS))
+   return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -196,6 +200,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned 
int cmd,
 #endif /* HAVE_PCI_MMAP */
int ret = 0;
 
+   if (security_is_locked_down(LOCKDOWN_PCI_ACCESS))
+   return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -237,7 +244,8 @@ static int proc_bus_pci_mmap(struct file *file, struct 
vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine = 0, res_bit = IORESOURCE_MEM;
 
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) ||
+   security_is_locked_down(LOCKDOWN_PCI_ACCESS))
return -EPERM;
 
if (fpriv->mmap_state == pci_mmap_io) {
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index d96626c614f5..54f0a7721104 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "pci.h"
@@ -90,7 +91,8 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned 
long, dfn,
u32 dword;
int err = 0;
 
-   if (!capable(CAP_SYS_ADMIN))
+   if (!capable(CAP_SYS_ADMIN) ||
+   security_is_locked_down(LOCKDOWN_PCI_ACCESS))
return -EPERM;
 
dev = pci_get_domain_bus_and_slot(0, bus, dfn);
diff --git a/include/linux/security.h b/include/linux/security.h
index deac722f0d86..95aa5ac1fa6b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -86,6 +86,7 @@ enum lockdown_reason {
LOCKDOWN_DEV_MEM,
LOCKDOWN_KEXEC,
LOCKDOWN_HIBERNATION,
+   LOCKDOWN_PCI_ACCESS,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 42b7bc467ef6..ae76a7cce7ba 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -22,6 +22,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
[LOCKDOWN_KEXEC] = "kexec of unsigned images",
[LOCKDOWN_HIBERNATION] = "hibernation",
+   [LOCKDOWN_PCI_ACCESS] = "direct PCI access",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 28/30] debugfs: Restrict debugfs when the kernel is locked down

[Matthew Garrett]

From: David Howells 

Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs.  Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead.  The following changes are made:

 (1) chmod and chown are disallowed on debugfs objects (though the root dir
 can be modified by mount and remount, but I'm not worried about that).

 (2) When the kernel is locked down, only files with the following criteria
 are permitted to be opened:

- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap

 (3) When the kernel is locked down, files may only be opened for reading.

Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.

Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.

I would actually prefer to lock down all files by default and have the
the files unlocked by the creator.  This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).

Signed-off-by: David Howells 
cc: Andy Shevchenko 
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
cc: Matthew Garrett 
cc: Thomas Gleixner 
Signed-off-by: Matthew Garrett 
---
 fs/debugfs/file.c| 31 +++
 fs/debugfs/inode.c   | 31 +--
 include/linux/security.h |  1 +
 security/lockdown/lockdown.c |  1 +
 4 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 4fce1da7db23..227b147350b7 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -136,6 +137,25 @@ void debugfs_file_put(struct dentry *dentry)
 }
 EXPORT_SYMBOL_GPL(debugfs_file_put);
 
+/*
+ * Only permit access to world-readable files when the kernel is locked down.
+ * We also need to exclude any file that has ways to write or alter it as root
+ * can bypass the permissions check.
+ */
+static bool debugfs_is_locked_down(struct inode *inode,
+  struct file *filp,
+  const struct file_operations *real_fops)
+{
+   if ((inode->i_mode & 0) == 0444 &&
+   !(filp->f_mode & FMODE_WRITE) &&
+   !real_fops->unlocked_ioctl &&
+   !real_fops->compat_ioctl &&
+   !real_fops->mmap)
+   return false;
+
+   return security_is_locked_down(LOCKDOWN_DEBUGFS);
+}
+
 static int open_proxy_open(struct inode *inode, struct file *filp)
 {
struct dentry *dentry = F_DENTRY(filp);
@@ -147,6 +167,12 @@ static int open_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+
+   if (debugfs_is_locked_down(inode, filp, real_fops)) {
+   r = -EPERM;
+   goto out;
+   }
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -272,6 +298,11 @@ static int full_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+   if (debugfs_is_locked_down(inode, filp, real_fops)) {
+   r = -EPERM;
+   goto out;
+   }
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 95b5e78c22b1..76b24fb3c911 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -32,6 +33,31 @@ static struct vfsmount *debugfs_mount;
 static int debugfs_mount_count;
 static bool debugfs_registered;
 
+/*
+ * Don't allow access attributes to be changed whilst the kernel is locked down
+ * so that we can use the file mode as part of a heuristic to determine whether
+ * to lock down individual files.
+ */
+static int debugfs_setattr(struct dentry *dentry, struct iattr *ia)
+{
+   if ((ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) &&
+   security_is_locked_down(LOCKDOWN_DEBUGFS))
+   return -EPERM;
+   return simple_setattr(dentry, ia);
+}
+
+static const struct inode_operations debugfs_file_inode_operations = {
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations debugfs_dir_inode_operations = {
+   .lookup = simple_lookup,
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations 

[PATCH V33 30/30] efi: Restrict efivar_ssdt_load when the kernel is locked down

[Matthew Garrett]

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an
EFI variable, which gives arbitrary code execution in ring 0. Prevent
that when the kernel is locked down.

Signed-off-by: Matthew Garrett 
Cc: Ard Biesheuvel 
Cc: linux-...@vger.kernel.org
---
 drivers/firmware/efi/efi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 55b77c576c42..a9ea649e0512 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -242,6 +243,9 @@ static void generic_ops_unregister(void)
 static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata;
 static int __init efivar_ssdt_setup(char *str)
 {
+   if (security_is_locked_down(LOCKDOWN_ACPI_TABLES))
+   return -EPERM;
+
if (strlen(str) < sizeof(efivar_ssdt))
memcpy(efivar_ssdt, str, strlen(str));
else
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 29/30] tracefs: Restrict tracefs when the kernel is locked down

[Matthew Garrett]

Tracefs may release more information about the kernel than desirable, so
restrict it when the kernel is locked down in confidentiality mode by
preventing open().

Signed-off-by: Matthew Garrett 
Cc: Steven Rostedt 
---
 fs/tracefs/inode.c   | 41 +++-
 include/linux/security.h |  1 +
 security/lockdown/lockdown.c |  1 +
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 7098c49f3693..f6c04fa8e415 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TRACEFS_DEFAULT_MODE   0700
 
@@ -31,6 +32,21 @@ static struct vfsmount *tracefs_mount;
 static int tracefs_mount_count;
 static bool tracefs_registered;
 
+static int default_open_file(struct inode *inode, struct file *filp)
+{
+   struct dentry *dentry = filp->f_path.dentry;
+   struct file_operations *real_fops;
+
+   if (!dentry)
+   return -EINVAL;
+
+   if (security_is_locked_down(LOCKDOWN_TRACEFS))
+   return -EPERM;
+
+   real_fops = dentry->d_fsdata;
+   return real_fops->open(inode, filp);
+}
+
 static ssize_t default_read_file(struct file *file, char __user *buf,
 size_t count, loff_t *ppos)
 {
@@ -50,6 +66,13 @@ static const struct file_operations tracefs_file_operations 
= {
.llseek =   noop_llseek,
 };
 
+static const struct file_operations tracefs_proxy_file_operations = {
+   .read = default_read_file,
+   .write =default_write_file,
+   .open = default_open_file,
+   .llseek =   noop_llseek,
+};
+
 static struct tracefs_dir_ops {
int (*mkdir)(const char *name);
int (*rmdir)(const char *name);
@@ -225,6 +248,12 @@ static int tracefs_apply_options(struct super_block *sb)
return 0;
 }
 
+static void tracefs_destroy_inode(struct inode *inode)
+{
+   if (S_ISREG(inode->i_mode))
+   kfree(inode->i_fop);
+}
+
 static int tracefs_remount(struct super_block *sb, int *flags, char *data)
 {
int err;
@@ -260,6 +289,7 @@ static int tracefs_show_options(struct seq_file *m, struct 
dentry *root)
 
 static const struct super_operations tracefs_super_operations = {
.statfs = simple_statfs,
+   .destroy_inode  = tracefs_destroy_inode,
.remount_fs = tracefs_remount,
.show_options   = tracefs_show_options,
 };
@@ -393,6 +423,7 @@ struct dentry *tracefs_create_file(const char *name, 
umode_t mode,
 {
struct dentry *dentry;
struct inode *inode;
+   struct file_operations *proxy_fops;
 
if (!(mode & S_IFMT))
mode |= S_IFREG;
@@ -406,8 +437,16 @@ struct dentry *tracefs_create_file(const char *name, 
umode_t mode,
if (unlikely(!inode))
return failed_creating(dentry);
 
+   proxy_fops = kzalloc(sizeof(struct file_operations), GFP_KERNEL);
+   if (!proxy_fops)
+   return failed_creating(dentry);
+
+   dentry->d_fsdata = fops ? (void *)fops :
+   (void *)_file_operations;
+   memcpy(proxy_fops, dentry->d_fsdata, sizeof(struct file_operations));
+   proxy_fops->open = default_open_file;
inode->i_mode = mode;
-   inode->i_fop = fops ? fops : _file_operations;
+   inode->i_fop = proxy_fops;
inode->i_private = data;
d_instantiate(dentry, inode);
fsnotify_create(dentry->d_parent->d_inode, dentry);
diff --git a/include/linux/security.h b/include/linux/security.h
index 2563a9e3b415..040e7fc33397 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -100,6 +100,7 @@ enum lockdown_reason {
LOCKDOWN_KPROBES,
LOCKDOWN_BPF,
LOCKDOWN_PERF,
+   LOCKDOWN_TRACEFS,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index a6f7b0770e78..7dc601f06cd3 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -36,6 +36,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_KPROBES] = "use of kprobes",
[LOCKDOWN_BPF] = "use of bpf",
[LOCKDOWN_PERF] = "unsafe use of perf",
+   [LOCKDOWN_TRACEFS] = "use of tracefs",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 27/30] lockdown: Print current->comm in restriction messages

[Matthew Garrett]

Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit.  This makes it a bit easier to find
out what caused the message.

The message now patterned something like:

Lockdown: :  is restricted; see man kernel_lockdown.7

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 security/lockdown/lockdown.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 14edc475d75c..408f0048f8a2 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -80,8 +80,8 @@ early_param("lockdown", lockdown_param);
 static int lockdown_is_locked_down(enum lockdown_reason what)
 {  
if ((kernel_locked_down >= what) && lockdown_reasons[what])
-   pr_notice("Lockdown: %s is restricted; see man 
kernel_lockdown.7\n",
- lockdown_reasons[what]);
+   pr_notice("Lockdown: %s: %s is restricted; see man 
kernel_lockdown.7\n",
+ current->comm, lockdown_reasons[what]);
return (kernel_locked_down >= what);
 }
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode

[Matthew Garrett]

From: David Howells 

There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction. Disable them if the kernel has been locked down in
confidentiality mode.

Suggested-by: Alexei Starovoitov 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: net...@vger.kernel.org
cc: Chun-Yi Lee 
cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
---
 include/linux/security.h |  1 +
 kernel/trace/bpf_trace.c | 11 +++
 security/lockdown/lockdown.c |  1 +
 3 files changed, 13 insertions(+)

diff --git a/include/linux/security.h b/include/linux/security.h
index dae4aa83352c..8bf426cdd151 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -97,6 +97,7 @@ enum lockdown_reason {
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
+   LOCKDOWN_BPF,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d64c00afceb5..6f57485df840 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -137,6 +137,9 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const 
void *, unsafe_ptr)
 {
int ret;
 
+   if (security_is_locked_down(LOCKDOWN_BPF))
+   return -EINVAL;
+
ret = probe_kernel_read(dst, unsafe_ptr, size);
if (unlikely(ret < 0))
memset(dst, 0, size);
@@ -156,6 +159,8 @@ static const struct bpf_func_proto bpf_probe_read_proto = {
 BPF_CALL_3(bpf_probe_write_user, void *, unsafe_ptr, const void *, src,
   u32, size)
 {
+   if (security_is_locked_down(LOCKDOWN_BPF))
+   return -EINVAL;
/*
 * Ensure we're in user context which is safe for the helper to
 * run. This helper has no business in a kthread.
@@ -207,6 +212,9 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, 
u64, arg1,
char buf[64];
int i;
 
+   if (security_is_locked_down(LOCKDOWN_BPF))
+   return -EINVAL;
+
/*
 * bpf_check()->check_func_arg()->check_stack_boundary()
 * guarantees that fmt points to bpf program stack,
@@ -534,6 +542,9 @@ BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
 {
int ret;
 
+   if (security_is_locked_down(LOCKDOWN_BPF))
+   return -EINVAL;
+
/*
 * The strncpy_from_unsafe() call will likely not fill the entire
 * buffer, but that's okay in this circumstance as we're probing
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 89ad853daec2..0a3bbf1ba01d 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
+   [LOCKDOWN_BPF] = "use of bpf",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 14/30] x86/msr: Restrict MSR access when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode.  Based on a
patch by Kees Cook.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Kees Cook 
Reviewed-by: Thomas Gleixner 
cc: x...@kernel.org
---
 arch/x86/kernel/msr.c| 8 
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 10 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4588414e2561..72f0ed5a93c3 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -84,6 +85,9 @@ static ssize_t msr_write(struct file *file, const char __user 
*buf,
int err = 0;
ssize_t bytes = 0;
 
+   if (security_is_locked_down(LOCKDOWN_MSR))
+   return -EPERM;
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
 
@@ -135,6 +139,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
err = -EFAULT;
break;
}
+   if (security_is_locked_down(LOCKDOWN_MSR)) {
+   err = -EPERM;
+   break;
+   }
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
diff --git a/include/linux/security.h b/include/linux/security.h
index 59f0ac7adfa6..81c0968e485f 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -88,6 +88,7 @@ enum lockdown_reason {
LOCKDOWN_HIBERNATION,
LOCKDOWN_PCI_ACCESS,
LOCKDOWN_IOPORT,
+   LOCKDOWN_MSR,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 6e426887bb23..a01301972290 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -24,6 +24,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_HIBERNATION] = "hibernation",
[LOCKDOWN_PCI_ACCESS] = "direct PCI access",
[LOCKDOWN_IOPORT] = "raw io port access",
+   [LOCKDOWN_MSR] = "raw MSR access",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 19/30] Lock down TIOCSSERIAL

[Matthew Garrett]

From: David Howells 

Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port.  This only appears to be an issue for the serial
drivers that use the core serial code.  All other drivers seem to either
ignore attempts to change port/irq or give an error.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/serial_core.c | 7 +++
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 351843f847c0..2dbef7dc23f6 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -852,6 +853,12 @@ static int uart_set_info(struct tty_struct *tty, struct 
tty_port *port,
new_flags = (__force upf_t)new_info->flags;
old_custom_divisor = uport->custom_divisor;
 
+   if ((change_port || change_irq) &&
+   security_is_locked_down(LOCKDOWN_TIOCSSERIAL)) {
+   retval = -EPERM;
+   goto exit;
+   }
+
if (!capable(CAP_SYS_ADMIN)) {
retval = -EPERM;
if (change_irq || change_port ||
diff --git a/include/linux/security.h b/include/linux/security.h
index 87c433f1e7db..cb5d74f9b9ff 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -91,6 +91,7 @@ enum lockdown_reason {
LOCKDOWN_MSR,
LOCKDOWN_ACPI_TABLES,
LOCKDOWN_PCMCIA_CIS,
+   LOCKDOWN_TIOCSSERIAL,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index ced4ddbb36b4..c6456f300220 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -27,6 +27,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_MSR] = "raw MSR access",
[LOCKDOWN_ACPI_TABLES] = "modified ACPI tables",
[LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage",
+   [LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 11/30] uswsusp: Disable when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel.  Disable this if the kernel
is locked down.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: linux...@vger.kernel.org
Cc: pa...@ucw.cz
Cc: r...@rjwysocki.net
---
 kernel/power/user.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index 2d8b60a3c86b..8a8d7f1c8fbb 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -52,6 +53,9 @@ static int snapshot_open(struct inode *inode, struct file 
*filp)
if (!hibernation_available())
return -EPERM;
 
+   if (security_is_locked_down(LOCKDOWN_HIBERNATION))
+   return -EPERM;
+
lock_system_sleep();
 
if (!atomic_add_unless(_device_available, -1, 0)) {
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 16/30] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

[Matthew Garrett]

From: Josh Boyer 

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware .  Reject
the option when the kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: Dave Young 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/osl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..1f8f394fce34 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -194,7 +195,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa;
 
 #ifdef CONFIG_KEXEC
-   if (acpi_rsdp)
+   if (acpi_rsdp && !security_is_locked_down(LOCKDOWN_ACPI_TABLES))
return acpi_rsdp;
 #endif
pa = acpi_arch_get_root_pointer();
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 13/30] x86: Lock down IO port access when the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.

This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
cc: x...@kernel.org
---
 arch/x86/kernel/ioport.c | 7 +--
 include/linux/security.h | 1 +
 security/lockdown/lockdown.c | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 0fe1c8782208..ac0ba0b2f3be 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,7 +32,8 @@ long ksys_ioperm(unsigned long from, unsigned long num, int 
turn_on)
 
if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
-   if (turn_on && !capable(CAP_SYS_RAWIO))
+   if (turn_on && (!capable(CAP_SYS_RAWIO) ||
+   security_is_locked_down(LOCKDOWN_IOPORT)))
return -EPERM;
 
/*
@@ -126,7 +128,8 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
return -EINVAL;
/* Trying to gain more privileges? */
if (level > old) {
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) ||
+   security_is_locked_down(LOCKDOWN_IOPORT))
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/include/linux/security.h b/include/linux/security.h
index 95aa5ac1fa6b..59f0ac7adfa6 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -87,6 +87,7 @@ enum lockdown_reason {
LOCKDOWN_KEXEC,
LOCKDOWN_HIBERNATION,
LOCKDOWN_PCI_ACCESS,
+   LOCKDOWN_IOPORT,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index ae76a7cce7ba..6e426887bb23 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -23,6 +23,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_KEXEC] = "kexec of unsigned images",
[LOCKDOWN_HIBERNATION] = "hibernation",
[LOCKDOWN_PCI_ACCESS] = "direct PCI access",
+   [LOCKDOWN_IOPORT] = "raw io port access",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 10/30] hibernate: Disable when the kernel is locked down

[Matthew Garrett]

From: Josh Boyer 

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Cc: r...@rjwysocki.net
Cc: pa...@ucw.cz
cc: linux...@vger.kernel.org
---
 include/linux/security.h | 1 +
 kernel/power/hibernate.c | 4 +++-
 security/lockdown/lockdown.c | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index 2d3c69b9fd04..deac722f0d86 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -85,6 +85,7 @@ enum lockdown_reason {
LOCKDOWN_MODULE_SIGNATURE,
LOCKDOWN_DEV_MEM,
LOCKDOWN_KEXEC,
+   LOCKDOWN_HIBERNATION,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index abef759de7c8..5804ffeb8622 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "power.h"
@@ -70,7 +71,8 @@ static const struct platform_hibernation_ops *hibernation_ops;
 
 bool hibernation_available(void)
 {
-   return (nohibernate == 0);
+   return nohibernate == 0 &&
+   !security_is_locked_down(LOCKDOWN_HIBERNATION);
 }
 
 /**
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 94af1c3583d8..42b7bc467ef6 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -21,6 +21,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
[LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
[LOCKDOWN_KEXEC] = "kexec of unsigned images",
+   [LOCKDOWN_HIBERNATION] = "hibernation",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 07/30] Copy secure_boot flag in boot params across kexec reboot

[Matthew Garrett]

From: Dave Young 

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

Adding a patch to fix this by retain the secure_boot flag in original
kernel.

secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub.  Fixing this issue by copying secure_boot flag across kexec reboot.

Signed-off-by: Dave Young 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
cc: ke...@lists.infradead.org
---
 arch/x86/kernel/kexec-bzimage64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index 22f60dd26460..4243359ac509 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -182,6 +182,7 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
 
+   params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = current_ei->efi_systab;
ei->efi_systab_hi = current_ei->efi_systab_hi;
-- 
2.22.0.410.gd8fdbe21b5-goog

[PATCH V33 03/30] security: Add a static lockdown policy LSM

[Matthew Garrett]

While existing LSMs can be extended to handle lockdown policy,
distributions generally want to be able to apply a straightforward
static policy. This patch adds a simple LSM that can be configured to
reject either integrity or all lockdown queries, and can be configured
at runtime (through securityfs), boot time (via a kernel parameter) or
build time (via a kconfig option). Based on initial code by David
Howells.

Signed-off-by: Matthew Garrett 
Cc: David Howells 
---
 .../admin-guide/kernel-parameters.txt |   9 +
 include/linux/security.h  |   4 +
 security/Kconfig  |   3 +-
 security/Makefile |   2 +
 security/lockdown/Kconfig |  46 +
 security/lockdown/Makefile|   1 +
 security/lockdown/lockdown.c  | 168 ++
 7 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 security/lockdown/Kconfig
 create mode 100644 security/lockdown/Makefile
 create mode 100644 security/lockdown/lockdown.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2b8ee90bb644..fa336f6cd5bc 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2239,6 +2239,15 @@
lockd.nlm_udpport=M [NFS] Assign UDP port.
Format: 
 
+   lockdown=   [SECURITY]
+   { integrity | confidentiality }
+   Enable the kernel lockdown feature. If set to
+   integrity, kernel features that allow userland to
+   modify the running kernel are disabled. If set to
+   confidentiality, kernel features that allow userland
+   to extract confidential information from the kernel
+   are also disabled.
+
locktorture.nreaders_stress= [KNL]
Set the number of locking read-acquisition kthreads.
Defaults to being automatically set based on the
diff --git a/include/linux/security.h b/include/linux/security.h
index b75941c811e6..a86a7739ca24 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -76,6 +76,10 @@ enum lsm_event {
LSM_POLICY_CHANGE,
 };
 
+/*
+ *  If you add to this, remember to extend lockdown_reasons in
+ *  security/lockdown/lockdown.c.
+ */
 enum lockdown_reason {
LOCKDOWN_NONE,
LOCKDOWN_INTEGRITY_MAX,
diff --git a/security/Kconfig b/security/Kconfig
index 1d6463fb1450..c35aa72103df 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -236,12 +236,13 @@ source "security/apparmor/Kconfig"
 source "security/loadpin/Kconfig"
 source "security/yama/Kconfig"
 source "security/safesetid/Kconfig"
+source "security/lockdown/Kconfig"
 
 source "security/integrity/Kconfig"
 
 config LSM
string "Ordered list of enabled LSMs"
-   default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
+   default 
"lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
help
  A comma-separated list of LSMs, in initialization order.
  Any LSMs left off this list will be ignored. This can be
diff --git a/security/Makefile b/security/Makefile
index c598b904938f..be1dd9d2cb2f 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -11,6 +11,7 @@ subdir-$(CONFIG_SECURITY_APPARMOR)+= apparmor
 subdir-$(CONFIG_SECURITY_YAMA) += yama
 subdir-$(CONFIG_SECURITY_LOADPIN)  += loadpin
 subdir-$(CONFIG_SECURITY_SAFESETID)+= safesetid
+subdir-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown
 
 # always enable default capabilities
 obj-y  += commoncap.o
@@ -27,6 +28,7 @@ obj-$(CONFIG_SECURITY_APPARMOR)   += apparmor/
 obj-$(CONFIG_SECURITY_YAMA)+= yama/
 obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/
 obj-$(CONFIG_SECURITY_SAFESETID)   += safesetid/
+obj-$(CONFIG_SECURITY_LOCKDOWN_LSM)+= lockdown/
 obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o
 
 # Object integrity file lists
diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
new file mode 100644
index ..431cd2b9a14e
--- /dev/null
+++ b/security/lockdown/Kconfig
@@ -0,0 +1,46 @@
+config SECURITY_LOCKDOWN_LSM
+   bool "Basic module for enforcing kernel lockdown"
+   depends on SECURITY
+   help
+ Build support for an LSM that enforces a coarse kernel lockdown
+ behaviour.
+
+config SECURITY_LOCKDOWN_LSM_EARLY
+bool "Enable lockdown LSM early in init"
+   depends on SECURITY_LOCKDOWN_LSM
+   help
+ Enable the lockdown LSM early in boot. This is necessary in order
+ to ensure that lockdown enforcement can be carried out on kernel
+ boot parameters that are otherwise parsed before the security
+ subsystem is 

[PATCH V33 06/30] kexec_load: Disable at runtime if the kernel is locked down

[Matthew Garrett]

From: Matthew Garrett 

The kexec_load() syscall permits the loading and execution of arbitrary
code in ring 0, which is something that lock-down is meant to prevent. It
makes sense to disable kexec_load() in this situation.

This does not affect kexec_file_load() syscall which can check for a
signature on the image to be booted.

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
Acked-by: Dave Young 
cc: ke...@lists.infradead.org
---
 include/linux/security.h | 1 +
 kernel/kexec.c   | 7 +++
 security/lockdown/lockdown.c | 1 +
 3 files changed, 9 insertions(+)

diff --git a/include/linux/security.h b/include/linux/security.h
index 034a8d54687f..2d3c69b9fd04 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -84,6 +84,7 @@ enum lockdown_reason {
LOCKDOWN_NONE,
LOCKDOWN_MODULE_SIGNATURE,
LOCKDOWN_DEV_MEM,
+   LOCKDOWN_KEXEC,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_CONFIDENTIALITY_MAX,
 };
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 68559808fdfa..040819d7b11b 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -207,6 +207,13 @@ static inline int kexec_load_check(unsigned long 
nr_segments,
if (result < 0)
return result;
 
+   /*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (security_is_locked_down(LOCKDOWN_KEXEC))
+   return -EPERM;
+
/*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 43a049b3b66a..94af1c3583d8 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -20,6 +20,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] 
= {
[LOCKDOWN_NONE] = "none",
[LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
[LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port",
+   [LOCKDOWN_KEXEC] = "kexec of unsigned images",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
-- 
2.22.0.410.gd8fdbe21b5-goog

Re: [PATCH -next] slub: play init_on_free=1 well with SLAB_RED_ZONE

[Kees Cook]

On Thu, Jun 20, 2019 at 06:14:33PM -0700, Kees Cook wrote:
> On Thu, Jun 20, 2019 at 03:28:01PM -0400, Qian Cai wrote:
> > diff --git a/mm/slub.c b/mm/slub.c
> > index a384228ff6d3..787971d4fa36 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1437,7 +1437,7 @@ static inline bool slab_free_freelist_hook(struct 
> > kmem_cache *s,
> > do {
> > object = next;
> > next = get_freepointer(s, object);
> > -   memset(object, 0, s->size);
> > +   memset(object, 0, s->object_size);
> 
> I think this should be more dynamic -- we _do_ want to wipe all
> of object_size in the case where it's just alignment and padding
> adjustments. If redzones are enabled, let's remove that portion only.

(Sorry, I meant: all of object's "size", not object_size.)

-- 
Kees Cook

[PATCH V33 00/30] Lockdown as an LSM

[Matthew Garrett]

Hi James,

Let's see how this one goes. I've moved the lockdown code into an LSM
hook and provided an internal enum of lockdown reasons that LSMs can
either group or expose at whatever level of granularity is appropriate.
I've also included a static LSM that mimics the behaviour of the
existing patchset. I think there's a reasonable discussion to have about
what sort of granularity other LSMs might want to offer, but I don't
think that necessarily needs to be a blocker to merging this.

As with the last implementation, this can be enabled via static kernel
configuration, the kernel command line or via securityfs, depending on
usecase. Distributions may wish to tie it to UEFI Secure Boot state, but
we can save that conversation to later.

Thoughts?

[PATCH V33 02/30] security: Add a "locked down" LSM hook

[Matthew Garrett]

Add a mechanism to allow LSMs to make a policy decision around whether
kernel functionality that would allow tampering with or examining the
runtime state of the kernel should be permitted.

Signed-off-by: Matthew Garrett 
---
 include/linux/lsm_hooks.h |  2 ++
 include/linux/security.h  | 11 +++
 security/security.c   |  6 ++
 3 files changed, 19 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 66fd1eac7a32..df2aebc99838 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1790,6 +1790,7 @@ union security_list_options {
int (*bpf_prog_alloc_security)(struct bpf_prog_aux *aux);
void (*bpf_prog_free_security)(struct bpf_prog_aux *aux);
 #endif /* CONFIG_BPF_SYSCALL */
+   int (*locked_down)(enum lockdown_reason what);
 };
 
 struct security_hook_heads {
@@ -2027,6 +2028,7 @@ struct security_hook_heads {
struct hlist_head bpf_prog_alloc_security;
struct hlist_head bpf_prog_free_security;
 #endif /* CONFIG_BPF_SYSCALL */
+   struct hlist_head locked_down;
 } __randomize_layout;
 
 /*
diff --git a/include/linux/security.h b/include/linux/security.h
index 1bb6fb2f1523..b75941c811e6 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -76,6 +76,12 @@ enum lsm_event {
LSM_POLICY_CHANGE,
 };
 
+enum lockdown_reason {
+   LOCKDOWN_NONE,
+   LOCKDOWN_INTEGRITY_MAX,
+   LOCKDOWN_CONFIDENTIALITY_MAX,
+};
+
 /* These functions are in security/commoncap.c */
 extern int cap_capable(const struct cred *cred, struct user_namespace *ns,
   int cap, unsigned int opts);
@@ -389,6 +395,7 @@ void security_inode_invalidate_secctx(struct inode *inode);
 int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
 int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
 int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
+int security_is_locked_down(enum lockdown_reason what);
 #else /* CONFIG_SECURITY */
 
 static inline int call_lsm_notifier(enum lsm_event event, void *data)
@@ -1189,6 +1196,10 @@ static inline int security_inode_getsecctx(struct inode 
*inode, void **ctx, u32
 {
return -EOPNOTSUPP;
 }
+static inline int security_is_locked_down(enum lockdown_reason what)
+{
+   return 0;
+}
 #endif /* CONFIG_SECURITY */
 
 #ifdef CONFIG_SECURITY_NETWORK
diff --git a/security/security.c b/security/security.c
index 2a6672c9e72f..17c17d4d8552 100644
--- a/security/security.c
+++ b/security/security.c
@@ -2378,3 +2378,9 @@ void security_bpf_prog_free(struct bpf_prog_aux *aux)
call_void_hook(bpf_prog_free_security, aux);
 }
 #endif /* CONFIG_BPF_SYSCALL */
+
+int security_is_locked_down(enum lockdown_reason what)
+{
+   return call_int_hook(locked_down, 0, what);
+}
+EXPORT_SYMBOL(security_is_locked_down);
-- 
2.22.0.410.gd8fdbe21b5-goog

Re: [PATCH -next] slub: play init_on_free=1 well with SLAB_RED_ZONE

[Kees Cook]

On Thu, Jun 20, 2019 at 03:28:01PM -0400, Qian Cai wrote:
> The linux-next commit "mm: security: introduce init_on_alloc=1 and
> init_on_free=1 boot options" [1] does not play well with SLAB_RED_ZONE
> as it will overwrite the right-side redzone with all zeros and triggers
> endless errors below. Fix it by only wiping out the slab object size and
> leave the redzone along. This has a side-effect that it does not wipe
> out the slab object metadata like the free pointer and the tracking data
> for SLAB_STORE_USER which does seem important anyway, so just to keep
> the code simple.
> 
> [1] https://patchwork.kernel.org/patch/10999465/
> 
> BUG kmalloc-64 (Tainted: GB): Redzone overwritten
> 
> INFO: 0x(ptrval)-0x(ptrval). First byte 0x0 instead of
> 0xcc
> INFO: Slab 0x(ptrval) objects=163 used=4 fp=0x(ptrval)
> flags=0x3fffc00201
> INFO: Object 0x(ptrval) @offset=58008 fp=0x(ptrval)
> 
> Redzone (ptrval): cc cc cc cc cc cc cc cc
> 
> Object (ptrval): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Object (ptrval): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Object (ptrval): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Object (ptrval): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Redzone (ptrval): 00 00 00 00 00 00 00 00
> 
> Padding (ptrval____): 00 00 00 00 00 00 00 00
> 
> CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB
> 5.2.0-rc5-next-20190620+ #2
> Call Trace:
> [c0002b72f4b0] [c089ce5c] dump_stack+0xb0/0xf4 (unreliable)
> [c0002b72f4f0] [c03e13d8] print_trailer+0x23c/0x264
> [c0002b72f580] [c03d0468] check_bytes_and_report+0x138/0x160
> [c0002b72f620] [c03d33dc] check_object+0x2ac/0x3e0
> [c0002b72f690] [c03da15c] free_debug_processing+0x1ec/0x680
> [c0002b72f780] [c03da944] __slab_free+0x354/0x6d0
> [c0002b72f840] [c015600c]
> __kthread_create_on_node+0x15c/0x260
> [c0002b72f910] [c0156144] kthread_create_on_node+0x34/0x50
> [c0002b72f930] [c0146fd0] create_worker+0xf0/0x230
> [c0002b72f9e0] [c014fc6c] workqueue_prepare_cpu+0xdc/0x280
> [c0002b72fa60] [c011b27c] cpuhp_invoke_callback+0x1bc/0x1220
> [c0002b72fb00] [c011e7d8] _cpu_up+0x168/0x340
> [c0002b72fb80] [c011eafc] do_cpu_up+0x14c/0x210
> [c0002b72fc10] [c0aedc90] smp_init+0x17c/0x1f0
> [c0002b72fcb0] [c0ac4a4c] kernel_init_freeable+0x358/0x7cc
> [c0002b72fdb0] [c00106ec] kernel_init+0x2c/0x150
> [c0002b72fe20] [c000b4cc] ret_from_kernel_thread+0x5c/0x70
> FIX kmalloc-64: Restoring 0x(ptrval)-0x(ptrval)=0xcc
> 
> FIX kmalloc-64: Object at 0x(ptrval) not freed
> 
> Signed-off-by: Qian Cai 
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index a384228ff6d3..787971d4fa36 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1437,7 +1437,7 @@ static inline bool slab_free_freelist_hook(struct 
> kmem_cache *s,
>   do {
>   object = next;
>   next = get_freepointer(s, object);
> - memset(object, 0, s->size);
> + memset(object, 0, s->object_size);

I think this should be more dynamic -- we _do_ want to wipe all
of object_size in the case where it's just alignment and padding
adjustments. If redzones are enabled, let's remove that portion only.

-Kees

>   set_freepointer(s, object, next);
>   } while (object != old_tail);
>  
> -- 
> 1.8.3.1
> 

-- 
Kees Cook

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Martin K. Petersen]

James,

> There's two problems.  One is simple terminology: the
> Documentation/process/licence-rules.rst say:
>
> GPL-2.0 means GPL 2 only
> GPL-2.0+ means GPL 2 or later
>
> I believe RMS made a fuss about this and he finally agreed to 
>
> GPL-2.0-only
> GPL-2.0-or-later

Looks like there are tons of the old style SPDX tags in the kernel. Is
there going to be a treewide conversion to the new tag format?

Just wondering how much to clean up given that the files Christoph
touched only constitute a subset of the old style tags found under
drivers/scsi.

-- 
Martin K. Petersen  Oracle Linux Engineering

RE: [PATCH] rapidio/mport_cdev: NUL terminate some strings

[alex.bou9]

Acked-by: Alexandre Bounine   

-Original Message-
From: Dan Carpenter  
Sent: Wednesday, May 29, 2019 7:06 AM
To: Matt Porter 
Cc: Alexandre Bounine ; Andrew Morton
; Ira Weiny ;
linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org
Subject: [PATCH] rapidio/mport_cdev: NUL terminate some strings

The dev_info.name[] array has space for RIO_MAX_DEVNAME_SZ + 1
characters.  But the problem here is that we don't ensure that the user
put a NUL terminator on the end of the string.  It could lead to an out
of bounds read.

Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: Dan Carpenter 
---
 drivers/rapidio/devices/rio_mport_cdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rapidio/devices/rio_mport_cdev.c
b/drivers/rapidio/devices/rio_mport_cdev.c
index 4a4a75fa26d5..3440b3e8e578 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -1690,6 +1690,7 @@ static int rio_mport_add_riodev(struct mport_cdev_priv
*priv,
 
if (copy_from_user(_info, arg, sizeof(dev_info)))
return -EFAULT;
+   dev_info.name[sizeof(dev_info.name) - 1] = '\0';
 
rmcd_debug(RDEV, "name:%s ct:0x%x did:0x%x hc:0x%x", dev_info.name,
   dev_info.comptag, dev_info.destid, dev_info.hopcount);
@@ -1821,6 +1822,7 @@ static int rio_mport_del_riodev(struct mport_cdev_priv
*priv, void __user *arg)
 
if (copy_from_user(_info, arg, sizeof(dev_info)))
return -EFAULT;
+   dev_info.name[sizeof(dev_info.name) - 1] = '\0';
 
mport = priv->md->mport;
 
-- 
2.20.1

Re: [PATCH -next v2] mm/page_alloc: fix a false memory corruption

[Kees Cook]

On Thu, Jun 20, 2019 at 04:46:06PM -0400, Qian Cai wrote:
> The linux-next commit "mm: security: introduce init_on_alloc=1 and
> init_on_free=1 boot options" [1] introduced a false positive when
> init_on_free=1 and page_poison=on, due to the page_poison expects the
> pattern 0xaa when allocating pages which were overwritten by
> init_on_free=1 with 0.
> 
> Fix it by switching the order between kernel_init_free_pages() and
> kernel_poison_pages() in free_pages_prepare().

Cool; this seems like the right approach. Alexander, what do you think?

Reviewed-by: Kees Cook 

-Kees

> 
> [1] https://patchwork.kernel.org/patch/10999465/
> 
> Signed-off-by: Qian Cai 
> ---
> 
> v2: After further debugging, the issue after switching order is likely a
> separate issue as clear_page() should not cause issues with future
> accesses.
> 
>  mm/page_alloc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 54dacf35d200..32bbd30c5f85 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1172,9 +1172,10 @@ static __always_inline bool free_pages_prepare(struct 
> page *page,
>  PAGE_SIZE << order);
>   }
>   arch_free_page(page, order);
> - kernel_poison_pages(page, 1 << order, 0);
>   if (want_init_on_free())
>   kernel_init_free_pages(page, 1 << order);
> +
> + kernel_poison_pages(page, 1 << order, 0);
>   if (debug_pagealloc_enabled())
>   kernel_map_pages(page, 1 << order, 0);
>  
> -- 
> 1.8.3.1
> 

-- 
Kees Cook

Re: [PATCH 3/6] libnvdimm/region: Register badblocks before namespaces

[Verma, Vishal L]

On Tue, 2019-06-11 at 16:25 -0700, Dan Williams wrote:
> Namespace activation expects to be able to reference region badblocks.
> The following warning sometimes triggers when asynchronous namespace
> activation races in front of the completion of namespace probing. Move
> all possible namespace probing after region badblocks initialization.
> 
> Otherwise, lockdep sometimes catches the uninitialized state of the
> badblocks seqlock with stack trace signatures like:
> 
> INFO: trying to register non-static key.
> pmem2: detected capacity change from 0 to 136365211648
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 9 PID: 358 Comm: kworker/u80:5 Tainted:
> G   OE 5.2.0-rc4+ #3382
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0
> 02/06/2015
> Workqueue: events_unbound async_run_entry_fn
> Call Trace:
>  dump_stack+0x85/0xc0
> pmem1.12: detected capacity change from 0 to 8589934592
>  register_lock_class+0x56a/0x570
>  ? check_object+0x140/0x270
>  __lock_acquire+0x80/0x1710
>  ? __mutex_lock+0x39d/0x910
>  lock_acquire+0x9e/0x180
>  ? nd_pfn_validate+0x28f/0x440 [libnvdimm]
>  badblocks_check+0x93/0x1f0
>  ? nd_pfn_validate+0x28f/0x440 [libnvdimm]
>  nd_pfn_validate+0x28f/0x440 [libnvdimm]
>  ? lockdep_hardirqs_on+0xf0/0x180
>  nd_dax_probe+0x9a/0x120 [libnvdimm]
>  nd_pmem_probe+0x6d/0x180 [nd_pmem]
>  nvdimm_bus_probe+0x90/0x2c0 [libnvdimm]
> 
> Fixes: 48af2f7e52f4 ("libnvdimm, pfn: during init, clear errors...")
> Cc: 
> Cc: Vishal Verma 
> Signed-off-by: Dan Williams 
> ---
>  drivers/nvdimm/region.c |   22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

This looks good to me,
Reviewed-by: Vishal Verma 

> 
> diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c
> index ef46cc3a71ae..488c47ac4c4a 100644
> --- a/drivers/nvdimm/region.c
> +++ b/drivers/nvdimm/region.c
> @@ -34,17 +34,6 @@ static int nd_region_probe(struct device *dev)
>   if (rc)
>   return rc;
>  
> - rc = nd_region_register_namespaces(nd_region, );
> - if (rc < 0)
> - return rc;
> -
> - ndrd = dev_get_drvdata(dev);
> - ndrd->ns_active = rc;
> - ndrd->ns_count = rc + err;
> -
> - if (rc && err && rc == err)
> - return -ENODEV;
> -
>   if (is_nd_pmem(_region->dev)) {
>   struct resource ndr_res;
>  
> @@ -60,6 +49,17 @@ static int nd_region_probe(struct device *dev)
>   nvdimm_badblocks_populate(nd_region, _region->bb,
> _res);
>   }
>  
> + rc = nd_region_register_namespaces(nd_region, );
> + if (rc < 0)
> + return rc;
> +
> + ndrd = dev_get_drvdata(dev);
> + ndrd->ns_active = rc;
> + ndrd->ns_count = rc + err;
> +
> + if (rc && err && rc == err)
> + return -ENODEV;
> +
>   nd_region->btt_seed = nd_btt_create(nd_region);
>   nd_region->pfn_seed = nd_pfn_create(nd_region);
>   nd_region->dax_seed = nd_dax_create(nd_region);
> 

Re: [PATCH v5 6/6] mm,thp: avoid writes to file with THP in pagecache

[Rik van Riel]

On Thu, 2019-06-20 at 13:53 -0700, Song Liu wrote:
> In previous patch, an application could put part of its text section
> in
> THP via madvise(). These THPs will be protected from writes when the
> application is still running (TXTBSY). However, after the application
> exits, the file is available for writes.
> 
> This patch avoids writes to file THP by dropping page cache for the
> file
> when the file is open for write. A new counter nr_thps is added to
> struct
> address_space. In do_last(), if the file is open for write and
> nr_thps
> is non-zero, we drop page cache for the whole file.
> 
> Signed-off-by: Song Liu 

Acked-by: Rik van Riel 


The comment for release_file_thp() is a little implementation
specific, which is normally a bad thing (for code we expect
to stick around for years), but probably the right thing for
code that is just a step in the direction we want to go.

Thank you for reworking these patches so quickly.

Re: [PATCH] device-dax: Add a 'resource' attribute

[Dan Williams]

On Thu, Jun 20, 2019 at 5:41 PM Vishal Verma  wrote:
>
> device-dax based devices were missing a 'resource' attribute to indicate
> the physical address range contributed by the device in question. This
> information is desirable to userspace tooling that may want to use the
> dax device as system-ram, and wants to selectively hotplug and online
> the memory blocks associated with a given device.
>
> Without this, the tooling would have to parse /proc/iomem for the memory
> ranges contributed by dax devices, which can be a workaround, but it is
> far easier to provide this information in the sysfs hierarchy.
>
> Cc: Dave Hansen 
> Cc: Dan Williams 
> Signed-off-by: Vishal Verma 

Looks good to me, applied.

Re: [LKP] [btrfs] c8eaeac7b7: aim7.jobs-per-min -11.7% regression

[Huang, Ying]

"Huang, Ying"  writes:

> "Huang, Ying"  writes:
>
>> Hi, Josef,
>>
>> kernel test robot  writes:
>>
>>> Greeting,
>>>
>>> FYI, we noticed a -11.7% regression of aim7.jobs-per-min due to commit:
>>>
>>>
>>> commit: c8eaeac7b734347c3afba7008b7af62f37b9c140 ("btrfs: reserve
>>> delalloc metadata differently")
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>>
>>> in testcase: aim7
>>> on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with 
>>> 384G memory
>>> with following parameters:
>>>
>>> disk: 4BRD_12G
>>> md: RAID0
>>> fs: btrfs
>>> test: disk_rr
>>> load: 1500
>>> cpufreq_governor: performance
>>>
>>> test-description: AIM7 is a traditional UNIX system level benchmark
>>> suite which is used to test and measure the performance of multiuser
>>> system.
>>> test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
>>
>> Here's another regression, do you have time to take a look at this?
>
> Ping

Ping again ...

Best Regards,
Huang, Ying

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Linus Torvalds]

On Thu, Jun 20, 2019 at 5:35 PM James Bottomley
 wrote:
>
> * This file is licensed under GPLv2.
>
> In all the libsas files, but then muddied the water by quoting GPLv2
> verbatim (which includes the or later than language).

Ok, thanks for the explanation. And yes, that would have likely
confused people who just looked at the license text.

Linus

[PATCH] device-dax: Add a 'resource' attribute

[Vishal Verma]

device-dax based devices were missing a 'resource' attribute to indicate
the physical address range contributed by the device in question. This
information is desirable to userspace tooling that may want to use the
dax device as system-ram, and wants to selectively hotplug and online
the memory blocks associated with a given device.

Without this, the tooling would have to parse /proc/iomem for the memory
ranges contributed by dax devices, which can be a workaround, but it is
far easier to provide this information in the sysfs hierarchy.

Cc: Dave Hansen 
Cc: Dan Williams 
Signed-off-by: Vishal Verma 
---
 drivers/dax/bus.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 2109cfe80219..2f3c42ca416a 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -295,6 +295,22 @@ static ssize_t target_node_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(target_node);
 
+static unsigned long long dev_dax_resource(struct dev_dax *dev_dax)
+{
+   struct dax_region *dax_region = dev_dax->region;
+
+   return dax_region->res.start;
+}
+
+static ssize_t resource_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dev_dax *dev_dax = to_dev_dax(dev);
+
+   return sprintf(buf, "%#llx\n", dev_dax_resource(dev_dax));
+}
+static DEVICE_ATTR_RO(resource);
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
char *buf)
 {
@@ -313,6 +329,8 @@ static umode_t dev_dax_visible(struct kobject *kobj, struct 
attribute *a, int n)
 
if (a == _attr_target_node.attr && dev_dax_target_node(dev_dax) < 0)
return 0;
+   if (a == _attr_resource.attr)
+   return 0400;
return a->mode;
 }
 
@@ -320,6 +338,7 @@ static struct attribute *dev_dax_attributes[] = {
_attr_modalias.attr,
_attr_size.attr,
_attr_target_node.attr,
+   _attr_resource.attr,
NULL,
 };
 
-- 
2.20.1

Re: linux-next: manual merge of the scsi tree with Linus' tree

[Martin K. Petersen]

Linus,

> That said, I would tend to trust the due diligence that Thomas, Greg &
> co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..

I left Christoph's patches in my 5.3 queue after Stephen let me know
about the treewide series because, well, it came from people with SCSI
affiliation and it got reviewed.

In any case I assumed the delta was formatting or purely cosmetic. I
don't recall there being any ambiguity about choice of license or SPDX
tag when I reviewed the patches.

I have been meaning to take a closer look but have had a critical fire
eating up a bunch of my time the last couple of weeks. I'll get to it...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: linux-next: manual merge of the scsi tree with Linus' tree

[James Bottomley]

On Thu, 2019-06-20 at 17:07 -0700, Linus Torvalds wrote:
> On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell  u> wrote:
> > 
> > At what point does it become worth while to do a back merge of
> > v5.2-rc4 (I think the last of the SPDX changes went into there) to
> > take care of all these (rather than Linus having to edit each of
> > these files himself during the merge window)?
> 
> For just trivial conflicts like this that have no code, I really
> would prefer no backmerges.
> 
> That said, I would tend to trust the due diligence that Thomas, Greg
> & co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..

There's two problems.  One is simple terminology: the
Documentation/process/licence-rules.rst say:

GPL-2.0 means GPL 2 only
GPL-2.0+ means GPL 2 or later

I believe RMS made a fuss about this and he finally agreed to 

GPL-2.0-only
GPL-2.0-or-later

It's just the kernel doc hasn't been updated so Christoph did what the
doc says when making the change and Thomas did what we've apparently
agreed to with RMS, hence textual discrepencies.

The other problem is actually substantive: In the libsas code Luben
Tuikov originally specified gpl 2.0 only by dint of stating:

* This file is licensed under GPLv2.

In all the libsas files, but then muddied the water by quoting GPLv2
verbatim (which includes the or later than language).  So for these
files Christoph did the conversion to v2 only SPDX tags and Thomas
converted to v2 or later tags.  Based on somewhat distant recollections
of history, I believe Christoph is right on this one.

James

Re: [PATCH] flow_dissector: Fix vlan header offset in __skb_flow_dissect

[Stanislav Fomichev]

On 06/20, Yuehaibing wrote:
> On 2019/6/20 2:39, Stanislav Fomichev wrote:
> > On 06/20, YueHaibing wrote:
> >> We build vlan on top of bonding interface, which vlan offload
> >> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
> >> BOND_XMIT_POLICY_ENCAP34.
> >>
> >> __skb_flow_dissect() fails to get information from protocol headers
> >> encapsulated within vlan, because 'nhoff' is points to IP header,
> >> so bond hashing is based on layer 2 info, which fails to distribute
> >> packets across slaves.
> >>
> >> Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info 
> >> from skb->vlan_tci")
> >> Signed-off-by: YueHaibing 
> >> ---
> >>  net/core/flow_dissector.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> >> index 415b95f..2a52abb 100644
> >> --- a/net/core/flow_dissector.c
> >> +++ b/net/core/flow_dissector.c
> >> @@ -785,6 +785,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> >>skb && skb_vlan_tag_present(skb)) {
> >>proto = skb->protocol;
> >>} else {
> >> +  if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
> >> +  nhoff -=  sizeof(*vlan);
> >> +
> > Should we instead fix the place where the skb is allocated to properly
> > pull vlan (skb_vlan_untag)? I'm not sure this particular place is
> > supposed to work with an skb. Having an skb with nhoff pointing to
> > IP header but missing skb_vlan_tag_present() when with
> > proto==ETH_P_8021xx seems weird.
> 
> The skb is a forwarded vxlan packet, it send through vlan interface like this:
> 
>vlan_dev_hard_start_xmit
> --> __vlan_hwaccel_put_tag //vlan_tci and VLAN_TAG_PRESENT is set
> --> dev_queue_xmit
> --> validate_xmit_skb
>   --> validate_xmit_vlan // vlan_hw_offload_capable is false
>  --> __vlan_hwaccel_push_inside //here skb_push vlan_hlen, then 
> clear skb->tci
> 
> --> bond_start_xmit
>--> bond_xmit_hash
>  --> __skb_flow_dissect // nhoff point to IP header
> -->  case htons(ETH_P_8021Q)
> // skb_vlan_tag_present is false, so
>   vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan), //vlan 
> point to ip header wrongly
I see, so bonding device propagates hw VLAN support from the slaves.
If one of the slaves doesn't have it, its disabled for the bond device.
Any idea why we do that? Why not pass skbs to the slave devices
instead and let them handle the hw/sw vlan implementation?
I see the propagation was added in 278339a42a1b 10 years ago and
I don't see any rationale in the commit description.
Somebody with more context should probably chime in :-)

Re: [PATCH v2] ocxl: Allow contexts to be attached with a NULL mm

[Andrew Donnellan]

On 20/6/19 2:12 pm, Alastair D'Silva wrote:

From: Alastair D'Silva 

If an OpenCAPI context is to be used directly by a kernel driver, there
may not be a suitable mm to use.

The patch makes the mm parameter to ocxl_context_attach optional.

Signed-off-by: Alastair D'Silva 


Acked-by: Andrew Donnellan 


---
  arch/powerpc/mm/book3s64/radix_tlb.c |  5 +
  drivers/misc/ocxl/context.c  |  9 ++---
  drivers/misc/ocxl/link.c | 28 
  3 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c 
b/arch/powerpc/mm/book3s64/radix_tlb.c
index bb9835681315..ce8a77fae6a7 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -666,6 +666,11 @@ EXPORT_SYMBOL(radix__flush_tlb_page);
  #define radix__flush_all_mm radix__local_flush_all_mm
  #endif /* CONFIG_SMP */
  
+/*

+ * If kernel TLBIs ever become local rather than global, then
+ * drivers/misc/ocxl/link.c:ocxl_link_add_pe will need some work, as it
+ * assumes kernel TLBIs are global.
+ */
  void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end)
  {
_tlbie_pid(0, RIC_FLUSH_ALL);
diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index bab9c9364184..994563a078eb 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -69,6 +69,7 @@ static void xsl_fault_error(void *data, u64 addr, u64 dsisr)
  int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, struct mm_struct 
*mm)
  {
int rc;
+   unsigned long pidr = 0;
  
  	// Locks both status & tidr

mutex_lock(>status_mutex);
@@ -77,9 +78,11 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, 
struct mm_struct *mm)
goto out;
}
  
-	rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,

-   mm->context.id, ctx->tidr, amr, mm,
-   xsl_fault_error, ctx);
+   if (mm)
+   pidr = mm->context.id;
+
+   rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid, pidr, ctx->tidr,
+ amr, mm, xsl_fault_error, ctx);
if (rc)
goto out;
  
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c

index cce5b0d64505..58d111afd9f6 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -224,6 +224,17 @@ static irqreturn_t xsl_fault_handler(int irq, void *data)
ack_irq(spa, ADDRESS_ERROR);
return IRQ_HANDLED;
}
+
+   if (!pe_data->mm) {
+   /*
+* translation fault from a kernel context - an OpenCAPI
+* device tried to access a bad kernel address
+*/
+   rcu_read_unlock();
+   pr_warn("Unresolved OpenCAPI xsl fault in kernel context\n");
+   ack_irq(spa, ADDRESS_ERROR);
+   return IRQ_HANDLED;
+   }
WARN_ON(pe_data->mm->context.id != pid);
  
  	if (mmget_not_zero(pe_data->mm)) {

@@ -523,7 +534,13 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
pe->amr = cpu_to_be64(amr);
pe->software_state = cpu_to_be32(SPA_PE_VALID);
  
-	mm_context_add_copro(mm);

+   /*
+* For user contexts, register a copro so that TLBIs are seen
+* by the nest MMU. If we have a kernel context, TLBIs are
+* already global.
+*/
+   if (mm)
+   mm_context_add_copro(mm);
/*
 * Barrier is to make sure PE is visible in the SPA before it
 * is used by the device. It also helps with the global TLBI
@@ -546,7 +563,8 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
 * have a reference on mm_users. Incrementing mm_count solves
 * the problem.
 */
-   mmgrab(mm);
+   if (mm)
+   mmgrab(mm);
trace_ocxl_context_add(current->pid, spa->spa_mem, pasid, pidr, tidr);
  unlock:
mutex_unlock(>spa_lock);
@@ -652,8 +670,10 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
if (!pe_data) {
WARN(1, "Couldn't find pe data when removing PE\n");
} else {
-   mm_context_remove_copro(pe_data->mm);
-   mmdrop(pe_data->mm);
+   if (pe_data->mm) {
+   mm_context_remove_copro(pe_data->mm);
+   mmdrop(pe_data->mm);
+   }
kfree_rcu(pe_data, rcu);
}
  unlock:



--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited