Re: [RESEND][PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

[Vaidyanathan Srinivasan]

* Benjamin Herrenschmidt  [2018-03-01 08:40:22]:

> On Thu, 2018-03-01 at 01:03 +0530, Akshay Adiga wrote:
> > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle
> > states via stop API.") uses stop-api provided by the firmware to restore
> > PSSCR. PSSCR restore is required for handling special wakeup. When special
> > wakeup is completed, the core enters stop state based on restored PSSCR.
> > 
> > Currently PSSCR is restored to deepest available stop state, causing
> > a idle cpu to enter deeper stop state on a special wakeup, which causes
> > the cpu to hang on wakeup.
> > 
> > A "sensors" command which reads temperature (through DTS sensors) on idle
> > cpu can trigger special wakeup.
> > 
> > Failed Scenario :
> > Request restore of PSSCR with RL = 11
> > cpu enters idle state (stop5)
> >   user triggers "sensors" command
> >Assert special wakeup on cpu
> >  Restores PSSCR with RL = 11  < Done by firmware
> >   Read DTS sensor
> >Deassert special wakeup
> >   cpu enters idle state (stop11) <-- Instead of stop5
> > 
> > Cpu hang is caused because cpu ended up in a deeper state than it requested
> > 
> > This patch fixes instability caused by special wakeup when stop11 is
> > enabled. Requests restore of PSSCR to deepest stop state used by cpuidle.
> > Only when offlining cpu, request restore of PSSCR to deepest stop state.
> > On onlining cpu, request restore of PSSCR to deepest stop state used by
> > cpuidle.
> 
> So if we chose a stop state, but somebody else does a special wakeup,
> we'll end up going back into a *deeper* one than the one we came from ?

Unfortunately yes.  This is the current limitation.  If we are in stop4
and above and we had not set a PSSCR to be restored, then the hardware
will default to all bits set (stop15) leading to entry into stop11
after the special wakeup is removed.  The requirement is such that we
need to have a correct PSSCR restore value set using stop-api.

We need to set a restore PSSCR value that represents one in a group
like stop4,5,6,7 will have identical state loss, hence we can either
set a PSSCR of 7 or 4 or 5 for any of this stop state entry and not
have to use stop-api to set exact value of stop4 or 5 at every entry.
 
> I still think this is broken by design. The chip should automatically
> go back to the state it went to after special wakeup, thus the PPE
> controlling the state should override the PSSCR value accordingly
> rather than relying on those SW hoops.

Special wakeup de-assertion and re-entry hits this limitation where we
have lost the original content of PSSCR SPR and hence CME does not know
what was requested.

Additional stop-api calls from software could have been avoided, but
practically we have only cpu hotplug case that uses stop11 and needs
this stop-api.  We can default the system to stop4 or stop5 and then
make stop-api call to explicitly set stop11 and then hotplug out the
cpu. We have to restore the deepest cpuidle state (stop4/5) back
during online.  As such this is not much of software overhead. But we
need an elegant method to control these calls from OPAL flags so that
kernel behaviour can be more closely controlled.

If we want to use stop11 in cpuidle (despite being very slow) for
evaluation reasons, then we will need to make more stop-api call to
choose between stop4/5 vs stop11 since they belong to different group.
Even in this case, since stop11 is the slow path, we would want to set
stop11 before entry and restore to stop4/5 after wakeup.  This way we
still completely avoid stop-api call in fast-path stop4/5 entry/exit.

--Vaidy

Re: KASAN: use-after-free Read in __list_del_entry_valid (3)

[Martijn Coenen]

On Tue, Mar 6, 2018 at 9:30 AM, syzbot
 wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 094b58e1040a44f991d7ab628035e69c4d6b79c9 (Mon Mar 5 19:57:06 2018 +)
> Merge tag 'linux-kselftest-4.16-rc5' of
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

I'll take a look at this one,

Martijn

>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> user-space arch: i386
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+09e05aba06723a94d...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> binder: release 6174:6185 transaction 4 in, still active
> binder: send failed reply for transaction 4 to 6174:6185
> binder: 6194:6198 ERROR: BC_REGISTER_LOOPER called without request
> ==
> binder: 6198 RLIMIT_NICE not set
> BUG: KASAN: use-after-free in __list_del_entry_valid+0x144/0x150
> lib/list_debug.c:54
> Read of size 8 at addr 8801daede810 by task kworker/1:1/24
>
> CPU: 1 PID: 24 Comm: kworker/1:1 Not tainted 4.16.0-rc4+ #252
> binder: BINDER_SET_CONTEXT_MGR already set
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events binder_deferred_func
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x24d lib/dump_stack.c:53
> binder: 6194:6206 got new transaction with bad transaction stack,
> transaction 9 has target 6194:0
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23c/0x360 mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  __list_del_entry_valid+0x144/0x150 lib/list_debug.c:54
>  __list_del_entry include/linux/list.h:117 [inline]
>  list_del_init include/linux/list.h:159 [inline]
>  binder_dequeue_work_head_ilocked drivers/android/binder.c:893 [inline]
>  binder_dequeue_work_head drivers/android/binder.c:913 [inline]
>  binder_release_work+0x163/0x490 drivers/android/binder.c:4191
> binder: 6194:6206 transaction failed 29201/-71, size 0-0 line 2875
> binder: 6191:6205 ioctl 40046207 0 returned -16
>  binder_thread_release+0x4d0/0x720 drivers/android/binder.c:4396
>  binder_deferred_release drivers/android/binder.c:4939 [inline]
>  binder_deferred_func+0x4f4/0x1340 drivers/android/binder.c:5022
> binder: BINDER_SET_CONTEXT_MGR already set
> binder: 6200:6207 ioctl 40046207 0 returned -16
> binder: 6191:6208 ERROR: BC_REGISTER_LOOPER called without request
>  process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
> binder: 6208 RLIMIT_NICE not set
> binder: 6200:6212 ERROR: BC_REGISTER_LOOPER called without request
> binder: 6212 RLIMIT_NICE not set
> binder: 6191:6213 got new transaction with bad transaction stack,
> transaction 11 has target 6194:0
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
> binder: 6191:6213 transaction failed 29201/-71, size 0-0 line 2875
> binder: 6198 RLIMIT_NICE not set
> binder: release 6200:6207 transaction 14 out, still active
> binder: undelivered TRANSACTION_COMPLETE
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
>
> Allocated by task 6185:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3607
>  kmalloc include/linux/slab.h:512 [inline]
>  kzalloc include/linux/slab.h:701 [inline]
>  binder_transaction+0x13c1/0x81c0 drivers/android/binder.c:2900
>  binder_thread_write+0xb50/0x3840 drivers/android/binder.c:3513
>  binder_ioctl_write_read.isra.38+0x261/0xcb0 drivers/android/binder.c:4451
>  binder_ioctl+0xb72/0x1417 drivers/android/binder.c:4591
>  C_SYSC_ioctl fs/compat_ioctl.c:1461 [inline]
>  compat_SyS_ioctl+0x151/0x2a30 fs/compat_ioctl.c:1407
>  do_syscall_32_irqs_on arch/x86/entry/common.c:330 [inline]
>  do_fast_syscall_32+0x3ec/0xf9f arch/x86/entry/common.c:392
>  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
>
> Freed by task 24:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd9/0x260 mm/slab.c:3800
>  binder_free_transaction+0x6a/0x90 drivers/android/binder.c:1966
>  binder_send_failed_reply+0x1c9/0x380 drivers/android/binder.c:2005
>  binder_thread_release+0x4bb/0x720 drivers/android/binder.c:4395
>  binder_deferred_release drivers/android/binder.c:4939 [inline]
>  binder_deferred_func+0x4f4/0x1340 drivers/android/binder.c:5022
>  process_one_work+0xc47/0x1bb0 kerne

[PATCH v5 4/7] x86: Align x86_64 PCI_MMCONFIG with 32-bit variant

[Jan Kiszka]

From: Jan Kiszka 

Allow to enable PCI_MMCONFIG when only SFI is present and make this
option default on. This will help consolidating both into one Kconfig
statement.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..c19f5342ec2b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2659,7 +2659,8 @@ config PCI_DOMAINS
 
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access"
-   depends on X86_64 && PCI && ACPI
+   default y
+   depends on X86_64 && PCI && (ACPI || SFI)
 
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
-- 
2.13.6

[PATCH v5 3/7] x86/jailhouse: Enable PCI mmconfig access in inmates

[Jan Kiszka]

From: Otavio Pontes 

Use the PCI mmconfig base address exported by jailhouse in boot
parameters in order to access the memory mapped PCI configuration space.

Signed-off-by: Otavio Pontes 
[Jan: rebased, fixed !CONFIG_PCI_MMCONFIG, used pcibios_last_bus]
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
---
 arch/x86/include/asm/pci_x86.h | 2 ++
 arch/x86/kernel/jailhouse.c| 8 
 arch/x86/pci/mmconfig-shared.c | 4 ++--
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index eb66fa9cd0fc..959d618dbb17 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -151,6 +151,8 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg, 
u8 start, u8 end,
   phys_addr_t addr);
 extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+   int end, u64 addr);
 
 extern struct list_head pci_mmcfg_list;
 
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index b68fd895235a..fa183a131edc 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -124,6 +124,14 @@ static int __init jailhouse_pci_arch_init(void)
if (pcibios_last_bus < 0)
pcibios_last_bus = 0xff;
 
+#ifdef CONFIG_PCI_MMCONFIG
+   if (setup_data.pci_mmconfig_base) {
+   pci_mmconfig_add(0, 0, pcibios_last_bus,
+setup_data.pci_mmconfig_base);
+   pci_mmcfg_arch_init();
+   }
+#endif
+
return 0;
 }
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0e590272366b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -94,8 +94,8 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int 
segment, int start,
return new;
 }
 
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-   int end, u64 addr)
+struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+int end, u64 addr)
 {
struct pci_mmcfg_region *new;
 
-- 
2.13.6

[PATCH v5 5/7] x86: Consolidate PCI_MMCONFIG configs

[Jan Kiszka]

From: Jan Kiszka 

Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we
have two PCI_MMCONFIG entries, one from the original i386 and another
from x86_64. This consolidates both entries into a single one.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c19f5342ec2b..8986a6b6e3df 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2641,8 +2641,10 @@ config PCI_DIRECT
depends on PCI && (X86_64 || (PCI_GODIRECT || PCI_GOANY || PCI_GOOLPC 
|| PCI_GOMMCONFIG))
 
 config PCI_MMCONFIG
-   def_bool y
-   depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || 
PCI_GOANY)
+   bool "Support mmconfig PCI config space access" if X86_64
+   default y
+   depends on PCI && (ACPI || SFI)
+   depends on X86_64 || (PCI_GOANY || PCI_GOMMCONFIG)
 
 config PCI_OLPC
def_bool y
@@ -2657,11 +2659,6 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
-config PCI_MMCONFIG
-   bool "Support mmconfig PCI config space access"
-   default y
-   depends on X86_64 && PCI && (ACPI || SFI)
-
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
-- 
2.13.6

[PATCH v5 2/7] PCI: Scan all functions when running over Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to
have a function 0.  Therefore, Linux scans for devices at function 0
(devfn 0/8/16/...) and only scans for other functions if function 0
has its Multi-Function Device bit set or ARI or SR-IOV indicate
there are more functions.

The Jailhouse hypervisor may pass individual functions of a
multi-function device to a guest without passing function 0, which
means a Linux guest won't find them.

Change Linux PCI probing so it scans all function numbers when
running as a guest over Jailhouse.

This is technically prohibited by the spec, so it is possible that
PCI devices without the Multi-Function Device bit set may have
unexpected behavior in response to this probe.

Derived from original patch by Benedikt Spranger.

CC: Benedikt Spranger 
Signed-off-by: Jan Kiszka 
Acked-by: Bjorn Helgaas 
Reviewed-by: Andy Shevchenko 
---
 arch/x86/pci/legacy.c |  4 +++-
 drivers/pci/probe.c   | 22 +++---
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
index 1cb01abcb1be..dfbe6ac38830 100644
--- a/arch/x86/pci/legacy.c
+++ b/arch/x86/pci/legacy.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -34,13 +35,14 @@ int __init pci_legacy_init(void)
 
 void pcibios_scan_specific_bus(int busn)
 {
+   int stride = jailhouse_paravirt() ? 1 : 8;
int devfn;
u32 l;
 
if (pci_find_bus(0, busn))
return;
 
-   for (devfn = 0; devfn < 256; devfn += 8) {
+   for (devfn = 0; devfn < 256; devfn += stride) {
if (!raw_pci_read(0, busn, devfn, PCI_VENDOR_ID, 2, &l) &&
l != 0x && l != 0x) {
DBG("Found device at %02x:%02x [%04x]\n", busn, devfn, 
l);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef5377438a1e..3c365dc996e7 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "pci.h"
@@ -2518,14 +2519,29 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
 {
unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0;
unsigned int start = bus->busn_res.start;
-   unsigned int devfn, cmax, max = start;
+   unsigned int devfn, fn, cmax, max = start;
struct pci_dev *dev;
+   int nr_devs;
 
dev_dbg(&bus->dev, "scanning bus\n");
 
/* Go find them, Rover! */
-   for (devfn = 0; devfn < 0x100; devfn += 8)
-   pci_scan_slot(bus, devfn);
+   for (devfn = 0; devfn < 256; devfn += 8) {
+   nr_devs = pci_scan_slot(bus, devfn);
+
+   /*
+* The Jailhouse hypervisor may pass individual functions of a
+* multi-function device to a guest without passing function 0.
+* Look for them as well.
+*/
+   if (jailhouse_paravirt() && nr_devs == 0) {
+   for (fn = 1; fn < 8; fn++) {
+   dev = pci_scan_single_device(bus, devfn + fn);
+   if (dev)
+   dev->multifunction = 1;
+   }
+   }
+   }
 
/* Reserve buses for SR-IOV capability */
used_buses = pci_iov_bus_range(bus);
-- 
2.13.6

[PATCH v5 6/7] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

[Jan Kiszka]

From: Jan Kiszka 

Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.

Saves some bytes in the Jailhouse non-root kernel.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig  | 6 +-
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/cpu/amd.c | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8986a6b6e3df..b53340e71f84 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2643,7 +2643,7 @@ config PCI_DIRECT
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access" if X86_64
default y
-   depends on PCI && (ACPI || SFI)
+   depends on PCI && (ACPI || SFI || JAILHOUSE_GUEST)
depends on X86_64 || (PCI_GOANY || PCI_GOMMCONFIG)
 
 config PCI_OLPC
@@ -2659,6 +2659,10 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
+config MMCONF_FAM10H
+   def_bool y
+   depends on X86_64 && PCI_MMCONFIG && ACPI
+
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 29786c87e864..73ccf80c09a2 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -146,6 +146,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
 
-   obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
+   obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
 endif
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f0e6456ca7d3..12bc0a1139da 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -716,7 +716,7 @@ static void init_amd_k8(struct cpuinfo_x86 *c)
 
 static void init_amd_gh(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_MMCONF_FAM10H
/* do this for boot cpu */
if (c == &boot_cpu_data)
check_enable_amd_mmconf_dmi();
-- 
2.13.6

[PATCH v5 7/7] MAINTAINERS: Add entry for Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..6dc0b8f3ae0e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7523,6 +7523,13 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/ix2505v*
 
+JAILHOUSE HYPERVISOR INTERFACE
+M: Jan Kiszka 
+L: jailhouse-...@googlegroups.com
+S: Maintained
+F: arch/x86/kernel/jailhouse.c
+F: arch/x86/include/asm/jailhouse_para.h
+
 JC42.4 TEMPERATURE SENSOR DRIVER
 M: Guenter Roeck 
 L: linux-hw...@vger.kernel.org
-- 
2.13.6

[PATCH v5 0/7] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

[Jan Kiszka]

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest
is currently pending in the tip tree. This builds on top and enhances
the PCI support for x86 and also ARM guests (ARM[64] does not require
platform patches and works already).

Key elements of this series are:
 - detection of Jailhouse via device tree hypervisor node
 - function-level PCI scan if Jailhouse is detected
 - MMCONFIG support for x86 guests

As most changes affect x86, I would suggest to route the series also via
tip after the necessary acks are collected.

Changes in v5:
 - fix build breakage of patch 6 on i386

Changes in v4:
 - slit up Kconfig changes
 - respect pcibios_last_bus during mmconfig setup
 - cosmetic changes requested by Andy

Changes in v3:
 - avoided duplicate scans of PCI functions under Jailhouse
 - reformated PCI_MMCONFIG condition and rephrase related commit log

Changes in v2:
 - adjusted commit log and include ordering in patch 2
 - rebased over Linus master

Jan

[1] https://lkml.org/lkml/2017/11/27/125
[2] http://jailhouse-project.org

CC: Benedikt Spranger 
CC: Juergen Gross 
CC: Mark Rutland 
CC: Otavio Pontes 
CC: Rob Herring 

Jan Kiszka (6):
  jailhouse: Provide detection for non-x86 systems
  PCI: Scan all functions when running over Jailhouse
  x86: Align x86_64 PCI_MMCONFIG with 32-bit variant
  x86: Consolidate PCI_MMCONFIG configs
  x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
  MAINTAINERS: Add entry for Jailhouse

Otavio Pontes (1):
  x86/jailhouse: Enable PCI mmconfig access in inmates

 Documentation/devicetree/bindings/jailhouse.txt |  8 
 MAINTAINERS |  7 +++
 arch/x86/Kconfig| 12 +++-
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 arch/x86/include/asm/pci_x86.h  |  2 ++
 arch/x86/kernel/Makefile|  2 +-
 arch/x86/kernel/cpu/amd.c   |  2 +-
 arch/x86/kernel/jailhouse.c |  8 
 arch/x86/pci/legacy.c   |  4 +++-
 arch/x86/pci/mmconfig-shared.c  |  4 ++--
 drivers/pci/probe.c | 22 +++---
 include/linux/hypervisor.h  | 17 +++--
 12 files changed, 74 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

-- 
2.13.6

[PATCH v5 1/7] jailhouse: Provide detection for non-x86 systems

[Jan Kiszka]

From: Jan Kiszka 

Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.

CC: Rob Herring 
CC: Mark Rutland 
CC: Juergen Gross 
Signed-off-by: Jan Kiszka 
Reviewed-by: Juergen Gross 
---
 Documentation/devicetree/bindings/jailhouse.txt |  8 
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 include/linux/hypervisor.h  | 17 +++--
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

diff --git a/Documentation/devicetree/bindings/jailhouse.txt 
b/Documentation/devicetree/bindings/jailhouse.txt
new file mode 100644
index ..2901c25ff340
--- /dev/null
+++ b/Documentation/devicetree/bindings/jailhouse.txt
@@ -0,0 +1,8 @@
+Jailhouse non-root cell device tree bindings
+
+
+When running in a non-root Jailhouse cell (partition), the device tree of this
+platform shall have a top-level "hypervisor" node with the following
+properties:
+
+- compatible = "jailhouse,cell"
diff --git a/arch/x86/include/asm/jailhouse_para.h 
b/arch/x86/include/asm/jailhouse_para.h
index 875b54376689..b885a961a150 100644
--- a/arch/x86/include/asm/jailhouse_para.h
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL2.0 */
 
 /*
- * Jailhouse paravirt_ops implementation
+ * Jailhouse paravirt detection
  *
  * Copyright (c) Siemens AG, 2015-2017
  *
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
index b19563f9a8eb..fc08b433c856 100644
--- a/include/linux/hypervisor.h
+++ b/include/linux/hypervisor.h
@@ -8,15 +8,28 @@
  */
 
 #ifdef CONFIG_X86
+
+#include 
 #include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
x86_platform.hyper.pin_vcpu(cpu);
 }
-#else
+
+#else /* !CONFIG_X86 */
+
+#include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
 }
-#endif
+
+static inline bool jailhouse_paravirt(void)
+{
+   return of_find_compatible_node(NULL, NULL, "jailhouse,cell");
+}
+
+#endif /* !CONFIG_X86 */
 
 #endif /* __LINUX_HYPEVISOR_H */
-- 
2.13.6

[PATCH v4 3/3] security: Add an example sample dynamic LSM

[Sargun Dhillon]

This adds an example LSM that utilizes the features added by the
dynamically loadable LSMs patch. Once the module is unloaded, the
command is once again allowed. It prevents the user from running:
date --set="October 21 2015 16:29:00 PDT"

Signed-off-by: Sargun Dhillon 
---
 samples/Kconfig   |  6 ++
 samples/Makefile  |  2 +-
 samples/lsm/Makefile  |  4 
 samples/lsm/lsm_example.c | 33 +
 4 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 samples/lsm/Makefile
 create mode 100644 samples/lsm/lsm_example.c

diff --git a/samples/Kconfig b/samples/Kconfig
index c332a3b9de05..022242c0b50b 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -117,4 +117,10 @@ config SAMPLE_STATX
help
  Build example userspace program to use the new extended-stat syscall.
 
+config SAMPLE_DYNAMIC_LSM
+   tristate "Build LSM examples -- loadable modules only"
+   depends on SECURITY_DYNAMIC_HOOKS && m
+   help
+ This builds an example dynamic LSM
+
 endif # SAMPLES
diff --git a/samples/Makefile b/samples/Makefile
index db54e766ddb1..9d23835d6e6d 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -3,4 +3,4 @@
 obj-$(CONFIG_SAMPLES)  += kobject/ kprobes/ trace_events/ livepatch/ \
   hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
   configfs/ connector/ v4l/ trace_printk/ blackfin/ \
-  vfio-mdev/ statx/
+  vfio-mdev/ statx/ lsm/
diff --git a/samples/lsm/Makefile b/samples/lsm/Makefile
new file mode 100644
index ..d4ccb940f18b
--- /dev/null
+++ b/samples/lsm/Makefile
@@ -0,0 +1,4 @@
+# builds the loadable LSM example kernel modules;
+# then to use one (as root):  insmod 
+# and to unload: rmmod module_name
+obj-$(CONFIG_SAMPLE_DYNAMIC_LSM) += lsm_example.o
diff --git a/samples/lsm/lsm_example.c b/samples/lsm/lsm_example.c
new file mode 100644
index ..95c56ebd4d16
--- /dev/null
+++ b/samples/lsm/lsm_example.c
@@ -0,0 +1,33 @@
+/*
+ * This sample hooks into the "settime"
+ *
+ * Once you run it, the following will not be allowed:
+ * date --set="October 21 2015 16:29:00 PDT"
+ */
+
+#include 
+#include 
+#include 
+
+static int settime_cb(const struct timespec *ts, const struct timezone *tz)
+{
+   /* We aren't allowed to travel to October 21 2015 16:29 PDT */
+   if (ts->tv_sec >= 1445470140 && ts->tv_sec < 1445470200)
+   return -EPERM;
+
+   return 0;
+}
+
+static struct security_hook_list sample_hooks[] = {
+   LSM_HOOK_INIT(settime, settime_cb),
+};
+
+static int __init lsm_init(void)
+{
+   return security_add_dynamic_hooks(sample_hooks,
+ ARRAY_SIZE(sample_hooks),
+ "sample");
+}
+
+module_init(lsm_init)
+MODULE_LICENSE("GPL");
-- 
2.14.1

[PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

[Sargun Dhillon]

This patch adds dynamic security hooks. These hooks are designed to allow
for safe runtime loading.

These hooks are only run after all built-in, and major LSMs are run.
The LSMs enabled by this feature must be minor LSMs, but they can poke
at the security blobs, as the blobs should be initialized by the time
their callback happens.

There should be little runtime performance overhead for this feature,
as it's protected behind static_keys, which are disabled by default,
and are only enabled per-hook at runtime, when a module is loaded.

Currently, the hook heads are separated for dynamic hooks, because
it is not read-only like the hooks which are loaded at runtime.

Some hooks are blacklisted, and attempting to load an LSM with any
of them in use will fail.

Signed-off-by: Sargun Dhillon 
---
 include/linux/lsm_hooks.h |  26 +-
 security/Kconfig  |   9 +++
 security/inode.c  |  13 ++-
 security/security.c   | 198 --
 4 files changed, 234 insertions(+), 12 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d28c7f5b01c1..4e6351957dff 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * union security_list_options - Linux Security Module hook function list
@@ -1968,6 +1969,9 @@ struct security_hook_list {
enum lsm_hook   head_idx;
union security_list_options hook;
char*lsm;
+#ifdef CONFIG_SECURITY_DYNAMIC_HOOKS
+   struct module   *owner;
+#endif
 } __randomize_layout;
 
 /*
@@ -1976,11 +1980,29 @@ struct security_hook_list {
  * care of the common case and reduces the amount of
  * text involved.
  */
+#ifdef CONFIG_SECURITY_DYNAMIC_HOOKS
+#define LSM_HOOK_INIT(HEAD, HOOK)  \
+   {   \
+   .head_idx = HOOK_IDX(HEAD), \
+   .hook = { .HEAD = HOOK },   \
+   .owner = THIS_MODULE,   \
+   }
+
+#else
 #define LSM_HOOK_INIT(HEAD, HOOK) \
{ .head_idx = HOOK_IDX(HEAD), .hook = { .HEAD = HOOK } }
+#endif
 
-extern char *lsm_names;
-
+#ifdef CONFIG_SECURITY_DYNAMIC_HOOKS
+extern int security_add_dynamic_hooks(struct security_hook_list *hooks,
+ int count, char *lsm);
+#else
+static inline int security_add_dynamic_hooks(struct security_hook_list *hooks,
+int count, char *lsm)
+{
+   return -EOPNOTSUPP;
+}
+#endif
 extern void security_add_hooks(struct security_hook_list *hooks, int count,
char *lsm);
 
diff --git a/security/Kconfig b/security/Kconfig
index c4302067a3ad..481b93b0d4d9 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -36,6 +36,15 @@ config SECURITY_WRITABLE_HOOKS
bool
default n
 
+config SECURITY_DYNAMIC_HOOKS
+   bool "Runtime loadable (minor) LSMs via LKMs"
+   depends on SECURITY && SRCU
+   help
+ This enables LSMs which live in LKMs, and supports loading, and
+ unloading them safely at runtime. These LSMs must be minor LSMs.
+ They cannot circumvent the built-in LSMs.
+ If you are unsure how to answer this question, answer N.
+
 config SECURITYFS
bool "Enable the securityfs filesystem"
help
diff --git a/security/inode.c b/security/inode.c
index 8dd9ca8848e4..89be07b044a5 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -22,6 +22,10 @@
 #include 
 #include 
 #include 
+#include 
+
+extern char *lsm_names;
+extern struct mutex lsm_lock;
 
 static struct vfsmount *mount;
 static int mount_count;
@@ -312,8 +316,13 @@ static struct dentry *lsm_dentry;
 static ssize_t lsm_read(struct file *filp, char __user *buf, size_t count,
loff_t *ppos)
 {
-   return simple_read_from_buffer(buf, count, ppos, lsm_names,
-   strlen(lsm_names));
+   ssize_t ret;
+
+   mutex_lock(&lsm_lock);
+   ret = simple_read_from_buffer(buf, count, ppos, lsm_names,
+ strlen(lsm_names));
+   mutex_unlock(&lsm_lock);
+   return ret;
 }
 
 static const struct file_operations lsm_ops = {
diff --git a/security/security.c b/security/security.c
index b9fb297b824e..492d44dd0549 100644
--- a/security/security.c
+++ b/security/security.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_LSM_EVM_XATTR  2
 
@@ -36,10 +37,18 @@
 #define SECURITY_NAME_MAX  10
 
 static struct list_head security_hook_heads[__MAX_LSM_HOOK] 
__lsm_ro_after_init;
-static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
-
 #define HOOK_HEAD(NAME)(&security_hook_heads[HOOK_IDX(NAME)])
 
+#ifdef CONFIG_SECURITY_DYNAMIC_HOOKS
+static struct list_head dynamic_security_hook_heads[__MAX_LSM_HOOK];
+static struct srcu_struct dynamic_hook_srcus[__MAX

[PATCH v4 0/3] Safe, dynamically loadable LSM hooks

[Sargun Dhillon]

This patchset introduces safe dynamic LSM support. These are currently
not unloadable, until we figure out a use case that needs that. Adding
an unload hook is trivial given the way the patch is written.

This exposes a second mechanism of loading hooks which are in modules.
These hooks are behind static keys, so they should come at low performance
overhead. The built-in hook heads are read-only, whereas the dynamic hooks
are mutable.

Not all hooks can be loaded into. Some hooks are blacklisted, and therefore
trying to load a module which plugs into those hooks will fail.

One of the big benefits with loadable security modules is to help with
"unknown unknowns". Although, livepatch is excellent, sometimes, a
surgical LSM is simpler.

It includes an example LSM that prevents specific time travel.

Changes since v3:
  * readded hook blacklisted
  * return error, rather than panic if unable to allocate memory

Changes since v2:
  * inode get/set security is readded
  * xfrm singleton hook readded
  * Security hooks are turned into an array
  * Security hooks and dynamic hooks enum is collapsed

Changes since v1:
  * It no longer allows unloading of modules
  * prctl is fixed
  * inode get/set security is removed
  * xfrm singleton hook removed


Sargun Dhillon (3):
  security: Refactor LSM hooks into an array and enum
  security: Expose a mechanism to load lsm hooks dynamically at runtime
  security: Add an example sample dynamic LSM

 include/linux/lsm_hooks.h | 459 --
 samples/Kconfig   |   6 +
 samples/Makefile  |   2 +-
 samples/lsm/Makefile  |   4 +
 samples/lsm/lsm_example.c |  33 
 security/Kconfig  |   9 +
 security/inode.c  |  13 +-
 security/security.c   | 222 --
 8 files changed, 508 insertions(+), 240 deletions(-)
 create mode 100644 samples/lsm/Makefile
 create mode 100644 samples/lsm/lsm_example.c

-- 
2.14.1

Re: WARNING: kmalloc bug in memdup_user

[Leon Romanovsky]

On Tue, Mar 06, 2018 at 10:59:02PM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> ce380619fab99036f5e745c7a865b21c59f005f6 (Tue Mar 6 04:31:14 2018 +)
> Merge tag 'please-pull-ia64_misc' of
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux
>
> So far this crash happened 52 times on upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a38b0e9f694c379ca...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1520367364.281:6): avc:  denied  { map } for
> pid=4138 comm="bash" path="/bin/bash" dev="sda1" ino=1457
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:file_t:s0 tclass=file permissive=1
> audit: type=1400 audit(1520367370.605:7): avc:  denied  { map } for
> pid=4152 comm="syzkaller100190" path="/root/syzkaller100190328" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> WARNING: CPU: 0 PID: 4152 at mm/slab_common.c:1012 kmalloc_slab+0x5d/0x70
> mm/slab_common.c:1012
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 4152 Comm: syzkaller100190 Not tainted 4.16.0-rc4+ #343
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x24d lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
> RIP: 0010:kmalloc_slab+0x5d/0x70 mm/slab_common.c:1012
> RSP: 0018:8801bf76f970 EFLAGS: 00010246
> RAX:  RBX: fff4 RCX: 819733cb
> RDX: 8423372f RSI:  RDI: 3efef4b4
> RBP: 8801bf76f970 R08:  R09: 
> R10: 88613380 R11:  R12: 3efef4b4
> R13: 2080 R14: 014200c0 R15: 8801bf76fa68
>  __do_kmalloc mm/slab.c:3700 [inline]
>  __kmalloc_track_caller+0x21/0x760 mm/slab.c:3720
>  memdup_user+0x2c/0x90 mm/util.c:160
>  ucma_set_option+0x11f/0x4d0 drivers/infiniband/core/ucma.c:1297
>  ucma_write+0x2d6/0x3d0 drivers/infiniband/core/ucma.c:1627
>  __vfs_write+0xef/0x970 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43fe69
> RSP: 002b:7ffe099a6388 EFLAGS: 0217 ORIG_RAX: 0001
> RAX: ffda RBX: 004002c8 RCX: 0043fe69
> RDX: 006b RSI: 20c0 RDI: 0003
> RBP: 006ca018 R08: 004002c8 R09: 004002c8
> R10: 004002c8 R11: 0217 R12: 00401790
> R13: 00401820 R14:  R15: 
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

I'm surprised that it surfed only now.
It is clear bug, user's input wasn't checked.
But it is not clear to me why optval wasn't declared as u64.

Thanks


signature.asc
Description: PGP signature

[PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

[Sargun Dhillon]

This commit should have no functional change. It changes the security hook
list heads struct into an array. Additionally, it exposes all of the hooks
via an enum. This loses memory layout randomization as the enum is not
randomized.

Signed-off-by: Sargun Dhillon 
---
 include/linux/lsm_hooks.h | 433 +++---
 security/security.c   |  30 ++--
 2 files changed, 233 insertions(+), 230 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 7161d8e7ee79..d28c7f5b01c1 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1729,241 +1729,243 @@ union security_list_options {
 #endif /* CONFIG_BPF_SYSCALL */
 };
 
-struct security_hook_heads {
-   struct list_head binder_set_context_mgr;
-   struct list_head binder_transaction;
-   struct list_head binder_transfer_binder;
-   struct list_head binder_transfer_file;
-   struct list_head ptrace_access_check;
-   struct list_head ptrace_traceme;
-   struct list_head capget;
-   struct list_head capset;
-   struct list_head capable;
-   struct list_head quotactl;
-   struct list_head quota_on;
-   struct list_head syslog;
-   struct list_head settime;
-   struct list_head vm_enough_memory;
-   struct list_head bprm_set_creds;
-   struct list_head bprm_check_security;
-   struct list_head bprm_committing_creds;
-   struct list_head bprm_committed_creds;
-   struct list_head sb_alloc_security;
-   struct list_head sb_free_security;
-   struct list_head sb_copy_data;
-   struct list_head sb_remount;
-   struct list_head sb_kern_mount;
-   struct list_head sb_show_options;
-   struct list_head sb_statfs;
-   struct list_head sb_mount;
-   struct list_head sb_umount;
-   struct list_head sb_pivotroot;
-   struct list_head sb_set_mnt_opts;
-   struct list_head sb_clone_mnt_opts;
-   struct list_head sb_parse_opts_str;
-   struct list_head dentry_init_security;
-   struct list_head dentry_create_files_as;
+enum lsm_hook {
+   LSM_HOOK_binder_set_context_mgr,
+   LSM_HOOK_binder_transaction,
+   LSM_HOOK_binder_transfer_binder,
+   LSM_HOOK_binder_transfer_file,
+   LSM_HOOK_ptrace_access_check,
+   LSM_HOOK_ptrace_traceme,
+   LSM_HOOK_capget,
+   LSM_HOOK_capset,
+   LSM_HOOK_capable,
+   LSM_HOOK_quotactl,
+   LSM_HOOK_quota_on,
+   LSM_HOOK_syslog,
+   LSM_HOOK_settime,
+   LSM_HOOK_vm_enough_memory,
+   LSM_HOOK_bprm_set_creds,
+   LSM_HOOK_bprm_check_security,
+   LSM_HOOK_bprm_committing_creds,
+   LSM_HOOK_bprm_committed_creds,
+   LSM_HOOK_sb_alloc_security,
+   LSM_HOOK_sb_free_security,
+   LSM_HOOK_sb_copy_data,
+   LSM_HOOK_sb_remount,
+   LSM_HOOK_sb_kern_mount,
+   LSM_HOOK_sb_show_options,
+   LSM_HOOK_sb_statfs,
+   LSM_HOOK_sb_mount,
+   LSM_HOOK_sb_umount,
+   LSM_HOOK_sb_pivotroot,
+   LSM_HOOK_sb_set_mnt_opts,
+   LSM_HOOK_sb_clone_mnt_opts,
+   LSM_HOOK_sb_parse_opts_str,
+   LSM_HOOK_dentry_init_security,
+   LSM_HOOK_dentry_create_files_as,
 #ifdef CONFIG_SECURITY_PATH
-   struct list_head path_unlink;
-   struct list_head path_mkdir;
-   struct list_head path_rmdir;
-   struct list_head path_mknod;
-   struct list_head path_truncate;
-   struct list_head path_symlink;
-   struct list_head path_link;
-   struct list_head path_rename;
-   struct list_head path_chmod;
-   struct list_head path_chown;
-   struct list_head path_chroot;
+   LSM_HOOK_path_unlink,
+   LSM_HOOK_path_mkdir,
+   LSM_HOOK_path_rmdir,
+   LSM_HOOK_path_mknod,
+   LSM_HOOK_path_truncate,
+   LSM_HOOK_path_symlink,
+   LSM_HOOK_path_link,
+   LSM_HOOK_path_rename,
+   LSM_HOOK_path_chmod,
+   LSM_HOOK_path_chown,
+   LSM_HOOK_path_chroot,
 #endif
-   struct list_head inode_alloc_security;
-   struct list_head inode_free_security;
-   struct list_head inode_init_security;
-   struct list_head inode_create;
-   struct list_head inode_link;
-   struct list_head inode_unlink;
-   struct list_head inode_symlink;
-   struct list_head inode_mkdir;
-   struct list_head inode_rmdir;
-   struct list_head inode_mknod;
-   struct list_head inode_rename;
-   struct list_head inode_readlink;
-   struct list_head inode_follow_link;
-   struct list_head inode_permission;
-   struct list_head inode_setattr;
-   struct list_head inode_getattr;
-   struct list_head inode_setxattr;
-   struct list_head inode_post_setxattr;
-   struct list_head inode_getxattr;
-   struct list_head inode_listxattr;
-   struct list_head inode_removexattr;
-   struct list_head inode_need_killpriv;
-   struct list_head inode_killpriv;
-   struct list_head inode_getsecurity;
-   struct list

Re: [PATCH 4.4 054/108] mtd: cfi: convert inline functions to macros

[Boris Brezillon]

On Mon, 05 Mar 2018 02:22:52 +
Ben Hutchings  wrote:

> On Thu, 2018-02-15 at 16:16 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Arnd Bergmann 
> > 
> > commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.  
> [...]
> > -static inline int map_word_andequal(struct map_info *map, map_word val1, 
> > map_word val2, map_word val3)
> > -{
> > -   int i;
> > -
> > -   for (i = 0; i < map_words(map); i++) {
> > -   if ((val1.x[i] & val2.x[i]) != val3.x[i])
> > -   return 0;
> > -   }
> > -
> > -   return 1;
> > -}  
> [...]
> > +#define map_word_andequal(map, val1, val2, val3)   \
> > +({ \
> > +   int i, ret = 1; \
> > +   for (i = 0; i < map_words(map); i++) {  \
> > +   if (((val1).x[i] & (val2).x[i]) != (val2).x[i]) {   \  
> [...]
> 
> The right-hand side of this comparison is now using val2 instead of
> val3.  (This bug seems to be unfixed upstream.)

Indeed. This being said, it's not buggy since all users of
map_word_andequal() pass the same value to val2 and val3.

Maybe we should just patch the macro and all call-sites to remove val3.

> 
> Ben.
> 



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V2 1/2] mmc: sdhci-msm: Add support to store supported vdd-io voltages

[Vijay Viswanath]

Hi Dough, Jeremy,

On 3/3/2018 4:38 AM, Jeremy McNicoll wrote:

On 2018-03-02 10:23 AM, Doug Anderson wrote:

Hi,

On Sun, Feb 11, 2018 at 10:01 PM, Vijay Viswanath
 wrote:

During probe check whether the vdd-io regulator of sdhc platform device
can support 1.8V and 3V and store this information as a capability of
platform device.

Signed-off-by: Vijay Viswanath 
---
  drivers/mmc/host/sdhci-msm.c | 38 
++

  1 file changed, 38 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index c283291..5c23e92 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -23,6 +23,7 @@
  #include 

  #include "sdhci-pltfm.h"
+#include 


This is a strange sort order for this include file.  Why is it after
the local include?



  #define CORE_MCI_VERSION   0x50
  #define CORE_VERSION_MAJOR_SHIFT   28
@@ -81,6 +82,9 @@
  #define CORE_HC_SELECT_IN_HS400    (6 << 19)
  #define CORE_HC_SELECT_IN_MASK (7 << 19)

+#define CORE_3_0V_SUPPORT  (1 << 25)
+#define CORE_1_8V_SUPPORT  (1 << 26)
+


Is there something magical about 25 and 26?  This is a new caps field,
so I'd have expected 0 and 1.




Yes, these bits are the same corresponding to the capabilities in the 
Capabilities Register (offset 0x40). The bit positions become important 
when capabilities register doesn't show support to some voltages, but we 
can support those voltages. At that time, we will have to fake 
capabilities. The changes for those are currently not yet pushed up.



  #define CORE_CSR_CDC_CTLR_CFG0 0x130
  #define CORE_SW_TRIG_FULL_CALIB    BIT(16)
  #define CORE_HW_AUTOCAL_ENA    BIT(17)
@@ -148,6 +152,7 @@ struct sdhci_msm_host {
 u32 curr_io_level;
 wait_queue_head_t pwr_irq_wait;
 bool pwr_irq_flag;
+   u32 caps_0;
  };

  static unsigned int msm_get_clock_rate_for_bus_mode(struct 
sdhci_host *host,
@@ -1313,6 +1318,35 @@ static void sdhci_msm_writeb(struct sdhci_host 
*host, u8 val, int reg)

 sdhci_msm_check_power_status(host, req_type);
  }

+static int sdhci_msm_set_regulator_caps(struct sdhci_msm_host 
*msm_host)

+{
+   struct mmc_host *mmc = msm_host->mmc;
+   struct regulator *supply = mmc->supply.vqmmc;
+   int i, count;
+   u32 caps = 0, vdd_uV;
+
+   if (!IS_ERR(mmc->supply.vqmmc)) {
+   count = regulator_count_voltages(supply);
+   if (count < 0)
+   return count;
+   for (i = 0; i < count; i++) {
+   vdd_uV = regulator_list_voltage(supply, i);
+   if (vdd_uV <= 0)
+   continue;
+   if (vdd_uV > 270)
+   caps |= CORE_3_0V_SUPPORT;
+   if (vdd_uV < 195)
+   caps |= CORE_1_8V_SUPPORT;
+   }


Shouldn't you be using regulator_is_supported_voltage() rather than
open coding?  Also: I've never personally worked on a device where it
was used, but there is definitely a concept floating about of a
voltage level of 1.2V.  Maybe should copy the ranges from
mmc_regulator_set_vqmmc()?




regulator_is_supported_voltage() checks for a range and it also uses 
regulator_list_voltage() internally. regulator_list_voltage() is also an 
exported API for use by drivers AFAIK. Please correct if it is not.



Also: seems like you should have some way to deal with "caps" ending
up w/ no bits set.  IIRC you can have a regulator that can be enabled
/ disabled but doesn't list a voltage, so if someone messed up their
device tree you could end up in this case.  Should you print a
warning?  ...or treat it as if we support "3.0V"?  ...or ?  I guess it
depends on how do you want patch #2 to behave in that case.


Both, initialize it to sane value and print something.  This way at
least you have a good chance of booting and not hard hanging and you
are given a reasonable message indicating what needs to be fixed.

-jeremy





+   }


How should things behave if vqmmc is an error?  In that case is it
important to not set "CORE_IO_PAD_PWR_SWITCH_EN" in patch set #2?
...or should you set "CORE_IO_PAD_PWR_SWITCH_EN" but then make sure
you don't set "CORE_IO_PAD_PWR_SWITCH"?




Thanks for the suggestion. If the regulators exit and doesn't list the 
voltages, then I believe initialization itself will not happen. We will 
not have any available ocr and in sdhci_setup_host it should fail.
But these enhancements can be incorporated. Since this patch is already 
acknowledged, I will incorporate these changes in a subsequent patch.



+   msm_host->caps_0 |= caps;
+   pr_debug("%s: %s: supported caps: 0x%08x\n", mmc_hostname(mmc),
+   __func__, caps);
+
+   return 0;
+}
+
+
  static const struct of_device_id sdhci_msm_dt_match[] = {
 { .compatible = "qcom,sdhci-msm-v4" },
 {},

Re: [PATCH 1/3] vfio/pci: Pull BAR mapping setup from read-write path

[Peter Xu]

On Wed, Feb 28, 2018 at 01:14:46PM -0700, Alex Williamson wrote:
> This creates a common helper that we'll use for ioeventfd setup.
> 
> Signed-off-by: Alex Williamson 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v6] mmc: Export host capabilities to debugfs.

[Harish Jenny K N]

On Wednesday 07 March 2018 12:10 PM, Avri Altman wrote:
>
>> -Original Message-
>> From: Harish Jenny K N [mailto:harish_kand...@mentor.com]
>> Sent: Wednesday, March 07, 2018 7:38 AM
>> To: ulf.hans...@linaro.org; linus.wall...@linaro.org;
>> adrian.hun...@intel.com; shawn@rock-chips.com; Avri Altman
>> ; andriy.shevche...@linux.intel.com
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> harish_kand...@mentor.com; vladimir_zapols...@mentor.com
>> Subject: [PATCH v6] mmc: Export host capabilities to debugfs.
>>
>> This patch exports the host capabilities to debugfs
>>
>> This idea of sharing host capabilities over debugfs came up from Abbas Raza
>>  Earlier discussions:
>> https://lkml.org/lkml/2018/3/5/357
>> https://www.spinics.net/lists/linux-mmc/msg48219.html
>>
>> Signed-off-by: Harish Jenny K N 
>> ---
>>
>>
>> +static int mmc_caps_show(struct seq_file *s, void *unused) {
>> +struct mmc_host *host = s->private;
>> +u32 caps = host->caps;
>> +
>> +seq_puts(s, "\nMMC Host capabilities are:\n");
>> +seq_puts(s,
>> "=\n");
>> +seq_printf(s, "Can the host do 4 bit transfers :\t%s\n",
>> +   ((caps & MMC_CAP_4_BIT_DATA) ? "Yes" : "No"));
> Maybe use a more compact form, and just call a macro with the applicable 
> (stringified) bit?

Something like this ?

#define YN(bit) ((caps & bit) ? "Yes" : "No")
and then call
seq_printf(s, "Can the host do 4 bit transfers :\t%s\n", 
YN(MMC_CAP_4_BIT_DATA));



Thanks,
Harish Jenny K N

Re: [PATCHv2 2/5] x86/boot/compressed/64: Find a place for 32-bit trampoline

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> On Tue, Feb 27, 2018 at 06:42:14PM +0300, Kirill A. Shutemov wrote:
> > If a bootloader enables 64-bit mode with 4-level paging, we might need to
> > switch over to 5-level paging. The switching requires the disabling of
> > paging, which works fine if kernel itself is loaded below 4G.
> > 
> > But if the bootloader puts the kernel above 4G (not sure if anybody does
> > this), we would lose control as soon as paging is disabled, because the
> > code becomes unreachable to the CPU.
> > 
> > To handle the situation, we need a trampoline in lower memory that would
> > take care of switching on 5-level paging.
> > 
> > This patch finds a spot in low memory for a trampoline.
> > 
> > The heuristic is based on code in reserve_bios_regions().
> > 
> > We find the end of low memory based on BIOS and EBDA start addresses.
> > The trampoline is put just before end of low memory. It's mimic approach
> > taken to allocate memory for realtime trampoline.
> > 
> > Signed-off-by: Kirill A. Shutemov 
> > Tested-by: Borislav Petkov 
> > ---
> >  arch/x86/boot/compressed/misc.c   |  4 
> >  arch/x86/boot/compressed/pgtable.h| 11 +++
> >  arch/x86/boot/compressed/pgtable_64.c | 34 
> > ++
> >  3 files changed, 49 insertions(+)
> >  create mode 100644 arch/x86/boot/compressed/pgtable.h
> > 
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index b50c42455e25..e58409667b13 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -14,6 +14,7 @@
> >  
> >  #include "misc.h"
> >  #include "error.h"
> > +#include "pgtable.h"
> >  #include "../string.h"
> >  #include "../voffset.h"
> >  
> > @@ -372,6 +373,9 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
> > memptr heap,
> > debug_putaddr(output_len);
> > debug_putaddr(kernel_total_size);
> >  
> > +   /* Report address of 32-bit trampoline */
> > +   debug_putaddr(trampoline_32bit);
> > +
> > /*
> >  * The memory hole needed for the kernel is the larger of either
> >  * the entire decompressed kernel plus relocation table, or the
> 
> 0-day found problem with the patch on 32-bit config.
> 
> Here's fixup:
> 
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index e58409667b13..8e4b55dd5df9 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -373,8 +373,10 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
> memptr heap,
>   debug_putaddr(output_len);
>   debug_putaddr(kernel_total_size);
>  
> +#ifdef CONFIG_X86_64
>   /* Report address of 32-bit trampoline */
>   debug_putaddr(trampoline_32bit);
> +#endif

The prototype of trampoline_32bit should be in an #ifdef as well, as the 
variable 
only exists on 64-bit kernels.

Thanks,

Ingo

[PATCH] scsi: jazz_esp, sun3x_esp: Pass struct device pointer in dma calls

[Finn Thain]

In jazz_esp and sun3x_esp, the esp_driver_ops methods pass esp->dev
in dma api calls as if it was a pointer to a struct device. But
it actually points to a struct platform_device. Fix this.

Cc: Thomas Bogendoerfer 
Signed-off-by: Finn Thain 
---
 drivers/scsi/jazz_esp.c  | 2 +-
 drivers/scsi/sun3x_esp.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/jazz_esp.c b/drivers/scsi/jazz_esp.c
index 9aaa74e349cc..6eb5ff3e2e61 100644
--- a/drivers/scsi/jazz_esp.c
+++ b/drivers/scsi/jazz_esp.c
@@ -147,7 +147,7 @@ static int esp_jazz_probe(struct platform_device *dev)
esp = shost_priv(host);
 
esp->host = host;
-   esp->dev = dev;
+   esp->dev = &dev->dev;
esp->ops = &jazz_esp_ops;
 
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
diff --git a/drivers/scsi/sun3x_esp.c b/drivers/scsi/sun3x_esp.c
index d50c5ed8f428..0b1421cdf8a0 100644
--- a/drivers/scsi/sun3x_esp.c
+++ b/drivers/scsi/sun3x_esp.c
@@ -210,7 +210,7 @@ static int esp_sun3x_probe(struct platform_device *dev)
esp = shost_priv(host);
 
esp->host = host;
-   esp->dev = dev;
+   esp->dev = &dev->dev;
esp->ops = &sun3x_esp_ops;
 
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
-- 
2.16.1

[tip:x86/pti] objtool: Fix 32-bit build

[tip-bot for Josh Poimboeuf]

Commit-ID:  63474dc4ac7ed3848a4786b9592dd061901f606d
Gitweb: https://git.kernel.org/tip/63474dc4ac7ed3848a4786b9592dd061901f606d
Author: Josh Poimboeuf 
AuthorDate: Tue, 6 Mar 2018 17:58:15 -0600
Committer:  Ingo Molnar 
CommitDate: Wed, 7 Mar 2018 07:50:38 +0100

objtool: Fix 32-bit build

Fix the objtool build when cross-compiling a 64-bit kernel on a 32-bit
host.  This also simplifies read_retpoline_hints() a bit and makes its
implementation similar to most of the other annotation reading
functions.

Reported-by: Sven Joachim 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: b5bc2231b8ad ("objtool: Add retpoline validation")
Link: 
http://lkml.kernel.org/r/2ca46c636c23aa9c9d57d53c75de4ee3ddf7a7df.1520380691.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/check.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 46c1d239cc1b..92b6a2c21631 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1116,42 +1116,29 @@ static int read_unwind_hints(struct objtool_file *file)
 
 static int read_retpoline_hints(struct objtool_file *file)
 {
-   struct section *sec, *relasec;
+   struct section *sec;
struct instruction *insn;
struct rela *rela;
-   int i;
 
-   sec = find_section_by_name(file->elf, ".discard.retpoline_safe");
+   sec = find_section_by_name(file->elf, ".rela.discard.retpoline_safe");
if (!sec)
return 0;
 
-   relasec = sec->rela;
-   if (!relasec) {
-   WARN("missing .rela.discard.retpoline_safe section");
-   return -1;
-   }
-
-   if (sec->len % sizeof(unsigned long)) {
-   WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
sizeof(unsigned long));
-   return -1;
-   }
-
-   for (i = 0; i < sec->len / sizeof(unsigned long); i++) {
-   rela = find_rela_by_dest(sec, i * sizeof(unsigned long));
-   if (!rela) {
-   WARN("can't find rela for retpoline_safe[%d]", i);
+   list_for_each_entry(rela, &sec->rela_list, list) {
+   if (rela->sym->type != STT_SECTION) {
+   WARN("unexpected relocation symbol type in %s", 
sec->name);
return -1;
}
 
insn = find_insn(file, rela->sym->sec, rela->addend);
if (!insn) {
-   WARN("can't find insn for retpoline_safe[%d]", i);
+   WARN("bad .discard.retpoline_safe entry");
return -1;
}
 
if (insn->type != INSN_JUMP_DYNAMIC &&
insn->type != INSN_CALL_DYNAMIC) {
-   WARN_FUNC("retpoline_safe hint not a indirect 
jump/call",
+   WARN_FUNC("retpoline_safe hint not an indirect 
jump/call",
  insn->sec, insn->offset);
return -1;
}

[GIT PULL] s390 patches for 4.16-rc5

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Nine bug fixes for s390:

 * Three fixes for the expoline code, one of them is strictly speaking
   a cleanup but as it relates to code added with 4.16 I would like to
   include the patch.

 * Three timer related fixes in the common I/O layer

 * A fix for the handling of internal DASD request which could cause panics.

 * One correction in regard to the accounting of pud page tables vs.
   compat tasks.

 * The register scrubbing in entry.S caused spurious crashes, this is
   fixed now as well.

Christian Borntraeger (1):
  s390/entry.S: fix spurious zeroing of r0

Eugeniu Rosca (1):
  s390: Replace IS_ENABLED(EXPOLINE_*) with IS_ENABLED(CONFIG_EXPOLINE_*)

Guenter Roeck (1):
  s390: Fix runtime warning about negative pgtables_bytes

Hendrik Brueckner (1):
  s390/clean-up: use CFI_* macros in entry.S

Martin Schwidefsky (1):
  s390: do not bypass BPENTER for interrupt system calls

Sebastian Ott (3):
  s390/cio: fix ccw_device_start_timeout API
  s390/cio: fix return code after missing interrupt
  s390/cio: clear timer when terminating driver I/O

Stefan Haberland (1):
  s390/dasd: fix handling of internal requests

 arch/s390/include/asm/mmu_context.h |  1 +
 arch/s390/kernel/entry.S| 10 +++---
 arch/s390/kernel/nospec-branch.c|  4 +--
 drivers/s390/block/dasd.c   | 21 ---
 drivers/s390/cio/device_fsm.c   |  7 ++--
 drivers/s390/cio/device_ops.c   | 72 +
 drivers/s390/cio/io_sch.h   |  1 +
 7 files changed, 54 insertions(+), 62 deletions(-)

diff --git a/arch/s390/include/asm/mmu_context.h 
b/arch/s390/include/asm/mmu_context.h
index 65154ea..6c8ce15 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -63,6 +63,7 @@ static inline int init_new_context(struct task_struct *tsk,
   _ASCE_USER_BITS | _ASCE_TYPE_SEGMENT;
/* pgd_alloc() did not account this pmd */
mm_inc_nr_pmds(mm);
+   mm_inc_nr_puds(mm);
}
crst_table_init((unsigned long *) mm->pgd, pgd_entry_type(mm));
return 0;
diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S
index 13a133a..a5621ea 100644
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -230,7 +231,7 @@ _PIF_WORK   = (_PIF_PER_TRAP | _PIF_SYSCALL_RESTART)
.hidden \name
.type \name,@function
 \name:
-   .cfi_startproc
+   CFI_STARTPROC
 #ifdef CONFIG_HAVE_MARCH_Z10_FEATURES
exrl0,0f
 #else
@@ -239,7 +240,7 @@ _PIF_WORK   = (_PIF_PER_TRAP | _PIF_SYSCALL_RESTART)
 #endif
j   .
 0: br  \reg
-   .cfi_endproc
+   CFI_ENDPROC
.endm
 
GEN_BR_THUNK __s390x_indirect_jump_r1use_r9,%r9,%r1
@@ -426,13 +427,13 @@ ENTRY(system_call)
UPDATE_VTIME %r8,%r9,__LC_SYNC_ENTER_TIMER
BPENTER __TI_flags(%r12),_TIF_ISOLATE_BP
stmg%r0,%r7,__PT_R0(%r11)
-   # clear user controlled register to prevent speculative use
-   xgr %r0,%r0
mvc __PT_R8(64,%r11),__LC_SAVE_AREA_SYNC
mvc __PT_PSW(16,%r11),__LC_SVC_OLD_PSW
mvc __PT_INT_CODE(4,%r11),__LC_SVC_ILC
stg %r14,__PT_FLAGS(%r11)
 .Lsysc_do_svc:
+   # clear user controlled register to prevent speculative use
+   xgr %r0,%r0
# load address of system call table
lg  %r10,__THREAD_sysc_table(%r13,%r12)
llgh%r8,__PT_INT_CODE+2(%r11)
@@ -1439,6 +1440,7 @@ cleanup_critical:
stg %r15,__LC_SYSTEM_TIMER
 0: # update accounting time stamp
mvc __LC_LAST_UPDATE_TIMER(8),__LC_SYNC_ENTER_TIMER
+   BPENTER __TI_flags(%r12),_TIF_ISOLATE_BP
# set up saved register r11
lg  %r15,__LC_KERNEL_STACK
la  %r9,STACK_FRAME_OVERHEAD(%r15)
diff --git a/arch/s390/kernel/nospec-branch.c b/arch/s390/kernel/nospec-branch.c
index 69d7fcf..9aff72d 100644
--- a/arch/s390/kernel/nospec-branch.c
+++ b/arch/s390/kernel/nospec-branch.c
@@ -2,8 +2,8 @@
 #include 
 #include 
 
-int nospec_call_disable = IS_ENABLED(EXPOLINE_OFF);
-int nospec_return_disable = !IS_ENABLED(EXPOLINE_FULL);
+int nospec_call_disable = IS_ENABLED(CONFIG_EXPOLINE_OFF);
+int nospec_return_disable = !IS_ENABLED(CONFIG_EXPOLINE_FULL);
 
 static int __init nospectre_v2_setup_early(char *str)
 {
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index a7c15f0..ecef8e7 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -2581,8 +2581,6 @@ int dasd_cancel_req(struct dasd_ccw_req *cqr)
case DASD_CQR_QUEUED:
/* request was not started - just set to cleared */
 

Re: [pci PATCH v3 0/3] Add support for unmanaged SR-IOV

[Christoph Hellwig]

On Tue, Mar 06, 2018 at 11:29:08AM -0800, Alexander Duyck wrote:
> This series is meant to add support for SR-IOV on devices when the VFs are
> not managed by the kernel. Examples of recent patches attempting to do this
> include:
> virto - https://patchwork.kernel.org/patch/10241225/
> pci-stub - https://patchwork.kernel.org/patch/10109935/
> vfio - https://patchwork.kernel.org/patch/10103353/
> uio - https://patchwork.kernel.org/patch/9974031/

nvme and ema seems to be existing examples.  Care to throw in
conversions while you're at it?

RE: [PATCH v6] mmc: Export host capabilities to debugfs.

[Avri Altman]

> -Original Message-
> From: Harish Jenny K N [mailto:harish_kand...@mentor.com]
> Sent: Wednesday, March 07, 2018 7:38 AM
> To: ulf.hans...@linaro.org; linus.wall...@linaro.org;
> adrian.hun...@intel.com; shawn@rock-chips.com; Avri Altman
> ; andriy.shevche...@linux.intel.com
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> harish_kand...@mentor.com; vladimir_zapols...@mentor.com
> Subject: [PATCH v6] mmc: Export host capabilities to debugfs.
> 
> This patch exports the host capabilities to debugfs
> 
> This idea of sharing host capabilities over debugfs came up from Abbas Raza
>  Earlier discussions:
> https://lkml.org/lkml/2018/3/5/357
> https://www.spinics.net/lists/linux-mmc/msg48219.html
> 
> Signed-off-by: Harish Jenny K N 
> ---
> 
> 
> +static int mmc_caps_show(struct seq_file *s, void *unused) {
> + struct mmc_host *host = s->private;
> + u32 caps = host->caps;
> +
> + seq_puts(s, "\nMMC Host capabilities are:\n");
> + seq_puts(s,
> "=\n");
> + seq_printf(s, "Can the host do 4 bit transfers :\t%s\n",
> +((caps & MMC_CAP_4_BIT_DATA) ? "Yes" : "No"));

Maybe use a more compact form, and just call a macro with the applicable 
(stringified) bit?


Thanks,
Avri

[PATCH 1/1] iommu/arm-smmu: Add support for qcom,smmu-500 variant

[Vivek Gautam]

Qualcomm's arm-smmu 500 implementation supports runtime pm
so enable the same.

Signed-off-by: Vivek Gautam 
---

 Based on iommu/arm-smmu pm runtime support series [1]:
 [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support
 
 Tested on sdm845 with necessary support to enable the smmu
 and with necessary user.

 [1] https://lkml.org/lkml/2018/3/2/325

 Documentation/devicetree/bindings/iommu/arm,smmu.txt | 14 ++
 drivers/iommu/arm-smmu.c |  8 
 2 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 6ea27bd4f785..0b5c6d2a9865 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -18,6 +18,7 @@ conditions.
 "arm,mmu-500"
 "cavium,smmu-v2"
 "qcom,-smmu-v2", "qcom,smmu-v2"
+"qcom,-smmu-500", "qcom,smmu-500"
 
   depending on the particular implementation and/or the
   version of the architecture implemented.
@@ -30,6 +31,10 @@ conditions.
   An example string would be -
   "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
 
+  "qcom,smmu-500" is arm,mmu-500 implementation that supports
+  efficient power management by supporting smmu's state
+  retention.
+
 - reg   : Base address and size of the SMMU.
 
 - #global-interrupts : The number of global interrupts exposed by the
@@ -179,3 +184,12 @@ conditions.
 <&mmcc SMMU_MDP_AHB_CLK>;
clock-names = "bus", "iface";
};
+
+   smmu5: iommu {
+   compatible = "qcom,sdm845-smmu-500", "qcom,smmu-500";
+   reg = <0x1500 0x8>;
+   #iommu-cells = <2>;
+   #global-interrupts = <1>;
+
+   ...
+   };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 7a96c924ae22..7f52456c6b25 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2008,6 +2008,12 @@ static const char * const qcom_smmuv2_clks[] = {
"bus", "iface",
 };
 
+static const struct arm_smmu_match_data qcom_smmu500 = {
+   .version = ARM_SMMU_V2,
+   .model = ARM_MMU500,
+   .rpm_supported = true,
+};
+
 static const struct arm_smmu_match_data qcom_smmuv2 = {
.version = ARM_SMMU_V2,
.model = QCOM_SMMUV2,
@@ -2024,6 +2030,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
{ .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
+   { .compatible = "qcom,smmu-500", .data = &qcom_smmu500 },
{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -2394,6 +2401,7 @@ IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
 IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
 IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
 IOMMU_OF_DECLARE(qcom_smmuv2, "qcom,smmu-v2");
+IOMMU_OF_DECLARE(qcom_smmu500, "qcom,smmu-500");
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
 MODULE_AUTHOR("Will Deacon ");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

[Byungchul Park]

On 3/7/2018 2:55 PM, Byungchul Park wrote:

On 3/6/2018 10:42 PM, Boqun Feng wrote:

On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote:

Hello Paul and RCU folks,

I am afraid I correctly understand and fix it. But I really wonder why
sync_rcu_exp_handler() reports the quiescent state even in the case that
current task is within a RCU read-side section. Do I miss something?

If I correctly understand it and you agree with it, I can add more logic
which make it more expedited by boosting current or making it urgent
when we fail to report the quiescent state on the IPI.

->8-
 From 0b0191f506c19ce331a1fdb7c2c5a00fb23fbcf2 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 6 Mar 2018 13:54:41 +0900
Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side 
section


We report the quiescent state for this cpu if it's out of RCU read-side
section at the moment IPI was just fired during the expedite process.

However, current code reports the quiescent state even in the case:

    1) the current task is still within a RCU read-side section
    2) the current task has been blocked within the RCU read-side 
section




If this happens, the task will queue itself in
rcu_preempt_note_context_switch() using rcu_preempt_ctxt_queue(). The gp
kthread will wait for this task to dequeue itself. IOW, we have other
mechanism to wait for this task other than bottom-up qs reporting tree.
So I think we are fine here.


Right. Basically we consider both the quiscent state within the current
task and queued tasks on rcu nodes that you mentioned, to control grace
periods when PREEMPT kernel is used.

Actually my concern was if it's safe to clear the bit of 'expmask' on
the IPI for all possible cases, even though anyway blocked tasks would
try to prevent the grace period from ending.

I worried if something subtle might cause problems, but the code looks
fine on second thought as you said. Thank you for your explanation.


In addition, by making quiescent states reported and bits of expmask
cleared only when it's out of rcu read sections, of course keeping
other mechanism unchanged like what you mentioned, I think we can avoid
unnecessary locking ops and other statements, keeping the code still
sane, even though the benefit might be small.

For example, by removing some evitable calls to rcu_report_cpu_mult()
either directly or indirectly. I'm not sure if RCU maintainers think
it's worthy tho.


Regards,
Boqun


Since we don't get to the quiescent state yet in the case, we shouldn't
report it but check it another time.

Signed-off-by: Byungchul Park 
---
  kernel/rcu/tree_exp.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 73e1d3d..cc69d14 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -731,13 +731,13 @@ static void sync_rcu_exp_handler(void *info)
  /*
   * We are either exiting an RCU read-side critical section 
(negative

   * values of t->rcu_read_lock_nesting) or are not in one at all
- * (zero value of t->rcu_read_lock_nesting).  Or we are in an RCU
- * read-side critical section that blocked before this expedited
- * grace period started.  Either way, we can immediately report
- * the quiescent state.
+ * (zero value of t->rcu_read_lock_nesting). We can immediately
+ * report the quiescent state.
   */
-    rdp = this_cpu_ptr(rsp->rda);
-    rcu_report_exp_rdp(rsp, rdp, true);
+    if (t->rcu_read_lock_nesting <= 0) {
+    rdp = this_cpu_ptr(rsp->rda);
+    rcu_report_exp_rdp(rsp, rdp, true);
+    }
  }
  /**
--
1.9.1





--
Thanks,
Byungchul

[PATCH v1 1/9] PCI/PM: Move pcie_clear_root_pme_status() to core

[Bjorn Helgaas]

From: Bjorn Helgaas 

Move pcie_clear_root_pme_status() from the port driver to the PCI core so
it will be available even when the port driver isn't present.  No
functional change intended.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pci.c  |9 +
 drivers/pci/pci.h  |1 +
 drivers/pci/pcie/portdrv.h |2 --
 drivers/pci/pcie/portdrv_pci.c |9 -
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..120e3393fc35 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1683,6 +1683,15 @@ int pci_set_pcie_reset_state(struct pci_dev *dev, enum 
pcie_reset_state state)
 }
 EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
 
+/**
+ * pcie_clear_root_pme_status - Clear root port PME interrupt status.
+ * @dev: PCIe root port or event collector.
+ */
+void pcie_clear_root_pme_status(struct pci_dev *dev)
+{
+   pcie_capability_set_dword(dev, PCI_EXP_RTSTA, PCI_EXP_RTSTA_PME);
+}
+
 /**
  * pci_check_pme_status - Check if given device has generated PME.
  * @dev: Device to check.
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index fcd81911b127..813ca2c895d8 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -71,6 +71,7 @@ void pci_update_current_state(struct pci_dev *dev, 
pci_power_t state);
 void pci_power_up(struct pci_dev *dev);
 void pci_disable_enabled_device(struct pci_dev *dev);
 int pci_finish_runtime_suspend(struct pci_dev *dev);
+void pcie_clear_root_pme_status(struct pci_dev *dev);
 int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
 void pci_pme_restore(struct pci_dev *dev);
 bool pci_dev_keep_suspended(struct pci_dev *dev);
diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index a854bc569117..a4fc44d52206 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -34,8 +34,6 @@ void pcie_port_bus_unregister(void);
 
 struct pci_dev;
 
-void pcie_clear_root_pme_status(struct pci_dev *dev);
-
 #ifdef CONFIG_HOTPLUG_PCI_PCIE
 extern bool pciehp_msi_disabled;
 
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index fb1c1bb87316..4413dd85e923 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -50,15 +50,6 @@ __setup("pcie_ports=", pcie_port_setup);
 
 /* global data */
 
-/**
- * pcie_clear_root_pme_status - Clear root port PME interrupt status.
- * @dev: PCIe root port or event collector.
- */
-void pcie_clear_root_pme_status(struct pci_dev *dev)
-{
-   pcie_capability_set_dword(dev, PCI_EXP_RTSTA, PCI_EXP_RTSTA_PME);
-}
-
 static int pcie_portdrv_restore_config(struct pci_dev *dev)
 {
int retval;

[PATCH v1 5/9] PCI/portdrv: Remove pcie_port_bus_type link order dependency

[Bjorn Helgaas]

From: Bjorn Helgaas 

The pcie_port_bus_type must be registered before drivers that depend on it
can be registered.  Those drivers include:

  pcied_init()# PCIe native hotplug driver
  aer_service_init()  # AER driver
  dpc_service_init()  # DPC driver
  pcie_pme_service_init() # PME driver

Previously we registered pcie_port_bus_type from pcie_portdrv_init(), a
device_initcall.  The callers of pcie_port_service_register() (above) are
also device_initcalls.  This is fragile because the device_initcall
ordering depends on link order, which is not explicit.

Register pcie_port_bus_type from pci_driver_init() along with pci_bus_type.
This removes the link order dependency between portdrv and the pciehp, AER,
DPC, and PCIe PME drivers.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pci-driver.c   |   45 +++-
 drivers/pci/pcie/Makefile  |2 +
 drivers/pci/pcie/portdrv_bus.c |   56 
 drivers/pci/pcie/portdrv_pci.c |   13 +
 4 files changed, 46 insertions(+), 70 deletions(-)
 delete mode 100644 drivers/pci/pcie/portdrv_bus.c

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 38ee7c8b4d1a..4db85a0faf34 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,7 @@
 #include 
 #include 
 #include "pci.h"
+#include "pcie/portdrv.h"
 
 struct pci_dynid {
struct list_head node;
@@ -1553,8 +1555,49 @@ struct bus_type pci_bus_type = {
 };
 EXPORT_SYMBOL(pci_bus_type);
 
+#ifdef CONFIG_PCIEPORTBUS
+static int pcie_port_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct pcie_device *pciedev;
+   struct pcie_port_service_driver *driver;
+
+   if (drv->bus != &pcie_port_bus_type || dev->bus != &pcie_port_bus_type)
+   return 0;
+
+   pciedev = to_pcie_device(dev);
+   driver = to_service_driver(drv);
+
+   if (driver->service != pciedev->service)
+   return 0;
+
+   if ((driver->port_type != PCIE_ANY_PORT) &&
+   (driver->port_type != pci_pcie_type(pciedev->port)))
+   return 0;
+
+   return 1;
+}
+
+struct bus_type pcie_port_bus_type = {
+   .name   = "pci_express",
+   .match  = pcie_port_bus_match,
+};
+EXPORT_SYMBOL_GPL(pcie_port_bus_type);
+#endif
+
 static int __init pci_driver_init(void)
 {
-   return bus_register(&pci_bus_type);
+   int ret;
+
+   ret = bus_register(&pci_bus_type);
+   if (ret)
+   return ret;
+
+#ifdef CONFIG_PCIEPORTBUS
+   ret = bus_register(&pcie_port_bus_type);
+   if (ret)
+   return ret;
+#endif
+
+   return 0;
 }
 postcore_initcall(pci_driver_init);
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 223e4c34c29a..e01c10c97b95 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -6,7 +6,7 @@
 # Build PCI Express ASPM if needed
 obj-$(CONFIG_PCIEASPM) += aspm.o
 
-pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o
+pcieportdrv-y  := portdrv_core.o portdrv_pci.o
 pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o
 
 obj-$(CONFIG_PCIEPORTBUS)  += pcieportdrv.o
diff --git a/drivers/pci/pcie/portdrv_bus.c b/drivers/pci/pcie/portdrv_bus.c
deleted file mode 100644
index f0fba552a0e2..
--- a/drivers/pci/pcie/portdrv_bus.c
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * File:   portdrv_bus.c
- * Purpose:PCI Express Port Bus Driver's Bus Overloading Functions
- *
- * Copyright (C) 2004 Intel
- * Copyright (C) Tom Long Nguyen (tom.l.ngu...@intel.com)
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include "portdrv.h"
-
-static int pcie_port_bus_match(struct device *dev, struct device_driver *drv);
-
-struct bus_type pcie_port_bus_type = {
-   .name   = "pci_express",
-   .match  = pcie_port_bus_match,
-};
-EXPORT_SYMBOL_GPL(pcie_port_bus_type);
-
-static int pcie_port_bus_match(struct device *dev, struct device_driver *drv)
-{
-   struct pcie_device *pciedev;
-   struct pcie_port_service_driver *driver;
-
-   if (drv->bus != &pcie_port_bus_type || dev->bus != &pcie_port_bus_type)
-   return 0;
-
-   pciedev = to_pcie_device(dev);
-   driver = to_service_driver(drv);
-
-   if (driver->service != pciedev->service)
-   return 0;
-
-   if ((driver->port_type != PCIE_ANY_PORT) &&
-   (driver->port_type != pci_pcie_type(pciedev->port)))
-   return 0;
-
-   return 1;
-}
-
-int pcie_port_bus_register(void)
-{
-   return bus_register(&pcie_port_bus_type);
-}
-
-void pcie_port_bus_unregister(void)
-{
-   bus_unregister(&pcie_port_bus_type);
-}
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c

[PATCH v1 9/9] PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter

[Bjorn Helgaas]

From: Bjorn Helgaas 

7570a333d8b0 ("PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp
driver") added the "pcie_hp=nomsi" kernel parameter to work around this
error on shutdown:

  irq 16: nobody cared (try booting with the "irqpoll" option)
  Pid: 1081, comm: reboot Not tainted 3.2.0 #1
  ...
  Disabling IRQ #16

This happened on an unspecified system (possibly involving the Integrated
Device Technology, Inc. Device 807f bridge) where "an un-wanted interrupt
is generated when PCI driver switches from MSI/MSI-X to INTx while shutting
down the device."

The implication was that the device was buggy, but it is normal for a
device to use INTx after MSI/MSI-X have been disabled.  The only problem
was that the driver was still attached and it wasn't prepared for INTx
interrupts.  Prarit Bhargava fixed this issue with fda78d7a0ead ("PCI/MSI:
Stop disabling MSI/MSI-X in pci_device_shutdown()").

There is no automated way to set this parameter, so it's not very useful
for distributions or end users.  It's really only useful for debugging, and
we have "pci=nomsi" for that purpose.

Revert 7570a333d8b0 to remove the "pcie_hp=nomsi" parameter.

Signed-off-by: Bjorn Helgaas 
CC: MUNEDA Takahiro 
CC: Kenji Kaneshige 
CC: Prarit Bhargava 
---
 Documentation/admin-guide/kernel-parameters.txt |4 
 drivers/pci/pcie/portdrv.h  |   12 
 drivers/pci/pcie/portdrv_core.c |   20 +++-
 3 files changed, 3 insertions(+), 33 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..761749562165 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3130,10 +3130,6 @@
force   Enable ASPM even on devices that claim not to support 
it.
WARNING: Forcing ASPM on may cause system lockups.
 
-   pcie_hp=[PCIE] PCI Express Hotplug driver options:
-   nomsi   Do not use MSI for PCI Express Native Hotplug (this
-   makes all PCIe ports use INTx for hotplug services).
-
pcie_ports= [PCIE] PCIe ports handling:
autoAsk the BIOS whether or not to use native PCIe services
associated with PCIe ports (PME, hot-plug, AER).  Use
diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index 2c19cf9ffea2..87a87cb9f42d 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -34,18 +34,6 @@ void pcie_port_bus_unregister(void);
 
 struct pci_dev;
 
-#ifdef CONFIG_HOTPLUG_PCI_PCIE
-extern bool pciehp_msi_disabled;
-
-static inline bool pciehp_no_msi(void)
-{
-   return pciehp_msi_disabled;
-}
-
-#else  /* !CONFIG_HOTPLUG_PCI_PCIE */
-static inline bool pciehp_no_msi(void) { return false; }
-#endif /* !CONFIG_HOTPLUG_PCI_PCIE */
-
 #ifdef CONFIG_PCIE_PME
 extern bool pcie_pme_msi_disabled;
 
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 29210e9bfbd3..bf9c5c885957 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -21,17 +21,6 @@
 #include "../pci.h"
 #include "portdrv.h"
 
-bool pciehp_msi_disabled;
-
-static int __init pciehp_setup(char *str)
-{
-   if (!strncmp(str, "nomsi", 5))
-   pciehp_msi_disabled = true;
-
-   return 1;
-}
-__setup("pcie_hp=", pciehp_setup);
-
 /**
  * release_pcie_device - free PCI Express port service device structure
  * @dev: Port service device to release
@@ -169,16 +158,13 @@ static int pcie_init_service_irqs(struct pci_dev *dev, 
int *irqs, int mask)
irqs[i] = -1;
 
/*
-* If we support PME or hotplug, but we can't use MSI/MSI-X for
-* them, we have to fall back to INTx or other interrupts, e.g., a
-* system shared interrupt.
+* If we support PME but can't use MSI/MSI-X for it, we have to
+* fall back to INTx or other interrupts, e.g., a system shared
+* interrupt.
 */
if ((mask & PCIE_PORT_SERVICE_PME) && pcie_pme_no_msi())
goto legacy_irq;
 
-   if ((mask & PCIE_PORT_SERVICE_HP) && pciehp_no_msi())
-   goto legacy_irq;
-
/* Try to use MSI-X or MSI if supported */
if (pcie_port_enable_irq_vec(dev, irqs, mask) == 0)
return 0;

[PATCH v1 2/9] PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver

[Bjorn Helgaas]

From: Bjorn Helgaas 

fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system
resume") added a .resume_noirq() callback to the PCIe port driver to clear
the PME Status bit during resume to work around a BIOS issue.

The BIOS evidently enabled PME interrupts for ACPI-based runtime wakeups
but did not clear the PME Status bit during resume, which meant PMEs after
resume did not trigger interrupts because PME Status did not transition
from cleared to set.

The fix was in the PCIe port driver, so it worked when CONFIG_PCIEPORTBUS
was set.  But I think we *always* want the fix because the platform may use
PME interrupts even if Linux is built without the PCIe port driver.

Move the fix from the port driver to the PCI core so we can work around
this "PME doesn't work after waking from a sleep state" issue regardless of
CONFIG_PCIEPORTBUS.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pci-driver.c   |   14 ++
 drivers/pci/pcie/portdrv_pci.c |   15 ---
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 3bed6beda051..bf0704b75f79 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -525,6 +525,18 @@ static void pci_pm_default_resume_early(struct pci_dev 
*pci_dev)
pci_fixup_device(pci_fixup_resume_early, pci_dev);
 }
 
+static void pcie_resume_early(struct pci_dev *pci_dev)
+{
+   /*
+* Some BIOSes forget to clear Root PME Status bits after system wakeup
+* which breaks ACPI-based runtime wakeup on PCI Express, so clear those
+* bits now just in case (shouldn't hurt).
+*/
+   if (pci_is_pcie(pci_dev) &&
+   pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT)
+   pcie_clear_root_pme_status(pci_dev);
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all (second part).
@@ -873,6 +885,8 @@ static int pci_pm_resume_noirq(struct device *dev)
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
 
+   pcie_resume_early(pci_dev);
+
if (drv && drv->pm && drv->pm->resume_noirq)
error = drv->pm->resume_noirq(dev);
 
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 4413dd85e923..f91afd09e356 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -62,20 +62,6 @@ static int pcie_portdrv_restore_config(struct pci_dev *dev)
 }
 
 #ifdef CONFIG_PM
-static int pcie_port_resume_noirq(struct device *dev)
-{
-   struct pci_dev *pdev = to_pci_dev(dev);
-
-   /*
-* Some BIOSes forget to clear Root PME Status bits after system wakeup
-* which breaks ACPI-based runtime wakeup on PCI Express, so clear those
-* bits now just in case (shouldn't hurt).
-*/
-   if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
-   pcie_clear_root_pme_status(pdev);
-   return 0;
-}
-
 static int pcie_port_runtime_suspend(struct device *dev)
 {
return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY;
@@ -103,7 +89,6 @@ static const struct dev_pm_ops pcie_portdrv_pm_ops = {
.thaw   = pcie_port_device_resume,
.poweroff   = pcie_port_device_suspend,
.restore= pcie_port_device_resume,
-   .resume_noirq   = pcie_port_resume_noirq,
.runtime_suspend = pcie_port_runtime_suspend,
.runtime_resume = pcie_port_runtime_resume,
.runtime_idle   = pcie_port_runtime_idle,

[PATCH v1 7/9] PCI/portdrv: Simplify PCIe feature permission checking

[Bjorn Helgaas]

From: Bjorn Helgaas 

Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the
platform firmware or the OS, so the host bridge driver may have to request
permission from the platform before using them.  On ACPI systems, this is
done by negotiate_os_control() in acpi_pci_root_add().

The PCIe port driver later uses pcie_port_platform_notify() and
pcie_port_acpi_setup() to figure out whether it can use these features.
But all we need is a single bit for each service, so these interfaces are
needlessly complicated.

Simplify this by adding bits in the struct pci_host_bridge to show when the
OS has permission to use each feature:

  + unsigned int use_aer:1;   /* OS may use PCIe AER */
  + unsigned int use_hotplug:1;   /* OS may use PCIe hotplug */
  + unsigned int use_pme:1;   /* OS may use PCIe PME */

These are set when we create a host bridge, and the host bridge driver can
clear the bits corresponding to any feature the platform doesn't want us to
use.

Signed-off-by: Bjorn Helgaas 
---
 drivers/acpi/pci_root.c |   13 ++--
 drivers/pci/pcie/Makefile   |1 -
 drivers/pci/pcie/portdrv.h  |   11 --
 drivers/pci/pcie/portdrv_core.c |   42 ---
 drivers/pci/probe.c |   10 +
 include/linux/pci.h |3 +++
 6 files changed, 50 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 6fc204a52493..dce53527cdc1 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -871,6 +871,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root 
*root,
struct acpi_device *device = root->device;
int node = acpi_get_node(device->handle);
struct pci_bus *bus;
+   struct pci_host_bridge *host_bridge;
 
info->root = root;
info->bridge = device;
@@ -895,9 +896,17 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root 
*root,
if (!bus)
goto out_release_info;
 
+   host_bridge = to_pci_host_bridge(bus->bridge);
+   if (!(root->osc_control_set & PCIE_PORT_SERVICE_HP))
+   host_bridge->use_hotplug = 0;
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL))
+   host_bridge->use_aer = 0;
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL))
+   host_bridge->use_pme = 0;
+
pci_scan_child_bus(bus);
-   pci_set_host_bridge_release(to_pci_host_bridge(bus->bridge),
-   acpi_pci_root_release_info, info);
+   pci_set_host_bridge_release(host_bridge, acpi_pci_root_release_info,
+   info);
if (node != NUMA_NO_NODE)
dev_printk(KERN_DEBUG, &bus->dev, "on NUMA node %d\n", node);
return bus;
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index e01c10c97b95..11fb633b866c 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -7,7 +7,6 @@
 obj-$(CONFIG_PCIEASPM) += aspm.o
 
 pcieportdrv-y  := portdrv_core.o portdrv_pci.o
-pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o
 
 obj-$(CONFIG_PCIEPORTBUS)  += pcieportdrv.o
 
diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index 749d200936d9..2c19cf9ffea2 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -66,15 +66,4 @@ static inline bool pcie_pme_no_msi(void) { return false; }
 static inline void pcie_pme_interrupt_enable(struct pci_dev *dev, bool en) {}
 #endif /* !CONFIG_PCIE_PME */
 
-#ifdef CONFIG_ACPI
-void pcie_port_acpi_setup(struct pci_dev *port, int *mask);
-
-static inline void pcie_port_platform_notify(struct pci_dev *port, int *mask)
-{
-   pcie_port_acpi_setup(port, mask);
-}
-#else /* !CONFIG_ACPI */
-static inline void pcie_port_platform_notify(struct pci_dev *port, int *mask){}
-#endif /* !CONFIG_ACPI */
-
 #endif /* _PORTDRV_H_ */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 94ce4dc50d1a..29210e9bfbd3 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -207,19 +207,20 @@ static int pcie_init_service_irqs(struct pci_dev *dev, 
int *irqs, int mask)
  */
 static int get_port_device_capability(struct pci_dev *dev)
 {
+   struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+   bool native;
int services = 0;
-   int cap_mask = 0;
 
-   cap_mask = PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP;
-   if (pci_aer_available())
-   cap_mask |= PCIE_PORT_SERVICE_AER | PCIE_PORT_SERVICE_DPC;
-
-   if (pcie_ports_auto)
-   pcie_port_platform_notify(dev, &cap_mask);
+   /*
+* If the user specified "pcie_ports=native", use the PCIe services
+* regardless of whether the platform has given us permission.  On
+* ACPI systems, this means we ignore _OSC.
+*/
+   native = !pcie_ports

[PATCH v1 4/9] PCI/portdrv: Disable port driver in compat mode

[Bjorn Helgaas]

From: Bjorn Helgaas 

The "pcie_ports=compat" kernel parameter sets pcie_ports_disabled, which is
intended to disable the PCIe port driver.  But even when it was disabled,
we registered pcie_portdriver so we could work around a BIOS PME issue (see
fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system
resume")).

Registering the driver meant that the pcie_portdrv_probe() path called
pci_enable_device(), pci_save_state(), pm_runtime_set_autosuspend_delay(),
pm_runtime_use_autosuspend(), etc., even when the driver was disabled.

We've since moved the BIOS PME workaround from the port driver to the core,
so stop registering the PCIe port driver in compat mode.

This means "pcie_ports=compat" will now be basically the same as turning
off CONFIG_PCIEPORTBUS completely.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pcie/portdrv_core.c |3 ---
 drivers/pci/pcie/portdrv_pci.c  |2 +-
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index ef3bad4ad010..9db77c683732 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -212,9 +212,6 @@ static int get_port_device_capability(struct pci_dev *dev)
int services = 0;
int cap_mask = 0;
 
-   if (pcie_ports_disabled)
-   return 0;
-
cap_mask = PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP
| PCIE_PORT_SERVICE_VC;
if (pci_aer_available())
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index f91afd09e356..c08ebd237242 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -262,7 +262,7 @@ static int __init pcie_portdrv_init(void)
int retval;
 
if (pcie_ports_disabled)
-   return pci_register_driver(&pcie_portdriver);
+   return -EACCES;
 
dmi_check_system(pcie_portdrv_dmi_table);
 

[PATCH v1 8/9] PCI/portdrv: Remove unnecessary include of

[Bjorn Helgaas]

From: Bjorn Helgaas 

portdrv_pci.c doesn't use anything from .  Remove the
include of it.  No functional change intended.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pcie/portdrv_pci.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 9475886eeb62..d12b58db18a1 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "../pci.h"
 #include "portdrv.h"

[PATCH v1 3/9] PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors

[Bjorn Helgaas]

From: Bjorn Helgaas 

Per PCIe r4.0, sec 6.1.6, Root Complex Event Collectors can generate PME
interrupts on behalf of Root Complex Integrated Endpoints.

Linux does not currently enable PME interrupts from RC Event Collectors,
but fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system
resume") suggests PME interrupts may be enabled by the platform for ACPI-
based runtime wakeup.

Clear the PCIe PME Status bit for Root Complex Event Collectors during
resume, just like we already do for Root Ports.

If the BIOS enables PME interrupts for an event collector and neglects to
clear the status bit on resume, this change should fix the same bug as
fe31e69740ed (PMEs not working after waking from a sleep state), but for
Root Complex Integrated Endpoints.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pci-driver.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index bf0704b75f79..38ee7c8b4d1a 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -533,7 +533,8 @@ static void pcie_resume_early(struct pci_dev *pci_dev)
 * bits now just in case (shouldn't hurt).
 */
if (pci_is_pcie(pci_dev) &&
-   pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT)
+   (pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT ||
+pci_pcie_type(pci_dev) == PCI_EXP_TYPE_RC_EC))
pcie_clear_root_pme_status(pci_dev);
 }
 

[PATCH v1 6/9] PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC

[Bjorn Helgaas]

From: Bjorn Helgaas 

No driver registers for PCIE_PORT_SERVICE_VC, so remove it.

This removes the VC "service" files from /sys/bus/pci_express/devices,
e.g., :07:00.0:pcie108, :08:04.0:pcie208 (all the files that
contained "8" as the last digit of the "pcieXXX" part).  The port driver
created these files for PCIe port devices that have a VC Capability.

Since this reduces PCIE_PORT_DEVICE_MAXSERVICES and moves DPC down into the
spot where VC used to be, the DPC sysfs files will now be named "pcieXX8".
I don't think there's anything useful userspace can do with those files, so
I hope nobody cares about these filenames.

There is no VC driver that calls pcie_port_service_register(), so there
never was a /sys/bus/pci_express/drivers/vc directory.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pcie/portdrv.h  |2 +-
 drivers/pci/pcie/portdrv_acpi.c |2 +-
 drivers/pci/pcie/portdrv_core.c |   14 --
 include/linux/pcieport_if.h |4 +---
 4 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index a4fc44d52206..749d200936d9 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -12,7 +12,7 @@
 
 #include 
 
-#define PCIE_PORT_DEVICE_MAXSERVICES   5
+#define PCIE_PORT_DEVICE_MAXSERVICES   4
 /*
  * The PCIe Capability Interrupt Message Number (PCIe r3.1, sec 7.8.2) must
  * be one of the first 32 MSI-X entries.  Per PCI r3.0, sec 6.8.3.1, MSI
diff --git a/drivers/pci/pcie/portdrv_acpi.c b/drivers/pci/pcie/portdrv_acpi.c
index 319c94976873..4a1b50867c98 100644
--- a/drivers/pci/pcie/portdrv_acpi.c
+++ b/drivers/pci/pcie/portdrv_acpi.c
@@ -48,7 +48,7 @@ void pcie_port_acpi_setup(struct pci_dev *port, int *srv_mask)
 
flags = root->osc_control_set;
 
-   *srv_mask = PCIE_PORT_SERVICE_VC | PCIE_PORT_SERVICE_DPC;
+   *srv_mask = PCIE_PORT_SERVICE_DPC;
if (flags & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)
*srv_mask |= PCIE_PORT_SERVICE_HP;
if (flags & OSC_PCI_EXPRESS_PME_CONTROL)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 9db77c683732..94ce4dc50d1a 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -189,10 +189,8 @@ static int pcie_init_service_irqs(struct pci_dev *dev, int 
*irqs, int mask)
if (ret < 0)
return -ENODEV;
 
-   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
-   if (i != PCIE_PORT_SERVICE_VC_SHIFT)
-   irqs[i] = pci_irq_vector(dev, 0);
-   }
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
+   irqs[i] = pci_irq_vector(dev, 0);
 
return 0;
 }
@@ -212,8 +210,7 @@ static int get_port_device_capability(struct pci_dev *dev)
int services = 0;
int cap_mask = 0;
 
-   cap_mask = PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP
-   | PCIE_PORT_SERVICE_VC;
+   cap_mask = PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP;
if (pci_aer_available())
cap_mask |= PCIE_PORT_SERVICE_AER | PCIE_PORT_SERVICE_DPC;
 
@@ -240,9 +237,6 @@ static int get_port_device_capability(struct pci_dev *dev)
 */
pci_disable_pcie_error_reporting(dev);
}
-   /* VC support */
-   if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_VC))
-   services |= PCIE_PORT_SERVICE_VC;
/* Root ports are capable of generating PME too */
if ((cap_mask & PCIE_PORT_SERVICE_PME)
&& pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
@@ -332,7 +326,7 @@ int pcie_port_device_register(struct pci_dev *dev)
 */
status = pcie_init_service_irqs(dev, irqs, capabilities);
if (status) {
-   capabilities &= PCIE_PORT_SERVICE_VC | PCIE_PORT_SERVICE_HP;
+   capabilities &= PCIE_PORT_SERVICE_HP;
if (!capabilities)
goto error_disable;
}
diff --git a/include/linux/pcieport_if.h b/include/linux/pcieport_if.h
index b69769dbf659..28eb21731db6 100644
--- a/include/linux/pcieport_if.h
+++ b/include/linux/pcieport_if.h
@@ -20,9 +20,7 @@
 #define PCIE_PORT_SERVICE_AER  (1 << PCIE_PORT_SERVICE_AER_SHIFT)
 #define PCIE_PORT_SERVICE_HP_SHIFT 2   /* Native Hotplug */
 #define PCIE_PORT_SERVICE_HP   (1 << PCIE_PORT_SERVICE_HP_SHIFT)
-#define PCIE_PORT_SERVICE_VC_SHIFT 3   /* Virtual Channel */
-#define PCIE_PORT_SERVICE_VC   (1 << PCIE_PORT_SERVICE_VC_SHIFT)
-#define PCIE_PORT_SERVICE_DPC_SHIFT4   /* Downstream Port Containment 
*/
+#define PCIE_PORT_SERVICE_DPC_SHIFT3   /* Downstream Port Containment 
*/
 #define PCIE_PORT_SERVICE_DPC  (1 << PCIE_PORT_SERVICE_DPC_SHIFT)
 
 struct pcie_device {

[PATCH v1 0/9] PCI: Simplify PCIe port driver

[Bjorn Helgaas]

This is an attempt to move a few things out of the port driver.

Patches 1-2 move a workaround for a BIOS PME issue from the port driver to
the PCI core, so it doesn't depend on CONFIG_PCIEPORTBUS.

Patch 3 extends that workaround so it works for Root Complex Event
Collectors.  I haven't seen reports of this being a problem, but I think we
should handle Event Collector PMEs the same as Root Port PMEs.

Patch 4 disables the port driver completely for "pcie_ports=compat".  We
used to register the driver, claim port devices, enable them, etc., as part
of supporting the above BIOS workaround.

Patch 5 removes a port driver link order dependency.

Patch 6 removes the unused VC service.

Patch 7 simplifies the _OSC code path by keeping more of the details in the
ACPI pci_root.c driver.

Patch 8 removes an unnecessary #include.

Patch 9 removes the "pcie_hp=nomsi" parameter.  This was added to work
around an issue when shutting down devices, but a later patch fixed the
root cause, and I don't think we need such a specific parameter any more
(we still have "pci=nomsi").

---

Bjorn Helgaas (9):
  PCI/PM: Move pcie_clear_root_pme_status() to core
  PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver
  PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors
  PCI/portdrv: Disable port driver in compat mode
  PCI/portdrv: Remove pcie_port_bus_type link order dependency
  PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC
  PCI/portdrv: Simplify PCIe feature permission checking
  PCI/portdrv: Remove unnecessary include of 
  PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter


 Documentation/admin-guide/kernel-parameters.txt |4 -
 drivers/acpi/pci_root.c |   13 +++-
 drivers/pci/pci-driver.c|   60 ++
 drivers/pci/pci.c   |9 +++
 drivers/pci/pci.h   |1 
 drivers/pci/pcie/Makefile   |3 -
 drivers/pci/pcie/portdrv.h  |   27 
 drivers/pci/pcie/portdrv_acpi.c |2 -
 drivers/pci/pcie/portdrv_bus.c  |   56 -
 drivers/pci/pcie/portdrv_core.c |   77 ++-
 drivers/pci/pcie/portdrv_pci.c  |   40 +---
 drivers/pci/probe.c |   10 +++
 include/linux/pci.h |3 +
 include/linux/pcieport_if.h |4 -
 14 files changed, 131 insertions(+), 178 deletions(-)
 delete mode 100644 drivers/pci/pcie/portdrv_bus.c

Re: [PATCH v2] xhci: Fix front USB ports on ASUS PRIME B350M-A

[Kai Heng Feng]

Hi Matthias,

Do you have any concern about this patch?

Hopefully this can get merged for v4.16…

Kai-Heng

Re: [PATCH 3/3] vfio/pci: Add ioeventfd support

[Peter Xu]

On Wed, Feb 28, 2018 at 01:15:20PM -0700, Alex Williamson wrote:

[...]

> @@ -1174,6 +1206,8 @@ static int vfio_pci_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>   vdev->irq_type = VFIO_PCI_NUM_IRQS;
>   mutex_init(&vdev->igate);
>   spin_lock_init(&vdev->irqlock);
> + mutex_init(&vdev->ioeventfds_lock);

Do we better need to destroy the mutex in vfio_pci_remove?

I see that vfio_pci_device.igate is also without a destructor.  I'm
not sure on both.

Thanks,

> + INIT_LIST_HEAD(&vdev->ioeventfds_list);
>  
>   ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
>   if (ret) {

-- 
Peter Xu

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

[Byungchul Park]

On 3/6/2018 10:42 PM, Boqun Feng wrote:

On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote:

Hello Paul and RCU folks,

I am afraid I correctly understand and fix it. But I really wonder why
sync_rcu_exp_handler() reports the quiescent state even in the case that
current task is within a RCU read-side section. Do I miss something?

If I correctly understand it and you agree with it, I can add more logic
which make it more expedited by boosting current or making it urgent
when we fail to report the quiescent state on the IPI.

->8-
 From 0b0191f506c19ce331a1fdb7c2c5a00fb23fbcf2 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 6 Mar 2018 13:54:41 +0900
Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side section

We report the quiescent state for this cpu if it's out of RCU read-side
section at the moment IPI was just fired during the expedite process.

However, current code reports the quiescent state even in the case:

1) the current task is still within a RCU read-side section
2) the current task has been blocked within the RCU read-side section



If this happens, the task will queue itself in
rcu_preempt_note_context_switch() using rcu_preempt_ctxt_queue(). The gp
kthread will wait for this task to dequeue itself. IOW, we have other
mechanism to wait for this task other than bottom-up qs reporting tree.
So I think we are fine here.


Right. Basically we consider both the quiscent state within the current
task and queued tasks on rcu nodes that you mentioned, to control grace
periods when PREEMPT kernel is used.

Actually my concern was if it's safe to clear the bit of 'expmask' on
the IPI for all possible cases, even though anyway blocked tasks would
try to prevent the grace period from ending.

I worried if something subtle might cause problems, but the code looks
fine on second thought as you said. Thank you for your explanation.


Regards,
Boqun


Since we don't get to the quiescent state yet in the case, we shouldn't
report it but check it another time.

Signed-off-by: Byungchul Park 
---
  kernel/rcu/tree_exp.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 73e1d3d..cc69d14 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -731,13 +731,13 @@ static void sync_rcu_exp_handler(void *info)
/*
 * We are either exiting an RCU read-side critical section (negative
 * values of t->rcu_read_lock_nesting) or are not in one at all
-* (zero value of t->rcu_read_lock_nesting).  Or we are in an RCU
-* read-side critical section that blocked before this expedited
-* grace period started.  Either way, we can immediately report
-* the quiescent state.
+* (zero value of t->rcu_read_lock_nesting). We can immediately
+* report the quiescent state.
 */
-   rdp = this_cpu_ptr(rsp->rda);
-   rcu_report_exp_rdp(rsp, rdp, true);
+   if (t->rcu_read_lock_nesting <= 0) {
+   rdp = this_cpu_ptr(rsp->rda);
+   rcu_report_exp_rdp(rsp, rdp, true);
+   }
  }
  
  /**

--
1.9.1



--
Thanks,
Byungchul

[PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi

[Jiandi An]

IPMI SSIF driver's parameter tryacpi and trydmi both
are set to true.  The addition of IPMI DMI driver to
create platform device for each IPMI device causes
SSIF probe to be done twice on the same SMB I2C address
for BMC.  Fix is to not call trydmi if tryacpi is able
to find I2C address for BMC from SPMI ACPI table and
probe successfully.

Signed-off-by: Jiandi An 
---
 drivers/char/ipmi/ipmi_ssif.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 9d3b0fa..5c57363 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -1981,29 +1981,41 @@ static int try_init_spmi(struct SPMITable *spmi)
return new_ssif_client(myaddr, NULL, 0, 0, SI_SPMI, NULL);
 }
 
-static void spmi_find_bmc(void)
+static int spmi_find_bmc(void)
 {
acpi_status  status;
struct SPMITable *spmi;
int  i;
+   int  rc = 0;
 
if (acpi_disabled)
-   return;
+   return -EPERM;
 
if (acpi_failure)
-   return;
+   return -ENODEV;
 
for (i = 0; ; i++) {
status = acpi_get_table(ACPI_SIG_SPMI, i+1,
(struct acpi_table_header **)&spmi);
-   if (status != AE_OK)
-   return;
+   if (status != AE_OK) {
+   if (i == 0)
+   return -ENODEV;
+   else
+   return 0;
+   }
 
-   try_init_spmi(spmi);
+   rc = try_init_spmi(spmi);
+   if (rc)
+   return rc;
}
+
+   return 0;
 }
 #else
-static void spmi_find_bmc(void) { }
+static int spmi_find_bmc(void)
+{
+   return -ENODEV;
+}
 #endif
 
 #ifdef CONFIG_DMI
@@ -2104,12 +2116,13 @@ static int init_ipmi_ssif(void)
   addr[i]);
}
 
-   if (ssif_tryacpi)
+   if (ssif_tryacpi) {
ssif_i2c_driver.driver.acpi_match_table =
ACPI_PTR(ssif_acpi_match);
-
-   if (ssif_tryacpi)
-   spmi_find_bmc();
+   rv = spmi_find_bmc();
+   if (!rv)
+   ssif_trydmi = false;
+   }
 
if (ssif_trydmi) {
rv = platform_driver_register(&ipmi_driver);
-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH] staging: lustre: Remove VLA usage

[Kees Cook]

The kernel would like to remove all VLA usage. This switches to a
simple kasprintf() instead.

Signed-off-by: Kees Cook 
---
 drivers/staging/lustre/lustre/llite/xattr.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c 
b/drivers/staging/lustre/lustre/llite/xattr.c
index 532384c91447..aab4eab64289 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -87,7 +87,7 @@ ll_xattr_set_common(const struct xattr_handler *handler,
const char *name, const void *value, size_t size,
int flags)
 {
-   char fullname[strlen(handler->prefix) + strlen(name) + 1];
+   char *fullname;
struct ll_sb_info *sbi = ll_i2sbi(inode);
struct ptlrpc_request *req = NULL;
const char *pv = value;
@@ -141,10 +141,13 @@ ll_xattr_set_common(const struct xattr_handler *handler,
return -EPERM;
}
 
-   sprintf(fullname, "%s%s\n", handler->prefix, name);
+   fullname = kasprintf(GFP_KERNEL, "%s%s\n", handler->prefix, name);
+   if (!fullname)
+   return -ENOMEM;
rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode),
 valid, fullname, pv, size, 0, flags,
 ll_i2suppgid(inode), &req);
+   kfree(fullname);
if (rc) {
if (rc == -EOPNOTSUPP && handler->flags == XATTR_USER_T) {
LCONSOLE_INFO("Disabling user_xattr feature because it 
is not supported on the server\n");
@@ -364,7 +367,7 @@ static int ll_xattr_get_common(const struct xattr_handler 
*handler,
   struct dentry *dentry, struct inode *inode,
   const char *name, void *buffer, size_t size)
 {
-   char fullname[strlen(handler->prefix) + strlen(name) + 1];
+   char *fullname;
struct ll_sb_info *sbi = ll_i2sbi(inode);
 #ifdef CONFIG_FS_POSIX_ACL
struct ll_inode_info *lli = ll_i2info(inode);
@@ -411,9 +414,13 @@ static int ll_xattr_get_common(const struct xattr_handler 
*handler,
if (handler->flags == XATTR_ACL_DEFAULT_T && !S_ISDIR(inode->i_mode))
return -ENODATA;
 #endif
-   sprintf(fullname, "%s%s\n", handler->prefix, name);
-   return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
-OBD_MD_FLXATTR);
+   fullname = kasprintf(GFP_KERNEL, "%s%s\n", handler->prefix, name);
+   if (!fullname)
+   return -ENOMEM;
+   rc = ll_xattr_list(inode, fullname, handler->flags, buffer, size,
+  OBD_MD_FLXATTR);
+   kfree(fullname);
+   return rc;
 }
 
 static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t buf_size)
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] staging: iio: meter: Remove reduntant __func__ from debug print

[hariprasath . elango]

From: HariPrasath Elango 

dev_dbg includes the function name & line number by default when dynamic
debugging is enabled. Hence__func__ is reduntant here and removed.

Signed-off-by: HariPrasath Elango 
---
 drivers/staging/iio/meter/ade7758_trigger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/meter/ade7758_trigger.c 
b/drivers/staging/iio/meter/ade7758_trigger.c
index 1f0d1a0..da489ae 100644
--- a/drivers/staging/iio/meter/ade7758_trigger.c
+++ b/drivers/staging/iio/meter/ade7758_trigger.c
@@ -34,7 +34,7 @@ static int ade7758_data_rdy_trigger_set_state(struct 
iio_trigger *trig,
 {
struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
 
-   dev_dbg(&indio_dev->dev, "%s (%d)\n", __func__, state);
+   dev_dbg(&indio_dev->dev, "(%d)\n", state);
return ade7758_set_irq(&indio_dev->dev, state);
 }
 
-- 
2.10.0.GIT

[PATCH v6] mmc: Export host capabilities to debugfs.

[Harish Jenny K N]

This patch exports the host capabilities to debugfs

This idea of sharing host capabilities over debugfs
came up from Abbas Raza 
Earlier discussions:
https://lkml.org/lkml/2018/3/5/357
https://www.spinics.net/lists/linux-mmc/msg48219.html

Signed-off-by: Harish Jenny K N 
---

Changes in v6:
- Used DEFINE_SHOW_ATTRIBUTE

Changes in v5:
- Added parser logic in kernel by using debugfs_create_file  for caps and caps2 
instead of debugfs_create_x32
- Changed Author

Changes in v4:
- Moved the creation of nodes to mmc_add_host_debugfs
- Exported caps2
- Renamed host_caps to caps

Changes in v3:
- Removed typecasting of &host->caps to (u32 *)

Changes in v2:
- Changed Author

 drivers/mmc/core/debugfs.c | 120 +
 1 file changed, 120 insertions(+)

diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index c51e0c0..136bdf7 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -225,6 +225,120 @@ static int mmc_clock_opt_set(void *data, u64 val)
 DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");

+static int mmc_caps_show(struct seq_file *s, void *unused)
+{
+   struct mmc_host *host = s->private;
+   u32 caps = host->caps;
+
+   seq_puts(s, "\nMMC Host capabilities are:\n");
+   seq_puts(s, "=\n");
+   seq_printf(s, "Can the host do 4 bit transfers :\t%s\n",
+  ((caps & MMC_CAP_4_BIT_DATA) ? "Yes" : "No"));
+   seq_printf(s, "Can do MMC high-speed timing :\t%s\n",
+  ((caps & MMC_CAP_MMC_HIGHSPEED) ? "Yes" : "No"));
+   seq_printf(s, "Can do SD high-speed timing :\t%s\n",
+  ((caps & MMC_CAP_SD_HIGHSPEED) ? "Yes" : "No"));
+   seq_printf(s, "Can signal pending SDIO IRQs :\t%s\n",
+  ((caps & MMC_CAP_SDIO_IRQ) ? "Yes" : "No"));
+   seq_printf(s, "Talks only SPI protocols :\t%s\n",
+  ((caps & MMC_CAP_SPI) ? "Yes" : "No"));
+   seq_printf(s, "Needs polling for card-detection :\t%s\n",
+  ((caps & MMC_CAP_NEEDS_POLL) ? "Yes" : "No"));
+   seq_printf(s, "Can the host do 8 bit transfers :\t%s\n",
+  ((caps & MMC_CAP_8_BIT_DATA) ? "Yes" : "No"));
+   seq_printf(s, "Suspend (e)MMC/SD at idle :\t%s\n",
+  ((caps & MMC_CAP_AGGRESSIVE_PM) ? "Yes" : "No"));
+   seq_printf(s, "Nonremovable e.g. eMMC :\t%s\n",
+  ((caps & MMC_CAP_NONREMOVABLE) ? "Yes" : "No"));
+   seq_printf(s, "Waits while card is busy :\t%s\n",
+  ((caps & MMC_CAP_WAIT_WHILE_BUSY) ? "Yes" : "No"));
+   seq_printf(s, "Allow erase/trim commands :\t%s\n",
+  ((caps & MMC_CAP_ERASE) ? "Yes" : "No"));
+   seq_printf(s, "Can support DDR mode at 3.3V :\t%s\n",
+  ((caps & MMC_CAP_3_3V_DDR) ? "Yes" : "No"));
+   seq_printf(s, "Can support DDR mode at 1.8V :\t%s\n",
+  ((caps & MMC_CAP_1_8V_DDR) ? "Yes" : "No"));
+   seq_printf(s, "Can support DDR mode at 1.2V :\t%s\n",
+  ((caps & MMC_CAP_1_2V_DDR) ? "Yes" : "No"));
+   seq_printf(s, "Can power off after boot :\t%s\n",
+  ((caps & MMC_CAP_POWER_OFF_CARD) ? "Yes" : "No"));
+   seq_printf(s, "CMD14/CMD19 bus width ok :\t%s\n",
+  ((caps & MMC_CAP_BUS_WIDTH_TEST) ? "Yes" : "No"));
+   seq_printf(s, "Host supports UHS SDR12 mode :\t%s\n",
+  ((caps & MMC_CAP_UHS_SDR12) ? "Yes" : "No"));
+   seq_printf(s, "Host supports UHS SDR25 mode :\t%s\n",
+  ((caps & MMC_CAP_UHS_SDR25) ? "Yes" : "No"));
+   seq_printf(s, "Host supports UHS SDR50 mode :\t%s\n",
+  ((caps & MMC_CAP_UHS_SDR50) ? "Yes" : "No"));
+   seq_printf(s, "Host supports UHS SDR104 mode :\t%s\n",
+  ((caps & MMC_CAP_UHS_SDR104) ? "Yes" : "No"));
+   seq_printf(s, "Host supports UHS DDR50 mode :\t%s\n",
+  ((caps & MMC_CAP_UHS_DDR50) ? "Yes" : "No"));
+   seq_printf(s, "Host supports Driver Type A :\t%s\n",
+  ((caps & MMC_CAP_DRIVER_TYPE_A) ? "Yes" : "No"));
+   seq_printf(s, "Host supports Driver Type C :\t%s\n",
+  ((caps & MMC_CAP_DRIVER_TYPE_C) ? "Yes" : "No"));
+   seq_printf(s, "Host supports Driver Type D :\t%s\n",
+  ((caps & MMC_CAP_DRIVER_TYPE_D) ? "Yes" : "No"));
+   seq_printf(s, "RW reqs can be completed within mmc_request_done() 
:\t%s\n",
+  ((caps & MMC_CAP_DONE_COMPLETE) ? "Yes" : "No"));
+   seq_printf(s, "Enable card detect wake :\t%s\n",
+  ((caps & MMC_CAP_CD_WAKE) ? "Yes" : "No"));
+   seq_printf(s, "Commands during data transfer :\t%s\n",
+  ((caps & MMC_CAP_CMD_DURING_TFR) ? "Yes" : "No"));
+   seq_printf(s, "CMD23 supported. :\t%s\n",
+  ((caps & MMC_CAP_CMD23) ? "Yes" : "No"));
+   seq_printf(s, "

[PATCH] security: Fix IMA Kconfig for dependencies on ARM64

[Jiandi An]

TPM_CRB driver is the TPM support for ARM64.  If it
is built as module, TPM chip is registered after IMA
init.  tpm_pcr_read() in IMA driver would fail and
display the following message even though eventually
there is TPM chip on the system:

ima: No TPM chip found, activating TPM-bypass! (rc=-19)

Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is
built in kernel and initializes before IMA driver.

Signed-off-by: Jiandi An 
---
 security/integrity/ima/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 35ef693..6a8f677 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -10,6 +10,7 @@ config IMA
select CRYPTO_HASH_INFO
select TCG_TPM if HAS_IOMEM && !UML
select TCG_TIS if TCG_TPM && X86
+   select TCG_CRB if TCG_TPM && ACPI
select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES
help
  The Trusted Computing Group(TCG) runtime Integrity
-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

On Wed, Mar 07, 2018 at 10:40:05AM +0530, hariprasath.ela...@gmail.com wrote:
> From: HariPrasath Elango 
> 
> dev_dbg includes the function name & line number by default when dynamic
> debugging is enabled. Hence__func__ is reduntant here and removed.
> 
> Signed-off-by: HariPrasath Elango 
> ---
>  drivers/staging/iio/meter/ade7758_trigger.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/meter/ade7758_trigger.c 
> b/drivers/staging/iio/meter/ade7758_trigger.c
> index 1f0d1a0..da489ae 100644
> --- a/drivers/staging/iio/meter/ade7758_trigger.c
> +++ b/drivers/staging/iio/meter/ade7758_trigger.c
> @@ -34,7 +34,7 @@ static int ade7758_data_rdy_trigger_set_state(struct 
> iio_trigger *trig,
>  {
>   struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>  
> - dev_dbg(&indio_dev->dev, "%s (%d)\n", __func__, state);
> + dev_dbg(&indio_dev->dev, "(%d)\n", state);
>   return ade7758_set_irq(&indio_dev->dev, state);
>  }
>  
> -- 
> 2.10.0.GIT
> 

Please ignore this patch as the subject line is wrong. It should be
'meter' and not 'adc.

Re: [PATCH v2] arm64: dts: msm8916: Add cpu cooling maps

[Viresh Kumar]

On Wed, Mar 7, 2018 at 10:30 AM, Amit Kucheria  wrote:
> From: Rajendra Nayak 
>
> Add cpu cooling maps for cpu passive trip points. The cpu cooling
> device states are mapped to cpufreq based scaling frequencies.
>
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Amit Kucheria 
> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index e468277..66b318e 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  / {
> model = "Qualcomm Technologies, Inc. MSM8916";
> @@ -115,6 +116,7 @@
> cpu-idle-states = <&CPU_SPC>;
> clocks = <&apcs 0>;
> operating-points-v2 = <&cpu_opp_table>;
> +   #cooling-cells = <2>;

LGTM.

[PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

[hariprasath . elango]

From: HariPrasath Elango 

dev_dbg includes the function name & line number by default when dynamic
debugging is enabled. Hence__func__ is reduntant here and removed.

Signed-off-by: HariPrasath Elango 
---
 drivers/staging/iio/meter/ade7758_trigger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/meter/ade7758_trigger.c 
b/drivers/staging/iio/meter/ade7758_trigger.c
index 1f0d1a0..da489ae 100644
--- a/drivers/staging/iio/meter/ade7758_trigger.c
+++ b/drivers/staging/iio/meter/ade7758_trigger.c
@@ -34,7 +34,7 @@ static int ade7758_data_rdy_trigger_set_state(struct 
iio_trigger *trig,
 {
struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
 
-   dev_dbg(&indio_dev->dev, "%s (%d)\n", __func__, state);
+   dev_dbg(&indio_dev->dev, "(%d)\n", state);
return ade7758_set_irq(&indio_dev->dev, state);
 }
 
-- 
2.10.0.GIT

Re: [PATCH v9 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

[Viresh Kumar]

On 06-03-18, 20:09, Sricharan R wrote:
> From: Stephen Boyd 
> 
> Register a cpufreq-generic device whenever we detect that a
> "qcom,krait" compatible CPU is present in DT.
> 
> Acked-by: Viresh Kumar 
> [Sricharan: updated to use dev_pm_opp_set_prop_name and
>   nvmem apis]
> Signed-off-by: Sricharan R 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/cpufreq/Kconfig.arm  |  10 ++
>  drivers/cpufreq/Makefile |   1 +
>  drivers/cpufreq/cpufreq-dt-platdev.c |   5 +
>  drivers/cpufreq/qcom-cpufreq.c   | 183 
> +++
>  4 files changed, 199 insertions(+)
>  create mode 100644 drivers/cpufreq/qcom-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

[Haiyue Wang]

The IPMI KCS device part of the LPC interface and is used for
communication with the host processor.

Signed-off-by: Haiyue Wang 
---
 arch/arm/boot/dts/aspeed-g5.dtsi | 43 +++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 8eac57c..f443169 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -267,8 +267,40 @@
ranges = <0x0 0x1e789000 0x1000>;
 
lpc_bmc: lpc-bmc@0 {
-   compatible = "aspeed,ast2500-lpc-bmc";
+   compatible = "aspeed,ast2500-lpc-bmc", 
"simple-mfd", "syscon";
reg = <0x0 0x80>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x80>;
+
+   kcs1: kcs1@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <1>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs2: kcs2@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <2>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs3: kcs3@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <3>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
};
 
lpc_host: lpc-host@80 {
@@ -294,6 +326,15 @@
status = "disabled";
};
 
+   kcs4: kcs4@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0xa0>;
+   interrupts = <8>;
+   kcs_chan = <4>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
lhc: lhc@20 {
compatible = 
"aspeed,ast2500-lhc";
reg = <0x20 0x24 0x48 0x8>;
-- 
2.7.4

[PATCH v2] mmc: Export card RCA register to sysfs.

[Harish Jenny K N]

This patch exports RCA register to sysfs which will help in
reading the disk identification information.

Reviewed-by: Shawn Lin 
Signed-off-by: Harish Jenny K N 
---

Changes in v2:
- Used 0x%04x to display 16 bit register

 drivers/mmc/core/mmc.c | 2 ++
 drivers/mmc/core/sd.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 208a762..6f8ebd6 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -792,6 +792,7 @@ static int mmc_compare_ext_csds(struct mmc_card *card, 
unsigned bus_width)
 MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult);
 MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors);
 MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr);
+MMC_DEV_ATTR(rca, "0x%04x\n", card->rca);
 MMC_DEV_ATTR(cmdq_en, "%d\n", card->ext_csd.cmdq_en);

 static ssize_t mmc_fwrev_show(struct device *dev,
@@ -848,6 +849,7 @@ static ssize_t mmc_dsr_show(struct device *dev,
&dev_attr_raw_rpmb_size_mult.attr,
&dev_attr_rel_sectors.attr,
&dev_attr_ocr.attr,
+   &dev_attr_rca.attr,
&dev_attr_dsr.attr,
&dev_attr_cmdq_en.attr,
NULL,
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 62b84dd..2ecd098 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -676,6 +676,7 @@ static int mmc_sd_init_uhs_card(struct mmc_card *card)
 MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
 MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial);
 MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr);
+MMC_DEV_ATTR(rca, "0x%04x\n", card->rca);


 static ssize_t mmc_dsr_show(struct device *dev,
@@ -709,6 +710,7 @@ static ssize_t mmc_dsr_show(struct device *dev,
&dev_attr_oemid.attr,
&dev_attr_serial.attr,
&dev_attr_ocr.attr,
+   &dev_attr_rca.attr,
&dev_attr_dsr.attr,
NULL,
 };
--
1.9.1

[PATCH v2] arm64: dts: msm8916: Add cpu cooling maps

[Amit Kucheria]

From: Rajendra Nayak 

Add cpu cooling maps for cpu passive trip points. The cpu cooling
device states are mapped to cpufreq based scaling frequencies.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Amit Kucheria 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index e468277..66b318e 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Qualcomm Technologies, Inc. MSM8916";
@@ -115,6 +116,7 @@
cpu-idle-states = <&CPU_SPC>;
clocks = <&apcs 0>;
operating-points-v2 = <&cpu_opp_table>;
+   #cooling-cells = <2>;
};
 
CPU1: cpu@1 {
@@ -126,6 +128,7 @@
cpu-idle-states = <&CPU_SPC>;
clocks = <&apcs 0>;
operating-points-v2 = <&cpu_opp_table>;
+   #cooling-cells = <2>;
};
 
CPU2: cpu@2 {
@@ -137,6 +140,7 @@
cpu-idle-states = <&CPU_SPC>;
clocks = <&apcs 0>;
operating-points-v2 = <&cpu_opp_table>;
+   #cooling-cells = <2>;
};
 
CPU3: cpu@3 {
@@ -148,6 +152,7 @@
cpu-idle-states = <&CPU_SPC>;
clocks = <&apcs 0>;
operating-points-v2 = <&cpu_opp_table>;
+   #cooling-cells = <2>;
};
 
L2_0: l2-cache {
@@ -196,6 +201,13 @@
type = "critical";
};
};
+
+   cooling-maps {
+   map0 {
+   trip = <&cpu_alert0>;
+   cooling-device = <&CPU0 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
};
 
cpu-thermal1 {
@@ -216,6 +228,13 @@
type = "critical";
};
};
+
+   cooling-maps {
+   map0 {
+   trip = <&cpu_alert1>;
+   cooling-device = <&CPU0 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
};
 
};
-- 
2.7.4

Re: [PATCH] arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset)

[Doug Anderson]

Hi,

On Tue, Mar 6, 2018 at 10:58 AM, Marc Zyngier  wrote:
> On 06/03/18 18:49, Heiko Stübner wrote:
>> Am Dienstag, 6. März 2018, 19:15:18 CET schrieb Marc Zyngier:
>>> Hi Doug,
>>>
>>> On 06/03/18 18:00, Doug Anderson wrote:
 Hi,

 On Tue, Mar 6, 2018 at 3:58 AM, Marc Zyngier  wrote:
> Hi all,
>
> On 01/03/18 08:43, Heiko Stübner wrote:
>> Am Dienstag, 27. Februar 2018, 21:47:11 CET schrieb Douglas Anderson:
>>> Back in the early days when gru devices were still under development
>>> we found an issue where the WiFi reset line needed to be configured as
>>> early as possible during the boot process to avoid the WiFi module
>>> being in a bad state.
>>>
>>> We found that the way to get the kernel to do this in the earliest
>>> possible place was to configure this line in the pinctrl hogs, so
>>> that's what we did.  For some history here you can see
>>> .  After the time that change landed in
>>> the kernel, we landed a firmware change to configure this line even
>>> earlier.  See .  However, even after the
>>> firmware change landed we kept the kernel change to deal with the fact
>>> that some people working on devices might take a little while to
>>> update their firmware.
>>>
>>> At this there are definitely zero devices out in the wild that have
>>> firmware without the fix in it.  Specifically looking in the firmware
>>> branch several critically important fixes for memory stability landed
>>> after the patch in coreboot and I know we didn't ship without those.
>>> Thus, by now, everyone should have the new firmware and it's safe to
>>> not have the kernel set this up in a pinctrl hog.
>>>
>>> Historically, even though it wasn't needed to have this in a pinctrl
>>> hog, we still kept it since it didn't hurt.  Pinctrl would apply the
>>> default hog at bootup and then would never touch things again.  That
>>> all changed with commit 981ed1bfbc6c ("pinctrl: Really force states
>>> during suspend/resume").  After that commit then we'll re-apply the
>>> default hog at resume time and that can screw up the reset state of
>>> WiFi.  ...and on rk3399 if you touch a device on PCIe in the wrong way
>>> then the whole system can go haywire.  That's what was happening.
>>> Specifically you'd resume a rk3399-gru-* device and it would mostly
>>> resume, then would crash with some crazy weird crash.
>>>
>>> One could say, perhaps, that the recent pinctrl change was at fault
>>> (and should be fixed) since it changed behavior.  ...but that's not
>>> really true.  The device tree for rk3399-gru is really to blame.
>>> Specifically since the pinctrl is defined in the hog and not in the
>>> "wlan-pd-n" node then the actual user of this pin doesn't have a
>>> pinctrl entry for it.  That's bad.
>>>
>>> Let's fix our problems by just moving the control of
>>> "wlan_module_reset_l pinctrl" out of the hog and put them in the
>>> proper place.
>>>
>>> NOTE: in theory, I think it should actually be possible to have a pin
>>> controlled _both_ by the hog and by an actual device.  Once the device
>>> claims the pin I think the hog is supposed to let go.  I'm not 100%
>>> sure that this works and in any case this solution would be more
>>> complex than is necessary.
>>>
>>> Reported-by: Marc Zyngier 
>>> Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS")
>>> Fixes: 981ed1bfbc6c ("pinctrl: Really force states during
>>> suspend/resume")
>>> Signed-off-by: Douglas Anderson 
>>
>> applied as fix for 4.16 with the 2 Tested-tags
>
> Sorry to rain on everyone's parade, but further testing shows that this
> patch may not be enough to restore a reliable s2r. My initial testing
> did show that we were resuming without the VOP errors, but there seem to
> be further issues (I'm loosing the keyboard and the trackpad after
> resume on Kevin).
>
> Applying my initial hack makes it work again. I suspect that there are
> more hog pins that need tweaking, but I'm a bit out of my depth here.

 Are you positive you weren't just wearing your lucky hat when you
 tested your patch and then took it off when you tested mine?  As far
>>>
>>> So far, I seem to have a 100% success rate in resuming with my silly
>>> hack, whist your DT patch alone only gives me a 50% rate at best.
>>>
 as I can see the only hogs left on kevin are:
   &ap_pwroff  /* AP will auto-assert this when in S3 */
   &clk_32k/* This pin is always 32k on gru boards */

 Those map to:
   ap_pwroff: ap-pwroff {

  rockchip,pins = <1 5 RK_FUNC_1 &pcfg_pull_none>;

   };

   clk_32k: clk-32k {

 rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;

B2B Prospect Contacts for 2018

[laury . nancy]

Hi,

Hope you are doing well.

We are a database providing company which provides lists/databases for  
various industries across the globe and we can provide you with contact  
details of decision makers and influencers of your target market.


All the contacts include Contact name, Job title, mailing address, City,  
State, Zip code, Revenue size, Employee size, Phone, Industry, URL and  
Verified deliverable emails only.


If you can let me know your targeted criteria as below, I can assist you  
with some samples along with the count/costs, and more details for your  
consideration.


• Geography:
• Industry:
• Executive title/job roles:

Thanks, and looking forward to hearing from you!

Regards,
Laury Nancy
Marketing Analyst

Other Industries: - Oil & Gas, Energy & Utility, Healthcare,  
Transportation, IT Security, Manufacturing, Finance, Insurance, Food &  
Beverage, Hospitality, Construction, Publishing and Printing,  
Semiconductors, Security Etc.

Re: [PATCH v4 14/24] fpga: dfl: fme: add partial reconfiguration sub feature support

[Wu Hao]

On Tue, Mar 06, 2018 at 12:29:35PM -0600, Alan Tull wrote:
>   On Mon, Mar 5, 2018 at 8:08 PM, Wu Hao  wrote:
> > On Mon, Mar 05, 2018 at 04:46:02PM -0600, Alan Tull wrote:
> >> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao  wrote:
> >>
> >> Hi Hao,
> >
> > Hi Alan,
> >
> > Thanks for the comments.
> >
> >>
> >> We are going to want to be able use different FPGA managers with this
> >> framework.  The different manager may be part of a different FME in
> >> fabric or it may be a hardware FPGA manager.  Fortunately, at this
> >> point now the changes, noted below, to get there are pretty small.
> >
> > Yes, understand these could be some cases that FME having different PR
> > hardware.
> >
> 
> Or supporting reduced FME plus hardware-based FPGA manager.
> 
> Just to re-emphasize, the basic intent of the FPGA manager subsystem
> in the first place is to have FPGA managers separate from higher level
> frameworks so that the higher level frameworks will be able to able to
> use different FPGAs.
> 
> >> > +/**
> >> > + * fpga_fme_create_mgr - create fpga mgr platform device as child device
> >> > + *
> >> > + * @pdata: fme platform_device's pdata
> >> > + *
> >> > + * Return: mgr platform device if successful, and error code otherwise.
> >> > + */
> >> > +static struct platform_device *
> >> > +fpga_fme_create_mgr(struct feature_platform_data *pdata)
> >> > +{
> >> > +   struct platform_device *mgr, *fme = pdata->dev;
> >> > +   struct feature *feature;
> >> > +   struct resource res;
> >> > +   struct resource *pres;
> >> > +   int ret = -ENOMEM;
> >> > +
> >> > +   feature = get_feature_by_id(&pdata->dev->dev, 
> >> > FME_FEATURE_ID_PR_MGMT);
> >> > +   if (!feature)
> >> > +   return ERR_PTR(-ENODEV);
> >> > +
> >> > +   /*
> >> > +* Each FME has only one fpga-mgr, so allocate platform device 
> >> > using
> >> > +* the same FME platform device id.
> >> > +*/
> >> > +   mgr = platform_device_alloc(FPGA_DFL_FME_MGR, fme->id);
> >>
> >> At this point, the framework is assuming all FME's include the same
> >> FPGA manager device which would use the driver in dfl-fme-mgr.c.
> >>
> >> I'm thinking of two cases where the manager isn't the same as a
> >> dfl-fme-mgr.c manager are a bit different:
> >>
> >> (1) a FME-based FPGA manager, but different implementation, different
> >> registers.  The constraint is that the port implementation has to be
> >> similar enough to use the rest of the base FME code.   I am wondering
> >> if the FPGA manager can be added to the DFL.  At this point, the DFL
> >> would drive which FPGA manager is alloc'd.   That way the user gets to
> >> use all this code in dfl-fme-pr.c but with their FPGA manager.
> >
> > Actually I'm not sure how this will be implemented in the hardware in the
> > future, but from my understanding, there may be several methods to add this
> > support (a different PR hardware) to FME.
> >
> > 1) introduce a new PR sub feature to FME.
> >driver knows it by different feature id, and create different fpga
> >manager platform device, but may not be able to reuse dfl-fme-pr.c.
> 
> What would prevent reusing dfl-fme-pr.c?  It looks like this is 98% of
> the way there and only needs a way of knowing which FPGA manager
> driver to alloc here. I am hoping that a new PR sub feature could be
> added and that dfl-fme-pr.c can be reused.

It depeneds on how hardware implements it. : )
I agree that if it follows the same way of current PR sub feature, then we
could reuse the dfl-fme-pr.c for sure.

> 
> >
> > 2) add a different PR hardware support to current PR sub feature.
> >It requires hardware to add registers to indicate this is a different
> >PR hardware than dfl-fme-mgr.c, and its register region information
> >(e.g location and size). Then this dfl-fme-pr.c driver could read
> >these information from hardware and create a different fpga manager
> >platform device with correct resources.
> 
> So this dfl-fme-pr.c would have to know where some ID registers are
> and the enumeration gets messier.  Some of the enumeration would be
> DFL and some would be from information that is not in the DFL headers.
> The DFL should contain the knowledge of which mgr to use.

Actually I don't know how hardware will implement this in the future, but I
just listed my ideas here. Per my understanding, driver (reuse dfl-fme-pr.c)
needs some more information to decide which platform device to create (for
fpga manager).

1) introduce a new PR sub feature. Then it has a different private feature
id in DFH (Device Feature Header). driver could use this id to create a
different platform device.

2) introduce some registers inside the current PR sub feature. Then driver
could read these registers to know which platform device to create for fpga
manager.

I think either 1) or 2) will only require small changes to current driver
code, I don't have any concern on supporting different PR hardware. :)

I u

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
> Hi Rob and Andrzej,
> 
> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>> Hi Rob, Chanwoo, Krzysztof,
>>
>>
>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>> Hi,
>>>
>>> Thanks for reviews of previous iterations.
>>>
>>> This patchset introduces USB physical connector bindings, together with
>>> working example.
>>> I have removed RFC prefix - the patchset seems to be heading
>>> to a happy end :)
>>>
>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>> v4: improved binding descriptions, added missing reg in dts.
>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>> example.
>>> v2: I have addressed comments by Rob and Laurent, thanks 
>>>
>>> Changes in datail are described in the patches.
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (5):
>>>   dt-bindings: add bindings for USB physical connector
>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>   extcon: add possibility to get extcon device by OF node
>>>
>>> Maciej Purski (1):
>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>
>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>> acks for dts part).
>> Now I have a question how to merge them.
>> The only functional dependency is between bridge and extcon, and from
>> the formal PoV bindings should be merged 1st.
>> I can merge it:
>> 1. All patches via drm-misc tree.
>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>> samsung-soc tree.
>>
>> Is it OK, for all? Better ideas?
> 
> Krzysztof picked the dts patches. I'll make the immutable branch based on 
> v4.16-rc1
> and apply them except for dts patchs. And I'll send the immutable branch to 
> Rob and Andrzej.
> 
> 

I made the immutable branch[1] as following: If you agree, I'll send pull 
request.
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17

Or you can make the immutable branch and send pull request to Rob and me.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

[Alex Shi]

On 03/07/2018 01:25 AM, Greg KH wrote:
> I suggest looking at the backports in the android-common tree that are
> needed for this "feature" to work properly, and pull them out and test
> them if you really want it in your Linaro trees.  If you think some of
> them should be added to the LTS kernels, I'll be glad to consider them,
> but don't do a hack to try to work around the lack of these features,
> otherwise you will not be happy in the long-run.
> 

Thanks for response! :)

If we want the life easy for Linaro, we don't do backporting for LTS
first, that cause more trouble to skip features which are merged in our
tree already, like kaslr, software pan. Backporting to lts first make
double trick when merge it back. We did this just because, we believe
LTS need this.

And further more, android skip to much fix patch for this 2 bugs:
some main commits are following:
for metldown:

arm64: kpti: Add ->enable callback to remap swapper using nG mappings
arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0()
arm64: Turn on KPTI only on CPUs that need it

For spectre, which is totally missing in android.

arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
arm/arm64: smccc: Make function identifiers an unsigned quantity
arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm/arm64: KVM: Turn kvm_psci_version into a static inline
arm64: KVM: Increment PC after handling an SMC trap
arm64: Implement branch predictor hardening for affected Cortex-A CPUs
arm64: entry: Apply BP hardening for suspicious interrupts from EL0
arm64: entry: Apply BP hardening for high-priority synchronous exceptions
arm64: KVM: Use per-CPU vector when BP hardening is enabled
arm64: Move BP hardening to check_and_switch_context
arm64: Add skeleton to harden the branch predictor against aliasing attacks
arm64: cpufeature: Pass capability structure to ->enable callback
arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
arm64: barrier: Add CSDB macros to control data-value prediction
arm64: alternatives: apply boot time fixups via the linear mapping

Thanks!
Alex

Re: [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

[Wang, Haiyue]

On 2018-03-07 11:56, Joel Stanley wrote:

And the patch is generated by rebasing on:
https://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
Please help to review.

Thanks for the patch. I suggest you submit this patch for inclusion in
the upstream kernel. To do this, send it to:
Joel Stanley
Andrew Jeffery
linux-arm-ker...@lists.infradead.org
linux-asp...@lists.ozlabs.org
linux-kernel@vger.kernel.org

Got it.

And I will consider it for merging.

 From there I can backport it into the dev-4.13 tree.

Cheers,

Joel

[PATCH] x86: mm: typo: fix a typo in a comment line

[Seunghun Han]

Fix a typo in a comment line of pti.c.

Signed-off-by: Seunghun Han 
---
 arch/x86/mm/pti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f16..631507f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7 @@ static void __init pti_clone_user_shared(void)
 }
 
 /*
- * Clone the ESPFIX P4D into the user space visinble page table
+ * Clone the ESPFIX P4D into the user space visible page table
  */
 static void __init pti_setup_espfix64(void)
 {
-- 
2.1.4

Re: Assalam Alaikum

[Eiman Yousef M A Al-Muzafar]

Assalam Alaikum, I am Eiman Yousef M A Al-Muzafar from Qatar, I Need your
Urgent Response for a Proposal of Trust and genuineness, Please Contact me
now : eimanyouse...@hotmail.com

Re: [PATCH 2/2] trace_uprobe: Simplify probes_seq_show()

[Ravi Bangoria]

On 03/07/2018 03:34 AM, Kees Cook wrote:
> On Tue, Mar 6, 2018 at 12:12 AM, Ravi Bangoria
>  wrote:
>>
>> On 02/08/2018 09:13 AM, Ravi Bangoria wrote:
>>> Wang, ping :)
>>>
>>> Kees, I don't hear back from Wang and no one has reported any issues with
>>> the patches yet. Can I have your Acked-by?
> I didn't see a v2 of these patches with the output fixed?

Kees, I didn't send v2 because those 0s seems unnecessary to me.

Please let me know if you still wants to show them. Will re-spin :)

Thanks,
Ravi

PS: Changing Masami's email address in cc.

[EXP softirq] 3f6b5ffc70: Kernel_panic-not_syncing:kmem_cache_create:Failed_to_create_slab'pid'.Error

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 3f6b5ffc706a54598b82456ae0be395aa6465982 ("EXP softirq: Is it possible 
to RCUify BH disable/enable?")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2018.03.01a

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 2G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | 
08c5ee9132 | 3f6b5ffc70 |
+-+++
| boot_successes  | 
12 | 0  |
| boot_failures   | 
0  | 21 |
| Kernel_panic-not_syncing:kmem_cache_create:Failed_to_create_slab'pid'.Error | 
0  | 19 |
| BUG:kernel_in_stage | 
0  | 2  |
+-+++



[0.052000] tsc: Detected 2260.998 MHz processor
[0.052036] clocksource: tsc-early: mask: 0x max_cycles: 
0x20974986637, max_idle_ns: 440795286310 ns
[0.056033] Calibrating delay loop (skipped) preset value.. 4521.99 BogoMIPS 
(lpj=9043992)
[0.060062] pid_max: default: 32768 minimum: 301
[0.064030] kmem_cache_create(pid) integrity check failed
[0.068033] Kernel panic - not syncing: kmem_cache_create: Failed to create 
slab 'pid'. Error -22
[0.068033] 
[0.072000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.16.0-rc1-00055-g3f6b5ff #33
[0.072000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[0.072000] Call Trace:
[0.072000]  dump_stack+0x5d/0x79
[0.072000]  panic+0xd8/0x229
[0.072000]  ? printk+0x43/0x4b
[0.072000]  kmem_cache_create_usercopy+0x1f2/0x224
[0.072000]  kmem_cache_create+0x12/0x14
[0.072000]  pid_idr_init+0xb0/0xba
[0.072000]  start_kernel+0x367/0x3f3
[0.072000]  secondary_startup_64+0xa5/0xb0

Elapsed time: 10

#!/bin/bash



To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.16.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCH

linux-next: Tree for Mar 7

[Stephen Rothwell]

Hi all,

Changes since 20180306:

The mali-dp tree gained a conflict against the drm-misc tree.

Non-merge commits (relative to Linus' tree): 5164
 5702 files changed, 210449 insertions(+), 150844 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (ce380619fab9 Merge tag 'please-pull-ia64_misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging fixes/master (7928b2cbe55b Linux 4.16-rc1)
Merging kbuild-current/fixes (638e69cf2230 fixdep: do not ignore kconfig.h)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index)
Merging arm64-fixes/for-next/fixes (b08e5fd90bfc arm_pmu: Use 
disable_irq_nosync when disabling SPI in CPU teardown hook)
Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem 
entry)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (b0c41b8b6e43 powerpc/pseries: Fix vector5 in ibm 
architecture vector table)
Merging sparc/master (aebb48f5e465 sparc64: fix typo in 
CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (22b8d8115d1b ethernet: natsemi: correct spelling)
Merging bpf/master (d02f51cbcf12 bpf: fix bpf_skb_adjust_net/bpf_skb_proto_xlat 
to deal with gso sctp skbs)
Merging ipsec/master (b8b549eec818 xfrm: Fix ESN sequence number handling for 
IPsec GSO packets.)
Merging netfilter/master (0d3601d2994a netfilter: nft_set_hash: skip fixed hash 
if timeout is specified)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (f0ab68d21b0e Merge tag 
'iwlwifi-for-kalle-2018-03-02' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (a78872363614 cfg80211: add missing dependency to 
CFG80211 suboptions)
Merging rdma-fixes/for-rc (4cd482c12be4 IB/core : Add null pointer check in 
addr_resolve)
Merging sound-current/for-linus (e312a869cd72 ALSA: hda/realtek - Fix dock 
line-out volume on Dell Precision 7520)
Merging pci-current/for-linus (a6f1086e29e9 PCI: Move 
of_irq_parse_and_map_pci() declaration under OF_IRQ)
Merging driver-core.current/driver-core-linus (661e50bc8532 Linux 4.16-rc4)
Merging tty.current/tty-linus (5d7f77ec72d1 serial: imx: fix bogus dev_err)
Merging usb.current/usb-linus (6f566af34628 Revert "typec: tcpm: Only request 
matching pdos")
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (7920a87c40db USB: serial: cp210x: add ELDAT 
Easywave RX09 id)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (7928b2cbe55b Linux 4.16-rc1)
Merging staging.current/staging-linus (740a5759bf22 staging: android: ashmem: 
Fix possible deadlock in ashmem_ioctl)
Merging char-misc.current/char-misc-linus (655296c8bbef Drivers: hv: vmbus: Fix 
ring buffer signaling)
Merging input-current/for-linus (ea4f7bd2aca9

Re: ext4 ignoring rootfs default mount options

[Theodore Y. Ts'o]

On Tue, Mar 06, 2018 at 02:03:15PM -0500, Lennart Sorensen wrote:
> While switching a system from using ext3 to ext4 (It's about time) I
> discovered that setting default options for the filesystem using tune2fs
> -o doesn't work for the root filesystem when mounted by the kernel itself.
> Filesystems mounted from userspace with the mount command use the options
> set just fine.  The extended option set with tune2fs -E mount_opts=
> works fine however.

Well it's not that it's being ignored.  It's just a
misunderstanding of how a few things.  It's also that the how we
handled mount options has evolved over time, leading to a situation
which is confusing.

First, tune2fs changes the default of ext4's mount options.  This is
stated in the tune2fs man page:

-o [^]mount-option[,...]
  Set or clear the indicated default mount options in the filesys‐
  tem.   Default  mount options can be overridden by mount options
  specified either in /etc/fstab(5) or on the command  line  argu‐
  ments  to mount(8).  Older kernels may not support this feature;
  in particular, kernels which predate  2.4.20  will  almost  cer‐
  tainly ignore the default mount options field in the superblock.

Secondly, the message when af ile sytem is mounted, e.g.:

> EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

... is the mount option string that are passed to the mount system
call.

The extended mount options is different.  It was something that we
added later.  If it is present, this the extended mount options is
printed first, followed by a semi-colon, followed by string passed to
the mount system call.

Hence:

> tune2fs -E mount_opts=nodelalloc /dev/sda1
> 
> at boot we got:
> EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: nodelalloc; 
> (null)


The description of -E option in the tune2fs man page talks about some
of this, but it's arguably confusing.

You can see exactly what mount options that are active by looking at
the file /proc/fs/ext4//options.  So this is how you can prove to
yourself that tune2fs -o works.

root@kvm-xfstests:~# dmesg -n 7
root@kvm-xfstests:~# tune2fs -o nodelalloc /dev/vdc 
tune2fs 1.44-WIP (06-Sep-2017)
root@kvm-xfstests:~# mount /dev/vdc /vdc
[   27.389192] EXT4-fs (vdc): mounted filesystem with ordered data mode. Opts: 
(null)
root@kvm-xfstests:~# cat /proc/fs/ext4/vdc/options 
rw
bsddf
nogrpid
block_validity
dioread_lock
nodiscard
nodelalloc
journal_checksum
barrier
auto_da_alloc
user_xattr
acl
noquota
resuid=0
resgid=0
errors=continue
commit=5
min_batch_time=0
max_batch_time=15000
stripe=0
data=ordered
inode_readahead_blks=32
init_itable=10
max_dir_size_kb=0

> For filesystems mounted from userspace with the mount command, either
> method works however.  The first option however is what the comment in
> fs/ext4/super.c suggests to use.
> 
> Of course I also got the messages:
> EXT4-fs (sda1): Mount option "nodelalloc" incompatible with ext3
> EXT4-fs (sda1): failed to parse options in superblock: nodelalloc
> EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities

So what's happening here is something that has recently started
getting reported by users.  Most modern distro's use an initial
ramdisk to mount the root file system, and they use blkid to determine
the file system with the right file system type.  If the kernel is
mounting the root file system.  An indication that this is what's
happening is the following message in dmesg:

[2.196149] VFS: Mounted root (ext4 filesystem) readonly on device 254:0.

This message means the kernel fallback code was used to mount the file
system, not the initial ramdisk code in userspace.

If you are using the kernel fallback code, it will first try to mount
the file system as ext3, and if you have "nodelalloc" in the extended
mount options in the superblock, it will try it first.  The messages
you have quoted above are harmless.  But they are scaring users, so we
are looking into ways to suppress them.

> And of course the last annoying thing I noticed is that /proc/mounts
> doesn't actually tell you that nodelalloc is active when it is set
> from the default mount options rather than from the mount command line
> (or fstab).  Lots of other non default options are explicitly handled,
> but not delalloc.  The only place you see it, is in the dmesg line
> telling you what options the filesystem was mounted with.

That's because /proc/mounts is trying to emulate the user-space
maintained /etc/mtab file.  So we deliberately suppress default mount
options.  If you take out this feature:

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 756f515b762d..e93b86f68da5 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2038,8 +2038,8 @@ static int _ext4_show_options(struct seq_file *seq, 
struct super_block *sb,
if (((m->flags & (MOPT_SET|MOPT_CLEAR)) == 0) ||
(m->flags & MOPT_CLEAR_ERR))
 

Re: [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

[Joel Stanley]

On Sun, Mar 4, 2018 at 3:33 PM, Haiyue Wang  wrote:
> The IPMI KCS device part of the LPC interface and is used for
> communication with the host processor.
>
> Signed-off-by: Haiyue Wang 
> ---
> Hi Joel & Andrew,
>
> The kcs-bmc-aspeed module has been in:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/char/ipmi/kcs_bmc_aspeed.c
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>
> I updated the device tree node about kcs-bmc, this is passed on my board.
>
> And the patch is generated by rebasing on:
> https://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
> Please help to review.

Thanks for the patch. I suggest you submit this patch for inclusion in
the upstream kernel. To do this, send it to:

Joel Stanley 
Andrew Jeffery 
linux-arm-ker...@lists.infradead.org
linux-asp...@lists.ozlabs.org
linux-kernel@vger.kernel.org

And I will consider it for merging.

>From there I can backport it into the dev-4.13 tree.

Cheers,

Joel

>
> BR,
> Haiyue
> ---
>  arch/arm/boot/dts/aspeed-g5.dtsi | 43 
> +++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi 
> b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 8eac57c..f443169 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -267,8 +267,40 @@
> ranges = <0x0 0x1e789000 0x1000>;
>
> lpc_bmc: lpc-bmc@0 {
> -   compatible = "aspeed,ast2500-lpc-bmc";
> +   compatible = 
> "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
> reg = <0x0 0x80>;
> +   reg-io-width = <4>;
> +
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0x0 0x0 0x80>;
> +
> +   kcs1: kcs1@0 {
> +   compatible = 
> "aspeed,ast2500-kcs-bmc";
> +   reg = <0x0 0x80>;
> +   interrupts = <8>;
> +   kcs_chan = <1>;
> +   kcs_addr = <0x0>;
> +   status = "disabled";
> +   };
> +
> +   kcs2: kcs2@0 {
> +   compatible = 
> "aspeed,ast2500-kcs-bmc";
> +   reg = <0x0 0x80>;
> +   interrupts = <8>;
> +   kcs_chan = <2>;
> +   kcs_addr = <0x0>;
> +   status = "disabled";
> +   };
> +
> +   kcs3: kcs3@0 {
> +   compatible = 
> "aspeed,ast2500-kcs-bmc";
> +   reg = <0x0 0x80>;
> +   interrupts = <8>;
> +   kcs_chan = <3>;
> +   kcs_addr = <0x0>;
> +   status = "disabled";
> +   };
> };
>
> lpc_host: lpc-host@80 {
> @@ -294,6 +326,15 @@
> status = "disabled";
> };
>
> +   kcs4: kcs4@0 {
> +   compatible = 
> "aspeed,ast2500-kcs-bmc";
> +   reg = <0x0 0xa0>;
> +   interrupts = <8>;
> +   kcs_chan = <4>;
> +   kcs_addr = <0x0>;
> +   status = "disabled";
> +   };
> +
> lhc: lhc@20 {
> compatible = 
> "aspeed,ast2500-lhc";
> reg = <0x20 0x24 0x48 0x8>;
> --
> 2.7.4
>

Re: [PATCH] MAINTAINERS: Add linux/of_*.h headers to appropriate subsystems

[Vinod Koul]

On Tue, Mar 06, 2018 at 09:13:34AM -0600, Rob Herring wrote:
> The DeviceTree support code for specific subsystems are maintained by
> the respective subsystem maintainers. However, only the DT
> maintainers are listed for most of the linux/of_*.h headers. Fix this
> and add the headers to the appropriate subsystem maintainer.
> 
> Reported-by: Guenter Roeck 
> Cc: Vinod Koul 
> Cc: Linus Walleij 
> Cc: Joerg Roedel 
> Cc: Bjorn Helgaas 
> Signed-off-by: Rob Herring 
> ---
>  MAINTAINERS | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93a12af4f180..248f4266c6bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4333,6 +4333,7 @@ Q:  
> https://patchwork.kernel.org/project/linux-dmaengine/list/
>  S:   Maintained
>  F:   drivers/dma/
>  F:   include/linux/dmaengine.h
> +F:   include/linux/of_dma.h
>  F:   Documentation/devicetree/bindings/dma/
>  F:   Documentation/driver-api/dmaengine/
>  T:   git git://git.infradead.org/users/vkoul/slave-dma.git

This:
Acked-By: Vinod Koul 

-- 
~Vinod

Re: [PATCH v2 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

[Matheus Castello]

Hi Eric,

thanks for reviewing it. I will send the v3 of the patch with your notes. 
I will just wait for the Linus considerations.

Best Regards
Matheus Castello

On 03/05/2018 07:21 PM, Eric Anholt wrote:
> Matheus Castello  writes:
> 
>> To keep driver up to date we add generic pinctrl binding support, which 
>> covers
>> the features used in this driver and has additional node properties that this
>> SoC has compatibility, so enabling future implementations of these properties
>> without the need to create new node properties in the device trees.
>>
>> The logic of this change maintain the old brcm legacy binding support in 
>> order
>> to keep the ABI stable.
>>
>> Signed-off-by: Matheus Castello 
>> ---
>>
>> A brief explanation of what I did:
>>
>> Add pinconf-generic header for use the defines and pinctrl-generic API.
>>
>> Add dt-bindings pinctrl bcm2835 header to use functions selections and
>> pulls definitions, which functions definitions where duplicated in the
>> enum bcm2835_fsel, I removed the duplicate defines from enum.
>>
>> In the bcm2835_pctl_dt_node_to_map_pull I used the generic macro for
>> pack the legacy param and arguments, since it will be unpacked along with
>> generic properties that is packed with this same macro.
>>
>> In bcm2835_pctl_dt_node_to_map I thougt it was better, and simpler, to use
>> pinctrl-generic parse code instead of parsing it inside the driver, so code
>> first check for generic binding parse, if something is parsed then it is
>> assumed that are using the new generic style, and when nothing is found then
>> parse continues to search for legacy properties.
>>
>> In the bcm2835_pinconf_set was changed the unpack legacy by the generic, and
>> was added a switch for the parameter tests, since pinctrl generic uses 3
>> properties to define the states of the pull instead of one with arguments, 
>> that
>> was the reason too that bcm2835_pull_config_set function was added, for reuse
>> the code that set state of pull.
>>
>>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 83 
>> +++
>>  1 file changed, 54 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
>> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index 785c366..755ea90 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> @@ -36,11 +36,13 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define MODULE_NAME "pinctrl-bcm2835"
>>  #define BCM2835_NUM_GPIOS 54
>> @@ -213,14 +215,6 @@ static const char * const bcm2835_gpio_groups[] = {
>>  };
>>
>>  enum bcm2835_fsel {
>> -BCM2835_FSEL_GPIO_IN = 0,
>> -BCM2835_FSEL_GPIO_OUT = 1,
>> -BCM2835_FSEL_ALT0 = 4,
>> -BCM2835_FSEL_ALT1 = 5,
>> -BCM2835_FSEL_ALT2 = 6,
>> -BCM2835_FSEL_ALT3 = 7,
>> -BCM2835_FSEL_ALT4 = 3,
>> -BCM2835_FSEL_ALT5 = 2,
>>  BCM2835_FSEL_COUNT = 8,
>>  BCM2835_FSEL_MASK = 0x7,
>>  };
>> @@ -714,7 +708,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
>> bcm2835_pinctrl *pc,
>>  configs = kzalloc(sizeof(*configs), GFP_KERNEL);
>>  if (!configs)
>>  return -ENOMEM;
>> -configs[0] = BCM2835_PINCONF_PACK(BCM2835_PINCONF_PARAM_PULL, pull);
>> +configs[0] = PIN_CONF_PACKED(BCM2835_PINCONF_PARAM_PULL, pull);
>>
>>  map->type = PIN_MAP_TYPE_CONFIGS_PIN;
>>  map->data.configs.group_or_pin = bcm2835_gpio_pins[pin].name;
>> @@ -736,6 +730,12 @@ static int bcm2835_pctl_dt_node_to_map(struct 
>> pinctrl_dev *pctldev,
>>  int i, err;
>>  u32 pin, func, pull;
>>
>> +/* Check for generic binding in this node */
>> +err = pinconf_generic_dt_node_to_map_all(pctldev, np, map, num_maps);
>> +if (err || *num_maps)
>> +return err;
>> +
>> +/* Generic binding did not find anything continue with legacy parse */
>>  pins = of_find_property(np, "brcm,pins", NULL);
>>  if (!pins) {
>>  dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
>> @@ -917,37 +917,62 @@ static int bcm2835_pinconf_get(struct pinctrl_dev 
>> *pctldev,
>>  return -ENOTSUPP;
>>  }
>>
>> +static void bcm2835_pull_config_set(struct bcm2835_pinctrl *pc,
>> +unsigned pin, unsigned arg)
>> +{
>> +u32 off, bit;
>> +
>> +off = GPIO_REG_OFFSET(pin);
>> +bit = GPIO_REG_SHIFT(pin);
>> +
>> +bcm2835_gpio_wr(pc, GPPUD, arg & 3);
>> +/*
>> +* BCM2835 datasheet say to wait 150 cycles, but not of what.
>> +* But the VideoCore firmware delay for this operation
>> +* based nearly on the same amount of VPU cycles and this clock
>> +* runs at 250 MHz.
>> +*/
>> +udelay(1);
>> +bcm2835_gpio_wr(pc, GPPUDCLK0 + (off * 4), BIT(bit));
>> +udelay(1);
>> +bcm2835_gpio_wr(pc, GPPUDCLK0 + (off * 4), 0);
>> +}
>> +
>>  static int bcm2835_pinconf_set(struct pinctrl_dev *pctldev,
>>  unsign

[PATCH] configfs: initialize inode with owner

[Gwendal Grignou]

From: Sarthak Kukreti 

Use standard helper to set inode owner when created from user space.
This is a noop when the owner is root.

Signed-off-by: Sarthak Kukreti 
Signed-off-by: Gwendal Grignou 
---
 fs/configfs/configfs_internal.h |  5 -
 fs/configfs/inode.c | 14 --
 fs/configfs/mount.c |  2 +-
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
index b65d1ef532d5..772fce1fd222 100644
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@ -68,7 +68,10 @@ extern struct kmem_cache *configfs_dir_cachep;
 
 extern int configfs_is_root(struct config_item *item);
 
-extern struct inode * configfs_new_inode(umode_t mode, struct configfs_dirent 
*, struct super_block *);
+extern struct inode *configfs_new_inode(umode_t mode,
+   struct configfs_dirent *sd,
+   struct inode *p_inode,
+   struct super_block *s);
 extern int configfs_create(struct dentry *, umode_t mode, void (*init)(struct 
inode *));
 
 extern int configfs_create_file(struct config_item *, const struct 
configfs_attribute *);
diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c
index eae87575e681..93db05a2db1f 100644
--- a/fs/configfs/inode.c
+++ b/fs/configfs/inode.c
@@ -108,9 +108,11 @@ int configfs_setattr(struct dentry * dentry, struct iattr 
* iattr)
return error;
 }
 
-static inline void set_default_inode_attr(struct inode * inode, umode_t mode)
+static inline void set_default_inode_attr(struct inode *inode,
+ struct inode *p_inode,
+ umode_t mode)
 {
-   inode->i_mode = mode;
+   inode_init_owner(inode, p_inode, mode);
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
 }
 
@@ -125,7 +127,7 @@ static inline void set_inode_attr(struct inode * inode, 
struct iattr * iattr)
 }
 
 struct inode *configfs_new_inode(umode_t mode, struct configfs_dirent *sd,
-struct super_block *s)
+struct inode *p_inode, struct super_block *s)
 {
struct inode * inode = new_inode(s);
if (inode) {
@@ -140,7 +142,7 @@ struct inode *configfs_new_inode(umode_t mode, struct 
configfs_dirent *sd,
 */
set_inode_attr(inode, sd->s_iattr);
} else
-   set_default_inode_attr(inode, mode);
+   set_default_inode_attr(inode, p_inode, mode);
}
return inode;
 }
@@ -190,11 +192,11 @@ int configfs_create(struct dentry * dentry, umode_t mode, 
void (*init)(struct in
return -EEXIST;
 
sd = dentry->d_fsdata;
-   inode = configfs_new_inode(mode, sd, dentry->d_sb);
+   p_inode = d_inode(dentry->d_parent);
+   inode = configfs_new_inode(mode, sd, p_inode, dentry->d_sb);
if (!inode)
return -ENOMEM;
 
-   p_inode = d_inode(dentry->d_parent);
p_inode->i_mtime = p_inode->i_ctime = CURRENT_TIME;
configfs_set_inode_lock_class(sd, inode);
 
diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
index a8f3b589a2df..23aede27c502 100644
--- a/fs/configfs/mount.c
+++ b/fs/configfs/mount.c
@@ -78,7 +78,7 @@ static int configfs_fill_super(struct super_block *sb, void 
*data, int silent)
sb->s_time_gran = 1;
 
inode = configfs_new_inode(S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO,
-  &configfs_root, sb);
+  &configfs_root, NULL, sb);
if (inode) {
inode->i_op = &configfs_root_inode_operations;
inode->i_fop = &configfs_dir_operations;
-- 
2.16.2.660.g709887971b-goog

Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

[Alex Shi]

>>> But really, I don't see this need as all ARM devices that I know of that
>>> are stuck on 4.9.y are already using the android-common tree.  Same for
>>> 4.4.y.  Do you know of any that are not, and that can not just use
>>> 4.14.y instead?
>>
>> There's way more to ARM than just Android systems, assuming that getting
>> things into the Android kernel is enough is like assuming that x86 is
>> covered since the distros have their own backports - it covers a lot of
>> users but not everyone.  Off the top of my head there's things like
>> routers, NASs, cameras, IoT, radio systems, industrial appliances, set
>> top boxes and these days even servers.  Most of these segments are just
>> as conservative about taking new kernel versions on shipping product as
>> the phone vendors are, the practices that make people relucant to take
>> bigger updates in production are general engineering practices common
>> across industry.
> 
> I know there is lots more than Android to ARM, but the huge majority by
> quantity is Android.
> 
> What I'm saying here is look at all of the backports that were required
> to get this working in the android tree.  It was non-trivial by a long
> shot, and based on that work, this series feels really "small" and I'm
> really worried that it's not really working or solving the problem here.>
> There are major features that were backported to the android trees for
> ARM that the upstream features for Spectre and Meltdown built on top of
> to get their solution.  To not backport all of that is a huge risk,
> right?

Thanks for response!

Yes, that is problem I concern, current android is far from enough to
protect it self form these two bugs. There are lots of fix missed. like
the main fix patch from upstream isn't included:
 arm64: Add skeleton to harden the branch predictor against aliasing attacks
commit 0f15adbb2861 upstream.

BTW, The concept of 2 bugs mitigation is relatively simple, and current
backporting include everything that arm did to mitigate them.

> 
> So that's why I keep pointing people at the android trees.  Look at what
> they did there.  There's nothing stoping anyone who is really insistant
> on staying on these old kernel versions from pulling from those branches
> to get these bugfixes in a known stable, and tested, implementation.
> That's why I point people there[1].  To do all of the backporting and
> add the new features feels _way_ beyond what I should be taking into the
> stable kernels.  We didn't do it for x86, why should we do it for ARM?

Thanks for your effort! That's the reason, LTS need spectre/meltdown fix
on ARM, people like to keep using them system with a simple
kernel/fireware update, instead of whole system update with whole system
retesting.

> 
> Yes, we did a horrid hack for the x86 backports (with the known issues
> that it has, and people seem to keep ignoring, which is crazy), and I
> would suggest NOT doing that same type of hack for ARM, but go grab a
> tree that we all know to work correctly if you are suck with these old
> kernels!

We know things aren't perfect in urgency fix, that's a reason for x86
story. but for arm side, arm had 3 versions fix, and do update 2 times
on them website, we did 2 times backport too for their fix. Obviously
arm get more time and take more lesson from x86 story for their fix.

> 
> Or just move to 4.14.y.  Seriously, that's probably the safest thing in
> the long run for anyone here.  And when you realize you can't do that,
> go yell at your SoC for forcing you into the nightmare that they conned
> you into by their 3+ million lines added to their kernel tree.  You were
> always living on borowed time, and it looks like that time is finally
> up...

yes, that's true. But compare to x86 market, backport to old stable
kernel would save much time for arm vendors and free them to more
new/upstream work instead.

> 
> thanks,
> 
> greg k-h
> 
> [1] It's also why I keep doing the LTS merges into the android-common
> trees within days of the upstream LTS release (today being an
> exception).  That way once you do a pull/merge, you can just keep
> always merging to keep a secure device that is always up to date
> with the latest LTS releases in a simple way.  How much easier can I
> make it for the ARM ecosystem here, really?
> 
> Oh, I know, get the SoC vendors to merge from the android-common
> trees into their trees.  Look, that's already happening today for at
> least 3 major SoCs!  So just go pull the update from your SoC today,
> for your chip, and it automatically has all of these fixes in it
> already!  If you know a SoC that is not pulling these updates
> regularly, let me know and I'll work with them to resolve that[2].
> 
> [2] I have offered to do that merge myself, from the android-common
> trees into any "internal" tree, so that future merges happen cleanly
> and automatically, for any company that asks for it.  So far only
> one company ha

Re: [PATCH v7 13/14] iommu/rockchip: Add runtime PM support

[Tomasz Figa]

On Wed, Mar 7, 2018 at 12:16 PM, JeffyChen  wrote:
> Hi Tomasz,
>
> Thanks for your reply.
>
> On 03/06/2018 06:07 PM, Tomasz Figa wrote:
>>
>> Hi Jeffy,
>>
>> It looks like I missed some details of how runtime PM enable works
>> before, so we might be able to simplify things. Sorry for not getting
>> things right earlier
>
>
> hmm, right, the enable state should be the same during those functions. will
> do it in the next version.

Thanks. I actually realized that we don't even need the
pm_runtime_enabled() checks either.

Actually, we can clean this up in an incremental patch, so no need to
resend if no other changes needed, since current code is still
technically correct.

Best regards,
Tomasz

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

[Greg KH]

On Tue, Mar 06, 2018 at 05:07:45PM -0800, Alexei Starovoitov wrote:
> combining multiple answers...
> 
> On 3/6/18 3:05 AM, Greg KH wrote:
> > 
> > Any chance you can add a field to your "umh module" type such that a
> > normal 'modinfo' program will be able to notice it is different easily?
> 
> ok. handling of modinfo turned out to be straightforward.
> kmod tooling worked fine with simple addition of .modinfo section.
> 
> $ modinfo bpfilter
> filename:
> /lib/modules/4.16.0-rc4-00799-g1716f0aa3039-dirty/net/bpfilter/bpfilter.ko
> umh:Y

Nice.  But perhaps spell it out, "user_mode_helper"?  Anyway,
bikesheding now, sorry, whatever you want to call it is fine with me.

> license:GPL
> 
> I will require umh=Y and license to be present.
> umh has to be set to Y for this 'umh modules'
> and taint of kernel will happen if license is not gpl.

Interesting, I like it :)


> Other modinfo like vermagic are not applicable here, since
> umh modules interact with kernel via normal kernel/user abi.

Very true.

> > > Since umh can crash, can be oom-ed by the kernel, killed by admin,
> > > the subsystem that uses them (like bpfilter) need to manage life
> > > time of umh on its own, so module infra doesn't do any accounting
> > > of them. They don't appear in "lsmod" and cannot be "rmmod".
> > > Multiple request_module("umh") will load multiple umh.ko processes.
> > > 
> > > Similar to kernel modules the kernel will be tainted if "umh module"
> > > has invalid signature.
> > 
> > Shouldn't we fail to load the "module" if the signature is not valid if
> > CONFIG_MODULE_SIG_FORCE=y is enabled, like we do for modules?  I run my
> > systems like that, and just "warning" isn't probably a good idea for
> > systems that want to enforce that everything is signed properly?
> 
> CONFIG_MODULE_SIG_FORCE=y is already handled by this patch.
> It's checked first for either .ko or umh.ko (before any elf parsing)
> and returns -ENOKEY to user space without any dmesg message.
> I think it's best to keep it as-is.
> The taint and warning is for 'undef SIG_FORCE' and when module
> is signed, but incorrectly.

Ah, sorry, I missed that, thanks for clearing it up.

> > Other than that, one minor question:
> > 
> > > @@ -1745,7 +1745,9 @@ static int do_execveat_common(int fd, struct 
> > > filename *filename,
> > >   sched_exec();
> > > 
> > >   bprm->file = file;
> > > - if (fd == AT_FDCWD || filename->name[0] == '/') {
> > > + if (!filename) {
> > > + bprm->filename = "/dev/null";
> > 
> > Why the use of "/dev/null" for the filename here, and elsewhere in the
> > code?  While I'm "sure" that everyone really does have /dev/null/
> > mounted in the root namespace, what is the use of it here?
> 
> filename is assumed to be non-null in several places further
> down and instead of hacking it everywhere it's cleaner to assign
> some string to it.
> I'll change it to filename = "none"
> Same in umh part.

Thanks, that makes sense.

greg k-h

Re: [PATCH v7 13/14] iommu/rockchip: Add runtime PM support

[Tomasz Figa]

On Tue, Mar 6, 2018 at 7:07 PM, Tomasz Figa  wrote:
> Hi Jeffy,
>
> It looks like I missed some details of how runtime PM enable works
> before, so we might be able to simplify things. Sorry for not getting
> things right earlier.
>
> On Tue, Mar 6, 2018 at 12:27 PM, Jeffy Chen  wrote:
>> When the power domain is powered off, the IOMMU cannot be accessed and
>> register programming must be deferred until the power domain becomes
>> enabled.
>>
>> Add runtime PM support, and use runtime PM device link from IOMMU to
>> master to startup and shutdown IOMMU.
>>
>> Signed-off-by: Jeffy Chen 
>> ---
>>
>> Changes in v7:
>> Add WARN_ON in irq isr, and modify iommu archdata comment.
>>
>> Changes in v6: None
>> Changes in v5:
>> Avoid race about pm_runtime_get_if_in_use() and pm_runtime_enabled().
>>
>> Changes in v4: None
>> Changes in v3:
>> Only call startup() and shutdown() when iommu attached.
>> Remove pm_mutex.
>> Check runtime PM disabled.
>> Check pm_runtime in rk_iommu_irq().
>>
>> Changes in v2: None
>>
>>  drivers/iommu/rockchip-iommu.c | 189 
>> -
>>  1 file changed, 148 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
>> index 2448a0528e39..db08978203f7 100644
>> --- a/drivers/iommu/rockchip-iommu.c
>> +++ b/drivers/iommu/rockchip-iommu.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -105,7 +106,14 @@ struct rk_iommu {
>> struct iommu_domain *domain; /* domain to which iommu is attached */
>>  };
>>
>> +/**
>> + * struct rk_iommudata - iommu archdata of master device.
>> + * @link:  device link with runtime PM integration from the master
>> + * (consumer) to the IOMMU (supplier).
>> + * @iommu: IOMMU of the master device.
>> + */
>>  struct rk_iommudata {
>> +   struct device_link *link;
>> struct rk_iommu *iommu;
>>  };
>>
>> @@ -518,7 +526,13 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
>> u32 int_status;
>> dma_addr_t iova;
>> irqreturn_t ret = IRQ_NONE;
>> -   int i;
>> +   bool need_runtime_put;
>> +   int i, err;
>> +
>> +   err = pm_runtime_get_if_in_use(iommu->dev);
>> +   if (WARN_ON(err <= 0 && err != -EINVAL))
>> +   return ret;
>> +   need_runtime_put = err > 0;
>
> Actually, for our purposes, we can assume that runtime PM enable
> status can be only changed by the driver itself. Looking at the LXR,
> PM core also calls __pm_runtime_disable() before calling
> .suspend_late() callback and pm_runtime_enable() after calling
> .resume_early() callback, but we should be able to ignore this,
> because we handle things in .suspend() callback in this driver.
>
> With this assumption in mind, all we need to do here is:
>
> if (WARN_ON(!pm_runtime_get_if_in_use(iommu->dev)))
> return 0;
>
>>
>> WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks));
>>
>> @@ -570,6 +584,9 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
>>
>> clk_bulk_disable(iommu->num_clocks, iommu->clocks);
>>
>> +   if (need_runtime_put)
>> +   pm_runtime_put(iommu->dev);
>
> if (pm_runtime_enabled())
> pm_runtime_put(iommu->dev);

Actually, we don't even need this pm_runtime_enabled() check and can
always call pm_runtime_put(), because at this point we would be only
in either of cases:
1) runtime PM compiled in and enabled, so we got the enable count and
need to put it,
2) runtime PM not compiled in, so pm_runtime_put() is a no-op.

>
>> +
>> return ret;
>>  }
>>
>> @@ -611,10 +628,20 @@ static void rk_iommu_zap_iova(struct rk_iommu_domain 
>> *rk_domain,
>> spin_lock_irqsave(&rk_domain->iommus_lock, flags);
>> list_for_each(pos, &rk_domain->iommus) {
>> struct rk_iommu *iommu;
>> +   int ret;
>> +
>> iommu = list_entry(pos, struct rk_iommu, node);
>> -   WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks));
>> -   rk_iommu_zap_lines(iommu, iova, size);
>> -   clk_bulk_disable(iommu->num_clocks, iommu->clocks);
>> +
>> +   /* Only zap TLBs of IOMMUs that are powered on. */
>> +   ret = pm_runtime_get_if_in_use(iommu->dev);
>> +   if (ret > 0 || ret == -EINVAL) {
>
> if (pm_runtime_get_if_in_use(iommu->dev)) {
>
>> +   WARN_ON(clk_bulk_enable(iommu->num_clocks,
>> +   iommu->clocks));
>> +   rk_iommu_zap_lines(iommu, iova, size);
>> +   clk_bulk_disable(iommu->num_clocks, iommu->clocks);
>
> if (pm_runtime_enabled(iommu->dev))
> pm_runtime_put(iommu->dev);

Same here.

Best regards,
Tomasz

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

[Julia Cartwright]

On Wed, Feb 21, 2018 at 08:15:59AM -0800, Jae Hyun Yoo wrote:
> This commit adds driver implementation for PECI bus into linux
> driver framework.
> 
> Signed-off-by: Jae Hyun Yoo 
> ---
[..]
> +static int peci_locked_xfer(struct peci_adapter *adapter,
> + struct peci_xfer_msg *msg,
> + bool do_retry,
> + bool has_aw_fcs)

_locked generally means that this function is invoked with some critical
lock held, what lock does the caller need to acquire before invoking
this function?

> +{
> + ktime_t start, end;
> + s64 elapsed_ms;
> + int rc = 0;
> +
> + if (!adapter->xfer) {

Is this really an optional feature of an adapter?  If this is not
optional, then this check should be in place when the adapter is
registered, not here.  (And it should WARN_ON(), because it's a driver
developer error).

> + dev_dbg(&adapter->dev, "PECI level transfers not supported\n");
> + return -ENODEV;
> + }
> +
> + if (in_atomic() || irqs_disabled()) {

As Andrew mentioned, this is broken.

You don't even need a might_sleep().  The locking functions you use here
will already include a might_sleep() w/ CONFIG_DEBUG_ATOMIC_SLEEP.

> + rt_mutex_trylock(&adapter->bus_lock);
> + if (!rc)
> + return -EAGAIN; /* PECI activity is ongoing */
> + } else {
> + rt_mutex_lock(&adapter->bus_lock);
> + }
> +
> + if (do_retry)
> + start = ktime_get();
> +
> + do {
> + rc = adapter->xfer(adapter, msg);
> +
> + if (!do_retry)
> + break;
> +
> + /* Per the PECI spec, need to retry commands that return 0x8x */
> + if (!(!rc && ((msg->rx_buf[0] & DEV_PECI_CC_RETRY_ERR_MASK) ==
> +   DEV_PECI_CC_TIMEOUT)))
> + break;

This is pretty difficult to parse.  Can you split it into two different
conditions?

> +
> + /* Set the retry bit to indicate a retry attempt */
> + msg->tx_buf[1] |= DEV_PECI_RETRY_BIT;

Are you sure this bit is to be set in the _second_ byte of tx_buf?

> +
> + /* Recalculate the AW FCS if it has one */
> + if (has_aw_fcs)
> + msg->tx_buf[msg->tx_len - 1] = 0x80 ^
> + peci_aw_fcs((u8 *)msg,
> + 2 + msg->tx_len);
> +
> + /* Retry for at least 250ms before returning an error */
> + end = ktime_get();
> + elapsed_ms = ktime_to_ms(ktime_sub(end, start));
> + if (elapsed_ms >= DEV_PECI_RETRY_TIME_MS) {
> + dev_dbg(&adapter->dev, "Timeout retrying xfer!\n");
> + break;
> + }
> + } while (true);
> +
> + rt_mutex_unlock(&adapter->bus_lock);
> +
> + return rc;
> +}
> +
> +static int peci_xfer(struct peci_adapter *adapter, struct peci_xfer_msg *msg)
> +{
> + return peci_locked_xfer(adapter, msg, false, false);
> +}
> +
> +static int peci_xfer_with_retries(struct peci_adapter *adapter,
> +   struct peci_xfer_msg *msg,
> +   bool has_aw_fcs)
> +{
> + return peci_locked_xfer(adapter, msg, true, has_aw_fcs);
> +}
> +
> +static int peci_scan_cmd_mask(struct peci_adapter *adapter)
> +{
> + struct peci_xfer_msg msg;
> + u32 dib;
> + int rc = 0;
> +
> + /* Update command mask just once */
> + if (adapter->cmd_mask & BIT(PECI_CMD_PING))
> + return 0;
> +
> + msg.addr  = PECI_BASE_ADDR;
> + msg.tx_len= GET_DIB_WR_LEN;
> + msg.rx_len= GET_DIB_RD_LEN;
> + msg.tx_buf[0] = GET_DIB_PECI_CMD;
> +
> + rc = peci_xfer(adapter, &msg);
> + if (rc < 0) {
> + dev_dbg(&adapter->dev, "PECI xfer error, rc : %d\n", rc);
> + return rc;
> + }
> +
> + dib = msg.rx_buf[0] | (msg.rx_buf[1] << 8) |
> +   (msg.rx_buf[2] << 16) | (msg.rx_buf[3] << 24);
> +
> + /* Check special case for Get DIB command */
> + if (dib == 0x00) {
> + dev_dbg(&adapter->dev, "DIB read as 0x00\n");
> + return -1;
> + }
> +
> + if (!rc) {

You should change this to:

if (rc) {
dev_dbg(&adapter->dev, "Error reading DIB, rc : %d\n", rc);
return rc;
}

And then leave the happy path below unindented.

> + /**
> +  * setting up the supporting commands based on minor rev#
> +  * see PECI Spec Table 3-1
> +  */
> + dib = (dib >> 8) & 0xF;
> +
> + if (dib >= 0x1) {
> + adapter->cmd_mask |= BIT(PECI_CMD_RD_PKG_CFG);
> + adapter->cmd_mask |= BIT(PECI_CMD_WR_PKG_CFG);
> + }
> +
> + if (dib >= 0x2)
> + adapter->cmd_mask |= BI

Re: [PATCH v2] scsi: sd: Keep disk read-only when re-reading partition

[Martin K. Petersen]

Jeremy,

> Sorry about this, but there's a bug in the first version of this patch.
> I'm not sure what the protocol is for sending revised patches when the
> earlier version got accepted, but I don't see the first version in
> 4.16/scsi-fixes yet.

It's your lucky day! I botched fixing up something the other day and as
a result the tree was never pushed.

v2 added to 4.16/scsi-fixes.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 7/7] RCU, workqueue: Implement rcu_work

[Lai Jiangshan]

On Wed, Mar 7, 2018 at 1:33 AM, Tejun Heo  wrote:

> +/**
> + * queue_rcu_work_on - queue work on specific CPU after a RCU grace period
> + * @cpu: CPU number to execute work on
> + * @wq: workqueue to use
> + * @rwork: work to queue

For many people, "RCU grace period" is clear enough, but not ALL.

So please make it a little more clear that it just queues work after
a *Normal* RCU grace period. it supports only one RCU variant.


> + *
> + * Return: %false if @work was already on a queue, %true otherwise.
> + */

I'm afraid this will be a hard-using API.

The user can't find a plan B when it returns false, especially when
the user expects the work must be called at least once again
after an RCU grace period.

And the error-prone part of it is that, like other queue_work() functions,
the return value of it is often ignored and makes the problem worse.

So, since workqueue.c provides this API, it should handle this
problem. For example, by calling call_rcu() again in this case, but
everything will be much more complex: a synchronization is needed
for "calling call_rcu() again" and allowing the work item called
twice after the last queue_rcu_work() is not workqueue style.

Some would argue that the delayed_work has the same problem
when the user expects the work must be called at least once again
after a period of time. But time interval is easy to detect, the user
can check the time and call the queue_delayed_work() again
when needed which is also a frequent design pattern. And
for rcu, it is hard to use this design pattern since it is hard
to detect (new) rcu grace period without using call_rcu().

I would not provide this API. it is not a NACK. I'm just trying
expressing my thinking about the API. I'd rather RCU be changed
and RCU callbacks are changed to be sleepable. But a complete
overhaul cleanup on the whole source tree for compatibility
is needed at first, an even more complex job.



> +bool queue_rcu_work_on(int cpu, struct workqueue_struct *wq,
> +  struct rcu_work *rwork)
> +{
> +   struct work_struct *work = &rwork->work;
> +
> +   if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) 
> {
> +   rwork->wq = wq;
> +   rwork->cpu = cpu;
> +   call_rcu(&rwork->rcu, rcu_work_rcufn);
> +   return true;
> +   }
> +
> +   return false;
> +}
> +EXPORT_SYMBOL(queue_rcu_work_on);
> +

Re: [PATCH 1/3] arm64: dts: msm8916: Add cpu cooling maps

[Viresh Kumar]

On Tue, Mar 6, 2018 at 8:13 PM, Rob Herring  wrote:
> On Tue, Mar 6, 2018 at 7:05 AM, Amit Kucheria  
> wrote:

>> model = "Qualcomm Technologies, Inc. MSM8916";
>> @@ -115,6 +116,10 @@
>> cpu-idle-states = <&CPU_SPC>;
>> clocks = <&apcs 0>;
>> operating-points-v2 = <&cpu_opp_table>;
>> +   /* cooling options */
>> +   cooling-min-level = <0>;
>> +   cooling-max-level = <7>;
>
> Viresh is working on removing these from the binding...

Yep, just drop all cooling-{min|max}-level lines from your code. That
is not used
anywhere by the kernel.

Re: [PATCH v2 1/2] perf sched: move thread::shortname to thread_runtime

[Namhyung Kim]

Hi,

On Tue, Mar 06, 2018 at 11:37:36AM +0800, changbin...@intel.com wrote:
> From: Changbin Du 
> 
> The thread::shortname only used by sched command, so move it
> to sched private structure.
> 
> Signed-off-by: Changbin Du 
> ---

[SNIP]
> diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
> index 40cfa36..14d44c3 100644
> --- a/tools/perf/util/thread.h
> +++ b/tools/perf/util/thread.h
> @@ -26,7 +26,6 @@ struct thread {
>   pid_t   ppid;
>   int cpu;
>   refcount_t  refcnt;
> - charshortname[3];
>   boolcomm_set;
>   int comm_len;
>   booldead; /* if set thread has exited */

I also suggest to move the 'dead' field to pack two bools.

Thanks,
Namhyung

[PATCH 2/2] dt-bindings: backlight: Add binding for RAVE SP backlight driver

[Andrey Smirnov]

Add Device Tree bindings for RAVE SP backlihgt drvier - an MFD cell of
parent RAVE SP driver (documented in
Documentation/devicetree/bindings/mfd/zii,rave-sp.txt).

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: linux-kernel@vger.kernel.org
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Aleksander Morgado 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 .../leds/backlight/zii,rave-sp-backlight.txt   | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt 
b/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt
new file mode 100644
index ..2eba8322fc28
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt
@@ -0,0 +1,23 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor Backlight Bindings
+
+RAVE SP backlight device is a "MFD cell" device corresponding to
+backlight functionality of RAVE Supervisory Processor. It is expected
+that its Device Tree node is specified as a child of the node
+corresponding to the parent RAVE SP device (as documented in
+Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
+
+Required properties:
+
+- compatible: Should be "zii,rave-sp-backlight"
+
+Example:
+
+   rave-sp {
+   compatible = "zii,rave-sp-rdu1";
+   current-speed = <38400>;
+
+   pwrbutton {
+   compatible = "zii,rave-sp-backlight";
+   };
+   }
+
-- 
2.14.3

[PATCH 1/2] backlight: Add RAVE SP backlight driver

[Andrey Smirnov]

This driver provides access to RAVE SP backlight control
functionality.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: linux-kernel@vger.kernel.org
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Aleksander Morgado 
Signed-off-by: Andrey Smirnov 
---
 drivers/video/backlight/Kconfig |  6 +++
 drivers/video/backlight/Makefile|  1 +
 drivers/video/backlight/rave-sp-backlight.c | 82 +
 include/linux/mfd/rave-sp.h |  1 +
 4 files changed, 90 insertions(+)
 create mode 100644 drivers/video/backlight/rave-sp-backlight.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 4e1d2ad50ba1..5d2d0d7e8100 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -467,6 +467,12 @@ config BACKLIGHT_ARCXCNN
  If you have an ARCxC family backlight say Y to enable
  the backlight driver.
 
+config BACKLIGHT_RAVE_SP
+   tristate "RAVE SP Backlight driver"
+   depends on RAVE_SP_CORE
+   help
+ Support for backlight control on RAVE SP device.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 5e28f01c8391..19da71d518bf 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT_TOSA)  += tosa_bl.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)   += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
 obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
+obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
diff --git a/drivers/video/backlight/rave-sp-backlight.c 
b/drivers/video/backlight/rave-sp-backlight.c
new file mode 100644
index ..62836ba561db
--- /dev/null
+++ b/drivers/video/backlight/rave-sp-backlight.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * LCD Backlight driver for RAVE SP
+ *
+ * Copyright (C) 2018 Zodiac Inflight Innovations
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineRAVE_SP_BACKLIGHT_LCD_ENBIT(7)
+
+static int rave_sp_backlight_update_status(struct backlight_device *bd)
+{
+   const struct backlight_properties *p = &bd->props;
+   const u8 intensity =
+   (p->power == FB_BLANK_UNBLANK) ? p->brightness : 0;
+   struct rave_sp *sp = dev_get_drvdata(&bd->dev);
+   u8 cmd[] = {
+   [0] = RAVE_SP_CMD_SET_BACKLIGHT,
+   [1] = 0,
+   [2] = intensity ? RAVE_SP_BACKLIGHT_LCD_EN | intensity : 0,
+   [3] = 0,
+   [4] = 0,
+   };
+
+   return rave_sp_exec(sp, cmd, sizeof(cmd), NULL, 0);
+}
+
+static const struct backlight_ops rave_sp_backlight_ops = {
+   .options= BL_CORE_SUSPENDRESUME,
+   .update_status  = rave_sp_backlight_update_status,
+};
+
+static struct backlight_properties rave_sp_backlight_props = {
+   .type   = BACKLIGHT_FIRMWARE,
+   .max_brightness = 100,
+   .brightness = 50,
+};
+
+static int rave_sp_backlight_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct backlight_device *bd;
+
+   bd = devm_backlight_device_register(dev, pdev->name, dev->parent,
+   dev_get_drvdata(dev->parent),
+   &rave_sp_backlight_ops,
+   &rave_sp_backlight_props);
+   if (IS_ERR(bd))
+   return PTR_ERR(bd);
+
+   backlight_update_status(bd);
+
+   return 0;
+}
+
+static const struct of_device_id rave_sp_backlight_of_match[] = {
+   { .compatible = "zii,rave-sp-backlight" },
+   {}
+};
+
+static struct platform_driver rave_sp_backlight_driver = {
+   .probe = rave_sp_backlight_probe,
+   .driver = {
+   .name = KBUILD_MODNAME,
+   .of_match_table = rave_sp_backlight_of_match,
+   },
+};
+module_platform_driver(rave_sp_backlight_driver);
+
+MODULE_DEVICE_TABLE(of, rave_sp_backlight_of_match);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Andrey Vostrikov ");
+MODULE_AUTHOR("Nikita Yushchenko ");
+MODULE_AUTHOR("Andrey Smirnov ");
+MODULE_DESCRIPTION("RAVE SP Backlight driver");
diff --git a/include/linux/mfd/rave-sp.h b/include/linux/mfd/rave-sp.h
index 796fb9794c9e..fe0ce7bc59cf 100644
--- a/include/linux/mfd/rave-sp.h
+++ b/include/linux/mfd/rave-sp.h
@@ -21,6 +21,7 @@ enum rave_sp_command {
RAVE_SP_CMD_STATUS  = 0xA0,
RAVE_SP_CMD_SW_WDT  = 0xA1,
RAVE_SP_CMD_PET_WDT = 0xA2,
+   RAVE_SP_CMD_SET_BACKLIGHT   = 0xA6,
RAVE_SP_CMD_RESET   = 0xA7,
RAVE_SP_CMD_RESET_REASON= 0xA8,
 
-- 
2.14.3

Re: [PATCH v2 0/2] perf sched map: re-annotate shortname if thread comm changed

[Du, Changbin]

On Tue, Mar 06, 2018 at 11:17:07AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 06, 2018 at 08:53:02AM +0100, Jiri Olsa escreveu:
> > On Tue, Mar 06, 2018 at 11:37:35AM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du 
> > > 
> > > v2:
> > >   o add a patch to move thread::shortname to thread_runtime
> > >   o add function perf_sched__process_comm() to process PERF_RECORD_COMM 
> > > event.
> > > 
> > > Changbin Du (2):
> > >   perf sched: move thread::shortname to thread_runtime
> > >   perf sched map: re-annotate shortname if thread comm changed
> > 
> > Acked-by: Jiri Olsa 
> 
> Thanks, applied both, the final layout for 'struct thread_runtime':
> 
> [root@jouet perf]# pahole -C thread_runtime ~/bin/perf
> struct thread_runtime {
>   u64last_time;/* 0 8 */
>   u64dt_run;   /* 8 8 */
>   u64dt_sleep; /*16 8 */
>   u64dt_iowait;/*24 8 */
>   u64dt_preempt;   /*32 8 */
>   u64dt_delay; /*40 8 */
>   u64ready_to_run; /*48 8 */
>   struct stats   run_stats;/*5640 */
>   /* --- cacheline 1 boundary (64 bytes) was 32 bytes ago --- */
>   u64total_run_time;   /*96 8 */
>   u64total_sleep_time; /*   104 8 */
>   u64total_iowait_time;/*   112 8 */
>   u64total_preempt_time;   /*   120 8 */
>   /* --- cacheline 2 boundary (128 bytes) --- */
>   u64total_delay_time; /*   128 8 */
>   intlast_state;   /*   136 4 */
>   char   shortname[3]; /*   140 3 */
>   _Bool  comm_changed; /*   143 1 */
>   u64migrations;   /*   144 8 */
> 
>   /* size: 152, cachelines: 3, members: 17 */
>   /* last cacheline: 24 bytes */
> };
> [root@jouet perf]#

Hi Arnaldo, thanks for your patient optimization for this!

-- 
Thanks,
Changbin Du

Re: [PATCH v2] selftests: futex Makefile add top level TAP header echo to RUN_TESTS

[Shuah Khan]

On 03/05/2018 05:18 PM, Darren Hart wrote:
> On Thu, Mar 01, 2018 at 01:19:07PM -0700, Shuah Khan wrote:
>> Add top level TAP header echo, testname and separator line to make
>> the output consistent with the common run_tests target.
>>
>> This change prevents nested TAP13 headers output from individual tests.
>> Nested TAP13 headers could cause problems for some parsers.
>>
>> Signed-off-by: Shuah Khan 
> 
> 
> Reviewed-by: Darren Hart (VMware) 
> 
> 

Thanks. Queued this up with the rest for 4.17-rc1

-- Shuah

Re: [Question] printk_safe: Do you want synch./barriers in raw_spin_is_locked()

[Sergey Senozhatsky]

Hello,

I'll Cc linux-kernel

On (03/06/18 17:21), Steven Rostedt wrote:
> On Tue, 6 Mar 2018 15:58:46 +0100
> Andrea Parri  wrote:
> 
> > Dear PRINTK maintainers,
> > 
> > Following a recent discussion on LKML[1], I started auditing callsites
> > of spin_is_locked() and the "implicit" assumptions these sites made on
> > the memory ordering enforced by this primitive (not a first attempt[2],
> > FWIW).  As it turns out, this primitive is mostly used (40+ calls) for
> > debugging purposes (WARN_ON(!spin_is_locked()) or such), but the calls
> > to raw_spin_is_locked() in printk_safe seem to escape this usage.
> > 
> > Which assumptions are you relying on (if any) for raw_spin_is_locked()
> > enforced memory ordering?
> 
> We don't care about other CPUs. The use case here is to make sure that
> the printk in an NMI does not take the lock when the current CPU has
> it. Memory ordering is fine when dealing with only one CPU. If other
> CPUs mess with the result, then the worse that will happen is that we
> go to the "safe" mode when we didn't have to.

Right, thanks Steven.

A side note,
I think the only reason we have that raw_spin_is_locked() is because we
call console drivers in printk-safe mode, so we don't have a 1:1 mapping:

printk-safe == raw_spin_is_locked(logbuf)

I sort of think we can stop calling console drivers in printk-safe,
there seems to be no real reasons to do so (kind of). And then we will
have that missing printk-safe == raw_spin_is_locked(logbuf) so we will
be able to drop raw_spin_is_locked() from printk-safe and make logbuf
spin_lock static again.

> BTW, next time when asking a question, don't do it off list. This may
> be something others would like to know. I usually don't answer
> questions like this when they don't include a Cc to a mailing list.

Agreed.

-ss

Re: [PATCH v2 01/11] kbuild: define PYTHON2 and PYTHON3 variables instead of PYTHON

[Masahiro Yamada]

2018-03-07 2:16 GMT+09:00 Tony Luck :
> On Thu, Mar 1, 2018 at 8:31 PM, Masahiro Yamada
>  wrote:
>> arch/ia64/scripts/unwcheck.py is apparently written in Python 2, so
>> it should be invoked by 'python2'.
>
> I pushed the patch from Corentin Labbe to update this script to run with 
> either
> python2 or python3. Linus took it yesterday:
>
> bd5edbe67794 ("ia64: convert unwcheck.py to python3")
>
> -Tony

Thanks for the reminder!

Yeah, I noticed this commit yesterday.
Now, unwcheck.py seems to be compatible
with both Python 2.x and 3.x
(I have not tested it, but I understood so from the
commit log.)

I will keep 'PYTHON' and arch/ia64/Makefile as they are.

I will just add 'PYTHON2' and 'PYTHON3'.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] dump_stack: convert generic dump_stack into a weak symbol

[Sergey Senozhatsky]

Hello Arnd,

On (03/06/18 14:27), Arnd Bergmann wrote:
[..]
> As we are now removing blackfin, based on the latest discussion, this
> part should no longer be necessary.

When is this going to happen? 4.17?

[..]
> nds32 currently only exists in linux-next, not in the mainline kernel.
> If it's the only architecture that does something different from everyone
> else, I think we should change nds32.
> 
> I looked at the nds32 show_stack() implementation now and it
> seems to me that it is completely unnecessary, as the implementation
> from lib/dump_stack.c does basically the same thing (by calling
> show_stack(NULL, NULL)).

Interesting point. I'll leave it to nds32 maintainers.
OTOH blackfin is still in linux-next, so I assume we need
that __weak dump_stack() for the time being.

[..]
> > +asmlinkage __weak __visible void dump_stack(void)
> >  {
> > __dump_stack();
> >  }
> 
> Weak symbols are generally discouraged in the kernel. We have
> them in a couple of places, but I find them rather confusing as they
> make it harder to figure out what is actually going on.

Honestly, I kind of find __weak less confusing than EXPORT_SYMBOL(dump_stack)
in 3 different places. __weak hints that the symbol likely will be overridden
somewhere, while EXPORT_SYMBOL() does not (at least not to me). Dunno.

-ss

Re: C tricks for efficient stack zeroing

[Julia Cartwright]

On Fri, Mar 02, 2018 at 08:50:17PM +0100, Jason A. Donenfeld wrote:
[..]
> What would be really nice would be to somehow keep track of the
> maximum stack depth, and just before the function returns, clear from
> the maximum depth to its stack base, all in one single call. This
> would not only make the code faster and less brittle, but it would
> also clean up some algorithms quite a bit.
> 
> Ideally this would take the form of a gcc attribute on the function,
> but I was unable to find anything of that nature. I started looking
> for little C tricks for this, and came up dry too. I realize I could
> probably just take the current stack address and zero out until _the
> very end_ but that seems to overshoot and would probably be bad for
> performance. The best I've been able to do come up with are some
> x86-specific macros, but that approach seems a bit underwhelming.
> Other approaches include adding a new attribute via the gcc plugin
> system, which could make this kind of thing more complete [cc'ing
> pipacs in case he's thought about that before].

Can objtool support a static stack usage analysis?

I'm wondering if it's possible to place these sensitive functions in a
special linker section, like .text.stackzero.; objtool could
collect static call data (as it already does) and stack usage, spitting
out a symbol definition stackzero__max_depth, which you could then
use to bound your zeroing.

Obviously this is a static analysis, with the limitations therein.

   Julia

Re: [PATCH V4] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert

[Martin K. Petersen]

Jianchao,

> In scsi core, __scsi_queue_insert should just put request back on
> the queue and retry using the same command as before. However, for
> blk-mq, scsi_mq_requeue_cmd is employed here which will unprepare
> the request. To align with the semantics of __scsi_queue_insert,
> use blk_mq_requeue_request with kick_requeue_list == true and put
> the reference of scsi_device.

Applied to 4.17/scsi-queue, thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 4.4 06/34] sget(): handle failures of register_shrinker()

[Ben Hutchings]

On Fri, 2018-03-02 at 09:51 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Al Viro 
> 
> 
> [ Upstream commit 9ee332d99e4d5a97548943b81c54668450ce641b ]
> 
> Signed-off-by: Al Viro 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  fs/super.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -497,7 +497,11 @@ retry:
>   hlist_add_head(&s->s_instances, &type->fs_supers);
>   spin_unlock(&sb_lock);
>   get_filesystem(type);
> - register_shrinker(&s->s_shrink);
> + err = register_shrinker(&s->s_shrink);
> + if (err) {
> + deactivate_locked_super(s);

But deactivate_locked_super() will call unregister_shrinker(), which
doesn't look safe if register_shrinker() failed.

Ben.

> + s = ERR_PTR(err);
> + }
>   return s;
>  }
>  
> 
> 
> 
-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

[Sergey Senozhatsky]

Hello,

On (03/06/18 20:59), Benjamin Warnke wrote:
>Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
>compresses each page individually. As a result the compression algorithm
>is
>forced to use a very small sliding window. None of the available
>compression
>algorithms is designed to achieve high compression ratios with small
>inputs.

I think you first need to merge zBeWalgo (looks like a long way to go)
And then add ZRAM support, as a separate patch.

>- 'ecoham' (100 MiB) This dataset is one of the input files for the
>scientific
>application ECOHAM which runs an ocean simulation. This dataset contains a
>lot of zeros. Where the data is not zero there are arrays of floating
>point
>values, adjacent float values are likely to be similar to each other,
>allowing for high compression ratios.
> 
>algorithm | ratio   | compression    | decompression
>zbewalgo  |   12.94 |  294.10 MBit/s | 1242.59 MBit/s
>deflate   |   12.54 |   75.51 MBit/s |  736.39 MBit/s
>842   |   12.26 |  182.59 MBit/s |  683.61 MBit/s
>lz4hc |   12.00 |   51.23 MBit/s | 1524.73 MBit/s
>lz4   |   10.68 | 1334.37 MBit/s | 1603.54 MBit/s
>lzo   |    9.79 | 1333.76 MBit/s | 1534.63 MBit/s
> 
>- 'source-code' (800 MiB) This dataset is a tarball of the source-code
>from a
>linux-kernel.
> 
>algorithm | ratio   | compression    | decompression
>deflate   |    3.27 |   42.48 MBit/s |  250.36 MBit/s
>lz4hc |    2.40 |  104.14 MBit/s | 1150.53 MBit/s
>lzo   |    2.27 |  444.77 MBit/s |  886.97 MBit/s
>lz4   |    2.18 |  453.08 MBit/s | 1101.45 MBit/s
>842   |    1.65 |   64.10 MBit/s |  158.40 MBit/s
>zbewalgo  |    1.19 |   52.89 MBit/s |  197.58 MBit/s
> 
>- 'hpcg' (8 GiB) This dataset is a (partial) memory-snapshot of the
>running hpcg-benchmark. At the time of the snapshot, that application
>performed a sparse matrix - vector multiplication.
> 
>algorithm | ratio   | compression    | decompression
>zbewalgo  |   16.16 |  179.97 MBit/s |  468.36 MBit/s
>deflate   |    9.52 |   65.11 MBit/s |  632.69 MBit/s
>lz4hc |    4.96 |  193.33 MBit/s | 1607.12 MBit/s
>842   |    4.20 |  150.99 MBit/s |  316.22 MBit/s
>lzo   |    4.14 |  922.74 MBit/s |  865.32 MBit/s
>lz4   |    3.79 |  908.39 MBit/s | 1375.33 MBit/s
> 
>- 'partdiff' (8 GiB) Array of double values. Adjacent doubles are similar,
>but
>not equal. This array is produced by a partial differential equation
>solver
>using a Jakobi-implementation.
> 
>algorithm | ratio   | compression    | decompression
>zbewalgo  |    1.30 |  203.30 MBit/s |  530.87 MBit/s
>deflate   |    1.02 |   37.06 MBit/s | 1131.88 MBit/s
>lzo   |    1.00 | 1741.46 MBit/s | 2012.78 MBit/s
>lz4   |    1.00 | 1458.08 MBit/s | 2013.88 MBit/s
>lz4hc |    1.00 |  173.19 MBit/s | 2012.37 MBit/s
>842   |    1.00 |   64.10 MBit/s | 2013.64 MBit/s

Hm, mixed feelings.

-ss

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

Hi Rob and Andrzej,

On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
> Hi Rob, Chanwoo, Krzysztof,
> 
> 
> On 27.02.2018 08:11, Andrzej Hajda wrote:
>> Hi,
>>
>> Thanks for reviews of previous iterations.
>>
>> This patchset introduces USB physical connector bindings, together with
>> working example.
>> I have removed RFC prefix - the patchset seems to be heading
>> to a happy end :)
>>
>> v5: fixed extra parenthesis in dts, renamed extcon function.
>> v4: improved binding descriptions, added missing reg in dts.
>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>> example.
>> v2: I have addressed comments by Rob and Laurent, thanks 
>>
>> Changes in datail are described in the patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (5):
>>   dt-bindings: add bindings for USB physical connector
>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>   extcon: add possibility to get extcon device by OF node
>>
>> Maciej Purski (1):
>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
> 
> It looks like all patches received R-B or acks (I forgot add Krzysztof's
> acks for dts part).
> Now I have a question how to merge them.
> The only functional dependency is between bridge and extcon, and from
> the formal PoV bindings should be merged 1st.
> I can merge it:
> 1. All patches via drm-misc tree.
> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
> samsung-soc tree.
> 
> Is it OK, for all? Better ideas?

Krzysztof picked the dts patches. I'll make the immutable branch based on 
v4.16-rc1
and apply them except for dts patchs. And I'll send the immutable branch to Rob 
and Andrzej.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH v3 1/2] input: Add RAVE SP Powerbutton driver

[Andrey Smirnov]

Add driver that properly handles input event emitted by RAVE SP
devices.

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: Guenter Roeck 
Cc: Chris Healy 
Cc: Lucas Stach 
Reviewed-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---

Changes since [v2]:

- Collected Reviewed-by from Lucas

Changes since [v1]:

- Removed redundant dev.parent assignment

- Various cosmetic changes

[v2] lkml.kernel.org/r/20180301165527.22274-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20180226154130.25774-1-andrew.smir...@gmail.com

 drivers/input/misc/Kconfig |  9 
 drivers/input/misc/Makefile|  1 +
 drivers/input/misc/rave-sp-pwrbutton.c | 94 ++
 3 files changed, 104 insertions(+)
 create mode 100644 drivers/input/misc/rave-sp-pwrbutton.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 62a1312a7387..6a3c753b093b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -841,4 +841,13 @@ config INPUT_HISI_POWERKEY
  To compile this driver as a module, choose M here: the
  module will be called hisi_powerkey.
 
+config INPUT_RAVE_SP_PWRBUTTON
+   tristate "RAVE SP Power button Driver"
+   depends on RAVE_SP_CORE
+   help
+ Say Y here if you want to enable power key reporting from RAVE SP
+
+ To compile this driver as a module, choose M here: the
+ module will be called rave-sp-pwrbutton.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a8f61af865aa..8cc58f362bb8 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
 obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
 obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
 obj-$(CONFIG_INPUT_PWM_VIBRA)  += pwm-vibra.o
+obj-$(CONFIG_INPUT_RAVE_SP_PWRBUTTON)  += rave-sp-pwrbutton.o
 obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
 obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
 obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
diff --git a/drivers/input/misc/rave-sp-pwrbutton.c 
b/drivers/input/misc/rave-sp-pwrbutton.c
new file mode 100644
index ..bcab3cdb7ebd
--- /dev/null
+++ b/drivers/input/misc/rave-sp-pwrbutton.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Power Button driver for RAVE SP
+//
+// Copyright (C) 2017 Zodiac Inflight Innovations
+//
+//
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RAVE_SP_EVNT_BUTTON_PRESS  (RAVE_SP_EVNT_BASE + 0x00)
+
+struct rave_sp_power_button {
+   struct input_dev *idev;
+   struct notifier_block nb;
+};
+
+static int rave_sp_power_button_event(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+   struct rave_sp_power_button *pb =
+   container_of(nb, struct rave_sp_power_button, nb);
+   const u8 event = rave_sp_action_unpack_event(action);
+   const u8 value = rave_sp_action_unpack_value(action);
+   struct input_dev *idev = pb->idev;
+
+   if (event == RAVE_SP_EVNT_BUTTON_PRESS) {
+   input_report_key(idev, KEY_POWER, value);
+   input_sync(idev);
+
+   return NOTIFY_STOP;
+   }
+
+   return NOTIFY_DONE;
+}
+
+static int rave_sp_pwrbutton_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct rave_sp_power_button *pb;
+   struct input_dev *idev;
+   int error;
+
+   pb = devm_kzalloc(dev, sizeof(*pb), GFP_KERNEL);
+   if (!pb)
+   return -ENOMEM;
+
+   idev = devm_input_allocate_device(dev);
+   if (!idev)
+   return -ENOMEM;
+
+   idev->name = pdev->name;
+
+   input_set_capability(idev, EV_KEY, KEY_POWER);
+
+   error = input_register_device(idev);
+   if (error)
+   return error;
+
+   pb->idev = idev;
+   pb->nb.notifier_call = rave_sp_power_button_event;
+   pb->nb.priority = 128;
+
+   error = devm_rave_sp_register_event_notifier(dev, &pb->nb);
+   if (error)
+   return error;
+
+   return 0;
+}
+
+static const struct of_device_id rave_sp_pwrbutton_of_match[] = {
+   { .compatible = "zii,rave-sp-pwrbutton" },
+   {}
+};
+
+static struct platform_driver rave_sp_pwrbutton_driver = {
+   .probe = rave_sp_pwrbutton_probe,
+   .driver = {
+   .name = KBUILD_MODNAME,
+   .of_match_table = rave_sp_pwrbutton_of_match,
+   },
+};
+module_platform_driver(rave_sp_pwrbutton_driver);
+
+MODULE_DEVICE_TABLE(of, rave_sp_pwrbutton_of_match);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Andrey Vostrikov ");
+MODULE_AUTHOR("Nikita Yushchenko ");
+MODULE_AUTHOR("Andrey Smirnov ");
+MODULE_DESCRIPTION("RAVE

Re: [RFC PATCH 1/2] riscv/spinlock: Strengthen implementations with fences

[Palmer Dabbelt]

On Mon, 05 Mar 2018 10:24:09 PST (-0800), parri.and...@gmail.com wrote:

Current implementations map locking operations using .rl and .aq
annotations.  However, this mapping is unsound w.r.t. the kernel
memory consistency model (LKMM) [1]:

Referring to the "unlock-lock-read-ordering" test reported below,
Daniel wrote:

  "I think an RCpc interpretation of .aq and .rl would in fact
   allow the two normal loads in P1 to be reordered [...]

   The intuition would be that the amoswap.w.aq can forward from
   the amoswap.w.rl while that's still in the store buffer, and
   then the lw x3,0(x4) can also perform while the amoswap.w.rl
   is still in the store buffer, all before the l1 x1,0(x2)
   executes.  That's not forbidden unless the amoswaps are RCsc,
   unless I'm missing something.

   Likewise even if the unlock()/lock() is between two stores.
   A control dependency might originate from the load part of
   the amoswap.w.aq, but there still would have to be something
   to ensure that this load part in fact performs after the store
   part of the amoswap.w.rl performs globally, and that's not
   automatic under RCpc."

Simulation of the RISC-V memory consistency model confirmed this
expectation.

In order to "synchronize" LKMM and RISC-V's implementation, this
commit strengthens the implementations of the locking operations
by replacing .rl and .aq with the use of ("lightweigth") fences,
resp., "fence rw,  w" and "fence r , rw".

C unlock-lock-read-ordering

{}
/* s initially owned by P1 */

P0(int *x, int *y)
{
WRITE_ONCE(*x, 1);
smp_wmb();
WRITE_ONCE(*y, 1);
}

P1(int *x, int *y, spinlock_t *s)
{
int r0;
int r1;

r0 = READ_ONCE(*y);
spin_unlock(s);
spin_lock(s);
r1 = READ_ONCE(*x);
}

exists (1:r0=1 /\ 1:r1=0)

[1] https://marc.info/?l=linux-kernel&m=151930201102853&w=2

https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/hKywNHBkAXM
https://marc.info/?l=linux-kernel&m=151633436614259&w=2

Signed-off-by: Andrea Parri 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Daniel Lustig 
Cc: Alan Stern 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: Boqun Feng 
Cc: Nicholas Piggin 
Cc: David Howells 
Cc: Jade Alglave 
Cc: Luc Maranget 
Cc: "Paul E. McKenney" 
Cc: Akira Yokosawa 
Cc: Ingo Molnar 
Cc: Linus Torvalds 
Cc: linux-ri...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/riscv/include/asm/fence.h| 12 
 arch/riscv/include/asm/spinlock.h | 29 +++--
 2 files changed, 27 insertions(+), 14 deletions(-)
 create mode 100644 arch/riscv/include/asm/fence.h


Oh, sorry about this -- I thought I'd deleted all this code, but I guess I just 
wrote a patch and then forgot about it.  Here's my original patch, which I have 
marked as a WIP:


commit 39908f1f8b75ae88ce44dc77b8219a94078ad298
Author: Palmer Dabbelt 
Date:   Tue Dec 5 16:26:50 2017 -0800

   RISC-V: Use generic spin and rw locks

   This might not be exactly the right thing to do: we could use LR/SC to
   produce slightly better locks by rolling the tests into the LR/SC.  I'm
   going to defer that until I get a better handle on the new memory model
   and just be safe here: after some discussion I'm pretty sure the AMOs
   are good, and cmpxchg is safe (by being way too string).

   Since we'd want to rewrite the spinlocks anyway so they queue, I don't
   see any reason to keep the old implementations around.

   Signed-off-by: Palmer Dabbelt 

diff --git a/arch/riscv/include/asm/spinlock.h 
b/arch/riscv/include/asm/spinlock.h
index 2fd27e8ef1fd..9b166ea81fe5 100644
--- a/arch/riscv/include/asm/spinlock.h
+++ b/arch/riscv/include/asm/spinlock.h
@@ -15,128 +15,7 @@
#ifndef _ASM_RISCV_SPINLOCK_H
#define _ASM_RISCV_SPINLOCK_H

-#include 
-#include 
-
-/*
- * Simple spin lock operations.  These provide no fairness guarantees.
- */
-
-/* FIXME: Replace this with a ticket lock, like MIPS. */
-
-#define arch_spin_is_locked(x) (READ_ONCE((x)->lock) != 0)
-
-static inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
-   __asm__ __volatile__ (
-   "amoswap.w.rl x0, x0, %0"
-   : "=A" (lock->lock)
-   :: "memory");
-}
-
-static inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
-   int tmp = 1, busy;
-
-   __asm__ __volatile__ (
-   "amoswap.w.aq %0, %2, %1"
-   : "=r" (busy), "+A" (lock->lock)
-   : "r" (tmp)
-   : "memory");
-
-   return !busy;
-}
-
-static inline void arch_spin_lock(arch_spinlock_t *lock)
-{
-   while (1) {
-   if (arch_spin_is_locked(lock))
-   continue;
-
-   if (arch_spin_trylock(lock))
-   break;
-   }
-}
-
-/***/
-
-static inline void arch_read_lock(arch_rwlock_t *lock)
-{
-   int tmp;
-
-   __asm__ __volatile__(
-   "1:lr.w%1, %0\n"
-  

[PATCH v3 2/2] dt-bindings: input: Add binding for RAVE SP input driver

[Andrey Smirnov]

Add Device Tree bindings for RAVE SP input drvier - an MFD cell of
parent RAVE SP driver (documented in
Documentation/devicetree/bindings/mfd/zii,rave-sp.txt).

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: Guenter Roeck 
Cc: Chris Healy 
Cc: Lucas Stach 
Acked-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---

Changes since [v2]:

- Collected Acked-by from Lucas

- Removed unnecessary status="okay"

No changes between v1 and v2, so v1 is not referenced here.

[v2] lkml.kernel.org/r/20180301165527.22274-2-andrew.smir...@gmail.com

 .../bindings/input/zii,rave-sp-pwrbutton.txt   | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt

diff --git a/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt 
b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
new file mode 100644
index ..b217018d03e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
@@ -0,0 +1,23 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor Power Button Bindings
+
+RAVE SP input device is a "MFD cell" device corresponding to power
+button functionality of RAVE Supervisory Processor. It is expected
+that its Device Tree node is specified as a child of the node
+corresponding to the parent RAVE SP device (as documented in
+Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
+
+Required properties:
+
+- compatible: Should be "zii,rave-sp-pwrbutton"
+
+Example:
+
+   rave-sp {
+   compatible = "zii,rave-sp-rdu1";
+   current-speed = <38400>;
+
+   pwrbutton {
+   compatible = "zii,rave-sp-pwrbutton";
+   };
+   }
+
-- 
2.14.3

Re: ftrace: Proposal for an Alternative RecordMcount framework

[Steven Rostedt]

On Wed, 7 Mar 2018 09:47:47 +0800
Alan Kao  wrote:


> > Please allow me to state the problem more clearly here.  I hope this helps.
> > 
> > 1. locations of mcount are recorded in a per-file basis.
> > 2. to optimize the binary, the linker turns on some aggressive
> >options, including relaxation.
> > 3. the optimizations changes the original offset.
> > 4. already recorded mcount call-sites no longer point to their
> >real positions.
> > 5. still a linked vmlinux is made.
> > 6. dynamic ftrace breaks the real logic in the kernel space,
> >panics happen.
> > 
> > Thanks,
> > Alan  
> 
> Any comments on this?

Sorry, I've been traveling and falling behind in this. I did read this
when I was offline but forgot to reply when I was back online.

> 
> BTW, the introduced framework has no effects on any other architectures that
> works fine.  This feature should be configurable and turned on only when the
> arch has aggressive link-time optimizations.
> 
> If you consider this appropriate, I will send the patch to this once it gets 
> ready.  Currently this is targeting at RISC-V and upcoming NDS32.

I see the issue you explained above and it makes sense. Perhaps make it
an option that can be enabled by anyone, and archs that require
aggressive link time optimizations would just select it.

-- Steve

Re: [PATCH] ubi: Reject MLC NAND

[David Oberhollenzer]

On 03/07/2018 12:18 AM, Pavel Machek wrote:
> Now... Yes, handling flash is hard, MLC NAND is worst of the
> bunch. But...
> 
MLC is not just more flimsy than SLC NAND.

The real problem is that on MLC NAND, pages come in pairs.

Multiple voltage levels inside a single, physical memory cell are used to
encode more than one bit. Instead of just having pages that are twice as big,
the flash exposes them as *two different pages*. Those pages are usually not
ordered sequentially either, but according to a vendor/device specific
pairing scheme.


> Read disturb is not unique to MLC, right? Happens to all the flashes,
> its just that MLC has tighter margins for error.
> 
You don't just have more read disturb on a single page. Reading one page
will also affect the paired page as well.[0]

In addition to that, you also have program disturb. Even *writing successfully*
to the upper page of a pair also causes bit flips on the lower one, affecting
completely different data.[0]

This could be addressed using the experimental ubihealthd that crawls the flash
from time to time (at UBI level), making UBI notice and fix bit flips.[0]


> Power-cut. UBIFS is just not power-cut safe, right? My notes say that
> power-cut during erase could result in flash that contains all 1s, but
> will start showing errors very quickly. Again, not MLC specific. Can
> be solved with battery...
> 
> (And yes, there are some problems specific to MLC, where parts of page
> need to be written in specific order. Not sure how it affects
> ubifs. But it was not listed as a reason for the patch.)
> 

Both UBI and UBIFS were designed to be power cut tolerant.[1]

On MLC however, if you interrupt a write access to the upper page of a pair,
you will also corrupt the lower one, i.e. *data that was already written*,
which is a serious issue.[0]


Richard and Boris did spend a lot of time working on a solution for that at
UBI level which would currently still require a lot of testing and fine
tuning, but sadly we ran out of budget.

The proposed patch tries to prevent further bad surprises for people who try
to use UBI and UBIFS on top of MLC by making sure that UBI _refuses_ to run
on MLC (at least for now).


Regards,

David

[0] http://linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc
[1] http://linux-mtd.infradead.org/doc/ubifs.html#L_powercut



signature.asc
Description: OpenPGP digital signature

Re: Regression in IPMI on 4.15.6

[Corey Minyard]

On 03/06/2018 05:54 PM, Laura Abbott wrote:

On 03/06/2018 09:19 AM, Corey Minyard wrote:

On 03/06/2018 11:17 AM, Laura Abbott wrote:

On 03/05/2018 11:39 AM, Corey Minyard wrote:

On 03/05/2018 01:31 PM, Corey Minyard wrote:

On 03/05/2018 01:07 PM, Laura Abbott wrote:

On 03/02/2018 05:46 AM, Corey Minyard wrote:

On 02/28/2018 01:07 PM, Corey Minyard wrote:

On 02/28/2018 08:17 AM, Corey Minyard wrote:

On 02/28/2018 07:53 AM, Corey Minyard wrote:

On 02/27/2018 05:55 PM, Laura Abbott wrote:

Hi,

Fedora got a bug report of a crash in IPMI on 4.15.6
https://bugzilla.redhat.com/show_bug.cgi?id=1549316
Unfortunately, it's only a screenshot but it's fairly
clear. It looks like a panic in the error handling path
in platform_device_unregister. Any ideas?





You may also run into another issue.  You can pull the
individual patch at

https://github.com/cminyard/linux-ipmi.git 
c8a1972e77dbe321ce5ce0247056e727234cbaec


Actually, it needed a few more tweaks.  Can you do change
426fa6179dae677134dfb37b21d057819418515b
instead?  It's "ipmi: Fix some error cleanup issues"

I can send you patches, if you like.  If you could test and get 
back

to me, that would be great.


Laura, have you had a chance to test this?  I'd like to get it 
in soon,

if possible.

Thanks,

-corey



I think "ipmi: Re-use existing macros for built-in properties" is 
broken:




That particular requires some new stuff.  I was just wanting you 
to pull that individual patch,

not the whole branch.  I can just send the two patches, if you like.


Or, I just pulled in 4.15.6 and cherry picked those two patches to:

https://github.com/cminyard/linux-ipmi.git fix-pdev-unreg

Hopefully that makes things easier.

-corey



Yes, the reporter said it worked fine.



It would be helpful to me to have a "Tested-by" line.  Can I put one in?
If so, whose name/email do I use?

Thanks for testing.

-corey



You can use the reporter and tester:

Tested-by: Bill Perkins 


Thanks a bunch, Laura.  I have it queued for 4.17, and
backport to 4.15 and 4.16.  If you need it sooner, I can
send it to Linus now.

-corey

Re: [PATCH v2 2/2] dt-bindings: input: Add binding for RAVE SP input driver

[Andrey Smirnov]

On Tue, Mar 6, 2018 at 6:17 AM, Fabio Estevam  wrote:
> Hi Andrey,
>
> On Thu, Mar 1, 2018 at 1:55 PM, Andrey Smirnov  
> wrote:
> l
>> +++ b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
>> @@ -0,0 +1,24 @@
>> +Zodiac Inflight Innovations RAVE Supervisory Processor Power Button Bindings
>> +
>> +RAVE SP input device is a "MFD cell" device corresponding to power
>> +button functionality of RAVE Supervisory Processor. It is expected
>> +that its Device Tree node is specified as a child of the node
>> +corresponding to the parent RAVE SP device (as documented in
>> +Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "zii,rave-sp-pwrbutton"
>> +
>> +Example:
>> +
>> +   rave-sp {
>> +   compatible = "zii,rave-sp-rdu1";
>> +   current-speed = <38400>;
>> +
>> +   pwrbutton {
>> +   compatible = "zii,rave-sp-pwrbutton";
>> +   status = "okay";
>
> In the dts patch review Shawn said:
>
> "The okay status is to flip the state of devices that are initially
> disabled.  I think it's unnecessary for the case here."
>
> so please remove the status line.

Sure, will do in v3.

Thanks,
Andrey Smirnov

Re: ftrace: Proposal for an Alternative RecordMcount framework

[Alan Kao]

On Thu, Mar 01, 2018 at 10:05:07AM +0800, Alan Kao wrote:
> On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote:
> > On Tue, 27 Feb 2018 18:04:26 +0800
> > Alan Kao  wrote:
> >  
> > > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2]
> > 
> > Note, doing it at that stage takes the longest time. It makes small
> > changes much longer to compile. That said...
> >
> 
> What if we can have some option to *disable* all the recordmcount.pl lauches
> after every .o?  There will be only an oneshot grep for a near-complete
> vmlinux binary.
> 
> > > 2. Form the output as an ELF objecj
> > > 3. Link the object to __mcount_loc_start symbol
> > > 4. Done
> > > 
> > > With the similar reason as the patch [3], we should mark _mcount to be
> > > a weak symbol to prevent it from being relaxed later.
> > > 
> > > We would like to know your opinion and comments on this.
> > > Thanks!
> > 
> > What about just having your arch use recordmcount.c instead? It doesn't
> > do any grepping. It is an elf reader and modifier and modifies the .o
> > file directly.
> 
> Thanks for the hint.  But after a quick scan, it seems that recordmcount.c
> processes .o files in a per-file basis, which means that we will still
> suffer from the linker relaxation problem.
> 
> > 
> > Note, I will be rewriting that code in the near future too, to
> > consolidate it with objtool.
> > 
> > -- Steve
> 
> Please allow me to state the problem more clearly here.  I hope this helps.
> 
> 1. locations of mcount are recorded in a per-file basis.
> 2. to optimize the binary, the linker turns on some aggressive
>options, including relaxation.
> 3. the optimizations changes the original offset.
> 4. already recorded mcount call-sites no longer point to their
>real positions.
> 5. still a linked vmlinux is made.
> 6. dynamic ftrace breaks the real logic in the kernel space,
>panics happen.
> 
> Thanks,
> Alan

Any comments on this?

BTW, the introduced framework has no effects on any other architectures that
works fine.  This feature should be configurable and turned on only when the
arch has aggressive link-time optimizations.

If you consider this appropriate, I will send the patch to this once it gets 
ready.  Currently this is targeting at RISC-V and upcoming NDS32.

Thanks,
Alan

[PATCH] staging: most: Remove unnecessary usage of BUG_ON().

[Quytelda Kahja]

There is no need for the calls to BUG_ON() in this driver, which are
used to check if mbo or mbo->context are NULL; mbo is never NULL, and
if mbo->context is NULL it would have already been dereferenced and
oopsed before reaching the BUG_ON().

Signed-off-by: Quytelda Kahja 
---
 drivers/staging/most/core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c
index 0ab2de5ecf18..3afc25a61643 100644
--- a/drivers/staging/most/core.c
+++ b/drivers/staging/most/core.c
@@ -915,7 +915,6 @@ static void arm_mbo(struct mbo *mbo)
unsigned long flags;
struct most_channel *c;
 
-   BUG_ON((!mbo) || (!mbo->context));
c = mbo->context;
 
if (c->is_poisoned) {
@@ -1018,8 +1017,6 @@ static void most_write_completion(struct mbo *mbo)
 {
struct most_channel *c;
 
-   BUG_ON((!mbo) || (!mbo->context));
-
c = mbo->context;
if (mbo->status == MBO_E_INVAL)
pr_info("WARN: Tx MBO status: invalid\n");
-- 
2.16.2

Re: dm-bufio: avoid false-positive Wmaybe-uninitialized warning

[Mike Snitzer]

On Tue, Mar 06 2018 at  4:33pm -0500,
Arnd Bergmann  wrote:

> On Thu, Feb 22, 2018 at 5:04 PM, Mike Snitzer  wrote:
> > On Thu, Feb 22 2018 at 10:56am -0500,
> > Arnd Bergmann  wrote:
> 
> >
> > Mikulas already sent a fix for this:
> > https://patchwork.kernel.org/patch/10211631/
> >
> > But I like yours a bit better, though I'll likely move the declaration
> > of 'noio_flag' temporary inside the conditional.
> >
> > Anyway, I'll get this fixed up shortly, thanks.
> 
> I see the fix made it into linux-next on the same day, but the build bots 
> still
> report the warning for mainline kernels and now also for stable kernels
> that got a backport of the patch that introduced it on arm64.
> 
> I assume you had not planned to send it for mainline, any chance you
> could change that and send it as a bugfix with a 'Cc:
> sta...@vger.kernel.org' tag to restore a clean build?

I did/do plan to send to Linus this week.

But I've updated the commit header to include the CC: stable like you
asked.

Thanks,
Mike

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

[Andy Lutomirski]

On Tue, Mar 6, 2018 at 11:06 PM, Mickaël Salaün  wrote:
>
> On 06/03/2018 23:46, Tycho Andersen wrote:
>> On Tue, Mar 06, 2018 at 10:33:17PM +, Andy Lutomirski wrote:
> Suppose I'm writing a container manager.  I want to run "mount" in the
> container, but I don't want to allow moun() in general and I want to
> emulate certain mount() actions.  I can write a filter that catches
> mount using seccomp and calls out to the container manager for help.
> This isn't theoretical -- Tycho wants *exactly* this use case to be
> supported.

 Well, I think this use case should be handled with something like
 LD_PRELOAD and a helper library. FYI, I did something like this:
 https://github.com/stemjail/stemshim
>>>
>>> I doubt that will work for containers.  Containers that use user
>>> namespaces and, for example, setuid programs aren't going to honor
>>> LD_PRELOAD.
>>
>> Or anything that calls syscalls directly, like go programs.
>
> That's why the vDSO-like approach. Enforcing an access control is not
> the issue here, patching a buggy userland (without patching its code) is
> the issue isn't it?
>
> As far as I remember, the main problem is to handle file descriptors
> while "emulating" the kernel behavior. This can be done with a "shim"
> code mapped in every processes. Chrome used something like this (in a
> previous sandbox mechanism) as a kind of emulation (with the current
> seccomp-bpf ). I think it should be doable to replace the (userland)
> emulation code with an IPC wrapper receiving file descriptors through
> UNIX socket.
>

Can you explain exactly what you mean by "vDSO-like"?

When a 64-bit program does a syscall, it just executes the SYSCALL
instruction.  The vDSO isn't involved at all.  32-bit programs usually
go through the vDSO, but not always.

It could be possible to force-load a DSO into an entire container and
rig up seccomp to intercept all SYSCALLs not originating from the DSO
such that they merely redirect control to the DSO, but that seems
quite messy.