Re: Linux 4.4.151

[Greg KH]

diff --git a/Makefile b/Makefile
index 7789195c6a59..04199cf99dd5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 150
+SUBLEVEL = 151
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4de6c282c02a..68a55273ce0f 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -173,6 +173,11 @@ static inline unsigned long pud_pfn(pud_t pud)
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+   return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)  pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)
@@ -578,8 +583,7 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pmd_page(pmd)  \
-   pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd)  pfn_to_page(pmd_pfn(pmd))
 
 /*
  * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -647,8 +651,7 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pud_page(pud)  \
-   pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
 
 /* Find an entry in the second-level page table.. */
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -688,7 +691,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pgd_page(pgd)  pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd)  pfn_to_page(pgd_pfn(pgd))
 
 /* to find an entry in a page-table-directory. */
 static inline unsigned long pud_index(unsigned long address)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index e3322adaaae0..4f07029de209 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -124,6 +124,12 @@ void __init acpi_nvs_nosave_s3(void)
nvs_nosave_s3 = true;
 }
 
+static int __init init_nvs_save_s3(const struct dmi_system_id *d)
+{
+   nvs_nosave_s3 = false;
+   return 0;
+}
+
 /*
  * ACPI 1.0 wants us to execute _PTS before suspending devices, so we allow the
  * user to request that behavior by using the 'acpi_old_suspend_ordering'
@@ -318,6 +324,27 @@ static struct dmi_system_id acpisleep_dmi_table[] 
__initdata = {
DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"),
},
},
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Asus 1025C",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1025C"),
+   },
+   },
+   /*
+* https://bugzilla.kernel.org/show_bug.cgi?id=189431
+* Lenovo G50-45 is a platform later than 2012, but needs nvs memory
+* saving during S3.
+*/
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Lenovo G50-45",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "80E3"),
+   },
+   },
{},
 };
 
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index e4c43a17b333..8088c34336aa 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1655,13 +1655,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
-   if (arg) {
-   if (copy_to_user(argp, &dev, sizeof(ulong)))
-   return -EFAULT;
-   return 0;
-   } else
-   return -EINVAL;
-   break;
+   return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & 
ISDN_DRVIOCTL_MASK;
diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 8435c3f204c1..a30d68c4b689 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -224,7 +224,7 @@ static void dw8250_set_termios(struct uart_port *p, struct 
ktermios *termios,
unsigned int rate;
int ret;
 
-   if (IS_ERR(d->clk) || !old)
+   if (IS_ERR(d->clk))
goto out;
 
clk_disable_unprepare(d->clk);
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
in

Linux 4.4.151

[Greg KH]

I'm announcing the release of the 4.4.151 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 +-
 arch/x86/include/asm/pgtable.h  |   13 -
 drivers/acpi/sleep.c|   27 +++
 drivers/isdn/i4l/isdn_common.c  |8 +---
 drivers/tty/serial/8250/8250_dw.c   |2 +-
 drivers/usb/serial/option.c |4 
 drivers/usb/serial/sierra.c |4 ++--
 include/net/af_vsock.h  |4 ++--
 include/net/llc.h   |5 +
 net/bluetooth/sco.c |3 ++-
 net/dccp/ccids/ccid2.c  |6 --
 net/l2tp/l2tp_core.c|2 +-
 net/llc/llc_core.c  |4 ++--
 net/sched/cls_tcindex.c |8 +++-
 net/vmw_vsock/af_vsock.c|   15 ---
 net/vmw_vsock/vmci_transport.c  |3 +--
 sound/core/memalloc.c   |8 ++--
 sound/core/seq/seq_virmidi.c|   10 ++
 sound/pci/cs5535audio/cs5535audio.h |6 +++---
 sound/pci/cs5535audio/cs5535audio_pcm.c |4 ++--
 sound/pci/hda/hda_intel.c   |2 +-
 sound/pci/hda/patch_conexant.c  |4 +++-
 sound/pci/vx222/vx222_ops.c |8 
 sound/pcmcia/vx/vxp_ops.c   |   10 +-
 24 files changed, 102 insertions(+), 60 deletions(-)

Aleksander Morgado (1):
  USB: option: add support for DW5821e

Alexey Kodanev (1):
  dccp: fix undefined behavior with 'cwnd' shift in ccid2_cwnd_restart()

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Cong Wang (2):
  llc: use refcount_inc_not_zero() for llc_sap_find()
  vsock: split dwork to avoid reinitializations

Greg Kroah-Hartman (1):
  Linux 4.4.151

Hangbin Liu (2):
  net_sched: Fix missing res info when create new tc_index filter
  net_sched: fix NULL pointer dereference when delete tcindex filter

Hans de Goede (1):
  ALSA: hda: Correct Asrock B85M-ITX power_save blacklist entry

John Ogness (1):
  USB: serial: sierra: fix potential deadlock at close

Kees Cook (1):
  isdn: Disable IIOCDBGVAR

Park Ju Hyung (2):
  ALSA: hda - Sleep for 10ms after entering D3 on Conexant codecs
  ALSA: hda - Turn CX8200 into D3 as well upon reboot

Sudip Mukherjee (1):
  Bluetooth: avoid killing an already killed socket

Takashi Iwai (5):
  ALSA: vx222: Fix invalid endian conversions
  ALSA: virmidi: Fix too long output trigger loop
  ALSA: cs5535audio: Fix invalid endian conversion
  ALSA: memalloc: Don't exceed over the requested size
  ALSA: vxpocket: Fix invalid endian conversions

Tom Lendacky (1):
  x86/mm: Simplify p[g4um]d_page() macros

Wei Wang (1):
  l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache

Willy Tarreau (1):
  ACPI / PM: save NVS memory for ASUS 1025C laptop

Zhang Rui (1):
  ACPI: save NVS memory for Lenovo G50-45



signature.asc
Description: PGP signature

Re: Linux 4.9.123

[Greg KH]

diff --git a/Makefile b/Makefile
index 1f44343a1e04..b11e375bb18e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 122
+SUBLEVEL = 123
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 5008be1ab183..c535012bdb56 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -190,6 +190,11 @@ static inline unsigned long pud_pfn(pud_t pud)
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+   return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)  pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)
@@ -621,8 +626,7 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pmd_page(pmd)  \
-   pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd)  pfn_to_page(pmd_pfn(pmd))
 
 /*
  * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -690,8 +694,7 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pud_page(pud)  \
-   pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
 
 /* Find an entry in the second-level page table.. */
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -731,7 +734,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pgd_page(pgd)  pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd)  pfn_to_page(pgd_pfn(pgd))
 
 /* to find an entry in a page-table-directory. */
 static inline unsigned long pud_index(unsigned long address)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 097d630ab886..f0633169c35b 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -330,6 +330,14 @@ static struct dmi_system_id acpisleep_dmi_table[] 
__initdata = {
DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"),
},
},
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Asus 1025C",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1025C"),
+   },
+   },
/*
 * https://bugzilla.kernel.org/show_bug.cgi?id=189431
 * Lenovo G50-45 is a platform later than 2012, but needs nvs memory
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index e4c43a17b333..8088c34336aa 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1655,13 +1655,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
-   if (arg) {
-   if (copy_to_user(argp, &dev, sizeof(ulong)))
-   return -EFAULT;
-   return 0;
-   } else
-   return -EINVAL;
-   break;
+   return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & 
ISDN_DRVIOCTL_MASK;
diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 3eb01a719d22..3177264a1166 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -235,7 +235,7 @@ static void dw8250_set_termios(struct uart_port *p, struct 
ktermios *termios,
unsigned int rate;
int ret;
 
-   if (IS_ERR(d->clk) || !old)
+   if (IS_ERR(d->clk))
goto out;
 
clk_disable_unprepare(d->clk);
@@ -626,6 +626,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+   { "BRCM2032", 0 },
{ "HISI0031", 0 },
{ },
 };
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 5d9038a5bbc4..5b54439a8a9b 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -83,8 +83,7 @@ static const struct serial8250_config uart_config[] = {
.name   = "16550A",
.fifo_size  = 16,
.tx_loadsz  = 16,
-   .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
- UAR

Re: Linux 4.14.66

[Greg KH]

diff --git a/Makefile b/Makefile
index 7995690ff1aa..e69d0d091742 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 65
+SUBLEVEL = 66
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 2ef0ad6a33d6..7a0af16f86f2 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -338,6 +338,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"),
},
},
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Asus 1025C",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1025C"),
+   },
+   },
/*
 * https://bugzilla.kernel.org/show_bug.cgi?id=189431
 * Lenovo G50-45 is a platform later than 2012, but needs nvs memory
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 38a5bb764c7b..598724ffde4e 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1640,13 +1640,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
-   if (arg) {
-   if (copy_to_user(argp, &dev, sizeof(ulong)))
-   return -EFAULT;
-   return 0;
-   } else
-   return -EINVAL;
-   break;
+   return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & 
ISDN_DRVIOCTL_MASK;
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index fc0415771c00..4dd0d868ff88 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -407,13 +407,20 @@ static int sram_probe(struct platform_device *pdev)
if (init_func) {
ret = init_func();
if (ret)
-   return ret;
+   goto err_disable_clk;
}
 
dev_dbg(sram->dev, "SRAM pool: %zu KiB @ 0x%p\n",
gen_pool_size(sram->pool) / 1024, sram->virt_base);
 
return 0;
+
+err_disable_clk:
+   if (sram->clk)
+   clk_disable_unprepare(sram->clk);
+   sram_free_partitions(sram);
+
+   return ret;
 }
 
 static int sram_remove(struct platform_device *pdev)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
index 36fddb199160..f4b3554b0b67 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
@@ -752,7 +752,7 @@ static int hw_atl_b0_hw_packet_filter_set(struct aq_hw_s 
*self,
 
rpfl2promiscuous_mode_en_set(self, IS_FILTER_ENABLED(IFF_PROMISC));
rpfl2multicast_flr_en_set(self,
- IS_FILTER_ENABLED(IFF_MULTICAST), 0);
+ IS_FILTER_ENABLED(IFF_ALLMULTI), 0);
 
rpfl2_accept_all_mc_packets_set(self,
IS_FILTER_ENABLED(IFF_ALLMULTI));
diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 3015789265dd..27c5b2b46b8d 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -260,7 +260,7 @@ static void dw8250_set_termios(struct uart_port *p, struct 
ktermios *termios,
long rate;
int ret;
 
-   if (IS_ERR(d->clk) || !old)
+   if (IS_ERR(d->clk))
goto out;
 
clk_disable_unprepare(d->clk);
@@ -672,6 +672,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+   { "BRCM2032", 0 },
{ "HISI0031", 0 },
{ },
 };
diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index e0aa5f03004c..411b4b03457b 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -436,7 +436,11 @@ static irqreturn_t exar_misc_handler(int irq, void *data)
struct exar8250 *priv = data;
 
/* Clear all PCI interrupts by reading INT0. No effect on IIR */
-   ioread8(priv->virt + UART_EXAR_INT0);
+   readb(priv->virt + UART_EXAR_INT0);
+
+   /* Clear INT0 for Expansion Interface slave ports, too */
+   if (priv->board->num_ports > 8)
+   readb(priv->virt + 0x2000 + UART_EXAR_INT0);
 
return IRQ_HANDLED;
 }
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index be456ea27ab2..ecf3d631bc09 100644
--- a/drivers/tty/serial/8250/8250_port.c

Re: [PATCH] selftests: net: move fragment forwarding/config up a level

[Ido Schimmel]

On Tue, Aug 21, 2018 at 01:41:54PM -0600, Shuah Khan wrote:
> On 08/21/2018 12:56 PM, Ido Schimmel wrote:
> > On Tue, Aug 21, 2018 at 06:12:12PM +0200, Anders Roxell wrote:
> >> 'make kselftest-merge' assumes that the config files for the tests are
> >> located under the 'main' tet dir, like tools/testing/selftests/net/ and
> >> not in a subdir to net.
> > 
> > The tests under tools/testing/selftests/net/forwarding/ aren't executed
> > as part of the Makefile. The config file is there mainly so that people
> > will know which config options they need in order to run the tests.
> > 
> > The tests can be added to the Makefile, but some of them take a few
> > minutes to complete which is probably against "Don't take too long;"
> > mentioned in Documentation/dev-tools/kselftest.rst.
> > 
> 
> I don't see any reason why these shouldn't be added. With the number of
> tests that get run by default, time has gone up. The goal is to run more
> tests not less. There are some stress/destructive tests that continue to
> be left out of the Makefile.

Thanks for clarifying. I'll add the tests.

Linux 4.17.18

[Greg KH]

I'm announcing the release of the 4.17.18 kernel.

All users of the 4.17 kernel series must upgrade.

The updated 4.17.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.17.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 drivers/acpi/sleep.c|8 
 drivers/isdn/i4l/isdn_common.c  |8 
 drivers/misc/sram.c |9 
 drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c   |2 
 drivers/net/ethernet/marvell/mvneta.c   |   53 ++--
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |8 
 drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c |   51 ++-
 drivers/net/ethernet/realtek/r8169.c|   12 
 drivers/tty/serial/8250/8250_dw.c   |3 
 drivers/tty/serial/8250/8250_exar.c |6 
 drivers/tty/serial/8250/8250_port.c |3 
 drivers/usb/serial/option.c |4 
 drivers/usb/serial/pl2303.c |2 
 drivers/usb/serial/pl2303.h |1 
 drivers/usb/serial/sierra.c |4 
 drivers/vhost/vhost.c   |9 
 include/net/af_vsock.h  |4 
 include/net/llc.h   |5 
 net/bluetooth/sco.c |3 
 net/core/sock_diag.c|2 
 net/dccp/ccids/ccid2.c  |6 
 net/ipv4/ip_vti.c   |3 
 net/ipv6/ip6_tunnel.c   |8 
 net/l2tp/l2tp_core.c|2 
 net/llc/llc_core.c  |4 
 net/rxrpc/ar-internal.h |8 
 net/rxrpc/conn_event.c  |4 
 net/rxrpc/net_ns.c  |6 
 net/rxrpc/output.c  |   12 
 net/rxrpc/peer_event.c  |  156 ++--
 net/rxrpc/peer_object.c |8 
 net/rxrpc/rxkad.c   |4 
 net/sched/cls_matchall.c|2 
 net/sched/cls_tcindex.c |8 
 net/socket.c|3 
 net/vmw_vsock/af_vsock.c|   15 -
 net/vmw_vsock/vmci_transport.c  |3 
 sound/core/memalloc.c   |8 
 sound/core/seq/oss/seq_oss.c|2 
 sound/core/seq/seq_clientmgr.c  |2 
 sound/core/seq/seq_virmidi.c|   10 
 sound/pci/cs5535audio/cs5535audio.h |6 
 sound/pci/cs5535audio/cs5535audio_pcm.c |4 
 sound/pci/hda/hda_intel.c   |2 
 sound/pci/hda/patch_conexant.c  |4 
 sound/pci/vx222/vx222_ops.c |8 
 sound/pcmcia/vx/vxp_ops.c   |   10 
 48 files changed, 295 insertions(+), 212 deletions(-)

Aaron Sierra (1):
  serial: 8250_exar: Read INT0 from slave device, too

Aleksander Morgado (1):
  USB: option: add support for DW5821e

Alexey Kodanev (1):
  dccp: fix undefined behavior with 'cwnd' shift in ccid2_cwnd_restart()

Andrew Lunn (1):
  net: ethernet: mvneta: Fix napi structure mixup on armada 3700

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Cong Wang (2):
  llc: use refcount_inc_not_zero() for llc_sap_find()
  vsock: split dwork to avoid reinitializations

David Howells (1):
  rxrpc: Fix the keepalive generator [ver #2]

Dmitry Bogdanov (1):
  net: aquantia: Fix IFF_ALLMULTI flag functionality

Greg Kroah-Hartman (1):
  Linux 4.17.18

Haishuang Yan (1):
  ip_vti: fix a null pointer deferrence when create vti fallback tunnel

Hangbin Liu (3):
  net_sched: fix NULL pointer dereference when delete tcindex filter
  net_sched: Fix missing res info when create new tc_index filter
  cls_matchall: fix tcf_unbind_filter missing

Hans de Goede (1):
  ALSA: hda: Correct Asrock B85M-ITX power_save blacklist entry

Heiner Kallweit (1):
  r8169: don't use MSI-X on RTL8168g

Jaso

Linux 4.9.123

[Greg KH]

I'm announcing the release of the 4.9.123 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 +-
 arch/x86/include/asm/pgtable.h  |   13 -
 drivers/acpi/sleep.c|8 
 drivers/isdn/i4l/isdn_common.c  |8 +---
 drivers/tty/serial/8250/8250_dw.c   |3 ++-
 drivers/tty/serial/8250/8250_port.c |3 +--
 drivers/usb/serial/option.c |4 
 drivers/usb/serial/sierra.c |4 ++--
 include/net/af_vsock.h  |4 ++--
 include/net/llc.h   |5 +
 net/bluetooth/sco.c |3 ++-
 net/dccp/ccids/ccid2.c  |6 --
 net/ipv6/ip6_tunnel.c   |8 ++--
 net/l2tp/l2tp_core.c|2 +-
 net/llc/llc_core.c  |4 ++--
 net/sched/cls_matchall.c|2 ++
 net/sched/cls_tcindex.c |8 +++-
 net/vmw_vsock/af_vsock.c|   15 ---
 net/vmw_vsock/vmci_transport.c  |3 +--
 sound/core/memalloc.c   |8 ++--
 sound/core/seq/seq_virmidi.c|   10 ++
 sound/pci/cs5535audio/cs5535audio.h |6 +++---
 sound/pci/cs5535audio/cs5535audio_pcm.c |4 ++--
 sound/pci/hda/hda_intel.c   |2 +-
 sound/pci/hda/patch_conexant.c  |4 +++-
 sound/pci/vx222/vx222_ops.c |8 
 sound/pcmcia/vx/vxp_ops.c   |   10 +-
 27 files changed, 89 insertions(+), 68 deletions(-)

Aleksander Morgado (1):
  USB: option: add support for DW5821e

Alexey Kodanev (1):
  dccp: fix undefined behavior with 'cwnd' shift in ccid2_cwnd_restart()

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Cong Wang (2):
  llc: use refcount_inc_not_zero() for llc_sap_find()
  vsock: split dwork to avoid reinitializations

Greg Kroah-Hartman (1):
  Linux 4.9.123

Hangbin Liu (3):
  net_sched: Fix missing res info when create new tc_index filter
  net_sched: fix NULL pointer dereference when delete tcindex filter
  cls_matchall: fix tcf_unbind_filter missing

Hans de Goede (1):
  ALSA: hda: Correct Asrock B85M-ITX power_save blacklist entry

John Ogness (1):
  USB: serial: sierra: fix potential deadlock at close

Kees Cook (1):
  isdn: Disable IIOCDBGVAR

Mark (1):
  tty: serial: 8250: Revert NXP SC16C2552 workaround

Park Ju Hyung (2):
  ALSA: hda - Sleep for 10ms after entering D3 on Conexant codecs
  ALSA: hda - Turn CX8200 into D3 as well upon reboot

Srinath Mannam (1):
  serial: 8250_dw: Add ACPI support for uart on Broadcom SoC

Sudip Mukherjee (1):
  Bluetooth: avoid killing an already killed socket

Takashi Iwai (5):
  ALSA: vx222: Fix invalid endian conversions
  ALSA: virmidi: Fix too long output trigger loop
  ALSA: cs5535audio: Fix invalid endian conversion
  ALSA: memalloc: Don't exceed over the requested size
  ALSA: vxpocket: Fix invalid endian conversions

Tom Lendacky (1):
  x86/mm: Simplify p[g4um]d_page() macros

Wei Wang (1):
  l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache

Willy Tarreau (1):
  ACPI / PM: save NVS memory for ASUS 1025C laptop

Xin Long (1):
  ip6_tunnel: use the right value for ipv4 min mtu check in ip6_tnl_xmit



signature.asc
Description: PGP signature

Linux 4.14.66

[Greg KH]

I'm announcing the release of the 4.14.66 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 -
 drivers/acpi/sleep.c  |8 +++
 drivers/isdn/i4l/isdn_common.c|8 ---
 drivers/misc/sram.c   |9 +++-
 drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c |2 -
 drivers/tty/serial/8250/8250_dw.c |3 +-
 drivers/tty/serial/8250/8250_exar.c   |6 -
 drivers/tty/serial/8250/8250_port.c   |3 --
 drivers/usb/serial/option.c   |4 +++
 drivers/usb/serial/pl2303.c   |2 +
 drivers/usb/serial/pl2303.h   |1 
 drivers/usb/serial/sierra.c   |4 +--
 drivers/vhost/vhost.c |9 +---
 include/net/af_vsock.h|4 +--
 include/net/llc.h |5 
 net/bluetooth/sco.c   |3 +-
 net/dccp/ccids/ccid2.c|6 +++--
 net/ipv6/ip6_tunnel.c |8 +--
 net/l2tp/l2tp_core.c  |2 -
 net/llc/llc_core.c|4 +--
 net/sched/cls_matchall.c  |2 +
 net/sched/cls_tcindex.c   |8 ++-
 net/vmw_vsock/af_vsock.c  |   15 +++---
 net/vmw_vsock/vmci_transport.c|3 --
 sound/core/memalloc.c |8 +--
 sound/core/seq/seq_virmidi.c  |   10 +
 sound/pci/cs5535audio/cs5535audio.h   |6 ++---
 sound/pci/cs5535audio/cs5535audio_pcm.c   |4 +--
 sound/pci/hda/hda_intel.c |2 -
 sound/pci/hda/patch_conexant.c|4 ++-
 sound/pci/vx222/vx222_ops.c   |8 +++
 sound/pcmcia/vx/vxp_ops.c |   10 -
 32 files changed, 104 insertions(+), 69 deletions(-)

Aaron Sierra (1):
  serial: 8250_exar: Read INT0 from slave device, too

Aleksander Morgado (1):
  USB: option: add support for DW5821e

Alexey Kodanev (1):
  dccp: fix undefined behavior with 'cwnd' shift in ccid2_cwnd_restart()

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Cong Wang (2):
  llc: use refcount_inc_not_zero() for llc_sap_find()
  vsock: split dwork to avoid reinitializations

Dmitry Bogdanov (1):
  net: aquantia: Fix IFF_ALLMULTI flag functionality

Greg Kroah-Hartman (1):
  Linux 4.14.66

Hangbin Liu (3):
  net_sched: fix NULL pointer dereference when delete tcindex filter
  net_sched: Fix missing res info when create new tc_index filter
  cls_matchall: fix tcf_unbind_filter missing

Hans de Goede (1):
  ALSA: hda: Correct Asrock B85M-ITX power_save blacklist entry

Jason Wang (1):
  vhost: reset metadata cache when initializing new IOTLB

Johan Hovold (1):
  misc: sram: fix resource leaks in probe error path

John Ogness (1):
  USB: serial: sierra: fix potential deadlock at close

Kees Cook (1):
  isdn: Disable IIOCDBGVAR

Mark (1):
  tty: serial: 8250: Revert NXP SC16C2552 workaround

Movie Song (1):
  USB: serial: pl2303: add a new device id for ATEN

Park Ju Hyung (2):
  ALSA: hda - Sleep for 10ms after entering D3 on Conexant codecs
  ALSA: hda - Turn CX8200 into D3 as well upon reboot

Srinath Mannam (1):
  serial: 8250_dw: Add ACPI support for uart on Broadcom SoC

Sudip Mukherjee (1):
  Bluetooth: avoid killing an already killed socket

Takashi Iwai (5):
  ALSA: vx222: Fix invalid endian conversions
  ALSA: virmidi: Fix too long output trigger loop
  ALSA: cs5535audio: Fix invalid endian conversion
  ALSA: memalloc: Don't exceed over the requested size
  ALSA: vxpocket: Fix invalid endian conversions

Wei Wang (1):
  l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache

Willy Tarreau (1):
  ACPI / PM: save NVS memory for ASUS 1025C laptop

Xin Long (1):
  ip6_tunnel: use the right value for ipv4 min mtu check in ip6_tnl_xmit



signature.asc
Description: PGP signature

Re: Linux 4.17.18

[Greg KH]

diff --git a/Makefile b/Makefile
index 5ff2040cf3ee..429a1fe0b40b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 17
-SUBLEVEL = 17
+SUBLEVEL = 18
 EXTRAVERSION =
 NAME = Merciless Moray
 
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 974e58457697..af54d7bbb173 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -338,6 +338,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"),
},
},
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Asus 1025C",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1025C"),
+   },
+   },
/*
 * https://bugzilla.kernel.org/show_bug.cgi?id=189431
 * Lenovo G50-45 is a platform later than 2012, but needs nvs memory
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 7c6f3f5d9d9a..66ac7fa6e034 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1640,13 +1640,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
-   if (arg) {
-   if (copy_to_user(argp, &dev, sizeof(ulong)))
-   return -EFAULT;
-   return 0;
-   } else
-   return -EINVAL;
-   break;
+   return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & 
ISDN_DRVIOCTL_MASK;
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index fc0415771c00..4dd0d868ff88 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -407,13 +407,20 @@ static int sram_probe(struct platform_device *pdev)
if (init_func) {
ret = init_func();
if (ret)
-   return ret;
+   goto err_disable_clk;
}
 
dev_dbg(sram->dev, "SRAM pool: %zu KiB @ 0x%p\n",
gen_pool_size(sram->pool) / 1024, sram->virt_base);
 
return 0;
+
+err_disable_clk:
+   if (sram->clk)
+   clk_disable_unprepare(sram->clk);
+   sram_free_partitions(sram);
+
+   return ret;
 }
 
 static int sram_remove(struct platform_device *pdev)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
index 956860a69797..3bdab972420b 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
@@ -762,7 +762,7 @@ static int hw_atl_b0_hw_packet_filter_set(struct aq_hw_s 
*self,
 
hw_atl_rpfl2promiscuous_mode_en_set(self, 
IS_FILTER_ENABLED(IFF_PROMISC));
hw_atl_rpfl2multicast_flr_en_set(self,
-IS_FILTER_ENABLED(IFF_MULTICAST), 0);
+IS_FILTER_ENABLED(IFF_ALLMULTI), 0);
 
hw_atl_rpfl2_accept_all_mc_packets_set(self,
   IS_FILTER_ENABLED(IFF_ALLMULTI));
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 0ad2f3f7da85..82ac1d10f239 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1901,10 +1901,10 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
 }
 
 /* Main rx processing when using software buffer management */
-static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
+static int mvneta_rx_swbm(struct napi_struct *napi,
+ struct mvneta_port *pp, int rx_todo,
  struct mvneta_rx_queue *rxq)
 {
-   struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports);
struct net_device *dev = pp->dev;
int rx_done;
u32 rcvd_pkts = 0;
@@ -1959,7 +1959,7 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int 
rx_todo,
 
skb->protocol = eth_type_trans(skb, dev);
mvneta_rx_csum(pp, rx_status, skb);
-   napi_gro_receive(&port->napi, skb);
+   napi_gro_receive(napi, skb);
 
rcvd_pkts++;
rcvd_bytes += rx_bytes;
@@ -2001,7 +2001,7 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int 
rx_todo,
 
mvneta_rx_csum(pp, rx_status, skb);
 
-   napi_gro_receive(&port->napi, skb);
+   napi_gro_receive(napi, skb);
}
 
if (rcvd_pkts) {
@@ -2020,10 +2020,10 @@ static int mvneta_rx_swbm(struct mvneta_port

Re: Linux 4.18.4

[Greg KH]

diff --git a/Makefile b/Makefile
index e2bd815f24eb..ef0dd566c104 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 18
-SUBLEVEL = 3
+SUBLEVEL = 4
 EXTRAVERSION =
 NAME = Merciless Moray
 
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 5d0486f1cfcd..1a1c0718cd7a 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -338,6 +338,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"),
},
},
+   {
+   .callback = init_nvs_save_s3,
+   .ident = "Asus 1025C",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1025C"),
+   },
+   },
/*
 * https://bugzilla.kernel.org/show_bug.cgi?id=189431
 * Lenovo G50-45 is a platform later than 2012, but needs nvs memory
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 7a501dbe7123..6a5b3f00f9ad 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1640,13 +1640,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
-   if (arg) {
-   if (copy_to_user(argp, &dev, sizeof(ulong)))
-   return -EFAULT;
-   return 0;
-   } else
-   return -EINVAL;
-   break;
+   return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & 
ISDN_DRVIOCTL_MASK;
diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c 
b/drivers/media/usb/dvb-usb-v2/gl861.c
index 9d154fdae45b..fee4b30df778 100644
--- a/drivers/media/usb/dvb-usb-v2/gl861.c
+++ b/drivers/media/usb/dvb-usb-v2/gl861.c
@@ -26,10 +26,14 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr,
if (wo) {
req = GL861_REQ_I2C_WRITE;
type = GL861_WRITE;
+   buf = kmemdup(wbuf, wlen, GFP_KERNEL);
} else { /* rw */
req = GL861_REQ_I2C_READ;
type = GL861_READ;
+   buf = kmalloc(rlen, GFP_KERNEL);
}
+   if (!buf)
+   return -ENOMEM;
 
switch (wlen) {
case 1:
@@ -42,24 +46,19 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr,
default:
dev_err(&d->udev->dev, "%s: wlen=%d, aborting\n",
KBUILD_MODNAME, wlen);
+   kfree(buf);
return -EINVAL;
}
-   buf = NULL;
-   if (rlen > 0) {
-   buf = kmalloc(rlen, GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
-   }
+
usleep_range(1000, 2000); /* avoid I2C errors */
 
ret = usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0), req, type,
  value, index, buf, rlen, 2000);
-   if (rlen > 0) {
-   if (ret > 0)
-   memcpy(rbuf, buf, rlen);
-   kfree(buf);
-   }
 
+   if (!wo && ret > 0)
+   memcpy(rbuf, buf, rlen);
+
+   kfree(buf);
return ret;
 }
 
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index c5dc6095686a..679647713e36 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -407,13 +407,20 @@ static int sram_probe(struct platform_device *pdev)
if (init_func) {
ret = init_func();
if (ret)
-   return ret;
+   goto err_disable_clk;
}
 
dev_dbg(sram->dev, "SRAM pool: %zu KiB @ 0x%p\n",
gen_pool_size(sram->pool) / 1024, sram->virt_base);
 
return 0;
+
+err_disable_clk:
+   if (sram->clk)
+   clk_disable_unprepare(sram->clk);
+   sram_free_partitions(sram);
+
+   return ret;
 }
 
 static int sram_remove(struct platform_device *pdev)
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 0ad2f3f7da85..82ac1d10f239 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1901,10 +1901,10 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
 }
 
 /* Main rx processing when using software buffer management */
-static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
+static int mvneta_rx_swbm(struct napi_struct *napi,
+ struct mvneta_port *pp, int rx_todo,
  struct mvneta_rx_queue *rxq)
 {
-   struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports);
struct net_device *dev = pp->dev;

Linux 4.18.4

[Greg KH]

I'm announcing the release of the 4.18.4 kernel.

All users of the 4.18 kernel series must upgrade.

The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 -
 drivers/acpi/sleep.c|8 
 drivers/isdn/i4l/isdn_common.c  |8 
 drivers/media/usb/dvb-usb-v2/gl861.c|   21 ++--
 drivers/misc/sram.c |9 -
 drivers/net/ethernet/marvell/mvneta.c   |   53 +++-
 drivers/net/ethernet/realtek/r8169.c|   12 ++-
 drivers/net/hyperv/rndis_filter.c   |2 -
 drivers/tty/serial/8250/8250_dw.c   |3 +
 drivers/tty/serial/8250/8250_exar.c |6 +++
 drivers/tty/serial/8250/8250_port.c |3 -
 drivers/uio/uio.c   |   10 +-
 drivers/usb/serial/option.c |4 ++
 drivers/usb/serial/pl2303.c |2 +
 drivers/usb/serial/pl2303.h |1 
 drivers/usb/serial/sierra.c |4 +-
 net/bluetooth/sco.c |3 +
 net/core/sock_diag.c|2 +
 net/ipv4/ip_vti.c   |3 +
 net/l2tp/l2tp_core.c|2 -
 net/sched/cls_matchall.c|2 +
 net/sched/cls_tcindex.c |8 +---
 net/socket.c|3 -
 sound/core/memalloc.c   |8 +---
 sound/core/seq/oss/seq_oss.c|2 -
 sound/core/seq/seq_clientmgr.c  |2 -
 sound/core/seq/seq_virmidi.c|   10 ++
 sound/firewire/dice/dice-alesis.c   |2 -
 sound/pci/cs5535audio/cs5535audio.h |6 +--
 sound/pci/cs5535audio/cs5535audio_pcm.c |4 +-
 sound/pci/hda/hda_intel.c   |2 -
 sound/pci/hda/patch_conexant.c  |4 +-
 sound/pci/vx222/vx222_ops.c |8 ++--
 sound/pcmcia/vx/vxp_ops.c   |   10 +++---
 34 files changed, 137 insertions(+), 92 deletions(-)

Aaron Sierra (1):
  serial: 8250_exar: Read INT0 from slave device, too

Aleksander Morgado (1):
  USB: option: add support for DW5821e

Andrew Lunn (1):
  net: ethernet: mvneta: Fix napi structure mixup on armada 3700

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Greg Kroah-Hartman (1):
  Linux 4.18.4

Hailong Liu (1):
  uio: fix wrong return value from uio_mmap()

Haishuang Yan (1):
  ip_vti: fix a null pointer deferrence when create vti fallback tunnel

Hangbin Liu (3):
  net_sched: fix NULL pointer dereference when delete tcindex filter
  net_sched: Fix missing res info when create new tc_index filter
  cls_matchall: fix tcf_unbind_filter missing

Hans de Goede (1):
  ALSA: hda: Correct Asrock B85M-ITX power_save blacklist entry

Heiner Kallweit (1):
  r8169: don't use MSI-X on RTL8168g

Jeremy Cline (1):
  net: sock_diag: Fix spectre v1 gadget in __sock_diag_cmd()

Jian-Hong Pan (1):
  r8169: don't use MSI-X on RTL8106e

Jisheng Zhang (1):
  net: mvneta: fix mvneta_config_rss on armada 3700

Johan Hovold (1):
  misc: sram: fix resource leaks in probe error path

John Ogness (1):
  USB: serial: sierra: fix potential deadlock at close

Kees Cook (1):
  isdn: Disable IIOCDBGVAR

Mark (1):
  tty: serial: 8250: Revert NXP SC16C2552 workaround

Mika Båtsman (1):
  media: gl861: fix probe of dvb_usb_gl861

Movie Song (1):
  USB: serial: pl2303: add a new device id for ATEN

Park Ju Hyung (2):
  ALSA: hda - Sleep for 10ms after entering D3 on Conexant codecs
  ALSA: hda - Turn CX8200 into D3 as well upon reboot

Srinath Mannam (1):
  serial: 8250_dw: Add ACPI support for uart on Broadcom SoC

Sudip Mukherjee (1):
  Bluetooth: avoid killing an already killed socket

Takashi Iwai (7):
  ALSA: vx222: Fix invalid endian conversions
  ALSA: virmidi: Fix too long output trigger loop
  ALSA: cs5535audio: Fix invalid endian conversion
  ALSA: memalloc: Don't exceed over the requested size
  ALSA: vxpocket: Fix invalid endian conversions
  ALSA: seq: Fix poll() error return
  hv/netvsc: Fix NULL dereference at single queue mode fallback

Takashi Sakamoto (1):
  ALSA: dice: fix wrong copy to rx parameters for Alesis iO26

Wei Wang (1):
  l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache

Willy Tarreau (1):
  ACPI / PM: save NVS memory for ASUS 1025C laptop

Xiubo Li (1):
  Revert "uio: use request_threaded_irq instead"



signature.asc
Description: PGP signature

Re: [PATCH v2] serial: mxs-auart: Fix potential infinite loop

[Uwe Kleine-König]

On Tue, Aug 07, 2018 at 01:59:05PM +0300, Anton Vasilyev wrote:
> On the error path of mxs_auart_request_gpio_irq() is performed
> backward iterating with index i of enum type. Underline enum type
> may be unsigned char. In this case check (--i >= 0) will be always
> true and error handling goes into infinite loop.
> 
> The patch changes the check so that it is valid for signed and unsigned
> types.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Anton Vasilyev 
> ---
> v2: mistype in patch as result of combination of different fixes.
> Change comment and leave enum type.
> ---
>  drivers/tty/serial/mxs-auart.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 76aa289652f7..27235a526cce 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1634,8 +1634,9 @@ static int mxs_auart_request_gpio_irq(struct 
> mxs_auart_port *s)
>  
>   /*
>* If something went wrong, rollback.
> +  * Be careful: i may be unsigned.
>*/
> - while (err && (--i >= 0))
> + while (err && (i-- > 0))
>   if (irq[i] >= 0)
>   free_irq(irq[i], s);

I wouldn't have added the comment, but the code change is correct.

Acked-by: Uwe Kleine-König 

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [RFC PATCH 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO

[Lothar Waßmann]

Michal Vokáč  wrote:

> Output of the PWM block of i.MX SoCs is always zero volts when the block
> is disabled. This can caue issues when inverted PWM polarity is needed.
> With inverted polarity a duty cycle = 0% corresponds to solid high level
> on the output. If the PWM is dissabled its output instantly goes to solid
> zero which corresponds to duty cycle = 100%.
> 
> To have a trully inverted PWM output configure the PWM pad as a GPIO
> with pull-up. Then switch the pad to PWM output whenever non-zero
> duty cycle is needed.
> 
> Signed-off-by: Michal Vokáč 
> ---
>  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 44 
> +++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> index c61bdf8..3b1bc4c 100644
> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> @@ -14,6 +14,12 @@ See the clock consumer binding,
>   Documentation/devicetree/bindings/clock/clock-bindings.txt
>  - interrupts: The interrupt for the pwm controller
>  
> +Optional properties:
> +- pinctrl: For i.MX27 and newer SoCs. Add extra pinctrl to configure the PWM
> +  pin to gpio function.  It allows control over the pin output level when the
> +  PWM block is disabled. This is meant to be used if inverted polarity of the
> +  PWM signal is required. See "Inverted PWM output" section bellow.
> +
>  Example:
>  
>  pwm1: pwm@53fb4000 {
> @@ -25,3 +31,41 @@ pwm1: pwm@53fb4000 {
>   clock-names = "ipg", "per";
>   interrupts = <61>;
>  };
> +
> +Inverted PWM output
> +---
> +
> +The i.MX SoC has such limitation that whenever a pad is configured as a PWM
> +output, the output level is always zero volts when the PWM block is disabled.
> +The zero output level is actively driven by the output stage of the PWM block
> +and can not be overridden by pull-up. It also does not matter what PWM 
> polarity
> +a PWM client (e.g. backlight) requested.
> +
> +To gain control of the PWM output level in disabled state two pinctrl states
> +can be used. The "default" state and the "pwm" state. In the default state 
> the
>
The "default" function of a PWM is to deliver a PWM signal. So it is
more sensible to me to have the PWM function as "default" and a "gpio"
function as alternative state.

> +PWM output is configured as a GPIO with pull-up. In the "pwm" state the 
> output
> +is configured as a PWM output. This setup assures that the PWM output is at
> +the required level that corresponds to duty cycle = 0 when PWM is disabled.
> +E.g. at boot.
> +
> +Example:
> +
> +&pwm1 {
> + pinctrl-names = "default", "pwm";
> + pinctrl-0 = <&pinctrl_backlight_gpio>;
> + pinctrl-1 = <&pinctrl_backlight_pwm>;
> +}
> +
> +pinctrl_backlight_gpio: pwm1grp-gpio {
> + fsl,pins = <
> + /* GPIO with 22kOhm pull-up */
> + MX6QDL_PAD_GPIO_9__GPIO1_IO09   0xF008
> + >;
> +};
> +
> +pinctrl_backlight_pwm: pwm1grp-pwm {
> + fsl,pins = <
> + /* PWM output */
> + MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8
> + >;
> +};



-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___

BUG: corrupted list in vmx_vcpu_load

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:0214f46b3a03 Merge branch 'siginfo-linus' of git://git.ker..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11bc9c2e40
kernel config:  https://syzkaller.appspot.com/x/.config?x=214e4990bd49329f
dashboard link: https://syzkaller.appspot.com/bug?extid=bba49d73fe3404646a7b
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

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

kvm [9433]: vcpu0, guest rIP: 0x20e disabled perfctr wrmsr: 0x187 data  
0x6000800
list_add corruption. next->prev should be prev (8801db01d130), but was  
dead0200. (next=8801947fdaa0).

[ cut here ]
kernel BUG at lib/list_debug.c:25!
invalid opcode:  [#1] SMP KASAN
CPU: 0 PID: 9519 Comm: syz-executor2 Not tainted 4.18.0+ #201
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__list_add_valid.cold.0+0xf/0x25 lib/list_debug.c:23
Code: e8 93 f5 5b fe e9 68 ff ff ff e8 89 f5 5b fe eb c9 4c 89 e7 e8 7f f5  
5b fe eb 97 48 89 d9 48 c7 c7 e0 9b 3a 87 e8 32 d8 03 fe <0f> 0b 48 89 f1  
48 c7 c7 a0 9c 3a 87 48 89 de e8 1e d8 03 fe 0f 0b

RSP: 0018:88018f9bf058 EFLAGS: 00010082
RAX: 0075 RBX: 8801947fdaa0 RCX: c9000200d000
RDX:  RSI: 8163a441 RDI: 0001
RBP: 88018f9bf070 R08: 880196e3a2c0 R09: ed003b605008
R10: ed003b605008 R11: 8801db028047 R12: 8801947fdaa0
R13: 8801947f8300 R14: 8801947fdaa0 R15: 8801db01d130
FS:  7ff35b75e700() GS:8801db00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fcb6c09b000 CR3: 0001ca309000 CR4: 001426f0
Call Trace:
 __list_add include/linux/list.h:60 [inline]
 list_add include/linux/list.h:79 [inline]
 vmx_vcpu_load+0x205/0xfe0 arch/x86/kvm/vmx.c:3061
 kvm_arch_vcpu_load+0x22b/0x940 arch/x86/kvm/x86.c:3106
 kvm_sched_in+0x82/0xa0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3970
 __fire_sched_in_preempt_notifiers kernel/sched/core.c:2481 [inline]
 fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
 finish_task_switch+0x50d/0x870 kernel/sched/core.c:2679
 context_switch kernel/sched/core.c:2828 [inline]
 __schedule+0x884/0x1df0 kernel/sched/core.c:3473
 preempt_schedule_common+0x22/0x60 kernel/sched/core.c:3597
 _cond_resched+0x1d/0x30 kernel/sched/core.c:4963
 slab_pre_alloc_hook mm/slab.h:421 [inline]
 slab_alloc mm/slab.c:3378 [inline]
 kmem_cache_alloc+0x292/0x710 mm/slab.c:3552
 alloc_inode+0xb2/0x190 fs/inode.c:212
 new_inode_pseudo+0x71/0x1a0 fs/inode.c:903
 new_inode+0x1c/0x40 fs/inode.c:932
 debugfs_get_inode+0x19/0x120 fs/debugfs/inode.c:37
 __debugfs_create_file+0xb5/0x400 fs/debugfs/inode.c:352
 debugfs_create_file+0x57/0x70 fs/debugfs/inode.c:399
 kvm_create_vm_debugfs arch/x86/kvm/../../../virt/kvm/kvm_main.c:615  
[inline]
 kvm_dev_ioctl_create_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:3209  
[inline]

 kvm_dev_ioctl+0xbf5/0x1b10 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3236
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ff35b75dc78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ff35b75e6d4 RCX: 00457089
RDX:  RSI: ae01 RDI: 0006
RBP: 009300a0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 004ce9b8 R14: 004c50d7 R15: 
Modules linked in:
Dumping ftrace buffer:
   (ftrace buffer empty)
---[ end trace a4f093c8080a0418 ]---
RIP: 0010:__list_add_valid.cold.0+0xf/0x25 lib/list_debug.c:23
Code: e8 93 f5 5b fe e9 68 ff ff ff e8 89 f5 5b fe eb c9 4c 89 e7 e8 7f f5  
5b fe eb 97 48 89 d9 48 c7 c7 e0 9b 3a 87 e8 32 d8 03 fe <0f> 0b 48 89 f1  
48 c7 c7 a0 9c 3a 87 48 89 de e8 1e d8 03 fe 0f 0b

RSP: 0018:88018f9bf058 EFLAGS: 00010082
RAX: 0075 RBX: 8801947fdaa0 RCX: c9000200d000
RDX:  RSI: 8163a441 RDI: 0001
RBP: 88018f9bf070 R08: 880196e3a2c0 R09: ed003b605008
R10: ed003b605008 R11: 8801db028047 R12: 8801947fdaa0
R13: 8801947f8300 R14: 8801947fdaa0 R15: 88

mmotm 2018-08-21-23-23 uploaded

[akpm]

The mm-of-the-moment snapshot 2018-08-21-23-23 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.18:
(patches marked "*" will be included in linux-next)

  origin.patch
* autofs-fix-autofs_sbi-does-not-check-super-block-type.patch
* mm-check-shrinker-is-memcg-aware-in-register_shrinker_prepared.patch
* mm-keep-int-fields-in-struct-shrink_control-together.patch
* mm-make-flags-of-unsigned-type-in-struct-shrinker.patch
* swap-add-comments-to-lock_cluster_or_swap_info.patch
* mm-swapfilec-replace-some-ifdef-with-is_enabled.patch
* swap-use-swap_count-in-swap_page_trans_huge_swapped.patch
* swap-unify-normal-huge-code-path-in-swap_page_trans_huge_swapped.patch
* swap-unify-normal-huge-code-path-in-put_swap_page.patch
* swap-get_swap_pages-use-entry_size-instead-of-cluster-in-parameter.patch
* swap-add-__swap_entry_free_locked.patch
* swap-put_swap_page-share-more-between-huge-normal-code-path.patch
* mm-oom-distinguish-blockable-mode-for-mmu-notifiers.patch
* mm-oom-remove-oom_lock-from-oom_reaper.patch
* mm-oom-describe-task-memory-unit-larger-pid-pad.patch
* mm-oom_killc-clean-up-oom_reap_task_mm.patch
* mm-proc-pid-maps-remove-is_pid-and-related-wrappers.patch
* mm-proc-pid-smaps-factor-out-mem-stats-gathering.patch
* mm-proc-pid-smaps-factor-out-common-stats-printing.patch
* mm-proc-pid-smaps_rollup-convert-to-single-value-seq_file.patch
* mm-mempool-add-missing-parameter-description.patch
* mm-zero-out-the-vma-in-vma_init.patch
* mm-clarify-config_page_poisoning-and-usage.patch
* mm-fix-page_freeze_refs-and-page_unfreeze_refs-in-comments.patch
* memcg-reduce-memcg-tree-traversals-for-stats-collection.patch
* update-documents-__vm_enough_memory-function-path.patch
* mm-remove-zone_id-and-make-use-of-zone_idx-in-is_dev_zone.patch
* mm-page_alloc-move-ifdefery-out-of-free_area_init_core.patch
* mm-access-zone-node-via-zone_to_nid-and-zone_set_nid.patch
* mm-remove-__paginginit.patch
* mm-page_alloc-inline-function-to-handle-config_deferred_struct_page_init.patch
* mm-page_alloc-introduce-free_area_init_core_hotplug.patch
* mm-selftest-add-map_populate-test.patch
* mm-oom-refactor-oom_kill_process.patch
* mm-oom-introduce-memoryoomgroup.patch
* proc-add-percpu-populated-pages-count-to-meminfo.patch
* zram-fix-bug-storing-backing_dev.patch
* mm-fix-comment-for-nodemask_alloc.patch
* proc-fixup-pde-allocation-bloat.patch
* procfs-uptime-use-ktime_get_boottime_ts64.patch
* proc-test-proc-self-symlink.patch
* proc-test-proc-thread-self-symlink.patch
* proc-smaller-readlock-section-in-readdir-proc.patch
* proc-put-task-earlier-in-proc-fail-nth.patch
* proc-save-2-atomic-ops-on-write-to-proc-attr.patch
* proc-use-macro-in-proc-latency-hook.patch
* proc-spread-c

[PATCH] init/do_mounts.c: add root=PARTLABEL= support

[Nikolaus Voss]

Support referencing the root partition label from GPT as argument
to the root= option on the kernel command line in analogy to
referencing the partition uuid as root=PARTUUID=.

Specifying the partition label instead of the uuid is often much
easier, e.g. in embedded environments when there is an
A/B rootfs partition scheme for interruptible firmware updates
(i.e. rootfsA/ rootfsB).

The partition label can be queried with the blkid command.

Signed-off-by: Nikolaus Voss 
---
 init/do_mounts.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 2c71dabe5626..239b5104cff0 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -177,6 +177,24 @@ static dev_t devt_from_partuuid(const char *uuid_str)
}
return res;
 }
+
+/**
+ * match_dev_by_label - callback for finding a partition using its label
+ * @dev:   device passed in by the caller
+ * @data:  opaque pointer to the label to match
+ *
+ * Returns 1 if the device matches, and 0 otherwise.
+ */
+static int match_dev_by_label(struct device *dev, const void *data)
+{
+   const char *label = data;
+   struct hd_struct *part = dev_to_part(dev);
+
+   if (part->info && !strcmp(label, part->info->volname))
+   return 1;
+
+   return 0;
+}
 #endif
 
 /*
@@ -200,6 +218,8 @@ static dev_t devt_from_partuuid(const char *uuid_str)
  *a partition with a known unique id.
  * 8) : major and minor number of the device separated by
  *a colon.
+ * 9) PARTLABEL= with name being the GPT partition label.
+ *MSDOS partitions do not support labels!
  *
  * If name doesn't have fall into the categories above, we return (0,0).
  * block_class is used to check if something is a disk name. If the disk
@@ -221,6 +241,17 @@ dev_t name_to_dev_t(const char *name)
if (!res)
goto fail;
goto done;
+   } else if (strncmp(name, "PARTLABEL=", 10) == 0) {
+   struct device *dev;
+
+   dev = class_find_device(&block_class, NULL, name + 10,
+   &match_dev_by_label);
+   if (!dev)
+   goto fail;
+
+   res = dev->devt;
+   put_device(dev);
+   goto done;
}
 #endif
 
-- 
2.17.1

Re: [PATCH v2 1/2] Bluetooth: mediatek: Add protocol support for MediaTek MT7668U USB devices

[Sean Wang]

Hi, Marcel

It seems the major problem is come from the wmt ctrl urbs for which I've 
already add more explanation inline.

Others seems all I can all fix or enhance in the next version.

On Tue, 2018-08-21 at 17:36 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > This adds the support of enabling MT7668U Bluetooth function running
> > on the top of btusb driver.
> > 
> > The information in /sys/kernel/debug/usb/devices about the Bluetooth
> > device is listed as the below.
> > 
> > T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
> > D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
> > P:  Vendor=0e8d ProdID=7668 Rev= 1.00
> > S:  Manufacturer=MediaTek Inc.
> > S:  Product=Wireless_Device
> > S:  SerialNumber=0
> > C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
> > A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
> > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
> > E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
> > E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
> > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> > I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> > I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> > I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> > I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> > I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> > I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> > E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> > 
> > Signed-off-by: Sean Wang 
> > ---
> > drivers/bluetooth/Kconfig |  11 +
> > drivers/bluetooth/btusb.c | 549 
> > ++
> > 2 files changed, 560 insertions(+)
> > 
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index 07e55cd..c25bb11 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -52,6 +52,17 @@ config BT_HCIBTUSB_BCM
> > 
> >   Say Y here to compile support for Broadcom protocol.
> > 
> > +config BT_HCIBTUSB_MTK
> > +   bool "MediaTek protocol support"
> > +   depends on BT_HCIBTUSB
> > +   default n
> > +   help
> > + The MediaTek protocol support enables firmware download
> > + support and chip initialization for MediaTek Bluetooth
> > + USB controllers.
> > +
> > + Say Y here to compile support for MediaTek protocol.
> > +
> > config BT_HCIBTUSB_RTL
> > bool "Realtek protocol support"
> > depends on BT_HCIBTUSB
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 60bf04b..4ebfb77 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -26,6 +26,7 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > #include 
> > #include 
> > #include 
> > @@ -69,6 +70,7 @@ static struct usb_driver btusb_driver;
> > #define BTUSB_BCM2045   0x4
> > #define BTUSB_IFNUM_2   0x8
> > #define BTUSB_CW66220x10
> > +#define BTUSB_MEDIATEK 0x20
> > 
> > static const struct usb_device_id btusb_table[] = {
> > /* Generic Bluetooth USB device */
> > @@ -355,6 +357,10 @@ static const struct usb_device_id blacklist_table[] = {
> > { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01),
> >   .driver_info = BTUSB_REALTEK },
> > 
> > +   /* MediaTek Bluetooth devices */
> > +   { USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
> > + .driver_info = BTUSB_MEDIATEK },
> > +
> > /* Additional Realtek 8723AE Bluetooth devices */
> > { USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
> > { USB_DEVICE(0x13d3, 0x3394), .driver_info = BTUSB_REALTEK },
> > @@ -437,6 +443,7 @@ struct btusb_data {
> > struct sk_buff *evt_skb;
> > struct sk_buff *acl_skb;
> > struct sk_buff *sco_skb;
> > +   struct sk_buff *rx_skb;
> 
> can we not just use the evt_skb here. Are you expecting also INT URBs?
> 

we can just use evt_skb.

I plan in the next version to use mtk specific recv function, not use 
btusb_recv_intr function in wmt ctrl urbs receive path.
In that way, we can use evt_skb,


> > 
> > struct usb_endpoint_descriptor *intr_ep;
> > struct usb_endpoint_descriptor *bulk_tx_ep;
> > @@ -459,6 +4

KASAN: null-ptr-deref Write in binder_update_page_range

[Dae R. Jeong]

Reporting the crash: KASAN: null-ptr-deref Write in binder_update_page_range

This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report.

Our analysis shows that the race occurs when invoking two syscalls
concurrently, mmap$binder() and ioctl$BINDER_WRITE_READ. More
specifically, since two code lines `alloc->vma = vma;` and
`alloc->vma_vm_mm = vma->vm_mm;` in binder_alloc_mmap_handler() is not
an atomic operation during mmap$binder() syscall, there is a time
window that `alloc->vma` is assigned but `alloc->vma_vm_mm` isn't
assigned. It causes the null pointer dereference in
binder_alloc_new_buf_locked() since it checks whether `alloc->vma` is
NULL, but it doesn't check that `alloc->vma_vm_mm` is NULL. More
details on the thread interleaving and the crash log are follows.


Thread interleaving:
CPU0 (binder_alloc_mmap_handler)  CPU1 (binder_alloc_new_buf_locked)
= =
// drivers/android/binder_alloc.c
// #L718 (v4.18-rc3)
alloc->vma = vma;
  // drivers/android/binder_alloc.c
  // #L346 (v4.18-rc3)
  if (alloc->vma == NULL) {
  ...
  // alloc->vma is not NULL at 
this point
  return ERR_PTR(-ESRCH);
  }
  ...
  // #L438
  binder_update_page_range(alloc, 0,
  (void 
*)PAGE_ALIGN((uintptr_t)buffer->data),
  end_page_addr);

  // In binder_update_page_range() 
#L218
  // But still alloc->vma_vm_mm is 
NULL here
  if (need_mm && 
mmget_not_zero(alloc->vma_vm_mm))
alloc->vma_vm_mm = vma->vm_mm;


Crash Log:
==
BUG: KASAN: null-ptr-deref in __atomic_add_unless 
include/asm-generic/atomic-instrumented.h:89 [inline]
BUG: KASAN: null-ptr-deref in atomic_add_unless include/linux/atomic.h:533 
[inline]
BUG: KASAN: null-ptr-deref in mmget_not_zero include/linux/sched/mm.h:75 
[inline]
BUG: KASAN: null-ptr-deref in binder_update_page_range+0xece/0x18e0 
drivers/android/binder_alloc.c:218
Write of size 4 at addr 0058 by task syz-executor0/11184

CPU: 1 PID: 11184 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x16e/0x22c lib/dump_stack.c:113
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report+0x163/0x380 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 check_memory_region+0x140/0x1a0 mm/kasan/kasan.c:267
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
 __atomic_add_unless include/asm-generic/atomic-instrumented.h:89 [inline]
 atomic_add_unless include/linux/atomic.h:533 [inline]
 mmget_not_zero include/linux/sched/mm.h:75 [inline]
 binder_update_page_range+0xece/0x18e0 drivers/android/binder_alloc.c:218
 binder_alloc_new_buf_locked drivers/android/binder_alloc.c:443 [inline]
 binder_alloc_new_buf+0x467/0xc30 drivers/android/binder_alloc.c:513
 binder_transaction+0x125b/0x4fb0 drivers/android/binder.c:2957
 binder_thread_write+0xc08/0x2770 drivers/android/binder.c:3528
 binder_ioctl_write_read.isra.39+0x24f/0x8e0 drivers/android/binder.c:4456
 binder_ioctl+0xa86/0xf34 drivers/android/binder.c:4596
 vfs_ioctl fs/ioctl.c:46 [inline]
 do_vfs_ioctl+0x154/0xd40 fs/ioctl.c:686
 ksys_ioctl+0x94/0xb0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:706
 do_syscall_64+0x167/0x4b0 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456469
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f575f268b28 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0072bfa0 RCX: 00456469
RDX: 23c0 RSI: c0306201 RDI: 0016
RBP: 01a2 R08:  R09: 
R10:  R11: 0246 R12: 7f575f2696d4
R13:  R14: 006f77d0 R15: 
==

= About RaceFuzz

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

[Christoph Hellwig]

On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
> The cpu_operations is certainly required because SOC vendors will add
> vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
> of all CPUs entering Linux kernel simultaneously. In fact, we might also 
> end-up
> having CPU ON/OFF operations in SBI.

Your forgot an essential part in your analysis:  Right now we only have
one single way to deal with cpu on/offlining, and that is the dummy WFI
kind.  Once other ways show up we can build proper infrastructure, but
until then this is just a white elephant as we have no idea how these
abstractions will look like.

And my hope is that we'll just see new SBI calls, in which case we'll
just need SBI and dummy version and can avoid all the indirect calls.

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

[Konstantin Khlebnikov]

On Tue, Aug 21, 2018 at 8:15 PM, Johannes Weiner  wrote:
> On Tue, Aug 21, 2018 at 08:11:44AM +0300, Konstantin Khlebnikov wrote:
>> On Sat, Aug 18, 2018 at 4:22 AM, Matthew Wilcox  wrote:
>> > On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
>> >> - scan = div64_u64(scan * fraction[file],
>> >> -  denominator);
>> >> + if (scan > 1)
>> >> + scan = div64_u64(scan * fraction[file],
>> >> +  denominator);
>> >
>> > Wouldn't we be better off doing a div_round_up?  ie:
>> >
>> > scan = div64_u64(scan * fraction[file] + denominator - 1, 
>> > denominator);
>> >
>> > although i'd rather hide that in a new macro in math64.h than opencode it
>> > here.
>>
>> All numbers here should be up to nr_pages * 200 and fit into unsigned long.
>> I see no reason for u64. If they overflow then u64 wouldn't help either.
>
> It is nr_pages * 200 * recent_scanned, where recent_scanned can be up
> to four times of what's on the LRUs. That can overflow a u32 with even
> small amounts of memory.

Ah, this thing is inverted because it aims to proportional reactivation rate
rather than the proportional pressure to reclaimable pages.
That's not obvious. I suppose this should be in comment above it.

Well, at least denominator should fit into unsigned long. So full
64/64 division is redundant.

[PATCH] soc: ti: pm33xx: Enable DS0 for the platforms on which it is functional

[Keerthy]

Enable DS0 for only those platforms on which it is functional

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/pm33xx-core.c| 5 +
 drivers/soc/ti/pm33xx.c  | 9 +
 include/linux/platform_data/pm33xx.h | 2 ++
 3 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-omap2/pm33xx-core.c 
b/arch/arm/mach-omap2/pm33xx-core.c
index f4971e4..f0f6e8e 100644
--- a/arch/arm/mach-omap2/pm33xx-core.c
+++ b/arch/arm/mach-omap2/pm33xx-core.c
@@ -135,6 +135,11 @@ static int am43xx_suspend(unsigned int state, int 
(*fn)(unsigned long),
 {
int ret = 0;
 
+   if (!(args & WFI_FLAG_DEEP_SLEEP0)) {
+   pr_err("DS0 mode not supported\n");
+   return -ENOTSUPP;
+   }
+
amx3_pre_suspend_common();
scu_power_mode(scu_base, SCU_PM_POWEROFF);
ret = cpu_suspend(args, fn);
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index d0dab32..53238d7 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -324,6 +324,15 @@ static int am33xx_pm_probe(struct platform_device *pdev)
suspend_wfi_flags |= WFI_FLAG_SAVE_EMIF;
suspend_wfi_flags |= WFI_FLAG_WAKE_M3;
 
+   /*
+* Deep Sleep0 mode is currently functional only on am437x-gp-evm,
+* am33xx-evm and boneblack family. Hence set the DS0 flag
+*/
+   if (of_machine_is_compatible("ti,am437x-gp-evm") ||
+   of_machine_is_compatible("ti,am335x-bone-black") ||
+   of_machine_is_compatible("ti,am335x-evm"))
+   suspend_wfi_flags |= WFI_FLAG_DEEP_SLEEP0;
+
ret = pm_ops->init();
if (ret) {
dev_err(dev, "Unable to call core pm init!\n");
diff --git a/include/linux/platform_data/pm33xx.h 
b/include/linux/platform_data/pm33xx.h
index fbf5ed7..5c54b64 100644
--- a/include/linux/platform_data/pm33xx.h
+++ b/include/linux/platform_data/pm33xx.h
@@ -28,12 +28,14 @@
  * WFI_FLAG_WAKE_M3: Disable MPU clock or clockdomain to cause wkup_m3 to
  *  execute when WFI instruction executes.
  * WFI_FLAG_RTC_ONLY: Configure the RTC to enter RTC+DDR mode.
+ * WFI_FLAG_DEEP_SLEEP0: Configure to enter Depp Sleep 0 mode.
  */
 #define WFI_FLAG_FLUSH_CACHE   BIT(0)
 #define WFI_FLAG_SELF_REFRESH  BIT(1)
 #define WFI_FLAG_SAVE_EMIF BIT(2)
 #define WFI_FLAG_WAKE_M3   BIT(3)
 #define WFI_FLAG_RTC_ONLY  BIT(4)
+#define WFI_FLAG_DEEP_SLEEP0   BIT(5)
 
 #ifndef __ASSEMBLER__
 struct am33xx_pm_sram_addr {
-- 
1.9.1

[GIT] IDE

[David Miller]

1) Remove redundant variables, from Colin Ian King.

2) Expected switch fall-through annotations, from Gustavo A. R. Silva

Please pull, thanks!

The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703:

  Linux 4.18 (2018-08-12 13:41:04 -0700)

are available in the Git repository at:

  gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/davem/ide.git 

for you to fetch changes up to a2eed33dcdb7663170b01f05dd8d0a3323ffe4b3:

  ide: mark expected switch fall-throughs (2018-08-13 11:48:54 -0700)


Colin Ian King (2):
  ide: remove redundant variables queue_run_ms and left
  ide-tape: remove redundant variable buffer_size

Gustavo A. R. Silva (1):
  ide: mark expected switch fall-throughs

 drivers/ide/hpt366.c   | 5 +++--
 drivers/ide/ide-floppy.c   | 1 +
 drivers/ide/ide-io.c   | 4 
 drivers/ide/ide-probe.c| 1 +
 drivers/ide/ide-tape.c | 2 --
 drivers/ide/ide-taskfile.c | 3 ++-
 drivers/ide/sis5513.c  | 1 +
 7 files changed, 8 insertions(+), 9 deletions(-)

[GIT] Sparc

[David Miller]

Nothing super serious:

1) Convert sparc32 over to NO_BOOTMEM, from Mike Rapoport.

2) Use dma_noncoherent_ops on sparc32, from Christoph Hellwig

3) Fix kbuild defconfig handling on sparc32, from Masahiro Yamada.

Please pull, thanks a lot.

The following changes since commit 778a33959a8ad4cb1ea2f4c5119f9e1e8b9f9d9b:

  Merge tag 'please-pull-noboot' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux (2018-08-20 19:37:09 
-0700)

are available in the Git repository at:

  gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/davem/sparc.git 

for you to fetch changes up to c84ca616b1260949782f408271336f0eda056c61:

  sparc: fix KBUILD_DEFCONFIG for ARCH=sparc32 (2018-08-21 12:41:12 -0700)


Christoph Hellwig (1):
  sparc: use generic dma_noncoherent_ops

David S. Miller (1):
  Merge branch 'sparc32-NO_BOOTMEM'

Masahiro Yamada (1):
  sparc: fix KBUILD_DEFCONFIG for ARCH=sparc32

Mike Rapoport (3):
  sparc: mm/init_32: kill trailing whitespace
  sparc32: switch to NO_BOOTMEM
  sparc32: split ramdisk detection and reservation to a helper function

 arch/sparc/Kconfig   |   6 ++--
 arch/sparc/Makefile  |   6 ++--
 arch/sparc/include/asm/dma-mapping.h |   5 ++-
 arch/sparc/kernel/ioport.c   | 193 
+---
 arch/sparc/mm/init_32.c  | 127 
++--
 5 files changed, 88 insertions(+), 249 deletions(-)

Re: [RFC][PATCH] lib/string: introduce sysfs_strncpy() and sysfs_strlcpy()

[Sergey Senozhatsky]

Hi,

On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
> 
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the input is nul-terminated) - I'm
> thinking a new interface might also have uses outside sysfs.

Makes sense.

> > E.g.
> > channel_dimm_label_store()
> > dimmdev_label_store()
> > pmbus_add_label()
> > axp20x_store_attr()
> > cmdline_store()
> 
> Hm, do any of those actually want the skipping of leading whitespace?

Hm, that's a good question. I'd probably say "mostly yes". The input
usually goes to strcmp/strcpy/strtol/etc. But we don't have to trim
leading whitespaces and can just let the driver error out [hopefully
the driver has a well tested error-out path].

> pmbus_add_label doesn't even seem to kill a trailing newline?

Sorry, I think pmbus_add_label() made it to the list by mistake. It doesn't
appear to be a ->store() callback.

> It's probably hard to create one interface that will work for all cases.

Agreed, that's why I targeted sysfs input data only ;)

> Dunno, looking at your examples above I'm a bit more skeptical that
> there is a lot of common ground. But of course there are hundreds of
> other store callbacks, so surely one can simplify some with a new helper.

Yep.

-ss

[PATCH net] net/ncsi: Fixup .dumpit message flags and ID check in Netlink handler

[Samuel Mendoza-Jonas]

The ncsi_pkg_info_all_nl() .dumpit handler is missing the NLM_F_MULTI
flag, causing additional package information after the first to be lost.
Also fixup a sanity check in ncsi_write_package_info() to reject out of
range package IDs.

Signed-off-by: Samuel Mendoza-Jonas 
---
 net/ncsi/ncsi-netlink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ncsi/ncsi-netlink.c b/net/ncsi/ncsi-netlink.c
index 82e6edf9c5d9..45f33d6dedf7 100644
--- a/net/ncsi/ncsi-netlink.c
+++ b/net/ncsi/ncsi-netlink.c
@@ -100,7 +100,7 @@ static int ncsi_write_package_info(struct sk_buff *skb,
bool found;
int rc;
 
-   if (id > ndp->package_num) {
+   if (id > ndp->package_num - 1) {
netdev_info(ndp->ndev.dev, "NCSI: No package with id %u\n", id);
return -ENODEV;
}
@@ -240,7 +240,7 @@ static int ncsi_pkg_info_all_nl(struct sk_buff *skb,
return 0; /* done */
 
hdr = genlmsg_put(skb, NETLINK_CB(cb->skb).portid, cb->nlh->nlmsg_seq,
- &ncsi_genl_family, 0,  NCSI_CMD_PKG_INFO);
+ &ncsi_genl_family, NLM_F_MULTI,  NCSI_CMD_PKG_INFO);
if (!hdr) {
rc = -EMSGSIZE;
goto err;
-- 
2.18.0

Re: [RFC][PATCH] lib/string: introduce sysfs_strncpy() and sysfs_strlcpy()

[Sergey Senozhatsky]

Hello Greg,

On (08/21/18 15:57), Greg Kroah-Hartman wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there. Am I wrong?
> 
> sysfs data is always null terminated.
> 
> What exactly are you trying to do here?  If a user sends you crappy data
> in a sysfs file (like leading or trailing whitespace), well, you can
> always just error out, no problem.

So what we are thinking about is sort of clean up / unification of the
way ->store() callbacks handle sysfs input. They all have to do the
same things for "corner case" handling and many of them forget to handle
some specific cases; or have to come up with extra code; or are not aware
of the existing API; etc.

For instance, let's look at 325c4b3b81027068 [well, a small part of]

---

@@ -245,7 +239,7 @@ static ssize_t pm_qos_resume_latency_store(struct device 
*dev,
 
if (value == 0)
value = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
-   } else if (!strcmp(buf, "n/a") || !strcmp(buf, "n/a\n")) {
+   } else if (sysfs_streq(buf, "n/a")) {
value = 0;
} else {
return -EINVAL;
@@ -285,9 +279,9 @@ static ssize_t pm_qos_latency_tolerance_store(struct device 
*dev,
if (value < 0)
return -EINVAL;
} else {
-   if (!strcmp(buf, "auto") || !strcmp(buf, "auto\n"))
+   if (sysfs_streq(buf, "auto"))
value = PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT;
-   else if (!strcmp(buf, "any") || !strcmp(buf, "any\n"))
+   else if (sysfs_streq(buf, "any"))
value = PM_QOS_LATENCY_ANY;
else
return -EINVAL;
@@ -342,20 +336,12 @@ static ssize_t
 wake_store(struct device * dev, struct device_attribute *attr,
const char * buf, size_t n)
 {
-   char *cp;
-   int len = n;
-
if (!device_can_wakeup(dev))
return -EINVAL;
 
-   cp = memchr(buf, '\n', n);
-   if (cp)
-   len = cp - buf;
-   if (len == sizeof _enabled - 1
-   && strncmp(buf, _enabled, sizeof _enabled - 1) == 0)
+   if (sysfs_streq(buf, _enabled))
device_set_wakeup_enable(dev, 1);
-   else if (len == sizeof _disabled - 1
-   && strncmp(buf, _disabled, sizeof _disabled - 1) == 0)
+   else if (sysfs_streq(buf, _disabled))
device_set_wakeup_enable(dev, 0);
else
return -EINVAL;
---

There was quite a bit of code. But these things still can and do happen;
Andy tweaked the existing code only.

So what we are looking at is a way which would let us to make that part
of drivers to be simpler and less fragile, perhaps.

> Please always post a user of your new api when you make stuff like this
> otherwise we do not know how it is used, or even why you are adding it.

Sure, I agree. There is no API proposal yet; so I gave a simple example
in the commit message and didn't bother to convert any of the existing
users.

I'm not even sure yet if we want to have a new API. The sort of a
root cause [it seems so] here is that sysfs input data has irregular
format. That's why we have irregular handling of

Either in a form of

if (!strcmp(buf, "auto") || !strcmp(buf, "auto\n"))
...
or in a form of

if (sz > 0 && value[sz - 1] == '\n')
value[sz - 1] = 0x00;
if (!strcmp(value, "auto"))

and so on.

So may be, instead of new API which was meant to help make sysfs data
look uniform, we can do tweaks to sysfs and pass to ->store() callbacks
data which already has no trailing newline and whitespaces. IOW, make it
uniform within sysfs. Then we can remove a bunch of code from the existing
drivers and make it easier for future drivers.
So sysfs could do strim-ing, etc. and ->store() would always receive data
which can be directly used as strcmp/strcpy/etc input. Because this is what
people want to do after all; but they learn at some point that they can't
and there are newline symbols, etc. to take care of.

What do you think? A new API is probably safer option here; but then,
again, people can forget to use it, or be unaware of it.

-ss

Ping [PATCH v3] perf report: Create auxiliary trace data files for s390

[Thomas Richter]

Create auxiliary trace data log files when invoked with option
 --itrace=d as in

[root@s35lp76 perf] ./perf report -i perf.data.aux1 --stdio --itrace=d

perf report creates several data files in the current directory
named aux.smp.## where ## is a 2 digit hex number with
leading zeros representing the CPU number this trace data
was recorded from. The file contents is binary and contains
the CPU-Measurement Sampling Data Blocks (SDBs).

The directory to save the auxiliary trace buffer can be
changed using the perf config file and command. Specify
section 'auxtrace' keyword 'dumpdir' and assign it a valid
directory name. If the directory does not exist or has the
wrong file type, the current directory is used.

[root@p23lp27 perf]# ./perf config auxtrace.dumpdir=/tmp
[root@p23lp27 perf]# ./perf config --user -l
auxtrace.dumpdir=/tmp
[root@p23lp27 perf]# ./perf report ...
[root@p23lp27 perf]# ll /tmp/aux.smp.00
-rw-r--r-- 1 root root 204800 Aug  2 13:48 /tmp/aux.smp.00
[root@p23lp27 perf]#

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
---
 tools/perf/util/s390-cpumsf.c | 94 +--
 1 file changed, 91 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/s390-cpumsf.c b/tools/perf/util/s390-cpumsf.c
index d2c78ffd9fee..a2eeebbfb25f 100644
--- a/tools/perf/util/s390-cpumsf.c
+++ b/tools/perf/util/s390-cpumsf.c
@@ -147,6 +147,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "cpumap.h"
 #include "color.h"
 #include "evsel.h"
@@ -159,6 +162,7 @@
 #include "auxtrace.h"
 #include "s390-cpumsf.h"
 #include "s390-cpumsf-kernel.h"
+#include "config.h"
 
 struct s390_cpumsf {
struct auxtrace auxtrace;
@@ -170,6 +174,8 @@ struct s390_cpumsf {
u32 pmu_type;
u16 machine_type;
booldata_queued;
+   booluse_logfile;
+   char*logdir;
 };
 
 struct s390_cpumsf_queue {
@@ -177,6 +183,7 @@ struct s390_cpumsf_queue {
unsigned intqueue_nr;
struct auxtrace_buffer  *buffer;
int cpu;
+   FILE*logfile;
 };
 
 /* Display s390 CPU measurement facility basic-sampling data entry */
@@ -595,6 +602,12 @@ static int s390_cpumsf_run_decoder(struct 
s390_cpumsf_queue *sfq,
buffer->use_size = buffer->size;
buffer->use_data = buffer->data;
}
+   if (sfq->logfile) { /* Write into log file */
+   size_t rc = fwrite(buffer->data, buffer->size, 1,
+  sfq->logfile);
+   if (rc != 1)
+   pr_err("Failed to write auxiliary data\n");
+   }
} else
buffer = sfq->buffer;
 
@@ -606,6 +619,13 @@ static int s390_cpumsf_run_decoder(struct 
s390_cpumsf_queue *sfq,
return -ENOMEM;
buffer->use_size = buffer->size;
buffer->use_data = buffer->data;
+
+   if (sfq->logfile) { /* Write into log file */
+   size_t rc = fwrite(buffer->data, buffer->size, 1,
+  sfq->logfile);
+   if (rc != 1)
+   pr_err("Failed to write auxiliary data\n");
+   }
}
pr_debug4("%s queue_nr:%d buffer:%" PRId64 " offset:%#" PRIx64 " 
size:%#zx rest:%#zx\n",
  __func__, sfq->queue_nr, buffer->buffer_nr, buffer->offset,
@@ -640,6 +660,23 @@ s390_cpumsf_alloc_queue(struct s390_cpumsf *sf, unsigned 
int queue_nr)
sfq->sf = sf;
sfq->queue_nr = queue_nr;
sfq->cpu = -1;
+   if (sf->use_logfile) {
+   char *name;
+   int rc;
+
+   rc = (sf->logdir)
+   ? asprintf(&name, "%s/aux.smp.%02x",
+sf->logdir, queue_nr)
+   : asprintf(&name, "aux.smp.%02x", queue_nr);
+   if (rc > 0)
+   sfq->logfile = fopen(name, "w");
+   if (sfq->logfile == NULL) {
+   pr_err("Failed to open auxiliary log file %s,"
+  "continue...\n", name);
+   sf->use_logfile = false;
+   }
+   free(name);
+   }
return sfq;
 }
 
@@ -850,8 +887,16 @@ static void s390_cpumsf_free_queues(struct perf_session 
*session)
struct auxtrace_queues *queues = &sf->queues;
unsigned int i;
 
-   for (i = 0; i < queues->nr_queues; i++)
+   for (i = 0; i < queues->nr_queues; i++) {
+   struct s390_cpumsf_queue *sfq = (struct s390_cpumsf_queue *)
+   queues->queue_array[i].priv;
+
+   if (sfq != NULL && sfq->logfile) {
+   fclose(

Re: [PATCH] compiler-gcc: get back Clang build

[Dominique Martinet]

Joe Perches wrote on Tue, Aug 21, 2018:
> On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> > I think that could work, but at the point making a separate
> > compiler-common.h and not including compiler-gcc.h for clang sounds
> > better to me... More importantly here, either solution sound complex
> > enough to require more than a few days and proper testing for all archs
> > etc when compared to the partial revert we have here.
> 
> The immediate need for a partial revert seems unnecessary as
> clang hasn't really worked for a couple releases now.

Sorry for repeating myself, clang is used by bcc for compiling BPF
programs (e.g. bpf_module_create_c_from_string() or any similar function
will use the clang libs to compile the bpf program with linux headers),
and this has always been working because it's not using our makefiles.

This broke today in master and I only joined this thread after looking
at why the build started failing today and noticing this patch, it
definitely hasn't been broken for two releases, or I wouldn't be here
with this timing :)


> The separate compiler file changes are much more sensible,
> even if it takes a few days.

A few days are fine, but I think some form of fix in 4.19-rc1 would be
good.

I'll stop taking your time now, but I think you are/were underestimating
how many people use clang with the linux kernel headers indirectly.
BPF is a well-used tool :)


Thanks,
-- 
Dominique Martinet

Re: [GIT PULL] IDA changes for 4.19

[Matthew Wilcox]

On Mon, Aug 13, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> 
> Hi Linus,
> 
> Please pull the IDA patchset.  It depends on the XArray patchset, so
> ignore this pull request if you've decided not to pull the XArray patches.
> The new IDA API is similar to ida_simple_get() but better named.  The
> internal restructuring of the IDA code removes the bitmap preallocation
> nonsense.

I've redone this patchset to not depend on the XArray.  It no longer
removes the bitmap preallocation because that was too entangled with the
rewrite to use the XArray.  But it does give us a better IDA API --
id = ida_alloc(ida, GFP_xxx); ida_free(ida, id); rather than the
cumbersome ida_simple_get(), ida_simple_remove().  The preallocation is
no longer visible to consumers, so removing it will be easier next round.

I hope the net -200 lines of code is convincing.

The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703:

  Linux 4.18 (2018-08-12 13:41:04 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/willy/linux-dax.git ida-4.19

for you to fetch changes up to 1df895190233fcc30d46beca4550bcafb7b959a6:

  ida: Change ida_get_new_above to return the id (2018-08-21 23:54:21 -0400)


Matthew Wilcox (28):
  radix tree test suite: Fix compilation
  radix tree test suite: Enable ubsan
  radix-tree: Fix UBSAN warning
  ida: Lock the IDA in ida_destroy
  ida: Add new API
  mtip32xx: Convert to new IDA API
  fs: Convert unnamed_dev_ida to new API
  fs: Convert namespace IDAs to new API
  devpts: Convert to new IDA API
  sd: Convert to new IDA API
  osd: Convert to new IDA API
  rsxx: Convert to new IDA API
  cb710: Convert to new IDA API
  Convert net_namespace to new IDA API
  ppc: Convert mmu context allocation to new IDA API
  media: Convert entity ID allocation to new IDA API
  ppc: Convert vas ID allocation to new IDA API
  dmaengine: Convert to new IDA API
  drm/vmwgfx: Convert to new IDA API
  target/iscsi: Allocate session IDs from an IDA
  ida: Start new test_ida module
  idr-test: Convert ida_check_nomem to new API
  test_ida: Move ida_check_leaf
  test_ida: Move ida_check_max
  test_ida: Convert check_ida_conv to new API
  test_ida: check_ida_destroy and check_ida_alloc
  ida: Remove old API
  ida: Change ida_get_new_above to return the id

Mike Christie (1):
  iscsi target: fix session creation failure handling

 arch/powerpc/mm/mmu_context_book3s64.c|  44 +-
 arch/powerpc/platforms/powernv/vas-window.c   |  26 +---
 drivers/block/mtip32xx/mtip32xx.c |  29 +---
 drivers/block/rsxx/core.c |  21 +--
 drivers/dma/dmaengine.c   |  23 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  41 ++---
 drivers/media/media-device.c  |  16 +-
 drivers/misc/cb710/core.c |  23 +--
 drivers/scsi/osd/osd_uld.c|  22 +--
 drivers/scsi/sd.c |  21 +--
 drivers/target/iscsi/iscsi_target.c   |  10 +-
 drivers/target/iscsi/iscsi_target.h   |   4 +-
 drivers/target/iscsi/iscsi_target_login.c |  41 +++--
 fs/devpts/inode.c |  47 ++
 fs/namespace.c|  50 ++
 fs/super.c|  67 +++-
 include/linux/idr.h   |  68 ++--
 lib/Kconfig.debug |   3 +
 lib/Makefile  |   1 +
 lib/idr.c | 155 +++
 lib/radix-tree.c  |  11 +-
 lib/test_ida.c| 177 +
 net/core/net_namespace.c  |  16 +-
 tools/testing/radix-tree/Makefile |   6 +-
 tools/testing/radix-tree/idr-test.c   | 214 +-
 tools/testing/radix-tree/linux/xarray.h   |   2 +
 tools/testing/radix-tree/main.c   |  23 +--
 tools/testing/radix-tree/test.h   |   3 +-
 28 files changed, 485 insertions(+), 679 deletions(-)
 create mode 100644 lib/test_ida.c
 create mode 100644 tools/testing/radix-tree/linux/xarray.h

Re: [PATCH] compiler-gcc: get back Clang build

[Joe Perches]

On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote:
> I think that could work, but at the point making a separate
> compiler-common.h and not including compiler-gcc.h for clang sounds
> better to me... More importantly here, either solution sound complex
> enough to require more than a few days and proper testing for all archs
> etc when compared to the partial revert we have here.

The immediate need for a partial revert seems unnecessary as
clang hasn't really worked for a couple releases now.

The separate compiler file changes are much more sensible,
even if it takes a few days.

Kindly Confirm Receive

[Richard Jeffery Esq]

Good day,

My name is Richard Jeffery I have a client, who died as a result of
heart-related condition on the 10th of December, 2015. I have contacted
you to assist in distributing the estate left behind by my client, who
shares the same last name as yours. Would discuss more when I hear from
you. Contact me on this on this private email
jefferyrich...@mail2litigator.com to indicate your interest.

Thnaks and regards,
Richard Jeffery
Email: jefferyrich...@mail2litigator.com

Re: [PATCH] compiler-gcc: get back Clang build

[Dominique Martinet]

Nick Desaulniers wrote on Tue, Aug 21, 2018:
> On Tue, Aug 21, 2018 at 9:45 AM Joe Perches  wrote:
> > > Tested with gcc-7 and clang-8.
> >
> > clang-8? Isn't the latest officlal clang 6.0.1 ?
> [...]
> > So if something other than 6.0.x is required,
> > then some additional check should probably be
> > added to compiler-clang.h as well.
> 
> Sure, but that doesn't need to go in Mashiro's patch today.  That can
> wait for a proper separation between compiler headers where we can
> then implement improved version checks.

I can confirm that the patch here works for me with clang 6.0.1 as far
as bpf programs are concerned (and gcc 8.1.1 for the kernel build itself
on x86 while I was at it); so at least there is nothing on the
compiler*.h headers that put off clang 6.0.1


(also replying to other subthread)
>From Joe Perches @ 2018-08-21 17:22 UTC:
> The question remains, if clang can't compile
> v4.17, why does it immediately matter for v4.19?

I haven't had any problem with clang and 4.17 as far as building bpf
programs is concerned, because the CC_HAVE_ASM_GOTO check is done in
makefiles that aren't used in the bpf case and not in compiler-gcc.h
or another header.

So I guess the "immediately matters for v4.19" depends on how much you
would care about bcc-compiled BPF programs.


> Why wouldn't overriding the clang __GNUC_
> #defines in compiler-gcc.h work acceptably with
> adding whatever is necessary to compiler-clang.h?

I think that could work, but at the point making a separate
compiler-common.h and not including compiler-gcc.h for clang sounds
better to me... More importantly here, either solution sound complex
enough to require more than a few days and proper testing for all archs
etc when compared to the partial revert we have here.

-- 
Dominique Martinet

linux-next: Tree for Aug 22

[Stephen Rothwell]

Hi all,

Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.

Changes since 20180821:

The akpm-current tree gained a conflict against the mips tree.

Non-merge commits (relative to Linus' tree): 2206
 2327 files changed, 76092 insertions(+), 33625 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 286 trees (counting Linus' and 65 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 (0214f46b3a03 Merge branch 'siginfo-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma())
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper 
PAGE_SHIFT bits in pfn_valid())
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c84ca616b126 sparc: fix KBUILD_DEFCONFIG for ARCH=sparc32)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (78c452fe7068 Merge branch 'net_sched-fixes')
Merging bpf/master (96c26e045816 xsk: fix return value of xdp_umem_assign_dev())
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (9c86336c15db ip6_vti: fix a null pointer deference 
when destroy vti6 tunnel)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (8a54d8fc160e cfg80211: remove division by size of 
sizeof(struct ieee80211_wmm_rule))
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (8a328ac1f9eb ALSA: hda/realtek - Fix HP 
Headset Mic can't record)
Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18)
Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.ker

[PATCH v3 1/4] dt-bindings: phy: add DT bindings for UniPhier USB3 PHY driver

[Kunihiko Hayashi]

Add DT bindings for PHY interface built into USB3 controller
implemented in UniPhier SoCs.

Signed-off-by: Kunihiko Hayashi 
---
 .../bindings/phy/uniphier-usb3-hsphy.txt   | 69 ++
 .../bindings/phy/uniphier-usb3-ssphy.txt   | 57 ++
 2 files changed, 126 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt
 create mode 100644 
Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt

diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt 
b/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt
new file mode 100644
index 000..e8d8086
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt
@@ -0,0 +1,69 @@
+Socionext UniPhier USB3 High-Speed (HS) PHY
+
+This describes the devicetree bindings for PHY interfaces built into
+USB3 controller implemented on Socionext UniPhier SoCs.
+Although the controller includes High-Speed PHY and Super-Speed PHY,
+this describes about High-Speed PHY.
+
+Required properties:
+- compatible: Should contain one of the following:
+"socionext,uniphier-pro4-usb3-hsphy" - for Pro4 SoC
+"socionext,uniphier-pxs2-usb3-hsphy" - for PXs2 SoC
+"socionext,uniphier-ld20-usb3-hsphy" - for LD20 SoC
+"socionext,uniphier-pxs3-usb3-hsphy" - for PXs3 SoC
+- reg: Specifies offset and length of the register set for the device.
+- #phy-cells: Should be 0.
+- clocks: A list of phandles to the clock gate for USB3 glue layer.
+   According to the clock-names, appropriate clocks are required.
+- clock-names: Should contain the following:
+"gio", "link" - for Pro4 SoC
+"phy", "phy-ext", "link" - for PXs3 SoC, "phy-ext" is optional.
+"phy", "link" - for others
+- resets: A list of phandles to the reset control for USB3 glue layer.
+   According to the reset-names, appropriate resets are required.
+- reset-names: Should contain the following:
+"gio", "link" - for Pro4 SoC
+"phy", "link" - for others
+
+Optional properties:
+- vbus-supply: A phandle to the regulator for USB VBUS.
+- nvmem-cells: Phandles to nvmem cell that contains the trimming data.
+   Available only for HS-PHY implemented on LD20 and PXs3, and
+   if unspecified, default value is used.
+- nvmem-cell-names: Should be the following names, which correspond to
+   each nvmem-cells.
+   All of the 3 parameters associated with the following names are
+   required for each port, if any one is omitted, the trimming data
+   of the port will not be set at all.
+"rterm", "sel_t", "hs_i" - Each cell name for phy parameters
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties.
+
+Example:
+
+   usb-glue@65b0 {
+   compatible = "socionext,uniphier-ld20-dwc3-glue",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x65b0 0x400>;
+
+   usb_vbus0: regulator {
+   ...
+   };
+
+   usb_hsphy0: hs-phy@200 {
+   compatible = "socionext,uniphier-ld20-usb3-hsphy";
+   reg = <0x200 0x10>;
+   #phy-cells = <0>;
+   clock-names = "link", "phy";
+   clocks = <&sys_clk 14>, <&sys_clk 16>;
+   reset-names = "link", "phy";
+   resets = <&sys_rst 14>, <&sys_rst 16>;
+   vbus-supply = <&usb_vbus0>;
+   nvmem-cell-names = "rterm", "sel_t", "hs_i";
+   nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>,
+ <&usb_hs_i0>;
+   };
+   ...
+   };
diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt 
b/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt
new file mode 100644
index 000..490b815
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt
@@ -0,0 +1,57 @@
+Socionext UniPhier USB3 Super-Speed (SS) PHY
+
+This describes the devicetree bindings for PHY interfaces built into
+USB3 controller implemented on Socionext UniPhier SoCs.
+Although the controller includes High-Speed PHY and Super-Speed PHY,
+this describes about Super-Speed PHY.
+
+Required properties:
+- compatible: Should contain one of the following:
+"socionext,uniphier-pro4-usb3-ssphy" - for Pro4 SoC
+"socionext,uniphier-pxs2-usb3-ssphy" - for PXs2 SoC
+"socionext,uniphier-ld20-usb3-ssphy" - for LD20 SoC
+"socionext,uniphier-pxs3-usb3-ssphy" - for PXs3 SoC
+- reg: Specifies offset and length of the register set for the device.
+- #phy-cells: Should be 0.
+- clocks: A list of phandles to the clock gate for USB3 glue layer.
+   According to the clock-names, appropriate clocks are required.
+- clock-names:
+"gio", "link" - for Pro4 SoC
+"phy", "phy-ext", "l

[PATCH v3 0/4] phy: socionext: add new UniPhier USB PHY driver support

[Kunihiko Hayashi]

This series adds support for PHY interface built into USB controller
implemented in Socionext UniPhier SoCs.

The USB3 PHY driver supports High-Speed PHY and Super-Speed PHY included in
the USB3 glue layer, and the USB2 PHY driver supports High-Speed PHY
integrated into system controller.

Changes since v2:
- rewrite a header with style that other phy drivers use
- replace return value of probe functions with PTR_ERR_OR_ZERO()
- fix typo of register offset macros

Changes since v1:
- rewrite a header with C++ comment style
- dt-bindings: separate a document for ssphy and hsphy
- dt-bindings: sort clock-names and reset-names to begin with "phy"
- dt-bindings: use vbus-supply instead of phy-supply, because vbus isn't
  for phy, but vbus is tied to the port that corresponds to each phy [1]
- stop using phy_power and add own .power_on and .power_off functions
  to control clk/reset for phy and vbus regulator
- separate clk_get() and reset_control_get() for each clk/reset
  and remove arrays of clock_names and reset_names
- remove phy-parameters that are the same as power-on values
- remove functions to set phy-parameters for legacy SoCs
- express phy-parameters by using macros including the number of
  the register and its bitfield (msb and lsb)

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593279.html

Kunihiko Hayashi (4):
  dt-bindings: phy: add DT bindings for UniPhier USB3 PHY driver
  phy: socionext: add USB3 PHY driver for UniPhier SoC
  dt-bindings: phy: add DT bindings for UniPhier USB2 PHY driver
  phy: socionext: add USB2 PHY driver for UniPhier SoC

 .../devicetree/bindings/phy/uniphier-usb2-phy.txt  |  45 +++
 .../bindings/phy/uniphier-usb3-hsphy.txt   |  69 
 .../bindings/phy/uniphier-usb3-ssphy.txt   |  57 +++
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/socionext/Kconfig  |  25 ++
 drivers/phy/socionext/Makefile |   7 +
 drivers/phy/socionext/phy-uniphier-usb2.c  | 244 
 drivers/phy/socionext/phy-uniphier-usb3hs.c| 422 +
 drivers/phy/socionext/phy-uniphier-usb3ss.c| 349 +
 10 files changed, 1220 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt
 create mode 100644 
Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt
 create mode 100644 
Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt
 create mode 100644 drivers/phy/socionext/Kconfig
 create mode 100644 drivers/phy/socionext/Makefile
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb2.c
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c

-- 
2.7.4

[PATCH v3 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC

[Kunihiko Hayashi]

Add a driver for PHY interface built into USB3 controller
implemented in UniPhier SoCs.
This driver supports High-Speed PHY and Super-Speed PHY.

Signed-off-by: Kunihiko Hayashi 
Signed-off-by: Motoya Tanigawa 
Signed-off-by: Masami Hiramatsu 
---
 drivers/phy/Kconfig |   1 +
 drivers/phy/Makefile|   1 +
 drivers/phy/socionext/Kconfig   |  12 +
 drivers/phy/socionext/Makefile  |   6 +
 drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 
 drivers/phy/socionext/phy-uniphier-usb3ss.c | 349 +++
 6 files changed, 791 insertions(+)
 create mode 100644 drivers/phy/socionext/Kconfig
 create mode 100644 drivers/phy/socionext/Makefile
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c8d452..b752589 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -53,6 +53,7 @@ source "drivers/phy/ralink/Kconfig"
 source "drivers/phy/renesas/Kconfig"
 source "drivers/phy/rockchip/Kconfig"
 source "drivers/phy/samsung/Kconfig"
+source "drivers/phy/socionext/Kconfig"
 source "drivers/phy/st/Kconfig"
 source "drivers/phy/tegra/Kconfig"
 source "drivers/phy/ti/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 84e3bd9..5539cde 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -21,5 +21,6 @@ obj-y += broadcom/\
   qualcomm/\
   ralink/  \
   samsung/ \
+  socionext/   \
   st/  \
   ti/
diff --git a/drivers/phy/socionext/Kconfig b/drivers/phy/socionext/Kconfig
new file mode 100644
index 000..4a172fc
--- /dev/null
+++ b/drivers/phy/socionext/Kconfig
@@ -0,0 +1,12 @@
+#
+# PHY drivers for Socionext platforms.
+#
+
+config PHY_UNIPHIER_USB3
+   tristate "UniPhier USB3 PHY driver"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on OF && HAS_IOMEM
+   select GENERIC_PHY
+   help
+ Enable this to support USB PHY implemented in USB3 controller
+ on UniPhier SoCs. This controller supports USB3.0 and lower speed.
diff --git a/drivers/phy/socionext/Makefile b/drivers/phy/socionext/Makefile
new file mode 100644
index 000..e230fa31
--- /dev/null
+++ b/drivers/phy/socionext/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_PHY_UNIPHIER_USB3)+= phy-uniphier-usb3hs.o 
phy-uniphier-usb3ss.o
diff --git a/drivers/phy/socionext/phy-uniphier-usb3hs.c 
b/drivers/phy/socionext/phy-uniphier-usb3hs.c
new file mode 100644
index 000..b1b048b
--- /dev/null
+++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller
+ * Copyright 2015-2018 Socionext Inc.
+ * Author:
+ *  Kunihiko Hayashi 
+ * Contributors:
+ *  Motoya Tanigawa 
+ *  Masami Hiramatsu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HSPHY_CFG0 0x0
+#define HSPHY_CFG0_HS_I_MASK   GENMASK(31, 28)
+#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26)
+#define HSPHY_CFG0_SWING_MASK  GENMASK(17, 16)
+#define HSPHY_CFG0_SEL_T_MASK  GENMASK(15, 12)
+#define HSPHY_CFG0_RTERM_MASK  GENMASK(7, 6)
+#define HSPHY_CFG0_TRIMMASK(HSPHY_CFG0_HS_I_MASK \
+| HSPHY_CFG0_SEL_T_MASK \
+| HSPHY_CFG0_RTERM_MASK)
+
+#define HSPHY_CFG1 0x4
+#define HSPHY_CFG1_DAT_EN  BIT(29)
+#define HSPHY_CFG1_ADR_EN  BIT(28)
+#define HSPHY_CFG1_ADR_MASKGENMASK(27, 16)
+#define HSPHY_CFG1_DAT_MASKGENMASK(23, 16)
+
+#define PHY_F(regno, msb, lsb) { (regno), (msb), (lsb) }
+
+#define LS_SLEWPHY_F(10, 6, 6) /* LS mode slew rate */
+#define FS_LS_DRV  PHY_F(10, 5, 5) /* FS/LS slew rate */
+
+#define MAX_PHY_PARAMS 2
+
+struct uniphier_u3hsphy_param {
+   struct {
+   int reg_no;
+   int msb;
+   int lsb;
+   } field;
+   u8 value;
+};
+
+struct uniphier_u3hsphy_trim_param {
+   unsigned int rterm;
+   unsigned int sel_t;
+   unsigned int hs_i;
+};
+
+#define trim_param_is_valid(p) ((p)->rterm || (p)->sel_t || (p)->hs_i)
+
+struct uniphier_u3hsphy_priv {
+   struct device *dev;
+   void __iomem *base;
+   struct clk *clk, *clk_parent, *clk_ext;
+   struct reset_control *rst, *rst_parent;
+   struct regulator *vbus;
+   const struct uniphier_u3hsphy_soc_data *data;
+};
+
+

[PATCH v3 4/4] phy: socionext: add USB2 PHY driver for UniPhier SoC

[Kunihiko Hayashi]

Add a driver for PHY interface built into USB2 controller implemented on
UniPhier SoCs. This driver supports HS-PHY for Pro4 and LD11.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/phy/socionext/Kconfig |  13 ++
 drivers/phy/socionext/Makefile|   1 +
 drivers/phy/socionext/phy-uniphier-usb2.c | 244 ++
 3 files changed, 258 insertions(+)
 create mode 100644 drivers/phy/socionext/phy-uniphier-usb2.c

diff --git a/drivers/phy/socionext/Kconfig b/drivers/phy/socionext/Kconfig
index 4a172fc..497ca38 100644
--- a/drivers/phy/socionext/Kconfig
+++ b/drivers/phy/socionext/Kconfig
@@ -2,6 +2,19 @@
 # PHY drivers for Socionext platforms.
 #
 
+config PHY_UNIPHIER_USB2
+   tristate "UniPhier USB2 PHY driver"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on OF && HAS_IOMEM
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support USB PHY implemented on USB2 controller
+ on UniPhier SoCs. This driver provides interface to interact
+ with USB 2.0 PHY that is part of the UniPhier SoC.
+ In case of Pro4, it is necessary to specify this USB2 PHY instead
+ of USB3 HS-PHY.
+
 config PHY_UNIPHIER_USB3
tristate "UniPhier USB3 PHY driver"
depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/phy/socionext/Makefile b/drivers/phy/socionext/Makefile
index e230fa31..91e4825 100644
--- a/drivers/phy/socionext/Makefile
+++ b/drivers/phy/socionext/Makefile
@@ -3,4 +3,5 @@
 # Makefile for the phy drivers.
 #
 
+obj-$(CONFIG_PHY_UNIPHIER_USB2)+= phy-uniphier-usb2.o
 obj-$(CONFIG_PHY_UNIPHIER_USB3)+= phy-uniphier-usb3hs.o 
phy-uniphier-usb3ss.o
diff --git a/drivers/phy/socionext/phy-uniphier-usb2.c 
b/drivers/phy/socionext/phy-uniphier-usb2.c
new file mode 100644
index 000..3f2086e
--- /dev/null
+++ b/drivers/phy/socionext/phy-uniphier-usb2.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * phy-uniphier-usb2.c - PHY driver for UniPhier USB2 controller
+ * Copyright 2015-2018 Socionext Inc.
+ * Author:
+ *  Kunihiko Hayashi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SG_USBPHY1CTRL 0x500
+#define SG_USBPHY1CTRL20x504
+#define SG_USBPHY2CTRL 0x508
+#define SG_USBPHY2CTRL20x50c   /* LD11 */
+#define SG_USBPHY12PLL 0x50c   /* Pro4 */
+#define SG_USBPHY3CTRL 0x510
+#define SG_USBPHY3CTRL20x514
+#define SG_USBPHY4CTRL 0x518   /* Pro4 */
+#define SG_USBPHY4CTRL20x51c   /* Pro4 */
+#define SG_USBPHY34PLL 0x51c   /* Pro4 */
+
+struct uniphier_u2phy_param {
+   u32 offset;
+   u32 value;
+};
+
+struct uniphier_u2phy_soc_data {
+   struct uniphier_u2phy_param config0;
+   struct uniphier_u2phy_param config1;
+};
+
+struct uniphier_u2phy_priv {
+   struct regmap *regmap;
+   struct phy *phy;
+   struct regulator *vbus;
+   const struct uniphier_u2phy_soc_data *data;
+   struct uniphier_u2phy_priv *next;
+};
+
+static int uniphier_u2phy_power_on(struct phy *phy)
+{
+   struct uniphier_u2phy_priv *priv = phy_get_drvdata(phy);
+   int ret = 0;
+
+   if (priv->vbus)
+   ret = regulator_enable(priv->vbus);
+
+   return ret;
+}
+
+static int uniphier_u2phy_power_off(struct phy *phy)
+{
+   struct uniphier_u2phy_priv *priv = phy_get_drvdata(phy);
+
+   if (priv->vbus)
+   regulator_disable(priv->vbus);
+
+   return 0;
+}
+
+static int uniphier_u2phy_init(struct phy *phy)
+{
+   struct uniphier_u2phy_priv *priv = phy_get_drvdata(phy);
+
+   if (!priv->data)
+   return 0;
+
+   regmap_write(priv->regmap, priv->data->config0.offset,
+priv->data->config0.value);
+   regmap_write(priv->regmap, priv->data->config1.offset,
+priv->data->config1.value);
+
+   return 0;
+}
+
+static struct phy *uniphier_u2phy_xlate(struct device *dev,
+   struct of_phandle_args *args)
+{
+   struct uniphier_u2phy_priv *priv = dev_get_drvdata(dev);
+
+   while (priv && args->np != priv->phy->dev.of_node)
+   priv = priv->next;
+
+   if (!priv) {
+   dev_err(dev, "Failed to find appropriate phy\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   return priv->phy;
+}
+
+static const struct phy_ops uniphier_u2phy_ops = {
+   .init  = uniphier_u2phy_init,
+   .power_on  = uniphier_u2phy_power_on,
+   .power_off = uniphier_u2phy_power_off,
+   .owner = THIS_MODULE,
+};
+
+static int uniphier_u2phy_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *parent, *child;
+   struct uniphier_u2phy_priv *priv = NULL, *next = NULL;
+   struct phy_provider *phy_provider;
+   struct regmap *reg

[PATCH v3 3/4] dt-bindings: phy: add DT bindings for UniPhier USB2 PHY driver

[Kunihiko Hayashi]

Add DT bindings for PHY interface built into USB2 controller
implemented on Socionext UniPhier SoCs.

Signed-off-by: Kunihiko Hayashi 
---
 .../devicetree/bindings/phy/uniphier-usb2-phy.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt 
b/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt
new file mode 100644
index 000..b43b282
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt
@@ -0,0 +1,45 @@
+Socionext UniPhier USB2 PHY
+
+This describes the devicetree bindings for PHY interface built into
+USB2 controller implemented on Socionext UniPhier SoCs.
+
+Pro4 SoC has both USB2 and USB3 host controllers, however, this USB3
+controller doesn't include its own High-Speed PHY. This needs to specify
+USB2 PHY instead of USB3 HS-PHY.
+
+Required properties:
+- compatible: Should contain one of the following:
+"socionext,uniphier-pro4-usb2-phy" - for Pro4 SoC
+"socionext,uniphier-ld11-usb2-phy" - for LD11 SoC
+
+Sub-nodes:
+Each PHY should be represented as a sub-node.
+
+Sub-nodes required properties:
+- #phy-cells: Should be 0.
+- reg: The number of the PHY.
+
+Sub-nodes optional properties:
+- vbus-supply: A phandle to the regulator for USB VBUS.
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties.
+
+Example:
+   soc-glue@5f80 {
+   ...
+   usb-phy {
+   compatible = "socionext,uniphier-ld11-usb2-phy";
+   usb_phy0: phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+   ...
+   };
+   };
+
+   usb@5a800100 {
+   compatible = "socionext,uniphier-ehci", "generic-ehci";
+   ...
+   phy-names = "usb";
+   phys = <&usb_phy0>;
+   };
-- 
2.7.4

Re: [PATCH] IB/ucm: fix UCM link error

[Jason Gunthorpe]

On Tue, Aug 21, 2018 at 04:20:44PM +0200, Arnd Bergmann wrote:
> Building UCM with CONFIG_INFINIBAND_USER_ACCESS=m results in a
> set of link errors including:
> 
> drivers/infiniband/core/ucm.o: In function `ib_ucm_event_handler':
> ucm.c:(.text+0x6dc): undefined reference to `ib_copy_path_rec_to_user'
> drivers/infiniband/core/ucma.o: In function `ucma_event_handler':
> ucma.c:(.text+0xdc0): undefined reference to `ib_copy_ah_attr_to_user'
> 
> To get it to build-test again, this makes the option itself a
> tristate, which lets Kconfig figure out the dependency correctly.
> 
> Fixes: 486edfb1039d ("IB/ucm: Fix compiling ucm.c")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to for-rc

But that fixes line isn't right is it?

Should it be

commit 7a8690ed6f5346f6738971892205e91d39b6b901
Author: Leon Romanovsky 
Date:   Wed May 23 08:22:11 2018 +0300

RDMA/ucm: Mark UCM interface as BROKEN

Which added the config in the first place??

Thanks,
Jason

> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 1d6f5710d1df..176b943dfec9 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -35,7 +35,7 @@ config INFINIBAND_USER_ACCESS
> rdma-core .
>  
>  config INFINIBAND_USER_ACCESS_UCM
> - bool "Userspace CM (UCM, DEPRECATED)"
> + tristate "Userspace CM (UCM, DEPRECATED)"
>   depends on BROKEN || COMPILE_TEST
>   depends on INFINIBAND_USER_ACCESS
>   help

Re: [PATCH] PM / OPP: Refactor counting of added OPPs for v2 to avoid unsupported OPPs

[Dave Gerlach]

Hi,
On 08/21/2018 10:10 PM, Dave Gerlach wrote:
> Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
> the operating-points-v2 table in the device tree and calls
> _opp_add_static_v2 for each to add them to the table. It counts each
> iteration through this loop as an added OPP, however on platforms making
> use of the opp-supported-hw property, _opp_add_static_v2 does not add
> OPPs that are not seen as supported on the platform but still returns
> success, as this is valid. Because of this the count variable will
> contain the number of OPP nodes in the table in device tree but not
> necessarily the ones that are supported and actually added.
> 
> As this count value is what is checked to determine if there are any
> valid OPPs, if a platform has an operating-points-v2 table with all OPP
> nodes containing opp-supported-hw values that are not currently
> supported then _of_add_opp_table_v2 will fail to abort as it should due
> to an empty table.
> 
> Additionally, since commit 3ba98324e81a ("PM / OPP: Get
> performance state using genpd helper"), the same count variable is
> compared against the number of OPPs containing performance states and
> requires that either all or none have pstates set, however in the case
> of any opp table that has any entries that do not get added by
> _opp_add_static_v2 due to incompatible opp-supported-hw fields, these
> numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
> 
> In order to ensure the count variable reflects the number of OPPs
> actually in the table, increment it during the existing loop which walks
> the opp table to check if pstate is set and then use that for the
> aforementioned checks.
> 
> Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
> Signed-off-by: Dave Gerlach 
> ---

This is needed to fix cpufreq probe on TI am335x platforms. Seems that
arch/arm/boot/dts/am33xx.dtsi is the only operating-points-v2 table with
multiple opp-supported-hw entries which may not all be supported at once, and
this caused the count differences that led me here.

Regards,
Dave

>  drivers/opp/of.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 7af0ddec936b..f288f83a2e62 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -399,8 +399,6 @@ static int _of_add_opp_table_v2(struct device *dev, 
> struct device_node *opp_np)
>  
>   /* We have opp-table node now, iterate over it and add OPPs */
>   for_each_available_child_of_node(opp_np, np) {
> - count++;
> -
>   ret = _opp_add_static_v2(opp_table, dev, np);
>   if (ret) {
>   dev_err(dev, "%s: Failed to add OPP, %d\n", __func__,
> @@ -411,15 +409,22 @@ static int _of_add_opp_table_v2(struct device *dev, 
> struct device_node *opp_np)
>   }
>   }
>  
> + /*
> +  * Iterate over the list of OPPs that were actually added, as
> +  * OPPs not supported by the hardware will be ignored by
> +  * _opp_add_static_v2 above.
> +  */
> + list_for_each_entry(opp, &opp_table->opp_list, node) {
> + count++;
> + pstate_count += !!opp->pstate;
> + }
> +
>   /* There should be one of more OPP defined */
>   if (WARN_ON(!count)) {
>   ret = -ENOENT;
>   goto put_opp_table;
>   }
>  
> - list_for_each_entry(opp, &opp_table->opp_list, node)
> - pstate_count += !!opp->pstate;
> -
>   /* Either all or none of the nodes shall have performance state set */
>   if (pstate_count && pstate_count != count) {
>   dev_err(dev, "Not all nodes have performance state set (%d: 
> %d)\n",
> 

[PATCH] PM / OPP: Refactor counting of added OPPs for v2 to avoid unsupported OPPs

[Dave Gerlach]

Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however on platforms making
use of the opp-supported-hw property, _opp_add_static_v2 does not add
OPPs that are not seen as supported on the platform but still returns
success, as this is valid. Because of this the count variable will
contain the number of OPP nodes in the table in device tree but not
necessarily the ones that are supported and actually added.

As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.

Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.

In order to ensure the count variable reflects the number of OPPs
actually in the table, increment it during the existing loop which walks
the opp table to check if pstate is set and then use that for the
aforementioned checks.

Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Signed-off-by: Dave Gerlach 
---
 drivers/opp/of.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 7af0ddec936b..f288f83a2e62 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -399,8 +399,6 @@ static int _of_add_opp_table_v2(struct device *dev, struct 
device_node *opp_np)
 
/* We have opp-table node now, iterate over it and add OPPs */
for_each_available_child_of_node(opp_np, np) {
-   count++;
-
ret = _opp_add_static_v2(opp_table, dev, np);
if (ret) {
dev_err(dev, "%s: Failed to add OPP, %d\n", __func__,
@@ -411,15 +409,22 @@ static int _of_add_opp_table_v2(struct device *dev, 
struct device_node *opp_np)
}
}
 
+   /*
+* Iterate over the list of OPPs that were actually added, as
+* OPPs not supported by the hardware will be ignored by
+* _opp_add_static_v2 above.
+*/
+   list_for_each_entry(opp, &opp_table->opp_list, node) {
+   count++;
+   pstate_count += !!opp->pstate;
+   }
+
/* There should be one of more OPP defined */
if (WARN_ON(!count)) {
ret = -ENOENT;
goto put_opp_table;
}
 
-   list_for_each_entry(opp, &opp_table->opp_list, node)
-   pstate_count += !!opp->pstate;
-
/* Either all or none of the nodes shall have performance state set */
if (pstate_count && pstate_count != count) {
dev_err(dev, "Not all nodes have performance state set (%d: 
%d)\n",
-- 
2.16.1

[PATCH v11 1/3] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID

[Jia He]

Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a new config option so it can move
memblock_next_valid_pfn to generic code file. All the latter optimizations
are based on this config.

The memblock initialization time on arm/arm64 can benefit from this.

Signed-off-by: Jia He 
Reviewed-by: Pavel Tatashin 
---
 arch/arm/Kconfig   | 1 +
 arch/arm64/Kconfig | 1 +
 mm/Kconfig | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 843edfd..d3c7705 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1641,6 +1641,7 @@ config ARCH_SELECT_MEMORY_MODEL
 
 config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
+   select HAVE_MEMBLOCK_PFN_VALID
 
 config HAVE_GENERIC_GUP
def_bool y
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 42c090c..d4119e6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -777,6 +777,7 @@ config ARCH_SELECT_MEMORY_MODEL
 
 config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
+   select HAVE_MEMBLOCK_PFN_VALID
 
 config HW_PERF_EVENTS
def_bool y
diff --git a/mm/Kconfig b/mm/Kconfig
index 94af022..28fcf54 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -137,6 +137,9 @@ config HAVE_MEMBLOCK_NODE_MAP
 config HAVE_MEMBLOCK_PHYS_MAP
bool
 
+config HAVE_MEMBLOCK_PFN_VALID
+   bool
+
 config HAVE_GENERIC_GUP
bool
 
-- 
1.8.3.1

[PATCH v11 3/3] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn

[Jia He]

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement.

E.g. if pfn and pfn+1 are in the same memblock region, we can simply pfn++
instead of doing the binary search in memblock_next_valid_pfn.

Furthermore, if the pfn is in a gap of two memory region, skip to next
region directly if possible.

Attached the memblock region information in my server.
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0020-0x]
[0.00]   Normal   [mem 0x0001-0x0017]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0020-0x0021]
[0.00]   node   0: [mem 0x0082-0x0307]
[0.00]   node   0: [mem 0x0308-0x0308]
[0.00]   node   0: [mem 0x0309-0x031f]
[0.00]   node   0: [mem 0x0320-0x033f]
[0.00]   node   0: [mem 0x0341-0x034f]
[0.00]   node   0: [mem 0x0350-0x0351]
[0.00]   node   0: [mem 0x0352-0x0353]
[0.00]   node   0: [mem 0x0354-0x03e3]
[0.00]   node   0: [mem 0x03e4-0x03e7]
[0.00]   node   0: [mem 0x03e8-0x03ec]
[0.00]   node   0: [mem 0x03ed-0x03ed5fff]
[0.00]   node   0: [mem 0x03ed6000-0x06eeafff]
[0.00]   node   0: [mem 0x06eeb000-0x0710]
[0.00]   node   0: [mem 0x0711-0x07f0]
[0.00]   node   0: [mem 0x07f1-0x07fa]
[0.00]   node   0: [mem 0x07fb-0x0806]
[0.00]   node   0: [mem 0x0807-0x080a]
[0.00]   node   0: [mem 0x080b-0x0832]
[0.00]   node   0: [mem 0x0833-0x0836]
[0.00]   node   0: [mem 0x0837-0x0838]
[0.00]   node   0: [mem 0x0839-0x083a9fff]
[0.00]   node   0: [mem 0x083aa000-0x083bbfff]
[0.00]   node   0: [mem 0x083bc000-0x083f]
[0.00]   node   0: [mem 0x0840-0x0841]
[0.00]   node   0: [mem 0x0842-0x0843]
[0.00]   node   0: [mem 0x0844-0x0865]
[0.00]   node   0: [mem 0x0866-0x0869]
[0.00]   node   0: [mem 0x086a-0x086a]
[0.00]   node   0: [mem 0x086b-0x086e]
[0.00]   node   0: [mem 0x086f-0x08b6]
[0.00]   node   0: [mem 0x08b7-0x08bb]
[0.00]   node   0: [mem 0x08bc-0x08ed]
[0.00]   node   0: [mem 0x08ee-0x08ee0fff]
[0.00]   node   0: [mem 0x08ee1000-0x08ee2fff]
[0.00]   node   0: [mem 0x08ee3000-0x0dec]
[0.00]   node   0: [mem 0x0ded-0x0def]
[0.00]   node   0: [mem 0x0df0-0x0fff]
[0.00]   node   0: [mem 0x1080-0x17fe]
[0.00]   node   0: [mem 0x1c00-0x1c00]
[0.00]   node   0: [mem 0x1c01-0x1c7f]
[0.00]   node   0: [mem 0x1c81-0x7efb]
[0.00]   node   0: [mem 0x7efc-0x7efd]
[0.00]   node   0: [mem 0x7efe-0x7efe]
[0.00]   node   0: [mem 0x7eff-0x7eff]
[0.00]   node   0: [mem 0x7f00-0x0017]
[0.00] Initmem setup node 0 [mem
0x0020-0x0017]
[0.00] On node 0 totalpages: 25145296
[0.00]   DMA32 zone: 16376 pages used for memmap
[0.00]   DMA32 zone: 0 pages reserved
[0.00]   DMA32 zone: 1028048 pages, LIFO batch:31
[0.00]   Normal zone: 376832 pages used for memmap
[0.00]   Normal zone: 24117248 pages, LIFO batch:31

Signed-off-by: Jia He 
Reviewed-by: Pavel Tatashin 
---
 mm/memblock.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 077ca62..46cb6be 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1144,28 +1144,49 @@ int __init_memblock memblock_set_node(phys_addr_t base, 
phys_addr_t size,
 unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
 {
struct memblock_type *type = &memblock.memory;
+   struct memblock_region *regions = type->regions;
unsigned int right = type->

[PATCH v11 2/3] mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64

[Jia He]

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.

But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
Daniel said:
"On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines."

About the performance consideration:
As said by James in b92df1de5,
"I have tested this patch on a virtual model of a Samurai CPU
with a sparse memory map.  The kernel boot time drops from 109 to
62 seconds."

Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 
---
 include/linux/mmzone.h |  9 +
 mm/memblock.c  | 30 ++
 mm/page_alloc.c|  5 -
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 32699b2..8e5e20b 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1266,6 +1266,10 @@ static inline int pfn_present(unsigned long pfn)
 #endif
 
 #define early_pfn_valid(pfn)   pfn_valid(pfn)
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+extern unsigned long memblock_next_valid_pfn(unsigned long pfn);
+#define next_valid_pfn(pfn)memblock_next_valid_pfn(pfn)
+#endif
 void sparse_init(void);
 #else
 #define sparse_init()  do {} while (0)
@@ -1287,6 +1291,11 @@ struct mminit_pfnnid_cache {
 #define early_pfn_valid(pfn)   (1)
 #endif
 
+/* fallback to default definitions*/
+#ifndef next_valid_pfn
+#define next_valid_pfn(pfn)(pfn + 1)
+#endif
+
 void memory_present(int nid, unsigned long start, unsigned long end);
 
 /*
diff --git a/mm/memblock.c b/mm/memblock.c
index 3d03866..077ca62 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1140,6 +1140,36 @@ int __init_memblock memblock_set_node(phys_addr_t base, 
phys_addr_t size,
 }
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
+{
+   struct memblock_type *type = &memblock.memory;
+   unsigned int right = type->cnt;
+   unsigned int mid, left = 0;
+   phys_addr_t addr = PFN_PHYS(++pfn);
+
+   do {
+   mid = (right + left) / 2;
+
+   if (addr < type->regions[mid].base)
+   right = mid;
+   else if (addr >= (type->regions[mid].base +
+ type->regions[mid].size))
+   left = mid + 1;
+   else {
+   /* addr is within the region, so pfn is valid */
+   return pfn;
+   }
+   } while (left < right);
+
+   if (right == type->cnt)
+   return -1UL;
+   else
+   return PHYS_PFN(type->regions[right].base);
+}
+EXPORT_SYMBOL(memblock_next_valid_pfn);
+#endif /*CONFIG_HAVE_MEMBLOCK_PFN_VALID*/
+
 static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
phys_addr_t align, phys_addr_t start,
phys_addr_t end, int nid, ulong flags)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cd3c7b9..607deff 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5485,8 +5485,11 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
if (context != MEMMAP_EARLY)
goto not_early;
 
-   if (!early_pfn_valid(pfn))
+   if (!early_pfn_valid(pfn)) {
+   pfn = next_valid_pfn(pfn) - 1;
continue;
+   }
+
if (!early_pfn_in_nid(pfn, nid))
continue;
if (!update_defer_init(pgdat, pfn, end_pfn, &nr_initialised))
-- 
1.8.3.1

[PATCH v11 0/3] remain and optimize memblock_next_valid_pfn on arm and arm64

[Jia He]

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.

But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.

More from what Daniel said:
"On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines."

About the performance consideration:
As said by James in b92df1de5,
"I have tested this patch on a virtual model of a Samurai CPU with a
sparse memory map.  The kernel boot time drops from 109 to 62 seconds."
Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.

Besides we can remain memblock_next_valid_pfn, there is still some room
for improvement. After this set, I can see the time overhead of memmap_init
is reduced from 27956us to 13537us in my armv8a server(QDF2400 with 96G
memory, pagesize 64k). I believe arm server will benefit more if memory is
larger than TBs

Patch 1 introduces new config to make codes more generic
Patch 2 remains the memblock_next_valid_pfn on arm and arm64,this patch is
originated from b92df1de5
Patch 3 optimizes the memblock_next_valid_pfn()

Changelog:
V11:- drop patch#4-6, refine the codes
V10:- move codes to memblock.c, refine the performance consideration
V9: - rebase to mmotm master, refine the log description. No major changes
V8: - introduce new config and move generic code to early_pfn.h
- optimize memblock_next_valid_pfn as suggested by Matthew Wilcox
V7: - fix i386 compilation error. refine the commit description
V6: - simplify the codes, move arm/arm64 common codes to one file.
- refine patches as suggested by Danial Vacek and Ard Biesheuvel
V5: - further refining as suggested by Danial Vacek. Make codes
  arm/arm64 more arch specific
V4: - refine patches as suggested by Danial Vacek and Wei Yang
- optimized on arm besides arm64
V3: - fix 2 issues reported by kbuild test robot
V2: - rebase to mmotm latest
- remain memblock_next_valid_pfn on arm64
- refine memblock_search_pfn_regions and pfn_valid_region

Jia He (3):
  arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
  mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64
  mm: page_alloc: reduce unnecessary binary search in
memblock_next_valid_pfn

 arch/arm/Kconfig   |  1 +
 arch/arm64/Kconfig |  1 +
 include/linux/mmzone.h |  9 +
 mm/Kconfig |  3 +++
 mm/memblock.c  | 51 ++
 mm/page_alloc.c|  5 -
 6 files changed, 69 insertions(+), 1 deletion(-)

-- 
1.8.3.1

Re: [GIT PULL] XArray for 4.19

[Linus Torvalds]

On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox  wrote:
>
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?

Absolutely.

Or preferably not rebasing at all, just starting from a good solid
base for new development in the first place.

Sometimes you start from the wrong point, and decide that you really
need to rebase, but then you should rebase to a more stable point, not
on top of some random independent development.

Rebasing can be a really good tool to clean up development that was
haphazard - maybe as you  go along you notice that something you did
earlier turned out to be counter-productive, so you rebase and clean
up your history that has not been made public yet.

But when you send me a big new feature, the absolutely *last* thing I
want to ever see is to see it based on some random unstable base.

And rebasing to avoid merge conflicts is *always* the wrong thing to
do, unless the reason you're rebasing is "hey, I wrote this feature
ages ago, I need to really refresh it to a more modern and stable
kernel, so I'll rebase it onto the current last release instead, so
that I have a good starting point".

And even then the basic reason is not so much that there were
conflicts, but that you just want your series to make more sense on
its own, and not have one horribly complex merge that is just due to
the fact that it was based on something ancient.

The absolute last thing I want to see during the merge window is
multiple independent features that have been tied together just
because they are rebased on top of each other.

Because that means - as in this case - that if one branch has
problems, it now affects all of them.

Merge conflicts aren't bad. In 99% of all cases, the conflict is
trivial to solve. And the cost of trying to deal with them with
rebasing is much much higher.

   Linus

Re: [PATCH v2] dmaengine: sprd: Support DMA link-list mode

[Baolin Wang]

Hi Vinod,

On 9 August 2018 at 15:05, Baolin Wang  wrote:
> From: Eric Long 
>
> The Spreadtrum DMA can support the link-list transaction mode, which means
> DMA controller can do transaction one by one automatically once we linked
> these transaction by link-list register.
>
> Signed-off-by: Eric Long 
> Signed-off-by: Baolin Wang 
> ---
> Changes since v1:
>  - Remove sprd_dma_fill_chn_desc() function.
>  - Remove the redundant validation of 'sglen' in 
> sprd_dma_fill_linklist_desc().
>  - Add some comments make code more clear.
>  - Fix the typos.
> ---

Do you have any comments for the v2 patch? Thanks.

>  drivers/dma/sprd-dma.c   |   81 
> ++
>  include/linux/dma/sprd-dma.h |   69 +++
>  2 files changed, 143 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
> index 55df0d4..38d4e4f 100644
> --- a/drivers/dma/sprd-dma.c
> +++ b/drivers/dma/sprd-dma.c
> @@ -68,6 +68,7 @@
>
>  /* SPRD_DMA_CHN_CFG register definition */
>  #define SPRD_DMA_CHN_ENBIT(0)
> +#define SPRD_DMA_LINKLIST_EN   BIT(4)
>  #define SPRD_DMA_WAIT_BDONE_OFFSET 24
>  #define SPRD_DMA_DONOT_WAIT_BDONE  1
>
> @@ -103,7 +104,7 @@
>  #define SPRD_DMA_REQ_MODE_MASK GENMASK(1, 0)
>  #define SPRD_DMA_FIX_SEL_OFFSET21
>  #define SPRD_DMA_FIX_EN_OFFSET 20
> -#define SPRD_DMA_LLIST_END_OFFSET  19
> +#define SPRD_DMA_LLIST_END BIT(19)
>  #define SPRD_DMA_FRG_LEN_MASK  GENMASK(16, 0)
>
>  /* SPRD_DMA_CHN_BLK_LEN register definition */
> @@ -164,6 +165,7 @@ struct sprd_dma_desc {
>  struct sprd_dma_chn {
> struct virt_dma_chanvc;
> void __iomem*chn_base;
> +   struct sprd_dma_linklistlinklist;
> struct dma_slave_config slave_cfg;
> u32 chn_num;
> u32 dev_id;
> @@ -582,7 +584,8 @@ static int sprd_dma_get_step(enum dma_slave_buswidth 
> buswidth)
>  }
>
>  static int sprd_dma_fill_desc(struct dma_chan *chan,
> - struct sprd_dma_desc *sdesc,
> + struct sprd_dma_chn_hw *hw,
> + unsigned int sglen, int sg_index,
>   dma_addr_t src, dma_addr_t dst, u32 len,
>   enum dma_transfer_direction dir,
>   unsigned long flags,
> @@ -590,7 +593,6 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
>  {
> struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
> struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> -   struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
> u32 req_mode = (flags >> SPRD_DMA_REQ_SHIFT) & SPRD_DMA_REQ_MODE_MASK;
> u32 int_mode = flags & SPRD_DMA_INT_MASK;
> int src_datawidth, dst_datawidth, src_step, dst_step;
> @@ -670,12 +672,52 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
> temp |= (src_step & SPRD_DMA_TRSF_STEP_MASK) << 
> SPRD_DMA_SRC_TRSF_STEP_OFFSET;
> hw->trsf_step = temp;
>
> +   /* link-list configuration */
> +   if (schan->linklist.phy_addr) {
> +   if (sg_index == sglen - 1)
> +   hw->frg_len |= SPRD_DMA_LLIST_END;
> +
> +   hw->cfg |= SPRD_DMA_LINKLIST_EN;
> +
> +   /* link-list index */
> +   temp = (sg_index + 1) % sglen;
> +   /* Next link-list configuration's physical address offset */
> +   temp = temp * sizeof(*hw) + SPRD_DMA_CHN_SRC_ADDR;
> +   /*
> +* Set the link-list pointer point to next link-list
> +* configuration's physical address.
> +*/
> +   hw->llist_ptr = schan->linklist.phy_addr + temp;
> +   } else {
> +   hw->llist_ptr = 0;
> +   }
> +
> hw->frg_step = 0;
> hw->src_blk_step = 0;
> hw->des_blk_step = 0;
> return 0;
>  }
>
> +static int sprd_dma_fill_linklist_desc(struct dma_chan *chan,
> +  unsigned int sglen, int sg_index,
> +  dma_addr_t src, dma_addr_t dst, u32 
> len,
> +  enum dma_transfer_direction dir,
> +  unsigned long flags,
> +  struct dma_slave_config *slave_cfg)
> +{
> +   struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> +   struct sprd_dma_chn_hw *hw;
> +
> +   if (!schan->linklist.virt_addr)
> +   return -EINVAL;
> +
> +   hw = (struct sprd_dma_chn_hw *)(schan->linklist.virt_addr +
> +   sg_index * sizeof(*hw));
> +
> +   return sprd_dma_fill_desc(chan, hw, sglen, sg_index, src, dst, len,
> + dir, flags, slave_cfg);
> +}
> +
>  static stru

Re: [GIT PULL] XArray for 4.19

[Matthew Wilcox]

On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox  wrote:
> >
> > Please consider pulling the XArray patch set.
> 
> So this merge window has been horrible, but I was just about to start
> looking at it.
> 
> And no. I'm not going to pull this.
> 
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.

I said in the pull request ...

  There are two conflicts I wanted to flag; the first is against the
  linux-nvdimm tree.  I rebased on top of one of the branches that went
  into that tree, so if you pull my tree before linux-nvdimm, you'll get
  fifteen commits I've had no involvement with.

Dan asked me to do that so that his commit (which I had no involvement
with) would be easier to backport.  At the time I thought this was a
reasonable request; I know this API change is disruptive and I wanted
to accommodate that.  I didn't know his patch was "complete garbage";
I didn't review it.

So, should I have based just on your tree and sent you a description of
what a resolved conflict should look like?

> And since I won't be merging this, I clearly won't be merging your
> other pull request that depended on this either.

I can yank most of the patches (all but the last two, iirc) out of the
IDA patchset and submit those as a separate pull request.  Would that
be acceptable?  I'm really struggling to juggle all the pieces here to
get them merged.

[PATCH v2] dma: mic_x100_dma: use devm_kzalloc to fix an issue

[Huang Shijie]

The following patch introduced an issue.
commit f6206f00d8c5 ("dmaengine: mic_x100_dma: use the new helper to 
simplify the code")

This issue is :

kfree(mic_dma_dev)
.
dma_async_device_unregister(mic_dma_dev->device);

Free the memory, and use it again.

So use devm_kzalloc to allocate mic_dma_dev to fix it.

When the Devres try to release the resources, it will call release at the
following order:

dma_async_device_unregister(mic_dma_dev->device);
.
kfree(mic_dma_dev)

Fixes: f6206f00d8c5 ("dmaengine: mic_x100_dma: use the new helper to simplify 
the code")
Signed-off-by: Huang Shijie 
---
v1 --> v2:
 Change the commit message and title
---
 drivers/dma/mic_x100_dma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
index b76cb17d879c..adfd316db1a8 100644
--- a/drivers/dma/mic_x100_dma.c
+++ b/drivers/dma/mic_x100_dma.c
@@ -639,7 +639,7 @@ static struct mic_dma_device *mic_dma_dev_reg(struct 
mbus_device *mbdev,
int ret;
struct device *dev = &mbdev->dev;
 
-   mic_dma_dev = kzalloc(sizeof(*mic_dma_dev), GFP_KERNEL);
+   mic_dma_dev = devm_kzalloc(dev, sizeof(*mic_dma_dev), GFP_KERNEL);
if (!mic_dma_dev) {
ret = -ENOMEM;
goto alloc_error;
@@ -664,7 +664,6 @@ static struct mic_dma_device *mic_dma_dev_reg(struct 
mbus_device *mbdev,
 reg_error:
mic_dma_uninit(mic_dma_dev);
 init_error:
-   kfree(mic_dma_dev);
mic_dma_dev = NULL;
 alloc_error:
dev_err(dev, "Error at %s %d ret=%d\n", __func__, __LINE__, ret);
@@ -674,7 +673,6 @@ static struct mic_dma_device *mic_dma_dev_reg(struct 
mbus_device *mbdev,
 static void mic_dma_dev_unreg(struct mic_dma_device *mic_dma_dev)
 {
mic_dma_uninit(mic_dma_dev);
-   kfree(mic_dma_dev);
 }
 
 /* DEBUGFS CODE */
-- 
2.17.1

Re: [PATCH v2 0/2] mm: soft-offline: fix race against page allocation

[Mike Kravetz]

On 08/21/2018 06:37 PM, Naoya Horiguchi wrote:
> On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
>> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi 
>>  wrote:
>>
>>> I've updated the patchset based on feedbacks:
>>>
>>> - updated comments (from Andrew),
>>> - moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to 
>>> mm/memory-failure.c,
>>>   which is necessary to check the return code of 
>>> set_hwpoison_free_buddy_page(),
>>> - lkp bot reported a build error when only 1/2 is applied.
>>>
>>>   >mm/memory-failure.c: In function 'soft_offline_huge_page':
>>>   > >> mm/memory-failure.c:1610:8: error: implicit declaration of function
>>>   > 'set_hwpoison_free_buddy_page'; did you mean 'is_free_buddy_page'?
>>>   > [-Werror=implicit-function-declaration]
>>>   >if (set_hwpoison_free_buddy_page(page))
>>>   >^~~~
>>>   >is_free_buddy_page
>>>   >cc1: some warnings being treated as errors
>>>
>>>   set_hwpoison_free_buddy_page() is defined in 2/2, so we can't use it
>>>   in 1/2. Simply doing s/set_hwpoison_free_buddy_page/!TestSetPageHWPoison/
>>>   will fix this.
>>>
>>> v1: https://lkml.org/lkml/2018/7/12/968
>>>
>>
>> Quite a bit of discussion on these two, but no actual acks or
>> review-by's?
> 
> Really sorry for late response.
> Xishi provided feedback on previous version, but no final ack/reviewed-by.
> This fix should work on the reported issue, but rewriting soft-offlining
> without PageHWPoison flag would be the better fix (no actual patch yet.)
> I'm not sure this patch should go to mainline immediately.

FWIW - The 'migration of huge PMD shared pages' issue I am working was
originally triggered via soft-offline.  While working the issue, I tried
to exercise huge page soft-offline really hard to recreate the issue and
validate a fix.  However, I was more likely to hit the soft-offline race(s)
your patches address.  Therefore, I applied your patches to focus my testing
and validation on the migration of huge PMD shared pages issue.  That is sort
of a Tested-by :).

Just wanted to point out that it was pretty easy to hit this issue.  It
was easier than the issue I am working.  And, the issue I am trying to
address was seen in a real customer environment.  So, I would not be
surprised to see this issue in real customer environments as well.

If you (or others) think we should go forward with these patches, I can
spend some time doing a review.  Already did a 'quick look' some time back.
-- 
Mike Kravetz

Re: [GIT PULL] XArray for 4.19

[Linus Torvalds]

On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox  wrote:
>
> Please consider pulling the XArray patch set.

So this merge window has been horrible, but I was just about to start
looking at it.

And no. I'm not going to pull this.

For some unfathomable reason, you have based it on the libnvdimm tree.
I don't understand at all wjhy you did that.

That libnvdimm tree didn't get merged., because it had complete
garbage in the mm/ code. And yes, that buggy shit was what you based
the radix tree code on.

I seriously have no idea why you have based it on some unstable random
tree in the first place.

But basing it on something that I independently refused to pull
because of obvious bugs from just a quick scan - that completely
invalidates this pull request.

Why?

I guess it makes this merge window easier, since now I don't even have
to look at the code, but it annoys the hell out of me when things like
that happen.

There wasn't even a mention in the pull request about how this was all
based on some libnvdimm code that hadn't been merged yet.

But you must have known that, since you must have explicitly done the
pull request not against my tree, but against the bogus base branch.

And since I won't be merging this, I clearly won't be merging your
other pull request that depended on this either.

Why the f*ck were these features so interlinked to begin with?

  Linus

linux-next: manual merge of the akpm-current tree with the mips tree

[Stephen Rothwell]

Hi all,

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

  arch/Kconfig

between commit:

  04f264d3a8b0 ("compiler.h: Allow arch-specific asm/compiler.h")

from the mips tree and commit:

  7358e371b0ef ("arch: enable relative relocations for arm64, power and x86")

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/Kconfig
index 526a57457594,4426e9687d89..
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -848,14 -841,16 +848,24 @@@ config REFCOUNT_FUL
  against various use-after-free conditions that can be used in
  security flaw exploits.
  
 +config HAVE_ARCH_COMPILER_H
 +  bool
 +  help
 +An architecture can select this if it provides an
 +asm/compiler.h header that should be included after
 +linux/compiler-*.h in order to override macro definitions that those
 +headers generally provide.
 +
+ config HAVE_ARCH_PREL32_RELOCATIONS
+   bool
+   help
+ May be selected by an architecture if it supports place-relative
+ 32-bit relocations, both in the toolchain and in the module loader,
+ in which case relative references can be used in special sections
+ for PCI fixup, initcalls etc which are only half the size on 64 bit
+ architectures, and don't require runtime relocation on relocatable
+ kernels.
+ 
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"


pgpPJlVxFR9qr.pgp
Description: OpenPGP digital signature

Re: [PATCH v2] ARM: dma-mapping: always clear allocated buffers

[YueHaibing]

Russell, will you pick this patch?

On 2018/7/25 15:13, YueHaibing wrote:
> +CC  Christoph Hellwig 
> 
> On 2018/7/25 15:07, YueHaibing wrote:
>> Sean Wang reported dma_zalloc_coherent doesn't work as expect on his
>> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
>> doesn't honor __GFP_ZERO.
>>
>> As commit 6829e274a623 ("arm64: dma-mapping: always clear allocated buffers")
>> has pointed out,buffers allocated by dma_alloc_coherent() are always zeroed
>> on most architectures. some drivers rely on this 'feature'. Allocated buffer
>> might be also exposed to userspace with dma_mmap() call,so clearing it is
>> desired from security point of view to avoid exposing random memory to 
>> userspace.
>>
>> This patch unifies dma_alloc_coherent() behavior on ARM architecture with 
>> other
>> implementations by unconditionally zeroing allocated buffer.Also to fix
>> dma_zalloc_coherent behavior.
>>
>> Reported-by: Sean Wang 
>> Signed-off-by: YueHaibing 
>> Reviewed-by: zhong jiang 
>> ---
>> v2: reference more argument from arm64 commit as Christoph suggested
>> ---
>>  arch/arm/mm/dma-mapping.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 6656647..cf5882f 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -564,6 +564,7 @@ static void *__alloc_from_pool(size_t size, struct page 
>> **ret_page)
>>  
>>  *ret_page = phys_to_page(phys);
>>  ptr = (void *)val;
>> +memset(ptr, 0, size);
>>  }
>>  
>>  return ptr;
>>

Re: [PATCH v2 0/2] mm: soft-offline: fix race against page allocation

[Naoya Horiguchi]

On Wed, Aug 15, 2018 at 03:43:34PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 14:32:30 +0900 Naoya Horiguchi 
>  wrote:
> 
> > I've updated the patchset based on feedbacks:
> > 
> > - updated comments (from Andrew),
> > - moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to 
> > mm/memory-failure.c,
> >   which is necessary to check the return code of 
> > set_hwpoison_free_buddy_page(),
> > - lkp bot reported a build error when only 1/2 is applied.
> > 
> >   >mm/memory-failure.c: In function 'soft_offline_huge_page':
> >   > >> mm/memory-failure.c:1610:8: error: implicit declaration of function
> >   > 'set_hwpoison_free_buddy_page'; did you mean 'is_free_buddy_page'?
> >   > [-Werror=implicit-function-declaration]
> >   >if (set_hwpoison_free_buddy_page(page))
> >   >^~~~
> >   >is_free_buddy_page
> >   >cc1: some warnings being treated as errors
> > 
> >   set_hwpoison_free_buddy_page() is defined in 2/2, so we can't use it
> >   in 1/2. Simply doing s/set_hwpoison_free_buddy_page/!TestSetPageHWPoison/
> >   will fix this.
> > 
> > v1: https://lkml.org/lkml/2018/7/12/968
> > 
> 
> Quite a bit of discussion on these two, but no actual acks or
> review-by's?

Really sorry for late response.
Xishi provided feedback on previous version, but no final ack/reviewed-by.
This fix should work on the reported issue, but rewriting soft-offlining
without PageHWPoison flag would be the better fix (no actual patch yet.)
I'm not sure this patch should go to mainline immediately.

Thanks,
Naoya Horiguchi

Re: [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()

[Jia He]

Hi Andrew

On 8/22/2018 5:08 AM, Andrew Morton Wrote:
> On Tue, 21 Aug 2018 14:14:30 +0800 Jia He  wrote:
> 
>> Hi Pasha
>>
>> On 8/17/2018 9:08 AM, Pasha Tatashin Wrote:
>>>
 Signed-off-by: Jia He 
 ---
  mm/memblock.c | 37 +
  1 file changed, 29 insertions(+), 8 deletions(-)

 diff --git a/mm/memblock.c b/mm/memblock.c
 index ccad225..84f7fa7 100644
 --- a/mm/memblock.c
 +++ b/mm/memblock.c
 @@ -1140,31 +1140,52 @@ int __init_memblock memblock_set_node(phys_addr_t 
 base, phys_addr_t size,
  #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
  
  #ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
 +static int early_region_idx __init_memblock = -1;
>>>
>>> One comment:
>>>
>>> This should be __initdata, but even better bring it inside the function
>>> as local static variable.
>>>
>> Seems it should be __initdata_memblock instead of __initdata?
>>
> 
> Eh, it's 4 bytes.
> 
> It should however be local to the sole function which uses it.

Sorry, I am not clear for this comment^
early_region_idx records the *last* valid region idx in last
memblock_next_valid_pfn. So it should be static instead of local variable?

> 
> And what's this "ulong" thing?  mm/ uses unsigned long.

ok, will change it

-- 
Cheers,
Jia
> 
> --- 
> a/mm/memblock.c~mm-page_alloc-reduce-unnecessary-binary-search-in-memblock_next_valid_pfn-fix
> +++ a/mm/memblock.c
> @@ -1232,15 +1232,15 @@ int __init_memblock memblock_set_node(ph
>  #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
>  
>  #ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
> -static int early_region_idx __init_memblock = -1;
> -ulong __init_memblock memblock_next_valid_pfn(ulong pfn)
> +unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
>  {
>   struct memblock_type *type = &memblock.memory;
>   struct memblock_region *regions = type->regions;
>   uint right = type->cnt;
>   uint mid, left = 0;
> - ulong start_pfn, end_pfn, next_start_pfn;
> + unsigned long start_pfn, end_pfn, next_start_pfn;
>   phys_addr_t addr = PFN_PHYS(++pfn);
> + static int early_region_idx __initdata_memblock = -1;
>  
>   /* fast path, return pfn+1 if next pfn is in the same region */
>   if (early_region_idx != -1) {
> --- 
> a/include/linux/mmzone.h~mm-page_alloc-reduce-unnecessary-binary-search-in-memblock_next_valid_pfn-fix
> +++ a/include/linux/mmzone.h
> @@ -1269,7 +1269,7 @@ static inline int pfn_present(unsigned l
>  
>  #define early_pfn_valid(pfn) pfn_valid(pfn)
>  #ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
> -extern ulong memblock_next_valid_pfn(ulong pfn);
> +extern unsigned long memblock_next_valid_pfn(unsigned long pfn);
>  #define next_valid_pfn(pfn)  memblock_next_valid_pfn(pfn)
>  #endif
>  void sparse_init(void);
> _
> 
> 

Re: [PATCH v3 2/2] hugetlb: take PMD sharing into account when flushing tlb/caches

[kbuild test robot]

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   mm/rmap.o: In function `try_to_unmap_one':
   rmap.c:(.text+0x2708): undefined reference to `huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `__unmap_hugepage_range':
>> hugetlb.c:(.text+0x5530): undefined reference to `huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `unmap_hugepage_range':
   hugetlb.c:(.text+0x57bc): undefined reference to `huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `hugetlb_change_protection':
   hugetlb.c:(.text+0x7714): undefined reference to `huge_pmd_sharing_possible'
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/3] clk: ingenic: Add proper Kconfig entries

[kbuild test robot]

Hi Paul,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18 next-20180821]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paul-Cercueil/clk-ingenic-Add-proper-Kconfig-entries/20180822-003241
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/clk/ingenic/cgu.c:137:13: sparse: expression using sizeof(void)
>> drivers/clk/ingenic/cgu.c:137:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:138:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:138:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:141:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:141:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:142:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:142:13: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:408:15: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:408:15: sparse: expression using sizeof(void)
   drivers/clk/ingenic/cgu.c:409:15: sparse: expression using sizeof(void)
   include/linux/slab.h:631:13: sparse: undefined identifier 
'__builtin_mul_overflow'

vim +137 drivers/clk/ingenic/cgu.c

b066303f Paul Burton 2015-05-24  120  
b066303f Paul Burton 2015-05-24  121  static unsigned long
b066303f Paul Burton 2015-05-24  122  ingenic_pll_calc(const struct 
ingenic_cgu_clk_info *clk_info,
b066303f Paul Burton 2015-05-24  123 unsigned long rate, unsigned 
long parent_rate,
b066303f Paul Burton 2015-05-24  124 unsigned *pm, unsigned *pn, 
unsigned *pod)
b066303f Paul Burton 2015-05-24  125  {
b066303f Paul Burton 2015-05-24  126const struct ingenic_cgu_pll_info 
*pll_info;
b066303f Paul Burton 2015-05-24  127unsigned m, n, od;
b066303f Paul Burton 2015-05-24  128  
b066303f Paul Burton 2015-05-24  129pll_info = &clk_info->pll;
b066303f Paul Burton 2015-05-24  130od = 1;
b066303f Paul Burton 2015-05-24  131  
b066303f Paul Burton 2015-05-24  132/*
b066303f Paul Burton 2015-05-24  133 * The frequency after the input 
divider must be between 10 and 50 MHz.
b066303f Paul Burton 2015-05-24  134 * The highest divider yields the best 
resolution.
b066303f Paul Burton 2015-05-24  135 */
b066303f Paul Burton 2015-05-24  136n = parent_rate / (10 * MHZ);
b066303f Paul Burton 2015-05-24 @137n = min_t(unsigned, n, 1 << 
clk_info->pll.n_bits);
b066303f Paul Burton 2015-05-24  138n = max_t(unsigned, n, 
pll_info->n_offset);
b066303f Paul Burton 2015-05-24  139  
b066303f Paul Burton 2015-05-24  140m = (rate / MHZ) * od * n / 
(parent_rate / MHZ);
b066303f Paul Burton 2015-05-24  141m = min_t(unsigned, m, 1 << 
clk_info->pll.m_bits);
b066303f Paul Burton 2015-05-24  142m = max_t(unsigned, m, 
pll_info->m_offset);
b066303f Paul Burton 2015-05-24  143  
b066303f Paul Burton 2015-05-24  144if (pm)
b066303f Paul Burton 2015-05-24  145*pm = m;
b066303f Paul Burton 2015-05-24  146if (pn)
b066303f Paul Burton 2015-05-24  147*pn = n;
b066303f Paul Burton 2015-05-24  148if (pod)
b066303f Paul Burton 2015-05-24  149*pod = od;
b066303f Paul Burton 2015-05-24  150  
b066303f Paul Burton 2015-05-24  151return div_u64((u64)parent_rate * m, n 
* od);
b066303f Paul Burton 2015-05-24  152  }
b066303f Paul Burton 2015-05-24  153  

:: The code at line 137 was first introduced by commit
:: b066303fb3e72a902a1f94dc06636ce82c3a5577 clk: ingenic: add driver for 
Ingenic SoC CGU clocks

:: TO: Paul Burton 
:: CC: Ralf Baechle 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH] zram: fix bug storing backing_dev

[Peter Kalauskas]

On Tue, Aug 21, 2018 at 5:45 PM Sergey Senozhatsky
 wrote:
>
> Hi,
>
> Did you intend to remove lkml mailing list from Cc?
>

No, that was an accident. I resent it so it's on the record.

I will submit a v2 patch with an updated commit message then.

Re: [PATCH] zram: fix bug storing backing_dev

[Peter Kalauskas]

On Tue, Aug 14, 2018 at 04:45:23PM -0700, Andrew Morton wrote:
> The changelog doesn't describe the end-user impact of the bug, which is
> very desirable when tagging a patch for -stable backporting.  Can we
> have that paragraph please?

The end-user impact is that echoing to writeback_dev would not cause it
to change. Would the following statement suffice?

  Without this change, it is not possible to change writeback_dev unless
  the tool used to do so does not include a newline character.  For
  example, 'echo -n' or 'printf' would work, but 'echo' would not work.

I can also include Sergey's description of the bug if that would be
helpful.


On Thu, Aug 16, 2018 at 10:48:35AM +0900, Sergey Senozhatsky wrote:
> On (08/14/18 16:45), Andrew Morton wrote:
> > >
> > > > > - strlcpy(file_name, buf, len);
> > >
> > > This is quite interesting. The reason it worked before was the fact that
> > > strlcpy() copies 'len - 1' bytes, which is strlen(buf) - 1 in our case,
> > > so it accidentally didn't copy the trailing new line symbol. Which also
> > > means that "echo -n /dev/sdX" most likely was broken.
> > >
> >
> > I can't find the original email on lkml for some reason, but I
> > recreated the patch.
>
> Neither can I.
>

Sorry, I sent it to Minchan directly. I'll send PATCH v2 to lkml, if v2
is needed.


On Wed, Aug 15, 2018 at 08:32:26PM -0700, Andrew Morton wrote:
> On Thu, 16 Aug 2018 10:48:35 +0900 Sergey Senozhatsky 
>  wrote:
>
> > > The implementation might be able to use strim() somehow.
> >
> > strim() trims white-spaces.
>
> Which includes \n.
>

The if statement is already used by comp_algorithm_store in zram_drv.c,
so perhaps it should remain the if statement for consistency. What do
you think, should I use strim or the if statement?

Re: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages

[Mike Kravetz]

On 08/21/2018 05:51 PM, kbuild test robot wrote:
> Hi Mike,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=sparc64 
> 

Ok, this should take care of all the build errors.  Needed to address
!CONFIG_HUGETLB_PAGE and !CONFIG_ARCH_WANT_HUGE_PMD_SHARE.

>From 2868cea3ff33fccd03da9188dde2ae5b619bf300 Mon Sep 17 00:00:00 2001
From: Mike Kravetz 
Date: Tue, 21 Aug 2018 10:50:17 -0700
Subject: [PATCH v5 1/2] mm: migration: fix migration of huge PMD shared pages

The page migration code employs try_to_unmap() to try and unmap the
source page.  This is accomplished by using rmap_walk to find all
vmas where the page is mapped.  This search stops when page mapcount
is zero.  For shared PMD huge pages, the page map count is always 1
no matter the number of mappings.  Shared mappings are tracked via
the reference count of the PMD page.  Therefore, try_to_unmap stops
prematurely and does not completely unmap all mappings of the source
page.

This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the
target page.  Hence, data is lost.

This problem was originally seen as DB corruption of shared global
areas after a huge page was soft offlined due to ECC memory errors.
DB developers noticed they could reproduce the issue by (hotplug)
offlining memory used to back huge pages.  A simple testcase can
reproduce the problem by creating a shared PMD mapping (note that
this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on
x86)), and using migrate_pages() to migrate process pages between
nodes while continually writing to the huge pages being migrated.

To fix, have the try_to_unmap_one routine check for huge PMD sharing
by calling huge_pmd_unshare for hugetlbfs huge pages.  If it is a
shared mapping it will be 'unshared' which removes the page table
entry and drops the reference on the PMD page.  After this, flush
caches and TLB.

mmu notifiers are called before locking page tables, but we can not
be sure of PMD sharing until page tables are locked.  Therefore,
check for the possibility of PMD sharing before locking so that
notifiers can prepare for the worst possible case.

Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz 
---
 include/linux/hugetlb.h | 14 +
 mm/hugetlb.c| 46 +
 mm/rmap.c   | 42 ++---
 3 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 36fa6a2a82e3..840b43a085cc 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
 pte_t *huge_pte_offset(struct mm_struct *mm,
   unsigned long addr, unsigned long sz);
 int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
+   unsigned long *start, unsigned long *end);
 struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
  int write);
 struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
 }
 
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+   pte_t *ptep)
+{
+   return 0;
+}
+
+static inline bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
+   unsigned long *start, unsigned long *end)
+{
+   return false;
+}
+
 #define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n)({ BUG(); 0; })
 #define follow_huge_addr(mm, addr, write)  ERR_PTR(-EINVAL)
 #define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3103099f64fd..f085019a4724 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4555,6 +4555,9 @@ static bool vma_shareable(struct vm_area_struct *vma, 
unsigned long addr)
 
/*
 * check on proper vm_flags and page table alignment
+*
+*

Re: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages

[kbuild test robot]

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   mm/rmap.o: In function `try_to_unmap_one':
>> rmap.c:(.text+0x2708): undefined reference to `huge_pmd_sharing_possible'
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [RFC][PATCH] lib/string: introduce sysfs_strncpy() and sysfs_strlcpy()

[Sergey Senozhatsky]

On (08/21/18 15:00), Andy Shevchenko wrote:
> > Returning the length of dst/-EOVERFLOW is a bit inconvenient, because
> > "the length" forces us to have size_t return, which is unsigned.
> 
> We have for ages ssize_t to workaround that.

OK.

[..]
> Wouldn't be better to split out something like
> 
> strnstrip() out of strim(), with simultaneous changes to strim(),
> strstrip(), and use it here?

Maybe yes, maybe not. strim() modifies the original string right after
it's done moving the end pointer. We can't do that in strcpy_trim() and
need to keep the original source string. So probably these two functions
don't have that much of a common code after all.

-ss

Re: [PATCH 1/1] perf/x86/intel: make error messages less confusing

[Andi Kleen]

On Tue, Aug 21, 2018 at 04:05:22PM -0700, Eduardo Valentin wrote:
> On Tue, Aug 21, 2018 at 03:09:37PM -0700, Andi Kleen wrote:
> > On Tue, Aug 21, 2018 at 02:15:28PM -0700, Eduardo Valentin wrote:
> > > On a system with X86_FEATURE_ARCH_PERFMON disabled
> > > and with a model not known by family PMU drivers,
> > > user gets a kernel message log like the following:
> > > [ 0.100114] Performance Events: unsupported p6 CPU model 85 no PMU 
> > > driver, software events only.
> > > 
> > > The "unsupported .. CPU" part may be confusing for some
> > > users. Rewording the messages on the failure path to:
> > > [ 0.667154] Performance Events: unknown p6 PMU on CPU model 85: 
> > > !X86_FEATURE_ARCH_PERFMON: no PMU driver, software events only.
> > 
> > Are you sure users even know what ARCH_PERFMON is?
> > 
> > Maybe it is confusing (why exactly?), but it doesn't seem to me that your
> > new message is any better.
> 
> Yeah, the part that says "unsupported CPU" is the confusing part,

That makes sense.

> I get people thinking that the specific reported CPU model is not
> supported by the kernel :-)
> 
> > 
> > If you refer to VMs not exposing the PMU perhaps that should be explicitely 
> > mentioned.
> > 
> > Of course the real fix is to always expose the PMU, not improve the error 
> > messages...
> 
> I agree that best is simply to enable PMU. But it does not hurt to improve 
> the error messaging, does it?
> 
> Any suggestions there, given that the initial attempt seams to make it even 
> worse :-)

Perhaps just say

"CPU does not support PMU"

which is really what the problem is here.

The other option would be to move this message after the big model switch,
but would need to be very careful that it doesn't have any unintended
side effects. 

-Andi

Re: Contiguous DMA buffer view for a custom device (Intel/x86)

[Alex Feinman]

Thanks, this sounds like what I need. However, since this is a
custom-purpose system, I am tempted to go with CMA and simply
preallocated 200MB on start

On Mon, Aug 20, 2018 at 1:58 PM Alan Cox  wrote:
>
> > b) IOMMU can solve this problem for me by providing a device-specific
> > contiguous view of a fragmented physical memory allocation
> > c) In order to enable IOMMU do the above, I need to allocate DRHDs and
> > DMARs in BIOS initialization (I build my own BIOS)
>
> Yes. The EDK2 firmware toolkit has all the bits you need in it I think.
>
> https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf
>
> isn't quite on the topic you want but it does explain it fairly well in
> passing.
>
> https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1
>
> is a bit out of date but may help too.
>
> > Please, let me know if I am on the right track? Of course I realize that
> > implementing SGDMA would be the best option, but short of that and blocking
> > out some physical memory on boot, what are my options?
>
> If performance is absolutely critical simply stealing a chunk of memory
> in the firmware and describing it your device some other way is ugly, but
> for a custom solution I guess anything goes 8)
>
> Alan

[GIT PULL] power-supply changes for 4.19

[Sebastian Reichel]

Hi Linus,

I was too busy for reviewing patches the last few weeks, so
everything has been in linux-next for a multiple weeks (except
for some fixes, that I initially planned to send for 4.18-rc,
but even those have been in -next for some time now). Stephen
Rothwell noticed a merge conflict in MAINTAINERS file, should
be trivial to figure out.

-- Sebastian

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
 tags/for-v4.19

for you to fetch changes up to 5198a48381455969aa1053a0ca2e4ce409be2fc2:

  Merge branch 'psy-fixes' into psy-next (2018-08-16 22:19:22 +0200)


power supply and reset changes for the v4.19 series

* Improve support for TI bq20z75 in sbs-battery
* Add Qualcomm PM8xxx reboot driver
* Add cros-ec USBPD charger driver
* Add adp5061 battery driver
* Move ds2760 battery driver from w1 to power-supply and add DT support
* Misc. fixes


Alexey Khoroshilov (1):
  power: reset: zx-reboot: put device node in zx_reboot_probe()

Arnd Bergmann (1):
  power: supply: ab8500: stop using getnstimeofday64()

Benjamin Tissoires (1):
  power: remove possible deadlock when unregistering power_supply

Brian Norris (2):
  power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
  dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

Colin Ian King (1):
  power: supply: max1721x: fix spelling mistake "RSenese" -> "RSense"

Dan Carpenter (1):
  power: supply: adp5061: Fix a couple off by ones

Daniel Mack (5):
  dt-bindings: w1: document generic onewire bindings
  dt-bindings: w1: document bindings for ds2760 battery monitor
  w1: core: match sub-nodes of bus masters in devicetree
  power: supply: ds2760_battery: merge ds2760 supply driver with its w1 
slave companion
  power: supply: ds2760_battery: add devicetree probing

David Lechner (2):
  power: supply: lego_ev3_battery: Don't ignore 
iio_read_channel_processed() return value
  power: supply: lego_ev3_battery: fix Vce offset

Enric Balletbo i Serra (2):
  power: supply: tps65217: Switch to SPDX identifier.
  mfd: cros_ec_dev: Register cros_usbpd-charger driver as a subdevice.

Gustavo A. R. Silva (2):
  power: supply: mark expected switch fall-throughs
  power: supply: max77693_charger: fix unintentional fall-through

H. Nikolaus Schaller (2):
  power: generic-adc-battery: fix out-of-bounds write when copying channel 
properties
  power: generic-adc-battery: check for duplicate properties copied from 
iio channels

Hans de Goede (1):
  power: supply: axp288_charger: Fix initial constant_charge_current value

Linus Walleij (1):
  power: gemini-poweroff: Avoid more spurious poweroffs

Liu Xiang (1):
  power: supply: bq27xxx: Update comments

Sameer Nanda (2):
  mfd: cros_ec: Add USBPD charger commands and struct definitions.
  power: supply: add cros-ec USBPD charger driver.

Sebastian Reichel (3):
  Merge tag 'ib-mfd-v4.19' into psy-next
  Merge tag 'ds2760-for-v4.19-signed' into psy-next
  Merge branch 'psy-fixes' into psy-next

Stefan Popa (1):
  adp5061: New driver for ADP5061 I2C battery charger

Sudeep Holla (1):
  power: vexpress: fix corruption in notifier registration

Vinod Koul (3):
  dt-bindings: power: reset: Add qcom pon binding
  power: reset: qcom-pon: Add Qcom PON driver
  dt-bindings: power: reset: qcom: Add resin binding

 .../bindings/input/qcom,pm8941-pwrkey.txt  |   1 +
 .../devicetree/bindings/power/reset/qcom,pon.txt   |  45 ++
 .../bindings/power/supply/maxim,ds2760.txt |  26 +
 .../bindings/power/supply/sbs_sbs-battery.txt  |  12 +-
 Documentation/devicetree/bindings/w1/w1-gpio.txt   |  11 +-
 Documentation/devicetree/bindings/w1/w1.txt|  25 +
 MAINTAINERS|   7 +
 drivers/mfd/cros_ec_dev.c  |  16 +
 drivers/power/reset/Kconfig|  11 +
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/gemini-poweroff.c  |  12 +-
 drivers/power/reset/qcom-pon.c |  91 +++
 drivers/power/reset/vexpress-poweroff.c|  12 +-
 drivers/power/reset/zx-reboot.c|   1 +
 drivers/power/supply/Kconfig   |  23 +-
 drivers/power/supply/Makefile  |   2 +
 drivers/power/supply/ab8500_fg.c   |  14 +-
 drivers/power/supply/adp5061.c | 745 +
 drivers/power/supply/axp20x_usb_power.c|   1 +
 drivers/power/supply/axp288_charger.c  |   2 +-
 drivers/power/supply/bq27xxx_battery.c 

Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped

[Tony Lindgren]

* Rafael J. Wysocki  [691231 23:00]:
> From: Rafael J. Wysocki 
> 
> If the tick has been stopped already, but the governor has not asked to
> stop it (which it can do sometimes), the idle loop should invoke
> tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> of this case properly.
> 
> Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the tick)

This patch seems to fix an issue where boot hangs occasionally
on beagleboard-xm with ARM multi_v7_defconfig as reported by
kernelci.org and Mark Brown earlier at [0].

At least so far no boot hangs for me with this fix, so:

Tested-by: Tony Lindgren 

[0] https://www.spinics.net/lists/linux-mmc/msg50480.html

[PATCH v2] mm: shmem: Correctly annotate new inodes for lockdep

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

Directories and inodes don't necessarily need to be in the same
lockdep class. For ex, hugetlbfs splits them out too to prevent
false positives in lockdep. Annotate correctly after new inode
creation. If its a directory inode, it will be put into a different
class.

This should fix a lockdep splat reported by syzbot:

> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc8-next-20180810+ #36 Not tainted
> --
> syz-executor900/4483 is trying to acquire lock:
> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> include/linux/fs.h:765 [inline]
> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
>
> but task is already holding lock:
> 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
> drivers/staging/android/ashmem.c:448
>
> which lock already depends on the new lock.
>
> -> #2 (ashmem_mutex){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
>ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
>call_mmap include/linux/fs.h:1844 [inline]
>mmap_region+0xf27/0x1c50 mm/mmap.c:1762
>do_mmap+0xa10/0x1220 mm/mmap.c:1535
>do_mmap_pgoff include/linux/mm.h:2298 [inline]
>vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
>ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
>__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
>__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (&mm->mmap_sem){}:
>__might_fault+0x155/0x1e0 mm/memory.c:4568
>_copy_to_user+0x30/0x110 lib/usercopy.c:25
>copy_to_user include/linux/uaccess.h:155 [inline]
>filldir+0x1ea/0x3a0 fs/readdir.c:196
>dir_emit_dot include/linux/fs.h:3464 [inline]
>dir_emit_dots include/linux/fs.h:3475 [inline]
>dcache_readdir+0x13a/0x620 fs/libfs.c:193
>iterate_dir+0x48b/0x5d0 fs/readdir.c:51
>__do_sys_getdents fs/readdir.c:231 [inline]
>__se_sys_getdents fs/readdir.c:212 [inline]
>__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (&sb->s_type->i_mutex_key#9){}:
>lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
>down_write+0x8f/0x130 kernel/locking/rwsem.c:70
>inode_lock include/linux/fs.h:765 [inline]
>shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
>ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
>ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
>vfs_ioctl fs/ioctl.c:46 [inline]
>file_ioctl fs/ioctl.c:501 [inline]
>do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
>ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
>__do_sys_ioctl fs/ioctl.c:709 [inline]
>__se_sys_ioctl fs/ioctl.c:707 [inline]
>__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
>   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
>
>  Possible unsafe locking scenario:
>
>CPU0CPU1
>
>   lock(ashmem_mutex);
>lock(&mm->mmap_sem);
>lock(ashmem_mutex);
>   lock(&sb->s_type->i_mutex_key#9);
>
>  *** DEADLOCK ***
>
> 1 lock held by syz-executor900/4483:
>  #0: 25208078 (ashmem_mutex){+.+.}, at:
> ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448

Reported-by: syzbot 
Cc: wi...@infradead.org
Cc: sta...@vger.kernel.org
Cc: pet...@infradead.org
Cc: Andrew Morton 
Reviewed-by: NeilBrown 
Suggested-by: NeilBrown 
Signed-off-by: Joel Fernandes (Google) 
---
v1->v2: Added Reviewed-by of NeilBrown and CC Andrew.

 mm/shmem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/shmem.c b/mm/shmem.c
index 41b9bbf24e16..8264bbdbb6a5 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2226,6 +2226,8 @@ static struct inode *shmem_get_inode(struct super_block 
*sb, const struct inode
mpol_shared_policy_init(&info->policy, NULL);
break;
}
+
+   lockdep_annotate_inode_mutex_key(inode);
} else
shmem_free_inode(sb);
return inode;
-- 
2.18.0.1017.ga543ac7ca45-goog

Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains

[Halil Pasic]

On 08/21/2018 07:07 PM, Tony Krowiak wrote:

On 08/21/2018 11:25 AM, Cornelia Huck wrote:

On Mon, 20 Aug 2018 13:41:32 -0400
Tony Krowiak  wrote:


On 08/20/2018 10:23 AM, Cornelia Huck wrote:

On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak  wrote:

From: Tony Krowiak 

Provides the sysfs interfaces for:

1. Assigning AP control domains to the mediated matrix device

2. Unassigning AP control domains from a mediated matrix device

3. Displaying the control domains assigned to a mediated matrix
 device

The IDs of the AP control domains assigned to the mediated matrix
device are stored in an AP domain mask (ADM). The bits in the ADM,
from most significant to least significant bit, correspond to
AP domain numbers 0 to 255. On some systems, the maximum allowable
domain number may be less than 255 - depending upon the host's
AP configuration - and assignment may be rejected if the input
domain ID exceeds the limit.

Please remind me of the relationship between control domains and usage
domains... IIRC, usage domains allow both requests and configuration,
while control domains allow only configuration, and are by convention a
superset of usage domains.

A usage domain is a domain to which an AP command-request message can be
submitted for processing. A control domain is a domain that can
be changed by an AP command request message submitted to a usage domain.
AP command request messages to configure a domain will contain the domain
number of the domain to be modified. The AP firmware will check the
control domain mask (ADM) and will allow the request to proceed only if
the corresponding bit in the ADM is set.

Thanks to you and Halil for the explanation.


Is there a hard requirement somewhere in there, or can the admin
cheerfully use different masks for usage domains and control domains
without the SIE choking on it?

There is no hard requirement that control domains must be a superset of
the usage domains, it is merely an architectural convention. AFAIK,
SIE doesn't enforce this and will not break if the convention is not
enforced externally. Having said that, you should note that the AQM
and ADM masks configured for the mediated matrix device will be logically
OR'd together to create the ADM stored in the CRYCB referenced from the
guest's SIE state description. In other words, we are enforcing the
convention in our software.

Hm, that's interesting, as Halil argued that we should not enforce it
in the kernel. Might be somewhat surprising as well. If that is really
the way to do it, this needs to be documented clearly.


This convention has been enforced by the kernel since v1. This is also
enforced by both the LPAR as well as in z/VM. The following is from the
PR/SM Planning Guide:

Control Domain
A logical partition's control domains are those cryptographic domains for which 
remote secure
administration functions can be established and administered from this logical 
partition. This
logical partition’s control domains must include its usage domains. For each 
index selected in the
usage domain index list, you must select the same index in the control domain 
index list



IMHO this quote is quite a half-full half-empty cup one:
* it mandates the set of usage domains is a subset of the set
of the control domains, but
* it speaks of independent controls, namely about the 'usage domain index'
and the 'control domain index list' and makes the enforcement of the rule
a job of the administrator (instead of codifying it in the controls).



Consequently, I'm going to opt for ensuring this is clearly documented. Based 
on the fact you've
requested clarification of many points described in this section of the doc, I
think I'll try putting my meager skills as a wordsmith to work to hopefully 
clarify things.
I'll run it by you when I complete that task to see if I've succeeded:)


I don't think just a doc update will do. Let me explain why.

What describe as "... note that the AQM and ADM masks configured for the
mediated matrix device will be logically OR'd together to create the ADM
stored in the CRYCB referenced from the guest's SIE state description."
is a gotcha at best. The member of struct ap_matrix and the member of the
respective apcb in the crycb are both called 'adm', but ap_matrix.adm is
not an ADM as we know it from the architecture, but rather ~ AQM & ADM.

I feel pretty strongly about this one. If we want to keep the enforcement
in the kernel, I guess, the assign_domain should set the bit corresponding
bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the
ap_matrix is committed into the crycb no further manipulating the masks
should take place.

I don't feel strongly about whether to enforce this convention about AQM
and ADM in the kernel or not. Frankly, I don't know what is behind the
rule. Since I can't tell if any problems are to be expected if this
convention is violated, I would feel more comfortable if the rule was
accommodated higher in the management stack.

Regards,
Hal

Re: [PATCH v3 2/2] hugetlb: take PMD sharing into account when flushing tlb/caches

[kbuild test robot]

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   powerpc64-linux-gnu-ld: warning: orphan section `.gnu.hash' from `linker 
stubs' being placed in section `.gnu.hash'.
   mm/rmap.o: In function `.try_to_unmap_one':
   rmap.c:(.text+0x2468): undefined reference to `.huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `.__unmap_hugepage_range':
>> (.text+0x6834): undefined reference to `.huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `.unmap_hugepage_range':
   (.text+0x6de8): undefined reference to `.huge_pmd_sharing_possible'
   mm/hugetlb.o: In function `.hugetlb_change_protection':
   (.text+0x91bc): undefined reference to `.huge_pmd_sharing_possible'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages

[Mike Kravetz]

On 08/21/2018 03:03 PM, kbuild test robot wrote:
> Hi Mike,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.18 next-20180821]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 

Oops, simple build fix addressed in updated patch below.

>From 57b7d63d88f65b1c385a5f15c7cd5fa07513e955 Mon Sep 17 00:00:00 2001
From: Mike Kravetz 
Date: Tue, 21 Aug 2018 10:50:17 -0700
Subject: [PATCH v4 1/2] mm: migration: fix migration of huge PMD shared pages

The page migration code employs try_to_unmap() to try and unmap the
source page.  This is accomplished by using rmap_walk to find all
vmas where the page is mapped.  This search stops when page mapcount
is zero.  For shared PMD huge pages, the page map count is always 1
no matter the number of mappings.  Shared mappings are tracked via
the reference count of the PMD page.  Therefore, try_to_unmap stops
prematurely and does not completely unmap all mappings of the source
page.

This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the
target page.  Hence, data is lost.

This problem was originally seen as DB corruption of shared global
areas after a huge page was soft offlined due to ECC memory errors.
DB developers noticed they could reproduce the issue by (hotplug)
offlining memory used to back huge pages.  A simple testcase can
reproduce the problem by creating a shared PMD mapping (note that
this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on
x86)), and using migrate_pages() to migrate process pages between
nodes while continually writing to the huge pages being migrated.

To fix, have the try_to_unmap_one routine check for huge PMD sharing
by calling huge_pmd_unshare for hugetlbfs huge pages.  If it is a
shared mapping it will be 'unshared' which removes the page table
entry and drops the reference on the PMD page.  After this, flush
caches and TLB.

mmu notifiers are called before locking page tables, but we can not
be sure of PMD sharing until page tables are locked.  Therefore,
check for the possibility of PMD sharing before locking so that
notifiers can prepare for the worst possible case.

Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz 
---
 include/linux/hugetlb.h | 14 ++
 mm/hugetlb.c| 40 +++
 mm/rmap.c   | 42 ++---
 3 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 36fa6a2a82e3..840b43a085cc 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
 pte_t *huge_pte_offset(struct mm_struct *mm,
   unsigned long addr, unsigned long sz);
 int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
+   unsigned long *start, unsigned long *end);
 struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
  int write);
 struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
 }
 
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+   pte_t *ptep)
+{
+   return 0;
+}
+
+static inline bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
+   unsigned long *start, unsigned long *end)
+{
+   return false;
+}
+
 #define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n)({ BUG(); 0; })
 #define follow_huge_addr(mm, addr, write)  ERR_PTR(-EINVAL)
 #define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3103099f64fd..fd155dc52117 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4555,6 +4555,9 @@ static bool vma_shareable(struct vm_area_struct *vma, 
unsigned long addr)
 
/*
 * check on proper vm_flags and page table alignment
+*
+* Note that this is the same check used in huge_pmd_sharing_possible.
+* If you change one, consider changing both.
 */
if (vma->vm_flags & VM_MAYSHARE &&
vma->vm_start <= base && end <= vma->vm_end)
@@ -4562,6 +

Re: [PATCH 1/1] perf/x86/intel: make error messages less confusing

[Eduardo Valentin]

On Tue, Aug 21, 2018 at 03:09:37PM -0700, Andi Kleen wrote:
> On Tue, Aug 21, 2018 at 02:15:28PM -0700, Eduardo Valentin wrote:
> > On a system with X86_FEATURE_ARCH_PERFMON disabled
> > and with a model not known by family PMU drivers,
> > user gets a kernel message log like the following:
> > [ 0.100114] Performance Events: unsupported p6 CPU model 85 no PMU driver, 
> > software events only.
> > 
> > The "unsupported .. CPU" part may be confusing for some
> > users. Rewording the messages on the failure path to:
> > [ 0.667154] Performance Events: unknown p6 PMU on CPU model 85: 
> > !X86_FEATURE_ARCH_PERFMON: no PMU driver, software events only.
> 
> Are you sure users even know what ARCH_PERFMON is?
> 
> Maybe it is confusing (why exactly?), but it doesn't seem to me that your
> new message is any better.

Yeah, the part that says "unsupported CPU" is the confusing part,
I get people thinking that the specific reported CPU model is not
supported by the kernel :-)

> 
> If you refer to VMs not exposing the PMU perhaps that should be explicitely 
> mentioned.
> 
> Of course the real fix is to always expose the PMU, not improve the error 
> messages...

I agree that best is simply to enable PMU. But it does not hurt to improve the 
error messaging, does it?

Any suggestions there, given that the initial attempt seams to make it even 
worse :-)

Was it only the ARCH_PERFMON part? I can probably just take that out.
Something like:

[ 0.667154] Performance Events: unknown p6 PMU on CPU model 85: no PMU driver, 
software events only.

> 
> -Andi
> 
> 

-- 
All the best,
Eduardo Valentin

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Liran Alon]

> On 21 Aug 2018, at 17:22, David Woodhouse  wrote:
> 
> On Tue, 2018-08-21 at 17:01 +0300, Liran Alon wrote:
>> 
>>> On 21 Aug 2018, at 12:57, David Woodhouse 
>> wrote:
>>>  
>>> Another alternative... I'm told POWER8 does an interesting thing
>> with
>>> hyperthreading and gang scheduling for KVM. The host kernel doesn't
>>> actually *see* the hyperthreads at all, and KVM just launches the
>> full
>>> set of siblings when it enters a guest, and gathers them again when
>> any
>>> of them exits. That's definitely worth investigating as an option
>> for
>>> x86, too.
>> 
>> I actually think that such scheduling mechanism which prevents
>> leaking cache entries to sibling hyperthreads should co-exist
>> together with the KVM address space isolation to fully mitigate L1TF
>> and other similar vulnerabilities. The address space isolation should
>> prevent VMExit handlers code gadgets from loading arbitrary host
>> memory to the cache. Once VMExit code path switches to full host
>> address space, then we should also make sure that no other sibling
>> hyprethread is running in the guest.
> 
> The KVM POWER8 solution (see arch/powerpc/kvm/book3s_hv.c) does that.
> The siblings are *never* running host kernel code; they're all torn
> down when any of them exits the guest. And it's always the *same*
> guest.
> 

I wasn’t aware of this KVM Power8 mechanism. Thanks for the pointer.
(371fefd6f2dc ("KVM: PPC: Allow book3s_hv guests to use SMT processor modes”))

Note though that my point regarding the co-existence of the isolated address 
space together with such scheduling mechanism is still valid.
The scheduling mechanism should not be seen as an alternative to the isolated 
address space if we wish to reduce the frequency of events
in which we need to kick sibling hyperthreads from guest.

>> Focusing on the scheduling mechanism, we must make sure that when a
>> logical processor runs guest code, all siblings logical processors
>> must run code which do not populate L1D cache with information
>> unrelated to this VM. This includes forbidding one logical processor
>> to run guest code while sibling is running a host task such as a NIC
>> interrupt handler.
>> Thus, when a vCPU thread exits the guest into the host and VMExit
>> handler reaches code flow which could populate L1D cache with this
>> information, we should force an exit from the guest of the siblings
>> logical processors, such that they will be allowed to resume only on
>> a core which we can promise that the L1D cache is free from
>> information unrelated to this VM.
>> 
>> At first, I have created a patch series which attempts to implement
>> such mechanism in KVM. However, it became clear to me that this may
>> need to be implemented in the scheduler itself. This is because:
>> 1. It is difficult to handle all new scheduling contrains only in
>> KVM.
>> 2. This mechanism should be relevant for any Type-2 hypervisor which
>> runs inside Linux besides KVM (Such as VMware Workstation or
>> VirtualBox).
>> 3. This mechanism could also be used to prevent future “core-cache-
>> leaking” vulnerabilities to be exploited between processes of
>> different security domains which run as siblings on the same core.
> 
> I'm not sure I agree. If KVM is handling "only let siblings run the
> *same* guest" and the siblings aren't visible to the host at all,
> that's quite simple. Any other hypervisor can also do it.
> 
> Now, the down-side of this is that the siblings aren't visible to the
> host. They can't be used to run multiple threads of the same userspace
> processes; only multiple threads of the same KVM guest. A truly generic
> core scheduler would cope with userspace threads too.
> 
> BUT I strongly suspect there's a huge correlation between the set of
> people who care enough about the KVM/L1TF issue to enable a costly
> XFPO-like solution, and the set of people who mostly don't give a shit
> about having sibling CPUs available to run the host's userspace anyway.
> 
> This is not the "I happen to run a Windows VM on my Linux desktop" use
> case...

If I understand your proposal correctly, you suggest to do something similar to 
the KVM Power8 solution:
1. Disable HyperThreading for use by host user space.
2. Use sibling hyperthreads only in KVM and schedule group of vCPUs that run on 
a single core as a “gang” to enter and exit guest together.

This solution may work well for KVM-based cloud providers that match the 
following criteria:
1. All compute instances run with SR-IOV and IOMMU Posted-Interrupts.
2. Configure affinity such that host dedicate distinct set of physical cores 
per guest. No physical core is able to run vCPUs from multiple guests.

However, this may not necessarily be the case: Some cloud providers have 
compute instances which all their devices are emulated or ParaVirtualized.
In the proposed scheduling mechanism, all the IOThreads of these guests will 
not be able to utilize HyperThreading which can be a significant performance 
hit

Re: [PATCH] mm: shmem: Correctly annotate new inodes

[NeilBrown]

On Tue, Aug 14 2018, Joel Fernandes (Google) wrote:

> Directories and inodes don't necessarily need to be in the same
> lockdep class. For ex, hugetlbfs splits them out too to prevent
> false positives in lockdep. Annotate correctly after new inode
> creation. If its a directory inode, it will be put into a different
> class.
>
> This should fix a lockdep splat reported by syzbot:
>
>> ==
>> WARNING: possible circular locking dependency detected
>> 4.18.0-rc8-next-20180810+ #36 Not tainted
>> --
>> syz-executor900/4483 is trying to acquire lock:
>> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
>> include/linux/fs.h:765 [inline]
>> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
>> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
>>
>> but task is already holding lock:
>> 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
>> drivers/staging/android/ashmem.c:448
>>
>> which lock already depends on the new lock.
>>
>> -> #2 (ashmem_mutex){+.+.}:
>>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>>__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
>>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
>>ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
>>call_mmap include/linux/fs.h:1844 [inline]
>>mmap_region+0xf27/0x1c50 mm/mmap.c:1762
>>do_mmap+0xa10/0x1220 mm/mmap.c:1535
>>do_mmap_pgoff include/linux/mm.h:2298 [inline]
>>vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
>>ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
>>__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>>__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
>>__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
>>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #1 (&mm->mmap_sem){}:
>>__might_fault+0x155/0x1e0 mm/memory.c:4568
>>_copy_to_user+0x30/0x110 lib/usercopy.c:25
>>copy_to_user include/linux/uaccess.h:155 [inline]
>>filldir+0x1ea/0x3a0 fs/readdir.c:196
>>dir_emit_dot include/linux/fs.h:3464 [inline]
>>dir_emit_dots include/linux/fs.h:3475 [inline]
>>dcache_readdir+0x13a/0x620 fs/libfs.c:193
>>iterate_dir+0x48b/0x5d0 fs/readdir.c:51
>>__do_sys_getdents fs/readdir.c:231 [inline]
>>__se_sys_getdents fs/readdir.c:212 [inline]
>>__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
>>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #0 (&sb->s_type->i_mutex_key#9){}:
>>lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
>>down_write+0x8f/0x130 kernel/locking/rwsem.c:70
>>inode_lock include/linux/fs.h:765 [inline]
>>shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
>>ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
>>ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
>>vfs_ioctl fs/ioctl.c:46 [inline]
>>file_ioctl fs/ioctl.c:501 [inline]
>>do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
>>ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
>>__do_sys_ioctl fs/ioctl.c:709 [inline]
>>__se_sys_ioctl fs/ioctl.c:707 [inline]
>>__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
>>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>>   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
>>
>>  Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>>   lock(ashmem_mutex);
>>lock(&mm->mmap_sem);
>>lock(ashmem_mutex);
>>   lock(&sb->s_type->i_mutex_key#9);
>>
>>  *** DEADLOCK ***
>>
>> 1 lock held by syz-executor900/4483:
>>  #0: 25208078 (ashmem_mutex){+.+.}, at:
>> ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448
>
> Reported-by: syzbot 
> Cc: wi...@infradead.org
> Cc: sta...@vger.kernel.org
> Cc: pet...@infradead.org
> Suggested-by: Neil Brown 
> Signed-off-by: Joel Fernandes (Google) 

Reviewed-by: NeilBrown 

This is necessary for any filesystem that doesn't use
unlock_new_inode().

(If/when you repost, I suggest including Andrew Morton).

Thanks,
NeilBrown


> ---
>  mm/shmem.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 2cab84403055..4429a8fd932d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2225,6 +2225,8 @@ static struct inode *shmem_get_inode(struct super_block 
> *sb, const struct inode
>   mpol_shared_policy_init(&info->policy, NULL);
>   break;
>   

Re: [PATCH 4/4] remoteproc: qcom: q6v5-pil: Add PDC restart for modem on SDM845 SoCs

[Bjorn Andersson]

On Fri 27 Jul 08:28 PDT 2018, Sibi Sankar wrote:

> In the presence of a PDC block working with subsystem RSC,
> assert/deassert PDC restart in modem start/stop path.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  .../bindings/remoteproc/qcom,q6v5.txt |  4 +++
>  drivers/remoteproc/qcom_q6v5_pil.c| 27 ---
>  2 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt 
> b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> index 601dd9f389aa..124fb1dc6fb8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> @@ -51,6 +51,8 @@ on the Qualcomm Hexagon core.
>   Usage: required
>   Value type: 
>   Definition: reference to the reset-controller for the modem sub-system
> + reference to the list of 2 reset-controllers for the modem
> + sub-system on SDM845 SoCs
>   reference to the list of 3 reset-controllers for the
>   wcss sub-system
>  
> @@ -58,6 +60,8 @@ on the Qualcomm Hexagon core.
>   Usage: required
>   Value type: 
>   Definition: must be "mss_restart" for the modem sub-system
> + Definition: must be "mss_restart", "pdc_restart" for the modem
> + sub-system on SDM845 SoCs
>   Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
>   for the wcss syb-system

Seems like we got an additional "Definition:" added here as we added the
wcss. Please don't add another one.

The rest looks good.

Regards,
Bjorn

[PATCH] ARM: use choice for kernel unwinders

[Stefan Agner]

While in theory multiple unwinders could be compiled in, it does
not make sense in practise. Use a choice to make the unwinder
selection mutually exclusive and mandatory.

Already before this commit it has not been possible to deselect
FRAME_POINTER. Remove the obsolete comment.

Furthermore, to produce a meaningful backtrace with FRAME_POINTER
enabled the kernel needs a specific function prologue:
movip, sp
stmfdsp!, {fp, ip, lr, pc}
subfp, ip, #4

To get to the required prologue gcc uses apcs and no-sched-prolog.
This compiler options are not available on clang, and clang is not
able to generate the required prologue. Make the FRAME_POINTER
config symbol depending on !clang.

Suggested-by: Arnd Bergmann 
Signed-off-by: Stefan Agner 
---
 arch/arm/Kconfig.debug | 43 ++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 693f84392f1b..ba09e744384a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -48,30 +48,41 @@ config DEBUG_WX
 
If in doubt, say "Y".
 
-# RMK wants arm kernels compiled with frame pointers or stack unwinding.
-# If you know what you are doing and are willing to live without stack
-# traces, you can get a slightly smaller kernel by setting this option to
-# n, but then RMK will have to kill you ;).
-config FRAME_POINTER
-   bool
-   depends on !THUMB2_KERNEL
-   default y if !ARM_UNWIND || FUNCTION_GRAPH_TRACER
+choice
+   prompt "Choose kernel unwinder"
+   default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
+   default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
+   help
+ This determines which method will be used for unwinding kernel stack
+ traces for panics, oopses, bugs, warnings, perf, /proc//stack,
+ livepatch, lockdep, and more.
+
+config UNWINDER_FRAME_POINTER
+   bool "Frame pointer unwinder"
+   depends on !THUMB2_KERNEL && !CC_IS_CLANG
+   select FRAME_POINTER
help
- If you say N here, the resulting kernel will be slightly smaller and
- faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled,
- when a problem occurs with the kernel, the information that is
- reported is severely limited.
+ This option enables the frame pointer unwinder for unwinding
+ kernel stack traces.
 
-config ARM_UNWIND
-   bool "Enable stack unwinding support (EXPERIMENTAL)"
+config UNWINDER_ARM
+   bool "ARM EABI stack unwinder"
depends on AEABI
-   default y
+   select ARM_UNWIND
help
  This option enables stack unwinding support in the kernel
  using the information automatically generated by the
  compiler. The resulting kernel image is slightly bigger but
  the performance is not affected. Currently, this feature
- only works with EABI compilers. If unsure say Y.
+ only works with EABI compilers.
+
+endchoice
+
+config ARM_UNWIND
+   bool
+
+config FRAME_POINTER
+   bool
 
 config OLD_MCOUNT
bool
-- 
2.18.0

Re: [PATCH 2/4] reset: qcom: PDC (Power Domain Controller) reset controller

[Bjorn Andersson]

On Fri 27 Jul 08:28 PDT 2018, Sibi Sankar wrote:

> Add reset controller for SDM845 SoC to control reset signals
> provided by PDC for Modem, Compute, Display, GPU, Debug, AOP,
> Sensors, Audio, SP and APPS
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/reset/Kconfig  |   9 +++
>  drivers/reset/Makefile |   1 +
>  drivers/reset/reset-qcom-pdc.c | 139 +
>  3 files changed, 149 insertions(+)
>  create mode 100644 drivers/reset/reset-qcom-pdc.c
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 13d28fdbdbb5..5344e202a630 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -98,6 +98,15 @@ config RESET_QCOM_AOSS
> reset signals provided by AOSS for Modem, Venus, ADSP,
> GPU, Camera, Wireless, Display subsystem. Otherwise, say N.
>  
> +config RESET_QCOM_PDC
> + bool "Qcom PDC Reset Driver"

"Qualcomm"

And I do not see a strong reason for this not being tristate, the
consumers we've talked about so far can all be modules.

> + depends on ARCH_QCOM || COMPILE_TEST
> + help
> +   This enables the PDC (Power Domain Controller) reset driver
> +   for Qualcomm Technologies Inc SDM845 SoCs. Say Y if you want
> +   to control reset signals provided by PDC for Modem, Compute,
> +   Display, GPU, Debug, AOP, Sensors, Audio, SP and APPS.
> +

Implementation looks fine.

Regards,
Bjorn

Re: [PATCH v2 1/3] mm: rework memcg kernel stack accounting

[Roman Gushchin]

On Tue, Aug 21, 2018 at 03:10:52PM -0700, Shakeel Butt wrote:
> On Tue, Aug 21, 2018 at 2:36 PM Roman Gushchin  wrote:
> >
> > If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> > using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> > stack pages are charged against corresponding memory cgroups
> > on allocation and uncharged on releasing them.
> >
> > The problem is that we do cache kernel stacks in small
> > per-cpu caches and do reuse them for new tasks, which can
> > belong to different memory cgroups.
> >
> > Each stack page still holds a reference to the original cgroup,
> > so the cgroup can't be released until the vmap area is released.
> >
> > To make this happen we need more than two subsequent exits
> > without forks in between on the current cpu, which makes it
> > very unlikely to happen. As a result, I saw a significant number
> > of dying cgroups (in theory, up to 2 * number_of_cpu +
> > number_of_tasks), which can't be released even by significant
> > memory pressure.
> >
> > As a cgroup structure can take a significant amount of memory
> > (first of all, per-cpu data like memcg statistics), it leads
> > to a noticeable waste of memory.
> >
> > Signed-off-by: Roman Gushchin 
> 
> Reviewed-by: Shakeel Butt 

Thanks!

> 
> BTW this makes a very good use-case for optimizing kmem uncharging
> similar to what you did for skmem uncharging.

Good point!
Let me prepare the patch.

Re: [PATCH v2 1/3] mm: rework memcg kernel stack accounting

[Shakeel Butt]

On Tue, Aug 21, 2018 at 2:36 PM Roman Gushchin  wrote:
>
> If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> stack pages are charged against corresponding memory cgroups
> on allocation and uncharged on releasing them.
>
> The problem is that we do cache kernel stacks in small
> per-cpu caches and do reuse them for new tasks, which can
> belong to different memory cgroups.
>
> Each stack page still holds a reference to the original cgroup,
> so the cgroup can't be released until the vmap area is released.
>
> To make this happen we need more than two subsequent exits
> without forks in between on the current cpu, which makes it
> very unlikely to happen. As a result, I saw a significant number
> of dying cgroups (in theory, up to 2 * number_of_cpu +
> number_of_tasks), which can't be released even by significant
> memory pressure.
>
> As a cgroup structure can take a significant amount of memory
> (first of all, per-cpu data like memcg statistics), it leads
> to a noticeable waste of memory.
>
> Signed-off-by: Roman Gushchin 

Reviewed-by: Shakeel Butt 

BTW this makes a very good use-case for optimizing kmem uncharging
similar to what you did for skmem uncharging.

> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Andy Lutomirski 
> Cc: Konstantin Khlebnikov 
> Cc: Tejun Heo 
> Cc: Shakeel Butt 
> ---
>  include/linux/memcontrol.h | 13 +-
>  kernel/fork.c  | 51 +-
>  2 files changed, 57 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 0e6c515fb698..b12a553048e2 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1250,10 +1250,11 @@ struct kmem_cache *memcg_kmem_get_cache(struct 
> kmem_cache *cachep);
>  void memcg_kmem_put_cache(struct kmem_cache *cachep);
>  int memcg_kmem_charge_memcg(struct page *page, gfp_t gfp, int order,
> struct mem_cgroup *memcg);
> +
> +#ifdef CONFIG_MEMCG_KMEM
>  int memcg_kmem_charge(struct page *page, gfp_t gfp, int order);
>  void memcg_kmem_uncharge(struct page *page, int order);
>
> -#ifdef CONFIG_MEMCG_KMEM
>  extern struct static_key_false memcg_kmem_enabled_key;
>  extern struct workqueue_struct *memcg_kmem_cache_wq;
>
> @@ -1289,6 +1290,16 @@ extern int memcg_expand_shrinker_maps(int new_id);
>  extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
>int nid, int shrinker_id);
>  #else
> +
> +static inline int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
> +{
> +   return 0;
> +}
> +
> +static inline void memcg_kmem_uncharge(struct page *page, int order)
> +{
> +}
> +
>  #define for_each_memcg_cache_index(_idx)   \
> for (; NULL; )
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 5ee74c113381..09b5b9a40166 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -223,9 +223,14 @@ static unsigned long *alloc_thread_stack_node(struct 
> task_struct *tsk, int node)
> return s->addr;
> }
>
> +   /*
> +* Allocated stacks are cached and later reused by new threads,
> +* so memcg accounting is performed manually on assigning/releasing
> +* stacks to tasks. Drop __GFP_ACCOUNT.
> +*/
> stack = __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN,
>  VMALLOC_START, VMALLOC_END,
> -THREADINFO_GFP,
> +THREADINFO_GFP & ~__GFP_ACCOUNT,
>  PAGE_KERNEL,
>  0, node, __builtin_return_address(0));
>
> @@ -248,9 +253,20 @@ static unsigned long *alloc_thread_stack_node(struct 
> task_struct *tsk, int node)
>  static inline void free_thread_stack(struct task_struct *tsk)
>  {
>  #ifdef CONFIG_VMAP_STACK
> -   if (task_stack_vm_area(tsk)) {
> +   struct vm_struct *vm = task_stack_vm_area(tsk);
> +
> +   if (vm) {
> int i;
>
> +   for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) {
> +   mod_memcg_page_state(vm->pages[i],
> +MEMCG_KERNEL_STACK_KB,
> +-(int)(PAGE_SIZE / 1024));
> +
> +   memcg_kmem_uncharge(vm->pages[i],
> +   compound_order(vm->pages[i]));
> +   }
> +
> for (i = 0; i < NR_CACHED_STACKS; i++) {
> if (this_cpu_cmpxchg(cached_stacks[i],
> NULL, tsk->stack_vm_area) != NULL)
> @@ -350,10 +366,6 @@ static void account_kernel_stack(struct task_struct 
> *tsk, int account)
> NR_KERNEL_STACK_KB,
> PAGE_SIZE / 1024 * account);
> }
> -
> - 

Re: [PATCH 1/1] perf/x86/intel: make error messages less confusing

[Andi Kleen]

On Tue, Aug 21, 2018 at 02:15:28PM -0700, Eduardo Valentin wrote:
> On a system with X86_FEATURE_ARCH_PERFMON disabled
> and with a model not known by family PMU drivers,
> user gets a kernel message log like the following:
> [ 0.100114] Performance Events: unsupported p6 CPU model 85 no PMU driver, 
> software events only.
> 
> The "unsupported .. CPU" part may be confusing for some
> users. Rewording the messages on the failure path to:
> [ 0.667154] Performance Events: unknown p6 PMU on CPU model 85: 
> !X86_FEATURE_ARCH_PERFMON: no PMU driver, software events only.

Are you sure users even know what ARCH_PERFMON is?

Maybe it is confusing (why exactly?), but it doesn't seem to me that your
new message is any better.

If you refer to VMs not exposing the PMU perhaps that should be explicitely 
mentioned.

Of course the real fix is to always expose the PMU, not improve the error 
messages...

-Andi

Re: [PATCH 1/4] dt-bindings: reset: Add PDC reset binding for SDM845 SoCs

[Bjorn Andersson]

On Fri 27 Jul 08:28 PDT 2018, Sibi Sankar wrote:

> Add SDM845 PDC (Power Domain Controller) reset controller binding
> 

Even though this is currently describing only a reset controller I think
this binding better be talking about the "PDC Global" hardware.

> Signed-off-by: Sibi Sankar 
> ---
>  .../bindings/reset/qcom,pdc-reset.txt | 52 +++
>  include/dt-bindings/reset/qcom,sdm845-pdc.h   | 20 +++
>  2 files changed, 72 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/qcom,pdc-reset.txt
>  create mode 100644 include/dt-bindings/reset/qcom,sdm845-pdc.h
> 
> diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-reset.txt 
> b/Documentation/devicetree/bindings/reset/qcom,pdc-reset.txt

Rename this qcom,pdc-global to match the compatible, and hardware name.

> new file mode 100644
> index ..85e159962e08
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-reset.txt
> @@ -0,0 +1,52 @@
> +PDC Reset Controller

PDC Global

> +==
> +
> +This binding describes a reset-controller found on PDC-Global(Power Domain
> +Controller) block for Qualcomm Technologies Inc SDM845 SoCs.

This looks good.

> +
> +Required properties:
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be:
> + "qcom,sdm845-pdc-global"
> +
> +- reg:
> + Usage: required
> + Value type: 
> + Definition: must specify the base address and size of the register
> + space.
> +
> +- #reset-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 1; cell entry represents the reset index.
> +
> +Example:
> +
> +pdc_reset: reset-controller@b2e {

This is perfectly fine, in its current form it is a reset-controller.

> + compatible = "qcom,sdm845-pdc-global";
> + reg = <0xb2e 0x2>;
> + #reset-cells = <1>;
> +};
> +

Apart from this, the binding looks good!

Regards,
Bjorn

Re: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages

[kbuild test robot]

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180821]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/mm/fault.o: In function `huge_pmd_sharing_possible':
>> fault.c:(.text+0xa06): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   arch/x86/mm/pgtable.o: In function `huge_pmd_sharing_possible':
   pgtable.c:(.text+0x4): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/fork.o: In function `huge_pmd_sharing_possible':
   fork.c:(.text+0x309): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sysctl.o: In function `huge_pmd_sharing_possible':
   sysctl.c:(.text+0x0): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/core.o: In function `huge_pmd_sharing_possible':
   core.c:(.text+0x299): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/loadavg.o: In function `huge_pmd_sharing_possible':
   loadavg.c:(.text+0x0): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/clock.o: In function `huge_pmd_sharing_possible':
   clock.c:(.text+0x0): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/cputime.o: In function `huge_pmd_sharing_possible':
   cputime.c:(.text+0x0): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/idle.o: In function `huge_pmd_sharing_possible':
   idle.c:(.text+0x36): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/fair.o: In function `huge_pmd_sharing_possible':
   fair.c:(.text+0x864): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/rt.o: In function `huge_pmd_sharing_possible':
   rt.c:(.text+0x72b): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/deadline.o: In function `huge_pmd_sharing_possible':
   deadline.c:(.text+0xac7): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/wait.o: In function `huge_pmd_sharing_possible':
   wait.c:(.text+0x16e): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/wait_bit.o: In function `huge_pmd_sharing_possible':
   wait_bit.c:(.text+0x7b): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/swait.o: In function `huge_pmd_sharing_possible':
   swait.c:(.text+0x4): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   kernel/sched/completion.o: In function `huge_pmd_sharing_possible':
   completion.c:(.text+0x4): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   mm/filemap.o: In function `huge_pmd_sharing_possible':
   filemap.c:(.text+0x3ca): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   mm/page_alloc.o: In function `huge_pmd_sharing_possible':
   page_alloc.c:(.text+0xa95): multiple definition of 
`huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   mm/swap.o: In function `huge_pmd_sharing_possible':
   swap.c:(.text+0x551): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   mm/vmscan.o: In function `huge_pmd_sharing_possible':
   vmscan.c:(.text+0x5bb): multiple definition of `huge_pmd_sharing_possible'
   arch/x86/mm/init_32.o:init_32.c:(.text+0x0): first defined here
   mm/shmem.o: In function `huge_pmd_sh

Re: [PATCH 4.4 00/22] 4.4.151-stable review

[Shuah Khan]

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

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/25] 4.9.123-stable review

[Shuah Khan]

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


Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH 2/8] nios2: build .dtb files in dts directory

[Rob Herring]

Align nios2 with other architectures which build the dtb files in the
same directory as the dts files. This is also in line with most other
build targets which are located in the same directory as the source.
This move will help enable the 'dtbs' target which builds all the dtbs
regardless of kernel config.

This transition could break some scripts if they expect dtb files in
the old location.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/Makefile  | 4 ++--
 arch/nios2/boot/Makefile | 4 
 arch/nios2/boot/dts/Makefile | 1 +
 3 files changed, 3 insertions(+), 6 deletions(-)
 create mode 100644 arch/nios2/boot/dts/Makefile

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 8673a79dca9c..50eece1c6adb 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -59,10 +59,10 @@ archclean:
$(Q)$(MAKE) $(clean)=$(nios2-boot)
 
 %.dtb: | scripts
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@
 
 dtbs:
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts
 
 $(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile
index 2ba23a679732..007586094dde 100644
--- a/arch/nios2/boot/Makefile
+++ b/arch/nios2/boot/Makefile
@@ -47,10 +47,6 @@ obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += linked_dtb.o
 
 targets += $(dtb-y)
 
-# Rule to build device tree blobs with make command
-$(obj)/%.dtb: $(src)/dts/%.dts FORCE
-   $(call if_changed_dep,dtc)
-
 $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
 
 install:
diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
new file mode 100644
index ..f66554cd5c45
--- /dev/null
+++ b/arch/nios2/boot/dts/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
-- 
2.17.1

[PATCH 4/8] nios2: fix building all dtbs

[Rob Herring]

nios2 has a 'dtbs' target, but nothing is added to 'dtb-*' targets and
no dtbs were getting built. This enables building all the dts files in
arch/nios2/boot/dts/ when COMPILE_TEST and OF_ALL_DTBS are enabled.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
index f6358e395b25..a91a0b09be63 100644
--- a/arch/nios2/boot/dts/Makefile
+++ b/arch/nios2/boot/dts/Makefile
@@ -1,3 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-y := $(patsubst "%.dts",%.dtb.o,$(CONFIG_NIOS2_DTB_SOURCE))
+
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
-- 
2.17.1

[PATCH 5/8] c6x: use common built-in dtb support

[Rob Herring]

Using the common build support for built-in dtb files just requires
adding a .dtb.o target to obj-y.

The dtb now needs to be copied when unflattened because an init section
is used now.

Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: Rob Herring 
---
I couldn't find a built cross-compiler for c6x, so this had no testing.

 arch/c6x/boot/dts/Makefile  | 11 +--
 arch/c6x/boot/dts/linked_dtb.S  |  2 --
 arch/c6x/include/asm/sections.h |  1 -
 arch/c6x/kernel/setup.c |  4 ++--
 arch/c6x/kernel/vmlinux.lds.S   | 10 --
 5 files changed, 3 insertions(+), 25 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S

diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index b212d278ebc4..fd937f781d16 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -6,14 +6,5 @@
 DTC_FLAGS ?= -p 1024

 ifneq ($(DTB),)
-obj-y += linked_dtb.o
+obj-y += $(DTB).dtb.o
 endif
-
-quiet_cmd_cp = CP  $< $@$2
-   cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
-# Generate builtin.dtb from $(DTB).dtb
-$(obj)/builtin.dtb: $(obj)/$(DTB).dtb
-   $(call if_changed,cp)
-
-$(obj)/linked_dtb.o: $(obj)/builtin.dtb
diff --git a/arch/c6x/boot/dts/linked_dtb.S b/arch/c6x/boot/dts/linked_dtb.S
deleted file mode 100644
index cf347f1d16ce..
--- a/arch/c6x/boot/dts/linked_dtb.S
+++ /dev/null
@@ -1,2 +0,0 @@
-.section __fdt_blob,"a"
-.incbin "arch/c6x/boot/dts/builtin.dtb"
diff --git a/arch/c6x/include/asm/sections.h b/arch/c6x/include/asm/sections.h
index d6c591ab5b7e..dc2f15eb3bde 100644
--- a/arch/c6x/include/asm/sections.h
+++ b/arch/c6x/include/asm/sections.h
@@ -8,6 +8,5 @@ extern char _vectors_start[];
 extern char _vectors_end[];

 extern char _data_lma[];
-extern char _fdt_start[], _fdt_end[];

 #endif /* _ASM_C6X_SECTIONS_H */
diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c
index 786e36e2f61d..509c5f086496 100644
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@ -270,7 +270,7 @@ int __init c6x_add_memory(phys_addr_t start, unsigned long 
size)
 notrace void __init machine_init(unsigned long dt_ptr)
 {
void *dtb = __va(dt_ptr);
-   void *fdt = _fdt_start;
+   void *fdt = __dtb_start;

/* interrupts must be masked */
set_creg(IER, 2);
@@ -363,7 +363,7 @@ void __init setup_arch(char **cmdline_p)
 memory_end >> PAGE_SHIFT);
memblock_reserve(memory_start, bootmap_size);

-   unflatten_device_tree();
+   unflatten_and_copy_device_tree();

c6x_cache_init();

diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S
index 1fba5b421eee..584bab2bace6 100644
--- a/arch/c6x/kernel/vmlinux.lds.S
+++ b/arch/c6x/kernel/vmlinux.lds.S
@@ -90,16 +90,6 @@ SECTIONS
*(.switch)
}

-   . = ALIGN (8) ;
-   __fdt_blob : AT(ADDR(__fdt_blob) - LOAD_OFFSET)
-   {
-   _fdt_start = . ;/* place for fdt blob */
-   *(__fdt_blob) ; /* Any link-placed DTB */
-   BYTE(0);/* section always has contents */
-   . = _fdt_start + 0x4000;/* Pad up to 16kbyte */
-   _fdt_end = . ;
-   }
-
_etext = .;

/*
--
2.17.1

[PATCH 8/8] c6x: enable building all dtbs

[Rob Herring]

Enable the 'dtbs' target for c6x. This allows building all the dts
files in arch/powerpc/boot/dts/ for enabled platforms or when
COMPILE_TEST and OF_ALL_DTBS are enabled.

Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: Rob Herring 
---
 arch/c6x/boot/dts/Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index fd937f781d16..f438285c3640 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -5,6 +5,12 @@
 
 DTC_FLAGS ?= -p 1024
 
+dtb-$(CONFIG_SOC_TMS320C6455) += dsk6455.dtb
+dtb-$(CONFIG_SOC_TMS320C6457) += evmc6457.dtb
+dtb-$(CONFIG_SOC_TMS320C6472) += evmc6472.dtb
+dtb-$(CONFIG_SOC_TMS320C6474) += evmc6474.dtb
+dtb-$(CONFIG_SOC_TMS320C6678) += evmc6678.dtb
+
 ifneq ($(DTB),)
 obj-y += $(DTB).dtb.o
 endif
-- 
2.17.1

[PATCH 3/8] nios2: use common rules to build built-in dtb

[Rob Herring]

Using the common build support for built-in dtb files just requires
adding a .dtb.o target to obj-y.

This has the side effect that CONFIG_NIOS2_DTB_SOURCE should now be just
the dts filename in arch/nios2/boot/dts/ directory. Before any path was
supported, but if you want to build in your dtb to the kernel, it should
be in the kernel tree.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/Makefile  |  6 ++
 arch/nios2/boot/Makefile | 14 --
 arch/nios2/boot/dts/Makefile |  2 ++
 arch/nios2/boot/linked_dtb.S | 19 ---
 4 files changed, 4 insertions(+), 37 deletions(-)
 delete mode 100644 arch/nios2/boot/linked_dtb.S

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 50eece1c6adb..db2e78fe65c7 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -49,16 +49,14 @@ BOOT_TARGETS = vmImage zImage
 PHONY += $(BOOT_TARGETS) install
 KBUILD_IMAGE := $(nios2-boot)/vmImage
 
-ifneq ($(CONFIG_NIOS2_DTB_SOURCE),"")
-   core-y  += $(nios2-boot)/
-endif
+core-y += $(nios2-boot)/dts/
 
 all: vmImage
 
 archclean:
$(Q)$(MAKE) $(clean)=$(nios2-boot)
 
-%.dtb: | scripts
+%.dtb %.dtb.S %.dtb.o: | scripts
$(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@
 
 dtbs:
diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile
index 007586094dde..0b48f1bf086d 100644
--- a/arch/nios2/boot/Makefile
+++ b/arch/nios2/boot/Makefile
@@ -31,20 +31,6 @@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
 $(obj)/compressed/vmlinux: $(obj)/vmlinux.gz FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
-# Rule to build device tree blobs
-DTB_SRC := $(patsubst "%",%,$(CONFIG_NIOS2_DTB_SOURCE))
-
-# Make sure the generated dtb gets removed during clean
-extra-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += system.dtb
-
-$(obj)/system.dtb: $(DTB_SRC) FORCE
-   $(call cmd,dtc)
-
-# Ensure system.dtb exists
-$(obj)/linked_dtb.o: $(obj)/system.dtb
-
-obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += linked_dtb.o
-
 targets += $(dtb-y)
 
 $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
index f66554cd5c45..f6358e395b25 100644
--- a/arch/nios2/boot/dts/Makefile
+++ b/arch/nios2/boot/dts/Makefile
@@ -1 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
+
+obj-y := $(patsubst "%.dts",%.dtb.o,$(CONFIG_NIOS2_DTB_SOURCE))
diff --git a/arch/nios2/boot/linked_dtb.S b/arch/nios2/boot/linked_dtb.S
deleted file mode 100644
index 071f922db338..
--- a/arch/nios2/boot/linked_dtb.S
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * Copyright (C) 2011 Thomas Chou 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
- *
- */
-.section .dtb.init.rodata,"a"
-.incbin "arch/nios2/boot/system.dtb"
-- 
2.17.1

[PATCH v2 3/3] mm: don't miss the last page because of round-off error

[Roman Gushchin]

I've noticed, that dying memory cgroups are  often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.

My investigation showed that the problem is caused by
applying the LRU pressure balancing math:

  scan = div64_u64(scan * fraction[lru], denominator),

where

  denominator = fraction[anon] + fraction[file] + 1.

Because fraction[lru] is always less than denominator,
if the initial scan size is 1, the result is always 0.

This means the last page is not scanned and has
no chances to be reclaimed.

Fix this by rounding up the result of the division.

In practice this change significantly improves the speed
of dying cgroups reclaim.

Signed-off-by: Roman Gushchin 
Cc: Andrew Morton 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Tejun Heo 
Cc: Rik van Riel 
Cc: Konstantin Khlebnikov 
Cc: Matthew Wilcox 
---
 include/linux/math64.h | 2 ++
 mm/vmscan.c| 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/math64.h b/include/linux/math64.h
index 837f2f2d1d34..94af3d9c73e7 100644
--- a/include/linux/math64.h
+++ b/include/linux/math64.h
@@ -281,4 +281,6 @@ static inline u64 mul_u64_u32_div(u64 a, u32 mul, u32 
divisor)
 }
 #endif /* mul_u64_u32_div */
 
+#define DIV64_U64_ROUND_UP(ll, d)  div64_u64((ll) + (d) - 1, (d))
+
 #endif /* _LINUX_MATH64_H */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4375b1e9bd56..2d78c5cff15e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2445,9 +2445,11 @@ static void get_scan_count(struct lruvec *lruvec, struct 
mem_cgroup *memcg,
/*
 * Scan types proportional to swappiness and
 * their relative recent reclaim efficiency.
+* Make sure we don't miss the last page
+* because of a round-off error.
 */
-   scan = div64_u64(scan * fraction[file],
-denominator);
+   scan = DIV64_U64_ROUND_UP(scan * fraction[file],
+ denominator);
break;
case SCAN_FILE:
case SCAN_ANON:
-- 
2.17.1

[PATCH v2 1/3] mm: rework memcg kernel stack accounting

[Roman Gushchin]

If CONFIG_VMAP_STACK is set, kernel stacks are allocated
using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
stack pages are charged against corresponding memory cgroups
on allocation and uncharged on releasing them.

The problem is that we do cache kernel stacks in small
per-cpu caches and do reuse them for new tasks, which can
belong to different memory cgroups.

Each stack page still holds a reference to the original cgroup,
so the cgroup can't be released until the vmap area is released.

To make this happen we need more than two subsequent exits
without forks in between on the current cpu, which makes it
very unlikely to happen. As a result, I saw a significant number
of dying cgroups (in theory, up to 2 * number_of_cpu +
number_of_tasks), which can't be released even by significant
memory pressure.

As a cgroup structure can take a significant amount of memory
(first of all, per-cpu data like memcg statistics), it leads
to a noticeable waste of memory.

Signed-off-by: Roman Gushchin 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Andy Lutomirski 
Cc: Konstantin Khlebnikov 
Cc: Tejun Heo 
Cc: Shakeel Butt 
---
 include/linux/memcontrol.h | 13 +-
 kernel/fork.c  | 51 +-
 2 files changed, 57 insertions(+), 7 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 0e6c515fb698..b12a553048e2 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -1250,10 +1250,11 @@ struct kmem_cache *memcg_kmem_get_cache(struct 
kmem_cache *cachep);
 void memcg_kmem_put_cache(struct kmem_cache *cachep);
 int memcg_kmem_charge_memcg(struct page *page, gfp_t gfp, int order,
struct mem_cgroup *memcg);
+
+#ifdef CONFIG_MEMCG_KMEM
 int memcg_kmem_charge(struct page *page, gfp_t gfp, int order);
 void memcg_kmem_uncharge(struct page *page, int order);
 
-#ifdef CONFIG_MEMCG_KMEM
 extern struct static_key_false memcg_kmem_enabled_key;
 extern struct workqueue_struct *memcg_kmem_cache_wq;
 
@@ -1289,6 +1290,16 @@ extern int memcg_expand_shrinker_maps(int new_id);
 extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
   int nid, int shrinker_id);
 #else
+
+static inline int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
+{
+   return 0;
+}
+
+static inline void memcg_kmem_uncharge(struct page *page, int order)
+{
+}
+
 #define for_each_memcg_cache_index(_idx)   \
for (; NULL; )
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 5ee74c113381..09b5b9a40166 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -223,9 +223,14 @@ static unsigned long *alloc_thread_stack_node(struct 
task_struct *tsk, int node)
return s->addr;
}
 
+   /*
+* Allocated stacks are cached and later reused by new threads,
+* so memcg accounting is performed manually on assigning/releasing
+* stacks to tasks. Drop __GFP_ACCOUNT.
+*/
stack = __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN,
 VMALLOC_START, VMALLOC_END,
-THREADINFO_GFP,
+THREADINFO_GFP & ~__GFP_ACCOUNT,
 PAGE_KERNEL,
 0, node, __builtin_return_address(0));
 
@@ -248,9 +253,20 @@ static unsigned long *alloc_thread_stack_node(struct 
task_struct *tsk, int node)
 static inline void free_thread_stack(struct task_struct *tsk)
 {
 #ifdef CONFIG_VMAP_STACK
-   if (task_stack_vm_area(tsk)) {
+   struct vm_struct *vm = task_stack_vm_area(tsk);
+
+   if (vm) {
int i;
 
+   for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) {
+   mod_memcg_page_state(vm->pages[i],
+MEMCG_KERNEL_STACK_KB,
+-(int)(PAGE_SIZE / 1024));
+
+   memcg_kmem_uncharge(vm->pages[i],
+   compound_order(vm->pages[i]));
+   }
+
for (i = 0; i < NR_CACHED_STACKS; i++) {
if (this_cpu_cmpxchg(cached_stacks[i],
NULL, tsk->stack_vm_area) != NULL)
@@ -350,10 +366,6 @@ static void account_kernel_stack(struct task_struct *tsk, 
int account)
NR_KERNEL_STACK_KB,
PAGE_SIZE / 1024 * account);
}
-
-   /* All stack pages belong to the same memcg. */
-   mod_memcg_page_state(vm->pages[0], MEMCG_KERNEL_STACK_KB,
-account * (THREAD_SIZE / 1024));
} else {
/*
 * All stack pages are in the same zone and belong to the
@@ -369,6 +381,30 @@ static void account_kernel_stack(struct task_struct *tsk, 
int account)
}
 }
 

[PATCH v2 2/3] mm: drain memcg stocks on css offlining

[Roman Gushchin]

Memcg charge is batched using per-cpu stocks, so an offline memcg
can be pinned by a cached charge up to a moment, when a process
belonging to some other cgroup will charge some memory on the same
cpu. In other words, cached charges can prevent a memory cgroup
from being reclaimed for some time, without any clear need.

Let's optimize it by explicit draining of all stocks on css offlining.
As draining is performed asynchronously, and is skipped if any
parallel draining is happening, it's cheap.

Signed-off-by: Roman Gushchin 
Reviewed-by: Shakeel Butt 
Acked-by: Michal Hocko 
Cc: Johannes Weiner 
Cc: Konstantin Khlebnikov 
Cc: Tejun Heo 
---
 mm/memcontrol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6a921890739f..c2a254f74f30 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4518,6 +4518,8 @@ static void mem_cgroup_css_offline(struct 
cgroup_subsys_state *css)
memcg_offline_kmem(memcg);
wb_memcg_offline(memcg);
 
+   drain_all_stock(memcg);
+
mem_cgroup_id_put(memcg);
 }
 
-- 
2.17.1

Re: [PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe

[Song Liu]

On Sun, Aug 19, 2018 at 10:54 PM, Song Liu  wrote:
> On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
>  wrote:
>> We assume to have only one reference counter for one uprobe.
>> Don't allow user to register multiple uprobes having same
>> inode+offset but different reference counter.
>>
>> Signed-off-by: Ravi Bangoria 
>> Acked-by: Srikar Dronamraju 
>> Reviewed-by: Oleg Nesterov 
>
> Reviewed-by: Song Liu 

Reviewed-and-tested-by: Song Liu 

>
>> ---
>>  kernel/events/uprobes.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
>> index 35065febcb6c..ecee371a59c7 100644
>> --- a/kernel/events/uprobes.c
>> +++ b/kernel/events/uprobes.c
>> @@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe 
>> *uprobe)
>> return u;
>>  }
>>
>> +static void
>> +ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
>> +{
>> +   pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
>> +   "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
>> +   uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
>> +   (unsigned long long) cur_uprobe->ref_ctr_offset,
>> +   (unsigned long long) uprobe->ref_ctr_offset);
>> +}
>> +
>>  static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
>>loff_t ref_ctr_offset)
>>  {
>> @@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode, 
>> loff_t offset,
>> cur_uprobe = insert_uprobe(uprobe);
>> /* a uprobe exists for this inode:offset combination */
>> if (cur_uprobe) {
>> +   if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
>> +   ref_ctr_mismatch_warn(cur_uprobe, uprobe);
>> +   put_uprobe(cur_uprobe);
>> +   kfree(uprobe);
>> +   return ERR_PTR(-EINVAL);
>> +   }
>> kfree(uprobe);
>> uprobe = cur_uprobe;
>> }
>> @@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode, 
>> loff_t offset,
>> uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
>> if (!uprobe)
>> return -ENOMEM;
>> +   if (IS_ERR(uprobe))
>> +   return PTR_ERR(uprobe);
>> +
>> /*
>>  * We can race with uprobe_unregister()->delete_uprobe().
>>  * Check uprobe_is_active() and retry if it is false.
>> --
>> 2.14.4
>>

Re: [PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)

[Song Liu]

On Sun, Aug 19, 2018 at 10:53 PM, Song Liu  wrote:
> On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
>  wrote:
>> Userspace Statically Defined Tracepoints[1] are dtrace style markers
>> inside userspace applications. Applications like PostgreSQL, MySQL,
>> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
>> have these markers embedded in them. These markers are added by developer
>> at important places in the code. Each marker source expands to a single
>> nop instruction in the compiled code but there may be additional
>> overhead for computing the marker arguments which expands to couple of
>> instructions. In case the overhead is more, execution of it can be
>> omitted by runtime if() condition when no one is tracing on the marker:
>>
>> if (reference_counter > 0) {
>> Execute marker instructions;
>> }
>>
>> Default value of reference counter is 0. Tracer has to increment the
>> reference counter before tracing on a marker and decrement it when
>> done with the tracing.
>>
>> Implement the reference counter logic in core uprobe. User will be
>> able to use it from trace_uprobe as well as from kernel module. New
>> trace_uprobe definition with reference counter will now be:
>>
>> :[(ref_ctr_offset)]
>>
>> where ref_ctr_offset is an optional field. For kernel module, new
>> variant of uprobe_register() has been introduced:
>>
>> uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
>>
>> No new variant for uprobe_unregister() because it's assumed to have
>> only one reference counter for one uprobe.
>>
>> [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>>
>> Note: 'reference counter' is called as 'semaphore' in original Dtrace
>> (or Systemtap, bcc and even in ELF) documentation and code. But the
>> term 'semaphore' is misleading in this context. This is just a counter
>> used to hold number of tracers tracing on a marker. This is not really
>> used for any synchronization. So we are calling it a 'reference counter'
>> in kernel / perf code.
>>
>> Signed-off-by: Ravi Bangoria 
>> Reviewed-by: Masami Hiramatsu 
>> [Only trace_uprobe.c]
>> Reviewed-by: Oleg Nesterov 
>
> Reviewed-by: Song Liu 

Reviewed-and-tested-by: Song Liu 

>
>> ---
>>  include/linux/uprobes.h |   5 +
>>  kernel/events/uprobes.c | 259 
>> ++--
>>  kernel/trace/trace.c|   2 +-
>>  kernel/trace/trace_uprobe.c |  38 ++-
>>  4 files changed, 293 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
>> index bb9d2084af03..103a48a48872 100644
>> --- a/include/linux/uprobes.h
>> +++ b/include/linux/uprobes.h
>> @@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs 
>> *regs);
>>  extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
>>  extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct 
>> mm_struct *mm, unsigned long vaddr, uprobe_opcode_t);
>>  extern int uprobe_register(struct inode *inode, loff_t offset, struct 
>> uprobe_consumer *uc);
>> +extern int uprobe_register_refctr(struct inode *inode, loff_t offset, 
>> loff_t ref_ctr_offset, struct uprobe_consumer *uc);
>>  extern int uprobe_apply(struct inode *inode, loff_t offset, struct 
>> uprobe_consumer *uc, bool);
>>  extern void uprobe_unregister(struct inode *inode, loff_t offset, struct 
>> uprobe_consumer *uc);
>>  extern int uprobe_mmap(struct vm_area_struct *vma);
>> @@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset, 
>> struct uprobe_consumer *uc)
>>  {
>> return -ENOSYS;
>>  }
>> +static inline int uprobe_register_refctr(struct inode *inode, loff_t 
>> offset, loff_t ref_ctr_offset, struct uprobe_consumer *uc)
>> +{
>> +   return -ENOSYS;
>> +}
>>  static inline int
>>  uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer 
>> *uc, bool add)
>>  {
>> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
>> index 919c1ce32beb..35065febcb6c 100644
>> --- a/kernel/events/uprobes.c
>> +++ b/kernel/events/uprobes.c
>> @@ -73,6 +73,7 @@ struct uprobe {
>> struct uprobe_consumer  *consumers;
>> struct inode*inode; /* Also hold a ref to inode 
>> */
>> loff_t  offset;
>> +   loff_t  ref_ctr_offset;
>> unsigned long   flags;
>>
>> /*
>> @@ -88,6 +89,15 @@ struct uprobe {
>> struct arch_uprobe  arch;
>>  };
>>
>> +struct delayed_uprobe {
>> +   struct list_head list;
>> +   struct uprobe *uprobe;
>> +   struct mm_struct *mm;
>> +};
>> +
>> +static DEFINE_MUTEX(delayed_uprobe_lock);
>> +static LIST_HEAD(delayed_uprobe_list);
>> +
>>  /*
>>   * Execute out of line area: anonymous executable mapping installed
>>   * by the probed task to execute the copy of the original instruction
>> @@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned 
>> long vaddr, uprob

Re: [PATCH v9 4/4] perf probe: Support SDT markers having reference counter (semaphore)

[Song Liu]

On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
 wrote:
> With this, perf buildid-cache will save SDT markers with reference
> counter in probe cache. Perf probe will be able to probe markers
> having reference counter. Ex,
>
>   # readelf -n /tmp/tick | grep -A1 loop2
> Name: loop2
> ... Semaphore: 0x10020036
>
>   # ./perf buildid-cache --add /tmp/tick
>   # ./perf probe sdt_tick:loop2
>   # ./perf stat -e sdt_tick:loop2 /tmp/tick
> hi: 0
> hi: 1
> hi: 2
> ^C
>  Performance counter stats for '/tmp/tick':
>  3  sdt_tick:loop2
>2.561851452 seconds time elapsed
>
> Signed-off-by: Ravi Bangoria 
> Acked-by: Masami Hiramatsu 
> Acked-by: Srikar Dronamraju 

Reviewed-and-tested-by: Song Liu 

> ---
>  tools/perf/util/probe-event.c | 39 
>  tools/perf/util/probe-event.h |  1 +
>  tools/perf/util/probe-file.c  | 34 ++--
>  tools/perf/util/probe-file.h  |  1 +
>  tools/perf/util/symbol-elf.c  | 46 
> ---
>  tools/perf/util/symbol.h  |  7 +++
>  6 files changed, 106 insertions(+), 22 deletions(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index f119eb628dbb..e86f8be89157 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -1819,6 +1819,12 @@ int parse_probe_trace_command(const char *cmd, struct 
> probe_trace_event *tev)
> tp->offset = strtoul(fmt2_str, NULL, 10);
> }
>
> +   if (tev->uprobes) {
> +   fmt2_str = strchr(p, '(');
> +   if (fmt2_str)
> +   tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
> +   }
> +
> tev->nargs = argc - 2;
> tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
> if (tev->args == NULL) {
> @@ -2012,6 +2018,22 @@ static int synthesize_probe_trace_arg(struct 
> probe_trace_arg *arg,
> return err;
>  }
>
> +static int
> +synthesize_uprobe_trace_def(struct probe_trace_event *tev, struct strbuf 
> *buf)
> +{
> +   struct probe_trace_point *tp = &tev->point;
> +   int err;
> +
> +   err = strbuf_addf(buf, "%s:0x%lx", tp->module, tp->address);
> +
> +   if (err >= 0 && tp->ref_ctr_offset) {
> +   if (!uprobe_ref_ctr_is_supported())
> +   return -1;
> +   err = strbuf_addf(buf, "(0x%lx)", tp->ref_ctr_offset);
> +   }
> +   return err >= 0 ? 0 : -1;
> +}
> +
>  char *synthesize_probe_trace_command(struct probe_trace_event *tev)
>  {
> struct probe_trace_point *tp = &tev->point;
> @@ -2041,15 +2063,17 @@ char *synthesize_probe_trace_command(struct 
> probe_trace_event *tev)
> }
>
> /* Use the tp->address for uprobes */
> -   if (tev->uprobes)
> -   err = strbuf_addf(&buf, "%s:0x%lx", tp->module, tp->address);
> -   else if (!strncmp(tp->symbol, "0x", 2))
> +   if (tev->uprobes) {
> +   err = synthesize_uprobe_trace_def(tev, &buf);
> +   } else if (!strncmp(tp->symbol, "0x", 2)) {
> /* Absolute address. See try_to_find_absolute_address() */
> err = strbuf_addf(&buf, "%s%s0x%lx", tp->module ?: "",
>   tp->module ? ":" : "", tp->address);
> -   else
> +   } else {
> err = strbuf_addf(&buf, "%s%s%s+%lu", tp->module ?: "",
> tp->module ? ":" : "", tp->symbol, 
> tp->offset);
> +   }
> +
> if (err)
> goto error;
>
> @@ -2633,6 +2657,13 @@ static void warn_uprobe_event_compat(struct 
> probe_trace_event *tev)
>  {
> int i;
> char *buf = synthesize_probe_trace_command(tev);
> +   struct probe_trace_point *tp = &tev->point;
> +
> +   if (tp->ref_ctr_offset && !uprobe_ref_ctr_is_supported()) {
> +   pr_warning("A semaphore is associated with %s:%s and "
> +  "seems your kernel doesn't support it.\n",
> +  tev->group, tev->event);
> +   }
>
> /* Old uprobe event doesn't support memory dereference */
> if (!tev->uprobes || tev->nargs == 0 || !buf)
> diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
> index 45b14f020558..15a98c3a2a2f 100644
> --- a/tools/perf/util/probe-event.h
> +++ b/tools/perf/util/probe-event.h
> @@ -27,6 +27,7 @@ struct probe_trace_point {
> char*symbol;/* Base symbol */
> char*module;/* Module name */
> unsigned long   offset; /* Offset from symbol */
> +   unsigned long   ref_ctr_offset; /* SDT reference counter offset */
> unsigned long   address;/* Actual address of the trace point 
> */
> boolretprobe;   /* Return probe flag */
>  };
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/u

Re: [BUG] madvise05 leads kernel panic on 4.9.122

[Yang Shi]

On 8/21/18 1:36 PM, Andi Kleen wrote:

On Tue, Aug 21, 2018 at 01:30:20PM -0700, yang@linux.alibaba.com wrote:


On 8/21/18 11:43 AM, David Woodhouse wrote:

On Tue, 2018-08-21 at 11:37 -0700, Yang Shi wrote:

I just ran some regression test on stable 4.9.122 with LTP. madvise05
triggers the below kernel panic:

Thanks, David. It works. A silly question, I don't get why this commit could
solve this issue, it looks just like a code refactor. Just because it
changed how to get pfn from page table entries? And, this may cause some
mismatch on 4.9 stable without it?

With the L1TF patches open coded pte_val() to get the PFN can cause problems
because it doesn't do the invert for PROT_NONE mappings

The cleanup changes the open coded versions to use p*_pfn(), which always
works correctly.


Thanks. Got it.



-Andi

Re: general protection fault in finish_task_switch (2)

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:778a33959a8a Merge tag 'please-pull-noboot' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14a5385a40
kernel config:  https://syzkaller.appspot.com/x/.config?x=214e4990bd49329f
dashboard link: https://syzkaller.appspot.com/bug?extid=1f56df64bfb3c29dde6f
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13ffa56140
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1002396140

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

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and  
https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
CPU: 0 PID: 4489 Comm: syz-executor233 Not tainted 4.18.0+ #103
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:__fire_sched_in_preempt_notifiers kernel/sched/core.c:2481  
[inline]

RIP: 0010:fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
RIP: 0010:finish_task_switch+0x538/0x870 kernel/sched/core.c:2679
Code: 89 e1 48 c1 e9 03 42 80 3c 39 00 0f 85 ab 01 00 00 4d 8b 24 24 4d 85  
e4 0f 84 e3 fc ff ff 49 8d 7c 24 10 48 89 f9 48 c1 e9 03 <42> 80 3c 39 00  
74 a5 e8 8c a5 67 00 eb 9e 80 3d 8b c3 32 07 00 0f

RSP: 0018:8801ac0ff058 EFLAGS: 00010a06
RAX:  RBX: 8801db02cc40 RCX: 1bd5a022
RDX:  RSI: 810ed162 RDI: dead0110
RBP: 8801ac0ff140 R08: 8801acb8c300 R09: ed003b221b6c
R10: ed003b221b6c R11: 8801d910db67 R12: dead0100
R13: 8801ca5e0040 R14:  R15: dc00
FS:  () GS:8801db00(0063) knlGS:f7f07b40
CS:  0010 DS: 002b ES: 002b CR0: 80050033
CR2: 7f1304e0b000 CR3: 0001acab3000 CR4: 001426f0
Call Trace:
 context_switch kernel/sched/core.c:2826 [inline]
 __schedule+0x884/0x1df0 kernel/sched/core.c:3471
 schedule+0xfb/0x450 kernel/sched/core.c:3515
 freezable_schedule include/linux/freezer.h:172 [inline]
 futex_wait_queue_me+0x3f9/0x840 kernel/futex.c:2530
 futex_wait+0x45b/0xa20 kernel/futex.c:2645
 do_futex+0x336/0x27d0 kernel/futex.c:3527
 __do_compat_sys_futex kernel/futex_compat.c:201 [inline]
 __se_compat_sys_futex kernel/futex_compat.c:175 [inline]
 __ia32_compat_sys_futex+0x3d9/0x5f0 kernel/futex_compat.c:175
 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
 do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f0bca9
Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b  
5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90  
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90

RSP: 002b:f7f071ec EFLAGS: 0296 ORIG_RAX: 00f0
RAX: ffda RBX: 080fb008 RCX: 
RDX:  RSI:  RDI: 0005
RBP: c080aebe R08:  R09: 
R10:  R11:  R12: 
R13:  R14:  R15: 
Modules linked in:
Dumping ftrace buffer:
   (ftrace buffer empty)
---[ end trace a4bb2f1beb6735f0 ]---
RIP: 0010:__fire_sched_in_preempt_notifiers kernel/sched/core.c:2481  
[inline]

RIP: 0010:fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
RIP: 0010:finish_task_switch+0x538/0x870 kernel/sched/core.c:2679
Code: 89 e1 48 c1 e9 03 42 80 3c 39 00 0f 85 ab 01 00 00 4d 8b 24 24 4d 85  
e4 0f 84 e3 fc ff ff 49 8d 7c 24 10 48 89 f9 48 c1 e9 03 <42> 80 3c 39 00  
74 a5 e8 8c a5 67 00 eb 9e 80 3d 8b c3 32 07 00 0f

RSP: 0018:8801ac0ff058 EFLAGS: 00010a06
RAX:  RBX: 8801db02cc40 RCX: 1bd5a022
RDX:  RSI: 810ed162 RDI: dead0110
RBP: 8801ac0ff140 R08: 8801acb8c300 R09: ed003b221b6c
R10: ed003b221b6c R11: 8801d910db67 R12: dead0100
R13: 8801ca5e0040 R14:  R15: dc00
FS:  () GS:8801db00(0063) knlGS:f7f07b40
CS:  0010 DS: 002b ES: 002b CR0: 80050033
CR2: 7f1304e0b000 CR3: 0001acab3000 CR4: 001426f0

[PATCH 1/1] perf/x86/intel: make error messages less confusing

[Eduardo Valentin]

On a system with X86_FEATURE_ARCH_PERFMON disabled
and with a model not known by family PMU drivers,
user gets a kernel message log like the following:
[ 0.100114] Performance Events: unsupported p6 CPU model 85 no PMU driver, 
software events only.

The "unsupported .. CPU" part may be confusing for some
users. Rewording the messages on the failure path to:
[ 0.667154] Performance Events: unknown p6 PMU on CPU model 85: 
!X86_FEATURE_ARCH_PERFMON: no PMU driver, software events only.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Cc: Kan Liang 
Cc: Dan Carpenter 
Cc: Eduardo Valentin 
Cc: Jia Zhang 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
Reported-by: Matt Wilson 
Signed-off-by: Eduardo Valentin 
---
 arch/x86/events/intel/core.c | 15 +++
 arch/x86/events/intel/p4.c   |  2 +-
 arch/x86/events/intel/p6.c   |  3 ++-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 86f0c15dcc2d..b57a16997ee6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3884,15 +3884,22 @@ __init int intel_pmu_init(void)
char *name;
 
if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
+   int ret = -ENODEV;
+
switch (boot_cpu_data.x86) {
case 0x6:
-   return p6_pmu_init();
+   ret = p6_pmu_init();
+   break;
case 0xb:
-   return knc_pmu_init();
+   ret = knc_pmu_init();
+   break;
case 0xf:
-   return p4_pmu_init();
+   ret = p4_pmu_init();
+   break;
}
-   return -ENODEV;
+   if (ret)
+   pr_cont(" !X86_FEATURE_ARCH_PERFMON: ");
+   return ret;
}
 
/*
diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
index d32c0eed38ca..963d2b0600f6 100644
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -1346,7 +1346,7 @@ __init int p4_pmu_init(void)
 
rdmsr(MSR_IA32_MISC_ENABLE, low, high);
if (!(low & (1 << 7))) {
-   pr_cont("unsupported Netburst CPU model %d ",
+   pr_cont("unknown Netburst PMU on CPU model %d: ",
boot_cpu_data.x86_model);
return -ENODEV;
}
diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c
index 408879b0c0d4..221e374299b2 100644
--- a/arch/x86/events/intel/p6.c
+++ b/arch/x86/events/intel/p6.c
@@ -269,7 +269,8 @@ __init int p6_pmu_init(void)
break;
 
default:
-   pr_cont("unsupported p6 CPU model %d ", 
boot_cpu_data.x86_model);
+   pr_cont("unknown p6 PMU on CPU model %d: ",
+   boot_cpu_data.x86_model);
return -ENODEV;
}
 
-- 
2.18.0

[PATCH v2 2/2] docs: kernel-parameters.txt: document rand_mem_physical_padding parameter

[Masayoshi Mizuma]

From: Masayoshi Mizuma 

This kernel parameter allows to change the padding used for the physical
memory mapping section when KASLR memory is enabled.

For some systems, the default value, CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
is not enough. The option is useful to adjust the padding size to work
around such issue.

Signed-off-by: Masayoshi Mizuma 
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 0c883029881a..97f54c910c9c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3477,6 +3477,13 @@
ramdisk_size=   [RAM] Sizes of RAM disks in kilobytes
See Documentation/blockdev/ramdisk.txt.
 
+   rand_mem_physical_padding=
+   [KNL] Define the padding size in terabytes
+   used for the physical memory mapping section
+   when KASLR memory is enabled.
+   The default value is
+   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
+
ras=option[,option,...] [KNL] RAS-specific options
 
cec_disable [X86]
-- 
2.18.0

[PATCH v2 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping

[Masayoshi Mizuma]

From: Masayoshi Mizuma 

There are some exceptional cases that the padding used for the physical
memory mapping section is not enough.

For example of the cases:
- As Baoquan reported in the following, SGI UV system.
  https://lkml.org/lkml/2017/9/7/87
- Each node of physical memory layout has huge space for hotplug.
  For exapmle of the layout:
SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
SRAT: Node 2 PXM 6 [mem 0x1800-0x1bff] hotplug
SRAT: Node 3 PXM 7 [mem 0x1c00-0x1fff] hotplug

We can increase the padding by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
however, the available entropy is decreased if the padding is increased.
So the config change is not very good for the other most of systems.
And, the needed padding size depends on the system environment, for
example physical memory layout, so the kernel option is better than
changing the config.

Signed-off-by: Masayoshi Mizuma 
---
 arch/x86/mm/kaslr.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b0eda9..aeb62615bd46 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -40,6 +40,7 @@
  */
 static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
 
+static int __initdata rand_mem_physical_padding = 
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
 /*
  * Memory regions randomized by KASLR (except modules that use a separate logic
  * earlier during boot). The list is ordered based on virtual addresses. This
@@ -69,6 +70,20 @@ static inline bool kaslr_memory_enabled(void)
return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
 }
 
+static int __init rand_mem_physical_padding_setup(char *str)
+{
+   int max_padding = (1 << (MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;
+
+   get_option(&str, &rand_mem_physical_padding);
+   if (rand_mem_physical_padding < 0)
+   rand_mem_physical_padding = 0;
+   else if (rand_mem_physical_padding > max_padding)
+   rand_mem_physical_padding = max_padding;
+
+   return 0;
+}
+early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
+
 /* Initialize base and padding for each memory region randomized with KASLR */
 void __init kernel_randomize_memory(void)
 {
@@ -102,7 +117,7 @@ void __init kernel_randomize_memory(void)
 */
BUG_ON(kaslr_regions[0].base != &page_offset_base);
memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
-   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+   rand_mem_physical_padding;
 
/* Adapt phyiscal memory region size based on available memory */
if (memory_tb < kaslr_regions[0].size_tb)
-- 
2.18.0

Re: [BUG][BISECT] NFSv4 root failures after "fs/locks: allow a lock request to block other requests."

[NeilBrown]

On Tue, Aug 21 2018, Jeff Layton wrote:

> On Tue, 2018-08-21 at 15:11 +1000, NeilBrown wrote:
>> On Thu, Aug 16 2018, NeilBrown wrote:
>> 
>> > On Wed, Aug 15 2018, Jeff Layton wrote:
>> > 
>> > > On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
>> > > > Hi,
>> > > > 
>> > > > Bisect pointed commit ce3147990450a68b3f549088b30f087742a08b5d
>> > > > ("fs/locks: allow a lock request to block other requests.") to failure
>> > > > boot of NFSv4 with root on several boards.
>> > > > 
>> > > > Log is here:
>> > > > https://krzk.eu/#/builders/21/builds/836/steps/12/logs/serial0
>> > > > 
>> > > > With several errors:
>> > > > kernel BUG at ../fs/locks.c:336!
>> > > > Unable to handle kernel NULL pointer dereference at virtual address 
>> > > > 0004
>> > > > 
>> > > > Configuration:
>> > > > 1. exynos_defconfig
>> > > > 2. Arch ARM Linux
>> > > > 3. Boards:
>> > > > a. Odroid family (ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC)
>> > > > b. Toradex Colibri VF50 (ARMv7, UP, Cortex-A5)
>> > > > 4. Systemd: v236, 238
>> > > > 5. All boards boot from TFTP with NFS root (NFSv4)
>> > > > 
>> > > > On Colibri VF50 I got slightly different errors:
>> > > > [   11.663204] Internal error: Oops - undefined instruction: 0 [#1] ARM
>> > > > [   12.455273] Unable to handle kernel NULL pointer dereference at
>> > > > virtual address 0004
>> > > > and only with some specific GCC (v6.3) or with other conditions which
>> > > > I did not bisect yet. Maybe Colibri's failure is unrelated to that
>> > > > commit.
>> > > > 
>> > > > Best regards,
>> > > > Krzysztof
>> > 
>> > Thanks a lot for the report Krzysztof!!
>> > 
>> > > 
>> > > The BUG is due to a lock being freed when the fl_blocked list wasn't
>> > > empty (implying that there were still blocked locks waiting on it).
>> > > 
>> > > There are a number of calls to locks_delete_lock_ctx in posix_lock_inode
>> > > and I don't think the fl_blocked list is being handled properly with all
>> > > of them. It only transplants the blocked locks to a new lock when there
>> > > are surviving locks on the list, and that may not be the case when the
>> > > whole file is being unlocked.
>> > 
>> > locks_delete_lock_ctx() calls locks_unlink_lock_ctx() which calls
>> > locks_wake_up_block() which doesn't only wake_up the blocks, but also
>> > detached them. When that function completes, ->fl_blocked must be empty.
>> > 
>> > The trace shows the locks_free_lock() call at the end of fcntl_setlk64()
>> > as the problematic call.
>> > This suggests that do_lock_file_wait() exited with ->fl_blocked
>> > non-empty, which it shouldn't.
>> > 
>> > I think we need to insert a call to locks_wake_up_block() in
>> > do_lock_file_wait() before it returns.
>> > I cannot find a sequence that would make this necessary, but
>> > it isn't surprising that there might be one.
>> > 
>> > I'll dig through the code a bit more later and make sure I understand
>> > what is happening.
>> > 
>> 
>> I think this problem if fixed by the following.  It is probably
>> triggered when the owner already has a lock for part of the requested
>> range.  After waiting for some other lock, the pending request gets
>> merged with the existing lock, and blocked requests aren't moved across
>> in that case.
>> 
>> I still haven't done more testing, so this is just FYI, not a
>> submission.
>> 
>> Thanks,
>> NeilBrown
>> 
>> From: NeilBrown 
>> Date: Tue, 21 Aug 2018 15:09:06 +1000
>> Subject: [PATCH] fs/locks: always delete_block after waiting.
>> 
>> Now that requests can block other requests, we
>> need to be careful to always clean up those blocked
>> requests.
>> Any time that we wait for a request, we might have
>> other requests attached, and when we stop waiting,
>> we much clean them up.
>> If the lock was granted, the requests might have been
>> moved to the new lock, though when merged with a
>> pre-exiting lock, this might not happen.
>> No all cases we don't want blocked locks to remain
>> attached, so we remove them to be safe.
>> 
>> Signed-off-by: NeilBrown 
>> ---
>>  fs/locks.c | 24 +---
>>  1 file changed, 9 insertions(+), 15 deletions(-)
>> 
>> diff --git a/fs/locks.c b/fs/locks.c
>> index de38bafb7f7b..6b310112cf3b 100644
>> --- a/fs/locks.c
>> +++ b/fs/locks.c
>> @@ -1276,12 +1276,10 @@ static int posix_lock_inode_wait(struct inode 
>> *inode, struct file_lock *fl)
>>  if (error != FILE_LOCK_DEFERRED)
>>  break;
>>  error = wait_event_interruptible(fl->fl_wait, !fl->fl_blocker);
>> -if (!error)
>> -continue;
>> -
>> -locks_delete_block(fl);
>> -break;
>> +if (error)
>> +break;
>>  }
>> +locks_delete_block(fl);
>>  return error;
>>  }
>>  
>> @@ -1971,12 +1969,10 @@ static int flock_lock_inode_wait(struct inode 
>> *inode, struct file_lock *fl)
>>  if (error != FILE_LOCK_DEFERRED)
>>  break;
>>