Re: [PATCH v2 1/3] certs: define a trusted platform keyring

[Mimi Zohar]

On Fri, 2018-03-09 at 21:08 +0530, Nayna Jain wrote:
> The kernel can be supplied in SEEPROM or lockable flash memory in embedded
> devices. Some devices may not support secure boot, but the kernel is
> trusted because the image is stored in protected memory. That kernel may
> need to kexec additional kernels, it may be used as a bootloader, for
> example, or it may need to kexec a crashdump kernel. In such cases, it may
> want to verify the signature of the next kernel.
> 
> The kernel, however, cannot directly verify platform keys, and an
> administrator may therefore not want to trust them for arbitrary usage.
> In order to differentiate platform keys from other keys and provide the
> necessary separation of trust, the kernel needs an additional keyring to
> store platform keys.
> 
> This patch implements a built-in list of certificates that are loaded onto
> the trusted platform keyring named ".platform_keys" to facilitate signature
> verification during kexec. Because the platform keyring are builtin, it
> cannot be updated from userspace.
> 
> This keyring can be enabled by setting CONFIG_PLATFORM_KEYRING. The
> platform certificate can be provided using CONFIG_PLATFORM_TRUSTED_KEYS.
> 
> Signed-off-by: Nayna Jain 

Please add my Reviewed-by: Mimi Zohar  on
this and 2/3.

Mimi

> ---
> Changelog:
> 
> v2:
> 
> * Include David Howell's feedback:
>  * Fix the indentation
> * Fix the patch description per line length as suggested by Mimi
> 
>  certs/Kconfig   | 17 ++
>  certs/Makefile  | 13 +++
>  certs/system_certificates.S | 20 +
>  certs/system_keyring.c  | 55 
> ++---
>  4 files changed, 97 insertions(+), 8 deletions(-)
> 
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 5f7663df6e8e..608a4358a25e 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -83,4 +83,21 @@ config SYSTEM_BLACKLIST_HASH_LIST
> wrapper to incorporate the list into the kernel.  Each  should
> be a string of hex digits.
> 
> +config PLATFORM_KEYRING
> +bool "Provide keyring for platform trusted keys"
> +depends on KEYS
> +depends on ASYMMETRIC_KEY_TYPE
> +help
> +   Provide a separate, distinct keyring for platform trusted keys, which
> +   the kernel automatically populates during initialization from values
> +   embedded during build, used for verifying the kexec'ed kernel image
> +   and, possibly, the initramfs signature.
> +
> +config PLATFORM_TRUSTED_KEYS
> + string "Platform/Firmware trusted X.509 certs."
> + depends on PLATFORM_KEYRING
> + help
> +   Provide the filename of a PEM-formatted file containing the platform
> +   trusted X.509 certificates to be loaded in the platform keyring.
> +
>  endmenu
> diff --git a/certs/Makefile b/certs/Makefile
> index 5d0999b9e21b..680903725031 100644
> --- a/certs/Makefile
> +++ b/certs/Makefile
> @@ -104,3 +104,16 @@ targets += signing_key.x509
>  $(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) FORCE
>   $(call 
> if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY))
>  endif # CONFIG_MODULE_SIG
> +
> +
> +ifeq ($(CONFIG_PLATFORM_KEYRING),y)
> +
> +$(eval $(call config_filename,PLATFORM_TRUSTED_KEYS))
> +
> +# GCC doesn't include .incbin files in -MD generated dependencies (PR#66871)
> +$(obj)/system_certificates.o: $(obj)/platform_certificate_list
> +
> +targets += platform_certificate_list
> +$(obj)/platform_certificate_list: scripts/extract-cert 
> $(PLATFORM_TRUSTED_KEYS_FILENAME) FORCE
> + $(call if_changed,extract_certs,$(CONFIG_PLATFORM_TRUSTED_KEYS))
> +endif # CONFIG_PLATFORM_KEYRING
> diff --git a/certs/system_certificates.S b/certs/system_certificates.S
> index 3918ff7235ed..b0eb448ee617 100644
> --- a/certs/system_certificates.S
> +++ b/certs/system_certificates.S
> @@ -14,6 +14,15 @@ __cert_list_start:
>   .incbin "certs/x509_certificate_list"
>  __cert_list_end:
> 
> +#ifdef CONFIG_PLATFORM_KEYRING
> + .align 8
> + .globl VMLINUX_SYMBOL(platform_certificate_list)
> +VMLINUX_SYMBOL(platform_certificate_list):
> +__platform_cert_list_start:
> + .incbin "certs/platform_certificate_list"
> +__platform_cert_list_end:
> +#endif /* CONFIG_PLATFORM_KEYRING */
> +
>  #ifdef CONFIG_SYSTEM_EXTRA_CERTIFICATE
>   .globl VMLINUX_SYMBOL(system_extra_cert)
>   .size system_extra_cert, CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE
> @@ -35,3 +44,14 @@ VMLINUX_SYMBOL(system_certificate_list_size):
>  #else
>   .long __cert_list_end - __cert_list_start
>  #endif
> +
> +#ifdef CONFIG_PLATFORM_KEYRING
> + .align 8
> + .globl VMLINUX_SYMBOL(platform_certificate_list_size)
> +VMLINUX_SYMBOL(platform_certificate_list_size):
> +#ifdef CONFIG_64BIT
> + .quad __platform_cert_list_end - __platform_cert_list_start
> +#else
> + .long __platform_cert_list_end - 

Re: [PATCH v2 1/3] certs: define a trusted platform keyring

[Mimi Zohar]

On Fri, 2018-03-09 at 21:08 +0530, Nayna Jain wrote:
> The kernel can be supplied in SEEPROM or lockable flash memory in embedded
> devices. Some devices may not support secure boot, but the kernel is
> trusted because the image is stored in protected memory. That kernel may
> need to kexec additional kernels, it may be used as a bootloader, for
> example, or it may need to kexec a crashdump kernel. In such cases, it may
> want to verify the signature of the next kernel.
> 
> The kernel, however, cannot directly verify platform keys, and an
> administrator may therefore not want to trust them for arbitrary usage.
> In order to differentiate platform keys from other keys and provide the
> necessary separation of trust, the kernel needs an additional keyring to
> store platform keys.
> 
> This patch implements a built-in list of certificates that are loaded onto
> the trusted platform keyring named ".platform_keys" to facilitate signature
> verification during kexec. Because the platform keyring are builtin, it
> cannot be updated from userspace.
> 
> This keyring can be enabled by setting CONFIG_PLATFORM_KEYRING. The
> platform certificate can be provided using CONFIG_PLATFORM_TRUSTED_KEYS.
> 
> Signed-off-by: Nayna Jain 

Please add my Reviewed-by: Mimi Zohar  on
this and 2/3.

Mimi

> ---
> Changelog:
> 
> v2:
> 
> * Include David Howell's feedback:
>  * Fix the indentation
> * Fix the patch description per line length as suggested by Mimi
> 
>  certs/Kconfig   | 17 ++
>  certs/Makefile  | 13 +++
>  certs/system_certificates.S | 20 +
>  certs/system_keyring.c  | 55 
> ++---
>  4 files changed, 97 insertions(+), 8 deletions(-)
> 
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 5f7663df6e8e..608a4358a25e 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -83,4 +83,21 @@ config SYSTEM_BLACKLIST_HASH_LIST
> wrapper to incorporate the list into the kernel.  Each  should
> be a string of hex digits.
> 
> +config PLATFORM_KEYRING
> +bool "Provide keyring for platform trusted keys"
> +depends on KEYS
> +depends on ASYMMETRIC_KEY_TYPE
> +help
> +   Provide a separate, distinct keyring for platform trusted keys, which
> +   the kernel automatically populates during initialization from values
> +   embedded during build, used for verifying the kexec'ed kernel image
> +   and, possibly, the initramfs signature.
> +
> +config PLATFORM_TRUSTED_KEYS
> + string "Platform/Firmware trusted X.509 certs."
> + depends on PLATFORM_KEYRING
> + help
> +   Provide the filename of a PEM-formatted file containing the platform
> +   trusted X.509 certificates to be loaded in the platform keyring.
> +
>  endmenu
> diff --git a/certs/Makefile b/certs/Makefile
> index 5d0999b9e21b..680903725031 100644
> --- a/certs/Makefile
> +++ b/certs/Makefile
> @@ -104,3 +104,16 @@ targets += signing_key.x509
>  $(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) FORCE
>   $(call 
> if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY))
>  endif # CONFIG_MODULE_SIG
> +
> +
> +ifeq ($(CONFIG_PLATFORM_KEYRING),y)
> +
> +$(eval $(call config_filename,PLATFORM_TRUSTED_KEYS))
> +
> +# GCC doesn't include .incbin files in -MD generated dependencies (PR#66871)
> +$(obj)/system_certificates.o: $(obj)/platform_certificate_list
> +
> +targets += platform_certificate_list
> +$(obj)/platform_certificate_list: scripts/extract-cert 
> $(PLATFORM_TRUSTED_KEYS_FILENAME) FORCE
> + $(call if_changed,extract_certs,$(CONFIG_PLATFORM_TRUSTED_KEYS))
> +endif # CONFIG_PLATFORM_KEYRING
> diff --git a/certs/system_certificates.S b/certs/system_certificates.S
> index 3918ff7235ed..b0eb448ee617 100644
> --- a/certs/system_certificates.S
> +++ b/certs/system_certificates.S
> @@ -14,6 +14,15 @@ __cert_list_start:
>   .incbin "certs/x509_certificate_list"
>  __cert_list_end:
> 
> +#ifdef CONFIG_PLATFORM_KEYRING
> + .align 8
> + .globl VMLINUX_SYMBOL(platform_certificate_list)
> +VMLINUX_SYMBOL(platform_certificate_list):
> +__platform_cert_list_start:
> + .incbin "certs/platform_certificate_list"
> +__platform_cert_list_end:
> +#endif /* CONFIG_PLATFORM_KEYRING */
> +
>  #ifdef CONFIG_SYSTEM_EXTRA_CERTIFICATE
>   .globl VMLINUX_SYMBOL(system_extra_cert)
>   .size system_extra_cert, CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE
> @@ -35,3 +44,14 @@ VMLINUX_SYMBOL(system_certificate_list_size):
>  #else
>   .long __cert_list_end - __cert_list_start
>  #endif
> +
> +#ifdef CONFIG_PLATFORM_KEYRING
> + .align 8
> + .globl VMLINUX_SYMBOL(platform_certificate_list_size)
> +VMLINUX_SYMBOL(platform_certificate_list_size):
> +#ifdef CONFIG_64BIT
> + .quad __platform_cert_list_end - __platform_cert_list_start
> +#else
> + .long __platform_cert_list_end - __platform_cert_list_start
> +#endif
> +#endif /* 

Re: [PATCH v2 3/3] ima: support platform keyring for kernel appraisal

[Mimi Zohar]

On Fri, 2018-03-09 at 21:08 +0530, Nayna Jain wrote:
> Distros may sign the kernel images and, possibly, the initramfs with
> platform trusted keys. On secure boot enabled systems or embedded devices,
> these signatures are to be validated using keys on the platform keyring.
> 
> This patch enables IMA-appraisal to access the platform keyring, based on a
> new Kconfig option "IMA_USE_PLATFORM_KEYRING".
> 
> Signed-off-by: Nayna Jain 

Thanks, Nayna!

Signed-off-by: Mimi Zohar 


> ---
> Changelog:
> 
> v2:
> * Rename integrity_load_keyring() to integrity_find_keyring()
> * Fix the patch description per line length as suggested by Mimi
> 
>  security/integrity/digsig.c   | 15 +++
>  security/integrity/ima/Kconfig| 10 ++
>  security/integrity/ima/ima_appraise.c | 22 +-
>  security/integrity/ima/ima_init.c |  4 
>  security/integrity/integrity.h| 17 -
>  5 files changed, 62 insertions(+), 6 deletions(-)
> 
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 6f9e4ce568cd..cfeb977bced9 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -34,6 +34,8 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>   ".ima",
>  #endif
>   "_module",
> + ".platform_keys",
> +
>  };
> 
>  #ifdef CONFIG_INTEGRITY_TRUSTED_KEYRING
> @@ -78,6 +80,19 @@ int integrity_digsig_verify(const unsigned int id, const 
> char *sig, int siglen,
>   return -EOPNOTSUPP;
>  }
> 
> +#ifdef CONFIG_IMA_USE_PLATFORM_KEYRING
> +int __init integrity_find_keyring(const unsigned int id)
> +{
> +
> + keyring[id] = find_keyring_by_name(keyring_name[id], 0);
> + if (IS_ERR(keyring[id]))
> + if (PTR_ERR(keyring[id]) != -ENOKEY)
> + return PTR_ERR(keyring[id]);
> + return 0;
> +
> +}
> +#endif
> +
>  int __init integrity_init_keyring(const unsigned int id)
>  {
>   const struct cred *cred = current_cred();
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 35ef69312811..2e89d4f8a364 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -227,3 +227,13 @@ config IMA_APPRAISE_SIGNED_INIT
>   default n
>   help
>  This option requires user-space init to be signed.
> +
> +config IMA_USE_PLATFORM_KEYRING
> +   bool "IMA uses keys from Platform Keyring for verification"
> +   depends on PLATFORM_KEYRING
> +   depends on IMA_APPRAISE
> +   depends on INTEGRITY_ASYMMETRIC_KEYS
> +   default n
> +   help
> +   This option enables IMA appraisal to look for the platform
> +   trusted keys in .platform_keys keyring.
> diff --git a/security/integrity/ima/ima_appraise.c 
> b/security/integrity/ima/ima_appraise.c
> index f2803a40ff82..5fec29f40595 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -276,13 +276,25 @@ int ima_appraise_measurement(enum ima_hooks func,
>(const char *)xattr_value, rc,
>iint->ima_hash->digest,
>iint->ima_hash->length);
> - if (rc == -EOPNOTSUPP) {
> - status = INTEGRITY_UNKNOWN;
> - } else if (rc) {
> + if (rc) {
> + if (rc == -EOPNOTSUPP) {
> + status = INTEGRITY_UNKNOWN;
> + break;
> + }
> + if (func == KEXEC_KERNEL_CHECK) {
> + rc = integrity_digsig_verify(
> + INTEGRITY_KEYRING_PLATFORM,
> + (const char *)xattr_value,
> + xattr_len,
> + iint->ima_hash->digest,
> + iint->ima_hash->length);
> + if (!rc) {
> + status = INTEGRITY_PASS;
> + break;
> + }
> + }
>   cause = "invalid-signature";
>   status = INTEGRITY_FAIL;
> - } else {
> - status = INTEGRITY_PASS;
>   }
>   break;
>   default:
> diff --git a/security/integrity/ima/ima_init.c 
> b/security/integrity/ima/ima_init.c
> index 29b72cd2502e..5778647c6bc4 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -122,6 +122,10 @@ int __init ima_init(void)
>   if (rc)
>   return rc;
> 
> + rc = integrity_find_keyring(INTEGRITY_KEYRING_PLATFORM);
> + if (rc)
> + pr_info("Platform keyring is not 

Re: [PATCH v2 3/3] ima: support platform keyring for kernel appraisal

[Mimi Zohar]

On Fri, 2018-03-09 at 21:08 +0530, Nayna Jain wrote:
> Distros may sign the kernel images and, possibly, the initramfs with
> platform trusted keys. On secure boot enabled systems or embedded devices,
> these signatures are to be validated using keys on the platform keyring.
> 
> This patch enables IMA-appraisal to access the platform keyring, based on a
> new Kconfig option "IMA_USE_PLATFORM_KEYRING".
> 
> Signed-off-by: Nayna Jain 

Thanks, Nayna!

Signed-off-by: Mimi Zohar 


> ---
> Changelog:
> 
> v2:
> * Rename integrity_load_keyring() to integrity_find_keyring()
> * Fix the patch description per line length as suggested by Mimi
> 
>  security/integrity/digsig.c   | 15 +++
>  security/integrity/ima/Kconfig| 10 ++
>  security/integrity/ima/ima_appraise.c | 22 +-
>  security/integrity/ima/ima_init.c |  4 
>  security/integrity/integrity.h| 17 -
>  5 files changed, 62 insertions(+), 6 deletions(-)
> 
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 6f9e4ce568cd..cfeb977bced9 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -34,6 +34,8 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>   ".ima",
>  #endif
>   "_module",
> + ".platform_keys",
> +
>  };
> 
>  #ifdef CONFIG_INTEGRITY_TRUSTED_KEYRING
> @@ -78,6 +80,19 @@ int integrity_digsig_verify(const unsigned int id, const 
> char *sig, int siglen,
>   return -EOPNOTSUPP;
>  }
> 
> +#ifdef CONFIG_IMA_USE_PLATFORM_KEYRING
> +int __init integrity_find_keyring(const unsigned int id)
> +{
> +
> + keyring[id] = find_keyring_by_name(keyring_name[id], 0);
> + if (IS_ERR(keyring[id]))
> + if (PTR_ERR(keyring[id]) != -ENOKEY)
> + return PTR_ERR(keyring[id]);
> + return 0;
> +
> +}
> +#endif
> +
>  int __init integrity_init_keyring(const unsigned int id)
>  {
>   const struct cred *cred = current_cred();
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 35ef69312811..2e89d4f8a364 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -227,3 +227,13 @@ config IMA_APPRAISE_SIGNED_INIT
>   default n
>   help
>  This option requires user-space init to be signed.
> +
> +config IMA_USE_PLATFORM_KEYRING
> +   bool "IMA uses keys from Platform Keyring for verification"
> +   depends on PLATFORM_KEYRING
> +   depends on IMA_APPRAISE
> +   depends on INTEGRITY_ASYMMETRIC_KEYS
> +   default n
> +   help
> +   This option enables IMA appraisal to look for the platform
> +   trusted keys in .platform_keys keyring.
> diff --git a/security/integrity/ima/ima_appraise.c 
> b/security/integrity/ima/ima_appraise.c
> index f2803a40ff82..5fec29f40595 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -276,13 +276,25 @@ int ima_appraise_measurement(enum ima_hooks func,
>(const char *)xattr_value, rc,
>iint->ima_hash->digest,
>iint->ima_hash->length);
> - if (rc == -EOPNOTSUPP) {
> - status = INTEGRITY_UNKNOWN;
> - } else if (rc) {
> + if (rc) {
> + if (rc == -EOPNOTSUPP) {
> + status = INTEGRITY_UNKNOWN;
> + break;
> + }
> + if (func == KEXEC_KERNEL_CHECK) {
> + rc = integrity_digsig_verify(
> + INTEGRITY_KEYRING_PLATFORM,
> + (const char *)xattr_value,
> + xattr_len,
> + iint->ima_hash->digest,
> + iint->ima_hash->length);
> + if (!rc) {
> + status = INTEGRITY_PASS;
> + break;
> + }
> + }
>   cause = "invalid-signature";
>   status = INTEGRITY_FAIL;
> - } else {
> - status = INTEGRITY_PASS;
>   }
>   break;
>   default:
> diff --git a/security/integrity/ima/ima_init.c 
> b/security/integrity/ima/ima_init.c
> index 29b72cd2502e..5778647c6bc4 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -122,6 +122,10 @@ int __init ima_init(void)
>   if (rc)
>   return rc;
> 
> + rc = integrity_find_keyring(INTEGRITY_KEYRING_PLATFORM);
> + if (rc)
> + pr_info("Platform keyring is not found. (rc=%d)\n", rc);
> +
>   rc = 

Re: [PATCH v5 3/6] power: supply: axp20x_battery: use data struct for variant specific code

[Quentin Schulz]

Hi Sebastian,

On Fri, Mar 09, 2018 at 05:08:25PM +0100, Sebastian Reichel wrote:
> Hi Quentin,
> 
> On Wed, Feb 28, 2018 at 11:35:58AM +0100, Quentin Schulz wrote:
> > We used to use IDs to select a function or a feature depending on the
> > variant. It's easier to maintain the code by adding data structure
> > storing the few differences between variants so that we don't add a pile
> > of if conditions.
> > 
> > Let's use this data structure and update the code to use it.
> > 
> > Signed-off-by: Quentin Schulz 
> > Reviewed-by: Chen-Yu Tsai 
> > ---
> 
> I applied this, but modified the patch slightly, so that
> it actually calls your new set_max_voltage() callback in
> axp20x_battery_set_prop(). Please check that the resulting
> patch looks correct to you:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=for-next=648badd797c762a713b48afc3b67d56abdd0073b
> 

You actually fixed an error in this patch while doing so, so thank you :)

Looks good to me.

Quentin


signature.asc
Description: PGP signature

Re: [PATCH v5 3/6] power: supply: axp20x_battery: use data struct for variant specific code

[Quentin Schulz]

Hi Sebastian,

On Fri, Mar 09, 2018 at 05:08:25PM +0100, Sebastian Reichel wrote:
> Hi Quentin,
> 
> On Wed, Feb 28, 2018 at 11:35:58AM +0100, Quentin Schulz wrote:
> > We used to use IDs to select a function or a feature depending on the
> > variant. It's easier to maintain the code by adding data structure
> > storing the few differences between variants so that we don't add a pile
> > of if conditions.
> > 
> > Let's use this data structure and update the code to use it.
> > 
> > Signed-off-by: Quentin Schulz 
> > Reviewed-by: Chen-Yu Tsai 
> > ---
> 
> I applied this, but modified the patch slightly, so that
> it actually calls your new set_max_voltage() callback in
> axp20x_battery_set_prop(). Please check that the resulting
> patch looks correct to you:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=for-next=648badd797c762a713b48afc3b67d56abdd0073b
> 

You actually fixed an error in this patch while doing so, so thank you :)

Looks good to me.

Quentin


signature.asc
Description: PGP signature

Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown

[Marc Zyngier]

On 09/03/18 10:33, Grzegorz Jaszczyk wrote:
>> Not using EOImode==1 is definitely an oddity (at least on the host), but
>> that doesn't mean it shouldn't work.
>>
>> The reason the thing is hanging is that although we correctly deactivate
>> the interrupt, nothing performs the priority drop. Your write to EOI
>> helps in the sense that it guarantees that both priority drop and
>> deactivate are done with the same operation, but that's not something
>> we'd want to expose.
>>
>> My preferred approach would be to nuke the active priority registers at
>> boot time, as the CPUs come up. I'll try to write something this week.
> 
> I've made a PoC which performs priority drop at boot time as you
> suggested and it works with both GICv2 and GICv3 but I see some
> problem:
> It seems that the only way to drop the priority is to perform write to
> EOI register (the GIC_RPR is RO). According to GIC documentation a
> write to EOI register must correspond to the most recent valid read
> from IAR. The problem is that the interrupt was already acked in the
> 'original' kernel, so reading GICC_IAR in crashdump kernel returns
> spurious interrupt and it seems that there is no way to figure out
> appropriate irqnr for EOI write. Nevertheless I've observed that
> choosing random irqnr for EOI write works fine (maybe because all
> interrupts in Linux uses the same priority?).
> 
> Here is the PoC (not ready for submission only for further
> discussion): https://pastebin.com/gLYNuRiZ
> 
> Looking forward to your feedback.

Well, the feedback is that this patch is really horrible, and choosing a 
random IRQ is at best hilarious. It also doesn't account for multiple 
priorities being active... In short, this is just fundamentally broken.

I gave you a clue about the active priority registers. Why didn't you 
try that?

Anyway, here's something that should fix it.

M.

>From 6ace9d56c96203c4d11a23cbec6a6c216164bb88 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Fri, 9 Mar 2018 14:53:19 +
Subject: [PATCH] irqchip/gic-v2: Reset APRn registers at boot time

Booting a crash kernel while in an interrupt handler is likely
to leave the Active Priority Registers with some state that
is not relevant to the new kernel, and is likely to lead
to erratic behaviours such as interrupts not firing as their
priority is already active.

As a sanity measure, wipe the APRs clean on startup.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 121af5cf688f..79801c24800b 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -453,15 +453,26 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
return mask;
 }
 
+static bool gic_check_gicv2(void __iomem *base)
+{
+   u32 val = readl_relaxed(base + GIC_CPU_IDENT);
+   return (val & 0xff0fff) == 0x02043B;
+}
+
 static void gic_cpu_if_up(struct gic_chip_data *gic)
 {
void __iomem *cpu_base = gic_data_cpu_base(gic);
u32 bypass = 0;
u32 mode = 0;
+   int i;
 
if (gic == _data[0] && static_key_true(_deactivate))
mode = GIC_CPU_CTRL_EOImodeNS;
 
+   if (gic_check_gicv2(cpu_base))
+   for (i = 0; i < 4; i++)
+   writel_relaxed(0, cpu_base + GIC_CPU_ACTIVEPRIO + i * 
4);
+
/*
* Preserve bypass disable bits to be written back later
*/
@@ -1264,12 +1275,6 @@ static int __init gicv2_force_probe_cfg(char *buf)
 }
 early_param("irqchip.gicv2_force_probe", gicv2_force_probe_cfg);
 
-static bool gic_check_gicv2(void __iomem *base)
-{
-   u32 val = readl_relaxed(base + GIC_CPU_IDENT);
-   return (val & 0xff0fff) == 0x02043B;
-}
-
 static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
 {
struct resource cpuif_res;
-- 
2.14.2


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

Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown

[Marc Zyngier]

On 09/03/18 10:33, Grzegorz Jaszczyk wrote:
>> Not using EOImode==1 is definitely an oddity (at least on the host), but
>> that doesn't mean it shouldn't work.
>>
>> The reason the thing is hanging is that although we correctly deactivate
>> the interrupt, nothing performs the priority drop. Your write to EOI
>> helps in the sense that it guarantees that both priority drop and
>> deactivate are done with the same operation, but that's not something
>> we'd want to expose.
>>
>> My preferred approach would be to nuke the active priority registers at
>> boot time, as the CPUs come up. I'll try to write something this week.
> 
> I've made a PoC which performs priority drop at boot time as you
> suggested and it works with both GICv2 and GICv3 but I see some
> problem:
> It seems that the only way to drop the priority is to perform write to
> EOI register (the GIC_RPR is RO). According to GIC documentation a
> write to EOI register must correspond to the most recent valid read
> from IAR. The problem is that the interrupt was already acked in the
> 'original' kernel, so reading GICC_IAR in crashdump kernel returns
> spurious interrupt and it seems that there is no way to figure out
> appropriate irqnr for EOI write. Nevertheless I've observed that
> choosing random irqnr for EOI write works fine (maybe because all
> interrupts in Linux uses the same priority?).
> 
> Here is the PoC (not ready for submission only for further
> discussion): https://pastebin.com/gLYNuRiZ
> 
> Looking forward to your feedback.

Well, the feedback is that this patch is really horrible, and choosing a 
random IRQ is at best hilarious. It also doesn't account for multiple 
priorities being active... In short, this is just fundamentally broken.

I gave you a clue about the active priority registers. Why didn't you 
try that?

Anyway, here's something that should fix it.

M.

>From 6ace9d56c96203c4d11a23cbec6a6c216164bb88 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Fri, 9 Mar 2018 14:53:19 +
Subject: [PATCH] irqchip/gic-v2: Reset APRn registers at boot time

Booting a crash kernel while in an interrupt handler is likely
to leave the Active Priority Registers with some state that
is not relevant to the new kernel, and is likely to lead
to erratic behaviours such as interrupts not firing as their
priority is already active.

As a sanity measure, wipe the APRs clean on startup.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 121af5cf688f..79801c24800b 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -453,15 +453,26 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
return mask;
 }
 
+static bool gic_check_gicv2(void __iomem *base)
+{
+   u32 val = readl_relaxed(base + GIC_CPU_IDENT);
+   return (val & 0xff0fff) == 0x02043B;
+}
+
 static void gic_cpu_if_up(struct gic_chip_data *gic)
 {
void __iomem *cpu_base = gic_data_cpu_base(gic);
u32 bypass = 0;
u32 mode = 0;
+   int i;
 
if (gic == _data[0] && static_key_true(_deactivate))
mode = GIC_CPU_CTRL_EOImodeNS;
 
+   if (gic_check_gicv2(cpu_base))
+   for (i = 0; i < 4; i++)
+   writel_relaxed(0, cpu_base + GIC_CPU_ACTIVEPRIO + i * 
4);
+
/*
* Preserve bypass disable bits to be written back later
*/
@@ -1264,12 +1275,6 @@ static int __init gicv2_force_probe_cfg(char *buf)
 }
 early_param("irqchip.gicv2_force_probe", gicv2_force_probe_cfg);
 
-static bool gic_check_gicv2(void __iomem *base)
-{
-   u32 val = readl_relaxed(base + GIC_CPU_IDENT);
-   return (val & 0xff0fff) == 0x02043B;
-}
-
 static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
 {
struct resource cpuif_res;
-- 
2.14.2


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

Re: [PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

[David Miller]

From: Jason Wang 
Date: Fri,  9 Mar 2018 14:50:31 +0800

> This small series try to fix several bugs of ptr_ring usage in
> vhost_net. Please review.

Series applied, thanks Jason.

Re: [PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

[David Miller]

From: Jason Wang 
Date: Fri,  9 Mar 2018 14:50:31 +0800

> This small series try to fix several bugs of ptr_ring usage in
> vhost_net. Please review.

Series applied, thanks Jason.

Re: Regression from efi: call get_event_log before ExitBootServices

[James Bottomley]

On Fri, 2018-03-09 at 10:29 +0100, Hans de Goede wrote:
> Hi,
> 
> On 08-03-18 18:26, Jeremy Cline wrote:
> > 
> > On 03/08/2018 11:50 AM, Hans de Goede wrote:
[...]
> > > > The UEFI firmware does some measurements and so does shim. So
> > > > you should have some event logs. What version of shim are you
> > > > using? And also would be good to know if it's the same shim
> > > > version that Jeremy is using.
> > > 
> > > That is a very good question, I'm using: shim-ia32-13-0.7.x86_64, 
> > > which is the last version for F27 AFAICT.
> > 
> > All my tablet has installed is shim-0.8-10.x86_64, no shim-ia32.
> 
> Yes my bad, although if the kernel changes break booting on systems
> without the shim that is still good to know and something which
> we probably ought to fix.

My laptop is set up with secure boot but without shim using a shim
protocol thin layer to check the kernel signature against db variables:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/ShimReplace.c

and I haven't seen any breakage, so not having a shim that does
measurements works for me all the way up to -rc4.

James

Re: Regression from efi: call get_event_log before ExitBootServices

[James Bottomley]

On Fri, 2018-03-09 at 10:29 +0100, Hans de Goede wrote:
> Hi,
> 
> On 08-03-18 18:26, Jeremy Cline wrote:
> > 
> > On 03/08/2018 11:50 AM, Hans de Goede wrote:
[...]
> > > > The UEFI firmware does some measurements and so does shim. So
> > > > you should have some event logs. What version of shim are you
> > > > using? And also would be good to know if it's the same shim
> > > > version that Jeremy is using.
> > > 
> > > That is a very good question, I'm using: shim-ia32-13-0.7.x86_64, 
> > > which is the last version for F27 AFAICT.
> > 
> > All my tablet has installed is shim-0.8-10.x86_64, no shim-ia32.
> 
> Yes my bad, although if the kernel changes break booting on systems
> without the shim that is still good to know and something which
> we probably ought to fix.

My laptop is set up with secure boot but without shim using a shim
protocol thin layer to check the kernel signature against db variables:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/ShimReplace.c

and I haven't seen any breakage, so not having a shim that does
measurements works for me all the way up to -rc4.

James

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

[Andrea Parri]

On Fri, Mar 09, 2018 at 11:39:11AM -0500, Alan Stern wrote:
> On Fri, 9 Mar 2018, Andrea Parri wrote:
> 
> > Atomics present the same issue with locking: release and acquire
> > variants need to be strengthened to meet the constraints defined
> > by the Linux-kernel memory consistency model [1].
> > 
> > Atomics present a further issue: implementations of atomics such
> > as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs,
> > which do not give full-ordering with .aqrl; for example, current
> > implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
> > below to end up with the state indicated in the "exists" clause.
> > 
> > In order to "synchronize" LKMM and RISC-V's implementation, this
> > commit strengthens the implementations of the atomics operations
> > by replacing .rl and .aq with the use of ("lightweigth") fences,
> > and by replacing .aqrl LR/SC pairs in sequences such as:
> > 
> >   0:  lr.w.aqrl  %0, %addr
> >   bne%0, %old, 1f
> >   ...
> >   sc.w.aqrl  %1, %new, %addr
> >   bnez   %1, 0b
> >   1:
> > 
> > with sequences of the form:
> > 
> >   0:  lr.w   %0, %addr
> >   bne%0, %old, 1f
> >   ...
> >   sc.w.rl%1, %new, %addr   /* SC-release   */
> >   bnez   %1, 0b
> >   fence  rw, rw/* "full" fence */
> >   1:
> > 
> > following Daniel's suggestion.
> > 
> > These modifications were validated with simulation of the RISC-V
> > memory consistency model.
> > 
> > C lr-sc-aqrl-pair-vs-full-barrier
> > 
> > {}
> > 
> > P0(int *x, int *y, atomic_t *u)
> > {
> > int r0;
> > int r1;
> > 
> > WRITE_ONCE(*x, 1);
> > r0 = atomic_cmpxchg(u, 0, 1);
> > r1 = READ_ONCE(*y);
> > }
> > 
> > P1(int *x, int *y, atomic_t *v)
> > {
> > int r0;
> > int r1;
> > 
> > WRITE_ONCE(*y, 1);
> > r0 = atomic_cmpxchg(v, 0, 1);
> > r1 = READ_ONCE(*x);
> > }
> > 
> > exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0)
> 
> There's another aspect to this imposed by the LKMM, and I'm not sure
> whether your patch addresses it.  You add a fence after the cmpxchg
> operation but nothing before it.  So what would happen with the 
> following litmus test (which the LKMM forbids)?

Available RISC-V memory model formalizations forbid it;  an intuitive
explanation could probably be derived by paralleling the argument for
arm64, as pointed out by Daniel at:

  https://marc.info/?l=linux-kernel=151994289015267=2

  Andrea


> 
> C SB-atomic_cmpxchg-mb
> 
> {}
> 
> P0(int *x, int *y)
> {
>   int r0;
> 
>   WRITE_ONCE(*x, 1);
>   r0 = atomic_cmpxchg(y, 0, 0);
> }
> 
> P1(int *x, int *y)
> {
>   int r1;
> 
>   WRITE_ONCE(*y, 1);
>   smp_mb();
>   r1 = READ_ONCE(*x);
> }
> 
> exists (0:r0=0 /\ 1:r1=0)
> 
> This is yet another illustration showing that full fences are stronger 
> than cominations of release + acquire.
> 
> Alan Stern
> 

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

[Andrea Parri]

On Fri, Mar 09, 2018 at 11:39:11AM -0500, Alan Stern wrote:
> On Fri, 9 Mar 2018, Andrea Parri wrote:
> 
> > Atomics present the same issue with locking: release and acquire
> > variants need to be strengthened to meet the constraints defined
> > by the Linux-kernel memory consistency model [1].
> > 
> > Atomics present a further issue: implementations of atomics such
> > as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs,
> > which do not give full-ordering with .aqrl; for example, current
> > implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
> > below to end up with the state indicated in the "exists" clause.
> > 
> > In order to "synchronize" LKMM and RISC-V's implementation, this
> > commit strengthens the implementations of the atomics operations
> > by replacing .rl and .aq with the use of ("lightweigth") fences,
> > and by replacing .aqrl LR/SC pairs in sequences such as:
> > 
> >   0:  lr.w.aqrl  %0, %addr
> >   bne%0, %old, 1f
> >   ...
> >   sc.w.aqrl  %1, %new, %addr
> >   bnez   %1, 0b
> >   1:
> > 
> > with sequences of the form:
> > 
> >   0:  lr.w   %0, %addr
> >   bne%0, %old, 1f
> >   ...
> >   sc.w.rl%1, %new, %addr   /* SC-release   */
> >   bnez   %1, 0b
> >   fence  rw, rw/* "full" fence */
> >   1:
> > 
> > following Daniel's suggestion.
> > 
> > These modifications were validated with simulation of the RISC-V
> > memory consistency model.
> > 
> > C lr-sc-aqrl-pair-vs-full-barrier
> > 
> > {}
> > 
> > P0(int *x, int *y, atomic_t *u)
> > {
> > int r0;
> > int r1;
> > 
> > WRITE_ONCE(*x, 1);
> > r0 = atomic_cmpxchg(u, 0, 1);
> > r1 = READ_ONCE(*y);
> > }
> > 
> > P1(int *x, int *y, atomic_t *v)
> > {
> > int r0;
> > int r1;
> > 
> > WRITE_ONCE(*y, 1);
> > r0 = atomic_cmpxchg(v, 0, 1);
> > r1 = READ_ONCE(*x);
> > }
> > 
> > exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0)
> 
> There's another aspect to this imposed by the LKMM, and I'm not sure
> whether your patch addresses it.  You add a fence after the cmpxchg
> operation but nothing before it.  So what would happen with the 
> following litmus test (which the LKMM forbids)?

Available RISC-V memory model formalizations forbid it;  an intuitive
explanation could probably be derived by paralleling the argument for
arm64, as pointed out by Daniel at:

  https://marc.info/?l=linux-kernel=151994289015267=2

  Andrea


> 
> C SB-atomic_cmpxchg-mb
> 
> {}
> 
> P0(int *x, int *y)
> {
>   int r0;
> 
>   WRITE_ONCE(*x, 1);
>   r0 = atomic_cmpxchg(y, 0, 0);
> }
> 
> P1(int *x, int *y)
> {
>   int r1;
> 
>   WRITE_ONCE(*y, 1);
>   smp_mb();
>   r1 = READ_ONCE(*x);
> }
> 
> exists (0:r0=0 /\ 1:r1=0)
> 
> This is yet another illustration showing that full fences are stronger 
> than cominations of release + acquire.
> 
> Alan Stern
> 

[GIT PULL] PCI fixes for v4.16

[Bjorn Helgaas]

PCI fixes:

  - fix sparc build issue when OF_IRQ not enabled (Guenter Roeck) 

  - fix enumeration of devices below switches on DesignWare-based
controllers (Koen Vandeputte)


The following changes since commit c37406e05d1e541df40b8b81c4bd40753fcaf414:

  PCI: Allow release of resources that were never assigned (2018-02-26 14:51:13 
-0600)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.16-fixes-3

for you to fetch changes up to fc110ebdd014dd1368c98e7685b47789c31fab42:

  PCI: dwc: Fix enumeration end when reaching root subordinate (2018-03-07 
10:46:39 -0600)


pci-v4.16-fixes-3


Guenter Roeck (1):
  PCI: Move of_irq_parse_and_map_pci() declaration under OF_IRQ

Koen Vandeputte (1):
  PCI: dwc: Fix enumeration end when reaching root subordinate

 drivers/pci/dwc/pcie-designware-host.c |  2 +-
 include/linux/of_pci.h | 17 ++---
 2 files changed, 11 insertions(+), 8 deletions(-)

[GIT PULL] PCI fixes for v4.16

[Bjorn Helgaas]

PCI fixes:

  - fix sparc build issue when OF_IRQ not enabled (Guenter Roeck) 

  - fix enumeration of devices below switches on DesignWare-based
controllers (Koen Vandeputte)


The following changes since commit c37406e05d1e541df40b8b81c4bd40753fcaf414:

  PCI: Allow release of resources that were never assigned (2018-02-26 14:51:13 
-0600)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.16-fixes-3

for you to fetch changes up to fc110ebdd014dd1368c98e7685b47789c31fab42:

  PCI: dwc: Fix enumeration end when reaching root subordinate (2018-03-07 
10:46:39 -0600)


pci-v4.16-fixes-3


Guenter Roeck (1):
  PCI: Move of_irq_parse_and_map_pci() declaration under OF_IRQ

Koen Vandeputte (1):
  PCI: dwc: Fix enumeration end when reaching root subordinate

 drivers/pci/dwc/pcie-designware-host.c |  2 +-
 include/linux/of_pci.h | 17 ++---
 2 files changed, 11 insertions(+), 8 deletions(-)

Re: [PATCH] pktgen: Remove VLA usage

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 8 Mar 2018 23:43:40 -0600

> In preparation to enabling -Wvla, remove VLA usage and replace it
> with a fixed-length array instead.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> David,
> 
> I'm not sure how often this function is being called and,
> depending on the frequency it may be worth to use
> dynamic memory allocation instead?

It happens every time a config setting is made via the sysfs
files when debug is enabled.

This is not something that happens often.

So your patch is fine, applied to net-next, thanks.

Re: [PATCH] pktgen: Remove VLA usage

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 8 Mar 2018 23:43:40 -0600

> In preparation to enabling -Wvla, remove VLA usage and replace it
> with a fixed-length array instead.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> David,
> 
> I'm not sure how often this function is being called and,
> depending on the frequency it may be worth to use
> dynamic memory allocation instead?

It happens every time a config setting is made via the sysfs
files when debug is enabled.

This is not something that happens often.

So your patch is fine, applied to net-next, thanks.

Re: [PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:31PM +0800, Jason Wang wrote:
> Hi:
> 
> This small series try to fix several bugs of ptr_ring usage in
> vhost_net. Please review.
> 
> Thanks

ACK series, thanks Jason!

> Alexander Potapenko (1):
>   vhost_net: initialize rx_ring in vhost_net_open()
> 
> Jason Wang (2):
>   vhost_net: keep private_data and rx_ring synced
>   vhost_net: examine pointer types during un-producing
> 
>  drivers/net/tun.c  | 3 ++-
>  drivers/vhost/net.c| 8 +---
>  include/linux/if_tun.h | 4 
>  3 files changed, 11 insertions(+), 4 deletions(-)
> 
> -- 
> 2.7.4

Re: [PATCH net 0/3] Several fixes for vhost_net ptr_ring usage

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:31PM +0800, Jason Wang wrote:
> Hi:
> 
> This small series try to fix several bugs of ptr_ring usage in
> vhost_net. Please review.
> 
> Thanks

ACK series, thanks Jason!

> Alexander Potapenko (1):
>   vhost_net: initialize rx_ring in vhost_net_open()
> 
> Jason Wang (2):
>   vhost_net: keep private_data and rx_ring synced
>   vhost_net: examine pointer types during un-producing
> 
>  drivers/net/tun.c  | 3 ++-
>  drivers/vhost/net.c| 8 +---
>  include/linux/if_tun.h | 4 
>  3 files changed, 11 insertions(+), 4 deletions(-)
> 
> -- 
> 2.7.4

Re: [PATCH net 2/3] vhost_net: keep private_data and rx_ring synced

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:33PM +0800, Jason Wang wrote:
> We get pointer ring from the exported sock, this means we should keep
> rx_ring and vq->private synced during both vq stop and backend set,
> otherwise we may see stale rx_ring.
> 
> Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array")
> Signed-off-by: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/vhost/net.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 60f1080..efb9306 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -973,6 +973,7 @@ static struct socket *vhost_net_stop_vq(struct vhost_net 
> *n,
>   vhost_net_disable_vq(n, vq);
>   vq->private_data = NULL;
>   vhost_net_buf_unproduce(nvq);
> + nvq->rx_ring = NULL;
>   mutex_unlock(>mutex);
>   return sock;
>  }
> @@ -1162,14 +1163,14 @@ static long vhost_net_set_backend(struct vhost_net 
> *n, unsigned index, int fd)
>   vhost_net_disable_vq(n, vq);
>   vq->private_data = sock;
>   vhost_net_buf_unproduce(nvq);
> - if (index == VHOST_NET_VQ_RX)
> - nvq->rx_ring = get_tap_ptr_ring(fd);
>   r = vhost_vq_init_access(vq);
>   if (r)
>   goto err_used;
>   r = vhost_net_enable_vq(n, vq);
>   if (r)
>   goto err_used;
> + if (index == VHOST_NET_VQ_RX)
> + nvq->rx_ring = get_tap_ptr_ring(fd);
>  
>   oldubufs = nvq->ubufs;
>   nvq->ubufs = ubufs;
> -- 
> 2.7.4

Re: [PATCH net 2/3] vhost_net: keep private_data and rx_ring synced

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:33PM +0800, Jason Wang wrote:
> We get pointer ring from the exported sock, this means we should keep
> rx_ring and vq->private synced during both vq stop and backend set,
> otherwise we may see stale rx_ring.
> 
> Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array")
> Signed-off-by: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/vhost/net.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 60f1080..efb9306 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -973,6 +973,7 @@ static struct socket *vhost_net_stop_vq(struct vhost_net 
> *n,
>   vhost_net_disable_vq(n, vq);
>   vq->private_data = NULL;
>   vhost_net_buf_unproduce(nvq);
> + nvq->rx_ring = NULL;
>   mutex_unlock(>mutex);
>   return sock;
>  }
> @@ -1162,14 +1163,14 @@ static long vhost_net_set_backend(struct vhost_net 
> *n, unsigned index, int fd)
>   vhost_net_disable_vq(n, vq);
>   vq->private_data = sock;
>   vhost_net_buf_unproduce(nvq);
> - if (index == VHOST_NET_VQ_RX)
> - nvq->rx_ring = get_tap_ptr_ring(fd);
>   r = vhost_vq_init_access(vq);
>   if (r)
>   goto err_used;
>   r = vhost_net_enable_vq(n, vq);
>   if (r)
>   goto err_used;
> + if (index == VHOST_NET_VQ_RX)
> + nvq->rx_ring = get_tap_ptr_ring(fd);
>  
>   oldubufs = nvq->ubufs;
>   nvq->ubufs = ubufs;
> -- 
> 2.7.4

Re: [PATCH net 1/3] vhost_net: initialize rx_ring in vhost_net_open()

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:32PM +0800, Jason Wang wrote:
> From: Alexander Potapenko 
> 
> KMSAN reported a use of uninit memory in vhost_net_buf_unproduce()
> while trying to access n->vqs[VHOST_NET_VQ_TX].rx_ring:
> 
> ==
> BUG: KMSAN: use of uninitialized memory in 
> vhost_net_buf_unproduce+0x7bb/0x9a0 drivers/vho
> et.c:170
> CPU: 0 PID: 3021 Comm: syz-fuzzer Not tainted 4.16.0-rc4+ #3853
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 
> 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>  kmsan_report+0x142/0x1f0 mm/kmsan/kmsan.c:1093
>  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>  vhost_net_buf_unproduce+0x7bb/0x9a0 drivers/vhost/net.c:170
>  vhost_net_stop_vq drivers/vhost/net.c:974 [inline]
>  vhost_net_stop+0x146/0x380 drivers/vhost/net.c:982
>  vhost_net_release+0xb1/0x4f0 drivers/vhost/net.c:1015
>  __fput+0x49f/0xa00 fs/file_table.c:209
>  fput+0x37/0x40 fs/file_table.c:243
>  task_work_run+0x243/0x2c0 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop arch/x86/entry/common.c:166 [inline]
>  prepare_exit_to_usermode+0x349/0x3b0 arch/x86/entry/common.c:196
>  syscall_return_slowpath+0xf3/0x6d0 arch/x86/entry/common.c:265
>  do_syscall_64+0x34d/0x450 arch/x86/entry/common.c:292
> ...
> origin:
>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:303 [inline]
>  kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:213
>  kmsan_kmalloc_large+0x6f/0xd0 mm/kmsan/kmsan.c:392
>  kmalloc_large_node_hook mm/slub.c:1366 [inline]
>  kmalloc_large_node mm/slub.c:3808 [inline]
>  __kmalloc_node+0x100e/0x1290 mm/slub.c:3818
>  kmalloc_node include/linux/slab.h:554 [inline]
>  kvmalloc_node+0x1a5/0x2e0 mm/util.c:419
>  kvmalloc include/linux/mm.h:541 [inline]
>  vhost_net_open+0x64/0x5f0 drivers/vhost/net.c:921
>  misc_open+0x7b5/0x8b0 drivers/char/misc.c:154
>  chrdev_open+0xc28/0xd90 fs/char_dev.c:417
>  do_dentry_open+0xccb/0x1430 fs/open.c:752
>  vfs_open+0x272/0x2e0 fs/open.c:866
>  do_last fs/namei.c:3378 [inline]
>  path_openat+0x49ad/0x6580 fs/namei.c:3519
>  do_filp_open+0x267/0x640 fs/namei.c:3553
>  do_sys_open+0x6ad/0x9c0 fs/open.c:1059
>  SYSC_openat+0xc7/0xe0 fs/open.c:1086
>  SyS_openat+0x63/0x90 fs/open.c:1080
>  do_syscall_64+0x2f1/0x450 arch/x86/entry/common.c:287
> ==
> 
> Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array")
> Signed-off-by: Alexander Potapenko 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/vhost/net.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 610cba2..60f1080 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -948,6 +948,7 @@ static int vhost_net_open(struct inode *inode, struct 
> file *f)
>   n->vqs[i].done_idx = 0;
>   n->vqs[i].vhost_hlen = 0;
>   n->vqs[i].sock_hlen = 0;
> + n->vqs[i].rx_ring = NULL;
>   vhost_net_buf_init(>vqs[i].rxq);
>   }
>   vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
> -- 
> 2.7.4

Re: [PATCH net 1/3] vhost_net: initialize rx_ring in vhost_net_open()

[Michael S. Tsirkin]

On Fri, Mar 09, 2018 at 02:50:32PM +0800, Jason Wang wrote:
> From: Alexander Potapenko 
> 
> KMSAN reported a use of uninit memory in vhost_net_buf_unproduce()
> while trying to access n->vqs[VHOST_NET_VQ_TX].rx_ring:
> 
> ==
> BUG: KMSAN: use of uninitialized memory in 
> vhost_net_buf_unproduce+0x7bb/0x9a0 drivers/vho
> et.c:170
> CPU: 0 PID: 3021 Comm: syz-fuzzer Not tainted 4.16.0-rc4+ #3853
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 
> 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>  kmsan_report+0x142/0x1f0 mm/kmsan/kmsan.c:1093
>  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>  vhost_net_buf_unproduce+0x7bb/0x9a0 drivers/vhost/net.c:170
>  vhost_net_stop_vq drivers/vhost/net.c:974 [inline]
>  vhost_net_stop+0x146/0x380 drivers/vhost/net.c:982
>  vhost_net_release+0xb1/0x4f0 drivers/vhost/net.c:1015
>  __fput+0x49f/0xa00 fs/file_table.c:209
>  fput+0x37/0x40 fs/file_table.c:243
>  task_work_run+0x243/0x2c0 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop arch/x86/entry/common.c:166 [inline]
>  prepare_exit_to_usermode+0x349/0x3b0 arch/x86/entry/common.c:196
>  syscall_return_slowpath+0xf3/0x6d0 arch/x86/entry/common.c:265
>  do_syscall_64+0x34d/0x450 arch/x86/entry/common.c:292
> ...
> origin:
>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:303 [inline]
>  kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:213
>  kmsan_kmalloc_large+0x6f/0xd0 mm/kmsan/kmsan.c:392
>  kmalloc_large_node_hook mm/slub.c:1366 [inline]
>  kmalloc_large_node mm/slub.c:3808 [inline]
>  __kmalloc_node+0x100e/0x1290 mm/slub.c:3818
>  kmalloc_node include/linux/slab.h:554 [inline]
>  kvmalloc_node+0x1a5/0x2e0 mm/util.c:419
>  kvmalloc include/linux/mm.h:541 [inline]
>  vhost_net_open+0x64/0x5f0 drivers/vhost/net.c:921
>  misc_open+0x7b5/0x8b0 drivers/char/misc.c:154
>  chrdev_open+0xc28/0xd90 fs/char_dev.c:417
>  do_dentry_open+0xccb/0x1430 fs/open.c:752
>  vfs_open+0x272/0x2e0 fs/open.c:866
>  do_last fs/namei.c:3378 [inline]
>  path_openat+0x49ad/0x6580 fs/namei.c:3519
>  do_filp_open+0x267/0x640 fs/namei.c:3553
>  do_sys_open+0x6ad/0x9c0 fs/open.c:1059
>  SYSC_openat+0xc7/0xe0 fs/open.c:1086
>  SyS_openat+0x63/0x90 fs/open.c:1080
>  do_syscall_64+0x2f1/0x450 arch/x86/entry/common.c:287
> ==
> 
> Fixes: c67df11f6e480 ("vhost_net: try batch dequing from skb array")
> Signed-off-by: Alexander Potapenko 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/vhost/net.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 610cba2..60f1080 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -948,6 +948,7 @@ static int vhost_net_open(struct inode *inode, struct 
> file *f)
>   n->vqs[i].done_idx = 0;
>   n->vqs[i].vhost_hlen = 0;
>   n->vqs[i].sock_hlen = 0;
> + n->vqs[i].rx_ring = NULL;
>   vhost_net_buf_init(>vqs[i].rxq);
>   }
>   vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
> -- 
> 2.7.4

Re: Regression from efi: call get_event_log before ExitBootServices

[Jeremy Cline]

On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen wrote:
> Thanks a lot for trying out the patch!
> 
> Please don't modify your install at this stage, I think we are hitting a
> firmware bug and that would be awesome if we can fix how we are handling it.
> So, if we reach that stage in the function it could either be that:
> * The allocation did not succeed, somehow, but the firmware still returned
> EFI_SUCCEED.
> * The size requested is incorrect (I'm thinking something like a 1G of
> log). This would be due to either a miscalculation of log_size (possible)
> or; the returned values of GetEventLog are not correct.
> I'm sending a patch to add checks for these. Could you please apply and
> retest?
> Again, thanks for helping debugging this.

No problem, thanks for the help :)

With the new patch:

Locating the TCG2Protocol
Calling GetEventLog on TCG2Protocol
Log returned
log_location is not empty
log_size != 0
log_size < 1M
Allocating memory for storing the logs
Returned from memory allocation
Copying log to new location

And then it hangs. I added a couple more print statements:

diff --git a/drivers/firmware/efi/libstub/tpm.c 
b/drivers/firmware/efi/libstub/tpm.c
index ee3fac109078..1ab5638bc50e 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -148,8 +148,11 @@ void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t 
*sys_table_arg)
efi_printk(sys_table_arg, "Copying log to new location\n");
 
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
+   efi_printk(sys_table_arg, "Successfully memset log_tbl to 0\n");
log_tbl->size = log_size;
+   efi_printk(sys_table_arg, "Set log_tbl->size\n");
log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   efi_printk(sys_table_arg, "Set log_tbl-version\n");
memcpy(log_tbl->log, (void *) first_entry_addr, log_size);
 
efi_printk(sys_table_arg, "Installing the log into the configuration 
table\n");

and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) + log_size);"

Regards,
Jeremy

Re: Regression from efi: call get_event_log before ExitBootServices

[Jeremy Cline]

On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen wrote:
> Thanks a lot for trying out the patch!
> 
> Please don't modify your install at this stage, I think we are hitting a
> firmware bug and that would be awesome if we can fix how we are handling it.
> So, if we reach that stage in the function it could either be that:
> * The allocation did not succeed, somehow, but the firmware still returned
> EFI_SUCCEED.
> * The size requested is incorrect (I'm thinking something like a 1G of
> log). This would be due to either a miscalculation of log_size (possible)
> or; the returned values of GetEventLog are not correct.
> I'm sending a patch to add checks for these. Could you please apply and
> retest?
> Again, thanks for helping debugging this.

No problem, thanks for the help :)

With the new patch:

Locating the TCG2Protocol
Calling GetEventLog on TCG2Protocol
Log returned
log_location is not empty
log_size != 0
log_size < 1M
Allocating memory for storing the logs
Returned from memory allocation
Copying log to new location

And then it hangs. I added a couple more print statements:

diff --git a/drivers/firmware/efi/libstub/tpm.c 
b/drivers/firmware/efi/libstub/tpm.c
index ee3fac109078..1ab5638bc50e 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -148,8 +148,11 @@ void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t 
*sys_table_arg)
efi_printk(sys_table_arg, "Copying log to new location\n");
 
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
+   efi_printk(sys_table_arg, "Successfully memset log_tbl to 0\n");
log_tbl->size = log_size;
+   efi_printk(sys_table_arg, "Set log_tbl->size\n");
log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   efi_printk(sys_table_arg, "Set log_tbl-version\n");
memcpy(log_tbl->log, (void *) first_entry_addr, log_size);
 
efi_printk(sys_table_arg, "Installing the log into the configuration 
table\n");

and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) + log_size);"

Regards,
Jeremy

Linux 4.15.8

[Greg KH]

I'm announcing the release of the 4.15.8 kernel.

All users of the 4.15 kernel series must upgrade.

The updated 4.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.15.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



 Documentation/networking/ip-sysctl.txt   |4 
 Makefile |2 
 arch/arm/boot/dts/logicpd-som-lv.dtsi|9 
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi   |8 
 arch/arm/boot/dts/rk3288-phycore-som.dtsi|   20 -
 arch/arm/kvm/hyp/Makefile|5 
 arch/arm/kvm/hyp/banked-sr.c |4 
 arch/arm/mach-mvebu/Kconfig  |4 
 arch/arm/plat-orion/common.c |   23 -
 arch/parisc/include/asm/cacheflush.h |1 
 arch/parisc/include/asm/processor.h  |2 
 arch/parisc/kernel/cache.c   |   57 ++--
 arch/parisc/kernel/pacache.S |   22 +
 arch/parisc/kernel/time.c|   11 
 arch/parisc/mm/init.c|7 
 arch/powerpc/mm/pgtable-radix.c  |   20 +
 arch/powerpc/platforms/pseries/ras.c |   31 +-
 arch/s390/kvm/interrupt.c|   25 +
 arch/s390/kvm/kvm-s390.c |   79 +++---
 arch/s390/kvm/kvm-s390.h |5 
 arch/s390/kvm/priv.c |9 
 arch/x86/include/asm/pgtable.h   |8 
 arch/x86/include/asm/pgtable_32.h|1 
 arch/x86/include/asm/pgtable_64.h|1 
 arch/x86/include/asm/pgtable_types.h |   10 
 arch/x86/kernel/setup.c  |   17 -
 arch/x86/kernel/setup_percpu.c   |   17 -
 arch/x86/kvm/lapic.c |   11 
 arch/x86/kvm/mmu.c   |2 
 arch/x86/kvm/svm.c   |9 
 arch/x86/kvm/vmx.c   |9 
 arch/x86/kvm/x86.c   |8 
 arch/x86/mm/cpu_entry_area.c |6 
 arch/x86/mm/init_32.c|   15 +
 arch/x86/platform/intel-mid/intel-mid.c  |2 
 arch/x86/xen/suspend.c   |   16 +
 block/blk-core.c |2 
 block/blk-mq.c   |4 
 block/ioctl.c|2 
 block/kyber-iosched.c|1 
 drivers/acpi/bus.c   |   38 ++-
 drivers/bluetooth/btusb.c|   25 +
 drivers/char/ipmi/ipmi_si_intf.c |9 
 drivers/char/tpm/st33zp24/st33zp24.c |4 
 drivers/char/tpm/tpm-interface.c |4 
 drivers/char/tpm/tpm2-cmd.c  |4 
 drivers/char/tpm/tpm_i2c_infineon.c  |5 
 drivers/char/tpm/tpm_i2c_nuvoton.c   |8 
 drivers/char/tpm/tpm_tis_core.c  |5 
 drivers/cpufreq/s3c24xx-cpufreq.c|8 
 drivers/edac/sb_edac.c   |2 
 drivers/md/md.c  |4 
 drivers/media/dvb-frontends/m88ds3103.c  |7 
 drivers/mmc/host/dw_mmc-exynos.c |1 
 drivers/mmc/host/dw_mmc-k3.c |4 
 drivers/mmc/host/dw_mmc-rockchip.c   |1 
 drivers/mmc/host/dw_mmc-zx.c |1 
 drivers/mmc/host/dw_mmc.c|   84 --
 drivers/mmc/host/dw_mmc.h|2 
 drivers/mmc/host/sdhci-pci-core.c|   35 ++
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |2 
 drivers/net/ethernet/amd/xgbe/xgbe-pci.c |2 
 drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c   |2 
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c |2 
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|8 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|   10 
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   49 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c|3 
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c 

Linux 4.15.8

[Greg KH]

I'm announcing the release of the 4.15.8 kernel.

All users of the 4.15 kernel series must upgrade.

The updated 4.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.15.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



 Documentation/networking/ip-sysctl.txt   |4 
 Makefile |2 
 arch/arm/boot/dts/logicpd-som-lv.dtsi|9 
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi   |8 
 arch/arm/boot/dts/rk3288-phycore-som.dtsi|   20 -
 arch/arm/kvm/hyp/Makefile|5 
 arch/arm/kvm/hyp/banked-sr.c |4 
 arch/arm/mach-mvebu/Kconfig  |4 
 arch/arm/plat-orion/common.c |   23 -
 arch/parisc/include/asm/cacheflush.h |1 
 arch/parisc/include/asm/processor.h  |2 
 arch/parisc/kernel/cache.c   |   57 ++--
 arch/parisc/kernel/pacache.S |   22 +
 arch/parisc/kernel/time.c|   11 
 arch/parisc/mm/init.c|7 
 arch/powerpc/mm/pgtable-radix.c  |   20 +
 arch/powerpc/platforms/pseries/ras.c |   31 +-
 arch/s390/kvm/interrupt.c|   25 +
 arch/s390/kvm/kvm-s390.c |   79 +++---
 arch/s390/kvm/kvm-s390.h |5 
 arch/s390/kvm/priv.c |9 
 arch/x86/include/asm/pgtable.h   |8 
 arch/x86/include/asm/pgtable_32.h|1 
 arch/x86/include/asm/pgtable_64.h|1 
 arch/x86/include/asm/pgtable_types.h |   10 
 arch/x86/kernel/setup.c  |   17 -
 arch/x86/kernel/setup_percpu.c   |   17 -
 arch/x86/kvm/lapic.c |   11 
 arch/x86/kvm/mmu.c   |2 
 arch/x86/kvm/svm.c   |9 
 arch/x86/kvm/vmx.c   |9 
 arch/x86/kvm/x86.c   |8 
 arch/x86/mm/cpu_entry_area.c |6 
 arch/x86/mm/init_32.c|   15 +
 arch/x86/platform/intel-mid/intel-mid.c  |2 
 arch/x86/xen/suspend.c   |   16 +
 block/blk-core.c |2 
 block/blk-mq.c   |4 
 block/ioctl.c|2 
 block/kyber-iosched.c|1 
 drivers/acpi/bus.c   |   38 ++-
 drivers/bluetooth/btusb.c|   25 +
 drivers/char/ipmi/ipmi_si_intf.c |9 
 drivers/char/tpm/st33zp24/st33zp24.c |4 
 drivers/char/tpm/tpm-interface.c |4 
 drivers/char/tpm/tpm2-cmd.c  |4 
 drivers/char/tpm/tpm_i2c_infineon.c  |5 
 drivers/char/tpm/tpm_i2c_nuvoton.c   |8 
 drivers/char/tpm/tpm_tis_core.c  |5 
 drivers/cpufreq/s3c24xx-cpufreq.c|8 
 drivers/edac/sb_edac.c   |2 
 drivers/md/md.c  |4 
 drivers/media/dvb-frontends/m88ds3103.c  |7 
 drivers/mmc/host/dw_mmc-exynos.c |1 
 drivers/mmc/host/dw_mmc-k3.c |4 
 drivers/mmc/host/dw_mmc-rockchip.c   |1 
 drivers/mmc/host/dw_mmc-zx.c |1 
 drivers/mmc/host/dw_mmc.c|   84 --
 drivers/mmc/host/dw_mmc.h|2 
 drivers/mmc/host/sdhci-pci-core.c|   35 ++
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |2 
 drivers/net/ethernet/amd/xgbe/xgbe-pci.c |2 
 drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c   |2 
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c |2 
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|8 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|   10 
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   49 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c|3 
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c 

Re: Linux 4.14.25

[Greg KH]

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index 77f4de59dc9c..d499676890d8 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -508,7 +508,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory
pressure.
-   Default: 1 page
+   Default: 4K
 
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
@@ -666,7 +666,7 @@ tcp_window_scaling - BOOLEAN
 tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
-   Default: 1 page
+   Default: 4K
 
default: initial size of send buffer used by TCP sockets.  This
value overrides net.core.wmem_default used by other protocols.
diff --git a/Makefile b/Makefile
index 38acc6047d7d..0fdae0f455ef 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 24
+SUBLEVEL = 25
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm/boot/dts/logicpd-som-lv.dtsi 
b/arch/arm/boot/dts/logicpd-som-lv.dtsi
index 4f2c5ec75714..e262fa9ef334 100644
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -97,6 +97,8 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
clock-frequency = <260>;
 
twl: twl@48 {
@@ -215,7 +217,12 @@
>;
};
 
-
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)
/* i2c1_scl.i2c1_scl */
+   OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)
/* i2c1_sda.i2c1_sda */
+   >;
+   };
 };
 
 _pmx_wkup {
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 6d89736c7b44..cf22b35f0a28 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -104,6 +104,8 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
clock-frequency = <260>;
 
twl: twl@48 {
@@ -211,6 +213,12 @@
OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0)
/* hsusb0_data7.hsusb0_data7 */
>;
};
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)
/* i2c1_scl.i2c1_scl */
+   OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)
/* i2c1_sda.i2c1_sda */
+   >;
+   };
 };
 
  {
diff --git a/arch/arm/boot/dts/rk3288-phycore-som.dtsi 
b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
index 99cfae875e12..5eae4776ffde 100644
--- a/arch/arm/boot/dts/rk3288-phycore-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
@@ -110,26 +110,6 @@
};
 };
 
- {
-   cpu0-supply = <_cpu>;
-   operating-points = <
-   /* KHzuV */
-   180 140
-   1608000 135
-   1512000 130
-   1416000 120
-   120 110
-   1008000 105
-816000 100
-696000  95
-60  90
-408000  90
-312000  90
-216000  90
-126000  90
-   >;
-};
-
  {
status = "okay";
bus-width = <8>;
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 5638ce0c9524..63d6b404d88e 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -7,6 +7,8 @@ ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
 
 KVM=../../../../virt/kvm
 
+CFLAGS_ARMV7VE:=$(call cc-option, -march=armv7ve)
+
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o
@@ -15,7 +17,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
 obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
+CFLAGS_banked-sr.o+= $(CFLAGS_ARMV7VE)
+
 obj-$(CONFIG_KVM_ARM_HOST) += entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += switch.o
+CFLAGS_switch.o   += $(CFLAGS_ARMV7VE)
 obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c
index 111bda8cdebd..be4b8b0a40ad 100644
--- a/arch/arm/kvm/hyp/banked-sr.c
+++ b/arch/arm/kvm/hyp/banked-sr.c
@@ -20,6 

Re: Linux 4.14.25

[Greg KH]

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index 77f4de59dc9c..d499676890d8 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -508,7 +508,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory
pressure.
-   Default: 1 page
+   Default: 4K
 
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
@@ -666,7 +666,7 @@ tcp_window_scaling - BOOLEAN
 tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
-   Default: 1 page
+   Default: 4K
 
default: initial size of send buffer used by TCP sockets.  This
value overrides net.core.wmem_default used by other protocols.
diff --git a/Makefile b/Makefile
index 38acc6047d7d..0fdae0f455ef 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 24
+SUBLEVEL = 25
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm/boot/dts/logicpd-som-lv.dtsi 
b/arch/arm/boot/dts/logicpd-som-lv.dtsi
index 4f2c5ec75714..e262fa9ef334 100644
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -97,6 +97,8 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
clock-frequency = <260>;
 
twl: twl@48 {
@@ -215,7 +217,12 @@
>;
};
 
-
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)
/* i2c1_scl.i2c1_scl */
+   OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)
/* i2c1_sda.i2c1_sda */
+   >;
+   };
 };
 
 _pmx_wkup {
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 6d89736c7b44..cf22b35f0a28 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -104,6 +104,8 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
clock-frequency = <260>;
 
twl: twl@48 {
@@ -211,6 +213,12 @@
OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0)
/* hsusb0_data7.hsusb0_data7 */
>;
};
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)
/* i2c1_scl.i2c1_scl */
+   OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)
/* i2c1_sda.i2c1_sda */
+   >;
+   };
 };
 
  {
diff --git a/arch/arm/boot/dts/rk3288-phycore-som.dtsi 
b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
index 99cfae875e12..5eae4776ffde 100644
--- a/arch/arm/boot/dts/rk3288-phycore-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-phycore-som.dtsi
@@ -110,26 +110,6 @@
};
 };
 
- {
-   cpu0-supply = <_cpu>;
-   operating-points = <
-   /* KHzuV */
-   180 140
-   1608000 135
-   1512000 130
-   1416000 120
-   120 110
-   1008000 105
-816000 100
-696000  95
-60  90
-408000  90
-312000  90
-216000  90
-126000  90
-   >;
-};
-
  {
status = "okay";
bus-width = <8>;
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 5638ce0c9524..63d6b404d88e 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -7,6 +7,8 @@ ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
 
 KVM=../../../../virt/kvm
 
+CFLAGS_ARMV7VE:=$(call cc-option, -march=armv7ve)
+
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o
@@ -15,7 +17,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
 obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
+CFLAGS_banked-sr.o+= $(CFLAGS_ARMV7VE)
+
 obj-$(CONFIG_KVM_ARM_HOST) += entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += switch.o
+CFLAGS_switch.o   += $(CFLAGS_ARMV7VE)
 obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c
index 111bda8cdebd..be4b8b0a40ad 100644
--- a/arch/arm/kvm/hyp/banked-sr.c
+++ b/arch/arm/kvm/hyp/banked-sr.c
@@ -20,6 

Linux 4.14.25

[Greg KH]

I'm announcing the release of the 4.14.25 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



 Documentation/networking/ip-sysctl.txt   |4 
 Makefile |2 
 arch/arm/boot/dts/logicpd-som-lv.dtsi|9 -
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi   |8 
 arch/arm/boot/dts/rk3288-phycore-som.dtsi|   20 --
 arch/arm/kvm/hyp/Makefile|5 
 arch/arm/kvm/hyp/banked-sr.c |4 
 arch/arm/mach-mvebu/Kconfig  |4 
 arch/arm/plat-orion/common.c |   23 +-
 arch/parisc/include/asm/cacheflush.h |1 
 arch/parisc/include/asm/processor.h  |2 
 arch/parisc/kernel/cache.c   |   57 +++---
 arch/parisc/kernel/pacache.S |   22 ++
 arch/parisc/kernel/time.c|   11 -
 arch/s390/kvm/interrupt.c|   25 ++-
 arch/s390/kvm/kvm-s390.c |   79 +
 arch/s390/kvm/kvm-s390.h |5 
 arch/s390/kvm/priv.c |9 -
 arch/x86/include/asm/pgtable.h   |8 
 arch/x86/include/asm/pgtable_32.h|1 
 arch/x86/include/asm/pgtable_64.h|1 
 arch/x86/include/asm/pgtable_types.h |   10 +
 arch/x86/kernel/setup.c  |   17 --
 arch/x86/kernel/setup_percpu.c   |   17 --
 arch/x86/kvm/lapic.c |   11 -
 arch/x86/kvm/mmu.c   |   97 +--
 arch/x86/kvm/paging_tmpl.h   |   18 +-
 arch/x86/kvm/svm.c   |9 -
 arch/x86/kvm/vmx.c   |9 -
 arch/x86/kvm/x86.c   |   12 -
 arch/x86/mm/cpu_entry_area.c |6 
 arch/x86/mm/init_32.c|   15 +
 arch/x86/platform/intel-mid/intel-mid.c  |2 
 arch/x86/xen/suspend.c   |   16 +
 block/blk-core.c |2 
 block/blk-mq.c   |4 
 block/kyber-iosched.c|1 
 drivers/acpi/bus.c   |   38 +++-
 drivers/bluetooth/btusb.c|   25 ++-
 drivers/char/tpm/st33zp24/st33zp24.c |4 
 drivers/char/tpm/tpm-interface.c |4 
 drivers/char/tpm/tpm2-cmd.c  |4 
 drivers/char/tpm/tpm_i2c_infineon.c  |5 
 drivers/char/tpm/tpm_i2c_nuvoton.c   |8 
 drivers/char/tpm/tpm_tis.c   |2 
 drivers/char/tpm/tpm_tis_core.c  |9 -
 drivers/char/tpm/tpm_tis_core.h  |4 
 drivers/char/tpm/tpm_tis_spi.c   |   48 +++--
 drivers/cpufreq/s3c24xx-cpufreq.c|8 
 drivers/edac/sb_edac.c   |2 
 drivers/md/md.c  |4 
 drivers/media/dvb-frontends/m88ds3103.c  |7 
 drivers/mmc/host/dw_mmc-exynos.c |1 
 drivers/mmc/host/dw_mmc-k3.c |4 
 drivers/mmc/host/dw_mmc-rockchip.c   |1 
 drivers/mmc/host/dw_mmc-zx.c |1 
 drivers/mmc/host/dw_mmc.c|   84 ++
 drivers/mmc/host/dw_mmc.h|2 
 drivers/mmc/host/sdhci-pci-core.c|   35 +++-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |2 
 drivers/net/ethernet/amd/xgbe/xgbe-pci.c |2 
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|8 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|   10 -
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   49 -
 drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c|3 
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c  |2 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c|   22 +-
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c |   29 +++
 

Linux 4.14.25

[Greg KH]

I'm announcing the release of the 4.14.25 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



 Documentation/networking/ip-sysctl.txt   |4 
 Makefile |2 
 arch/arm/boot/dts/logicpd-som-lv.dtsi|9 -
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi   |8 
 arch/arm/boot/dts/rk3288-phycore-som.dtsi|   20 --
 arch/arm/kvm/hyp/Makefile|5 
 arch/arm/kvm/hyp/banked-sr.c |4 
 arch/arm/mach-mvebu/Kconfig  |4 
 arch/arm/plat-orion/common.c |   23 +-
 arch/parisc/include/asm/cacheflush.h |1 
 arch/parisc/include/asm/processor.h  |2 
 arch/parisc/kernel/cache.c   |   57 +++---
 arch/parisc/kernel/pacache.S |   22 ++
 arch/parisc/kernel/time.c|   11 -
 arch/s390/kvm/interrupt.c|   25 ++-
 arch/s390/kvm/kvm-s390.c |   79 +
 arch/s390/kvm/kvm-s390.h |5 
 arch/s390/kvm/priv.c |9 -
 arch/x86/include/asm/pgtable.h   |8 
 arch/x86/include/asm/pgtable_32.h|1 
 arch/x86/include/asm/pgtable_64.h|1 
 arch/x86/include/asm/pgtable_types.h |   10 +
 arch/x86/kernel/setup.c  |   17 --
 arch/x86/kernel/setup_percpu.c   |   17 --
 arch/x86/kvm/lapic.c |   11 -
 arch/x86/kvm/mmu.c   |   97 +--
 arch/x86/kvm/paging_tmpl.h   |   18 +-
 arch/x86/kvm/svm.c   |9 -
 arch/x86/kvm/vmx.c   |9 -
 arch/x86/kvm/x86.c   |   12 -
 arch/x86/mm/cpu_entry_area.c |6 
 arch/x86/mm/init_32.c|   15 +
 arch/x86/platform/intel-mid/intel-mid.c  |2 
 arch/x86/xen/suspend.c   |   16 +
 block/blk-core.c |2 
 block/blk-mq.c   |4 
 block/kyber-iosched.c|1 
 drivers/acpi/bus.c   |   38 +++-
 drivers/bluetooth/btusb.c|   25 ++-
 drivers/char/tpm/st33zp24/st33zp24.c |4 
 drivers/char/tpm/tpm-interface.c |4 
 drivers/char/tpm/tpm2-cmd.c  |4 
 drivers/char/tpm/tpm_i2c_infineon.c  |5 
 drivers/char/tpm/tpm_i2c_nuvoton.c   |8 
 drivers/char/tpm/tpm_tis.c   |2 
 drivers/char/tpm/tpm_tis_core.c  |9 -
 drivers/char/tpm/tpm_tis_core.h  |4 
 drivers/char/tpm/tpm_tis_spi.c   |   48 +++--
 drivers/cpufreq/s3c24xx-cpufreq.c|8 
 drivers/edac/sb_edac.c   |2 
 drivers/md/md.c  |4 
 drivers/media/dvb-frontends/m88ds3103.c  |7 
 drivers/mmc/host/dw_mmc-exynos.c |1 
 drivers/mmc/host/dw_mmc-k3.c |4 
 drivers/mmc/host/dw_mmc-rockchip.c   |1 
 drivers/mmc/host/dw_mmc-zx.c |1 
 drivers/mmc/host/dw_mmc.c|   84 ++
 drivers/mmc/host/dw_mmc.h|2 
 drivers/mmc/host/sdhci-pci-core.c|   35 +++-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |2 
 drivers/net/ethernet/amd/xgbe/xgbe-pci.c |2 
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|8 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|   10 -
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   49 -
 drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c|3 
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c  |2 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c|   22 +-
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c |   29 +++
 

Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers]

On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote:

> On 03/09/2018 05:31 PM, Joseph Myers wrote:
> > Note that SH glibc test results need some work - there are a large number 
> > of failures listed at .  
> > Probably most could be addressed with the NaN fixes I outlined at 
> >  - but that 
> > does of course need someone to do the work to implement that in GCC and 
> > glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> > seem very specific on this, but the existing setting was definitely 
> > determined by testing on hardware.  SH experts with access to a range of 
> > different hardware may be needed to advise on what different hardware does 
> > or is supposed to do in this regard.)
> 
> Ok, thanks for the explanation.
> 
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.

"make check", or "make -k check" if you're concerned about some tests 
failing to build (e.g. the compiler running out of memory on a few large 
tests) - the testsuite should continue after execution failures, but not 
after compilation failures.  (Having previously configured with 
--prefix=/usr for the build.  And if the compiler used doesn't have 
libgcc_s and libstdc++ shared libraries in directories ld.so searches by 
default, you should copy those libraries into the glibc build directory 
before running tests.)  On a system that can handle it you'd use an 
appropriate -jN option for parallelism, but probably not on m68k.

For cross testing over SSH (when glibc is running on a system that is very 
slow running the compiler or has too little memory to do so) you need a 
shared filesystem at the same path on both the system where glibc is built 
and the system where tests will execute (probably NFS-exported from the 
build system, and it may be necessary to mount it on the test system with 
acdirmax=0,acdirmin=0 to limit any caching).  Then you can pass 
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh " to make 
check.

In both cases, for very slow test systems you may wish to export 
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers]

On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote:

> On 03/09/2018 05:31 PM, Joseph Myers wrote:
> > Note that SH glibc test results need some work - there are a large number 
> > of failures listed at .  
> > Probably most could be addressed with the NaN fixes I outlined at 
> >  - but that 
> > does of course need someone to do the work to implement that in GCC and 
> > glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> > seem very specific on this, but the existing setting was definitely 
> > determined by testing on hardware.  SH experts with access to a range of 
> > different hardware may be needed to advise on what different hardware does 
> > or is supposed to do in this regard.)
> 
> Ok, thanks for the explanation.
> 
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.

"make check", or "make -k check" if you're concerned about some tests 
failing to build (e.g. the compiler running out of memory on a few large 
tests) - the testsuite should continue after execution failures, but not 
after compilation failures.  (Having previously configured with 
--prefix=/usr for the build.  And if the compiler used doesn't have 
libgcc_s and libstdc++ shared libraries in directories ld.so searches by 
default, you should copy those libraries into the glibc build directory 
before running tests.)  On a system that can handle it you'd use an 
appropriate -jN option for parallelism, but probably not on m68k.

For cross testing over SSH (when glibc is running on a system that is very 
slow running the compiler or has too little memory to do so) you need a 
shared filesystem at the same path on both the system where glibc is built 
and the system where tests will execute (probably NFS-exported from the 
build system, and it may be necessary to mount it on the test system with 
acdirmax=0,acdirmin=0 to limit any caching).  Then you can pass 
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh " to make 
check.

In both cases, for very slow test systems you may wish to export 
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH v2 17/17] mfd: viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:56:31 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/viperboard.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e6b3c70aeb22..e9f61262d583 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -59,10 +59,8 @@ static int vprbrd_probe(struct usb_interface *interface,
 
/* allocate memory for our device state and initialize it */
vb = kzalloc(sizeof(*vb), GFP_KERNEL);
-   if (vb == NULL) {
-   dev_err(>dev, "Out of memory\n");
+   if (!vb)
return -ENOMEM;
-   }
 
mutex_init(>lock);
 
-- 
2.16.2

[PATCH v2 17/17] mfd: viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:56:31 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/viperboard.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e6b3c70aeb22..e9f61262d583 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -59,10 +59,8 @@ static int vprbrd_probe(struct usb_interface *interface,
 
/* allocate memory for our device state and initialize it */
vb = kzalloc(sizeof(*vb), GFP_KERNEL);
-   if (vb == NULL) {
-   dev_err(>dev, "Out of memory\n");
+   if (!vb)
return -ENOMEM;
-   }
 
mutex_init(>lock);
 
-- 
2.16.2

[PATCH v2 16/17] mfd: twl6030-irq: Delete an error message for a failed memory allocation in twl6030_init_irq()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:49:32 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/twl6030-irq.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index e3ec8dfa9f1e..e939431ed10c 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -392,10 +392,8 @@ int twl6030_init_irq(struct device *dev, int irq_num)
nr_irqs = TWL6030_NR_IRQS;
 
twl6030_irq = devm_kzalloc(dev, sizeof(*twl6030_irq), GFP_KERNEL);
-   if (!twl6030_irq) {
-   dev_err(dev, "twl6030_irq: Memory allocation failed\n");
+   if (!twl6030_irq)
return -ENOMEM;
-   }
 
mask[0] = 0xFF;
mask[1] = 0xFF;
-- 
2.16.2

[PATCH v2 16/17] mfd: twl6030-irq: Delete an error message for a failed memory allocation in twl6030_init_irq()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:49:32 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/twl6030-irq.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index e3ec8dfa9f1e..e939431ed10c 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -392,10 +392,8 @@ int twl6030_init_irq(struct device *dev, int irq_num)
nr_irqs = TWL6030_NR_IRQS;
 
twl6030_irq = devm_kzalloc(dev, sizeof(*twl6030_irq), GFP_KERNEL);
-   if (!twl6030_irq) {
-   dev_err(dev, "twl6030_irq: Memory allocation failed\n");
+   if (!twl6030_irq)
return -ENOMEM;
-   }
 
mask[0] = 0xFF;
mask[1] = 0xFF;
-- 
2.16.2

[PATCH] staging:r8188eu: Use lib80211 to support TKIP

[Ivan Safonov]

Custom TKIP decryption replaced with lib80211 implementation.
MIC check use lib80211 too.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/Kconfig |   1 +
 drivers/staging/rtl8188eu/core/rtw_recv.c | 161 --
 drivers/staging/rtl8188eu/core/rtw_security.c |  92 +++
 3 files changed, 94 insertions(+), 160 deletions(-)

diff --git a/drivers/staging/rtl8188eu/Kconfig 
b/drivers/staging/rtl8188eu/Kconfig
index ff7832798a77..673fdce25530 100644
--- a/drivers/staging/rtl8188eu/Kconfig
+++ b/drivers/staging/rtl8188eu/Kconfig
@@ -7,6 +7,7 @@ config R8188EU
select LIB80211
select LIB80211_CRYPT_WEP
select LIB80211_CRYPT_CCMP
+   select LIB80211_CRYPT_TKIP
---help---
This option adds the Realtek RTL8188EU USB device such as TP-Link 
TL-WN725N.
If built as a module, it will be called r8188eu.
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index c6857a5be12a..05936a45eb93 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ETHERNET_HEADER_SIZE   14  /*  Ethernet Header Length */
 #define LLC_HEADER_SIZE6   /*  LLC Header Length */
@@ -220,31 +221,20 @@ u32 rtw_free_uc_swdec_pending_queue(struct adapter 
*adapter)
 static int recvframe_chkmic(struct adapter *adapter,
struct recv_frame *precvframe)
 {
-   int i, res = _SUCCESS;
-   u32 datalen;
-   u8  miccode[8];
-   u8  bmic_err = false, brpt_micerror = true;
-   u8  *pframe, *payload, *pframemic;
-   u8  *mickey;
-   struct  sta_info*stainfo;
-   struct  rx_pkt_attrib   *prxattrib = >attrib;
-   struct  security_priv   *psecuritypriv = >securitypriv;
-
-   struct mlme_ext_priv*pmlmeext = >mlmeextpriv;
-   struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
-
-   stainfo = rtw_get_stainfo(>stapriv, >ta[0]);
+   int res = _SUCCESS;
+   struct rx_pkt_attrib *prxattrib = >attrib;
+   struct sta_info *stainfo = rtw_get_stainfo(>stapriv, 
prxattrib->ta);
 
if (prxattrib->encrypt == _TKIP_) {
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: prxattrib->encrypt==_TKIP_\n", __func__));
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: 
da=0x%02x:0x%02x:0x%02x:0x%02x:0x%02x:0x%02x\n",
- __func__, prxattrib->ra[0], prxattrib->ra[1], 
prxattrib->ra[2],
- prxattrib->ra[3], prxattrib->ra[4], 
prxattrib->ra[5]));
-
-   /* calculate mic code */
if (stainfo) {
+   int key_idx;
+   const int iv_len = 8, icv_len = 4, key_length = 32;
+   struct sk_buff *skb = precvframe->pkt;
+   u8 key[32], iv[8], icv[4], *pframe = skb->data;
+   void *crypto_private = NULL;
+   struct lib80211_crypto_ops *crypto_ops = 
try_then_request_module(lib80211_get_crypto_ops("TKIP"), "lib80211_crypt_tkip");
+   struct security_priv *psecuritypriv = 
>securitypriv;
+
if (IS_MCAST(prxattrib->ra)) {
if (!psecuritypriv) {
res = _FAIL;
@@ -253,115 +243,58 @@ static int recvframe_chkmic(struct adapter *adapter,
DBG_88E("\n %s: didn't install group 
key!!\n", __func__);
goto exit;
}
-   mickey = 
>dot118021XGrprxmickey[prxattrib->key_index].skey[0];
-
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: bcmc key\n", __func__));
+   key_idx = prxattrib->key_index;
+   memcpy(key, 
psecuritypriv->dot118021XGrpKey[key_idx].skey, 16);
+   memcpy(key + 16, 
psecuritypriv->dot118021XGrprxmickey[key_idx].skey, 16);
} else {
-   mickey = >dot11tkiprxmickey.skey[0];
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
-("\n %s: unicast key\n", __func__));
+   key_idx = 0;
+   memcpy(key, stainfo->dot118021x_UncstKey.skey, 
16);
+   memcpy(key + 16, 
stainfo->dot11tkiprxmickey.skey, 16);
}
 
-   /* icv_len included the mic code */
-   datalen = precvframe->pkt->len-prxattrib->hdrlen 

Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support

[Sebastian Reichel]

Hi,

On Fri, Mar 09, 2018 at 07:11:53AM -0800, Tony Lindgren wrote:
> * Mark Brown  [180309 12:41]:
> > On Fri, Mar 09, 2018 at 08:34:14AM +, Lee Jones wrote:
> > > On Thu, 08 Mar 2018, Mark Brown wrote:
> > 
> > > > Linux.  Clocks are a big issue with audio stuff, right now sections of
> > > > the clock tree get handled in the CODEC driver but we're going to want
> > > > to push them out to a clock driver so we're not reimplementing handling
> > > > for clocks.
> > 
> > > How is the CODEC controlled?  Does it have its own registers?  I guess
> > > by "it's not a separate device or IP" you mean that it doesn't.  But
> > > that begs the question, how does this then device differ from all the
> > > other devices (adc, battery, charger, regulator, rtc, pwrbutton,
> > > usb-phy and led)?
> > 
> > I'm not convinced that this is a particularly good idea for the other
> > functions but anyway...  the big thing here is that in these devices the
> > CODEC is generally not the level that the IP is created at, it's a
> > collection of interlinked IPs which usually includes not only audio
> > stuff but also some clocking stuff.  The repeatable blocks that could
> > get reused independently are generally a level down from the CODEC
> > level, for example if you look at something like wm8994 there's a couple
> > of identical FLL IPs which could make sense to enumerate individually in
> > the DT.  The top level generally doesn't get reused and is purely an
> > encoding of what Linux is currently doing.
> 
> It seems that most of the components in the PMICs are just standard
> components packed into the PMIC with a control interface provided
> over I2C or SPI.
> 
> So using compatible for things like ADC, RTC and so on makes sense
> if eventually figure out which ones are shared across various
> drivers.
> 
> Sounds like audio is a bit more fuzzy like Mark describes above.
> And by not using a compatible for audio we can have things working
> while not establishing and ABI for something that might change
> in the future.

I would agree, if there was no ABI now, but we still have the
ABI. Instead of specifying the compatible property, we now need
to specify what the node name should look like (see my binding
update). That's just a different ABI.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support

[Sebastian Reichel]

Hi,

On Fri, Mar 09, 2018 at 07:11:53AM -0800, Tony Lindgren wrote:
> * Mark Brown  [180309 12:41]:
> > On Fri, Mar 09, 2018 at 08:34:14AM +, Lee Jones wrote:
> > > On Thu, 08 Mar 2018, Mark Brown wrote:
> > 
> > > > Linux.  Clocks are a big issue with audio stuff, right now sections of
> > > > the clock tree get handled in the CODEC driver but we're going to want
> > > > to push them out to a clock driver so we're not reimplementing handling
> > > > for clocks.
> > 
> > > How is the CODEC controlled?  Does it have its own registers?  I guess
> > > by "it's not a separate device or IP" you mean that it doesn't.  But
> > > that begs the question, how does this then device differ from all the
> > > other devices (adc, battery, charger, regulator, rtc, pwrbutton,
> > > usb-phy and led)?
> > 
> > I'm not convinced that this is a particularly good idea for the other
> > functions but anyway...  the big thing here is that in these devices the
> > CODEC is generally not the level that the IP is created at, it's a
> > collection of interlinked IPs which usually includes not only audio
> > stuff but also some clocking stuff.  The repeatable blocks that could
> > get reused independently are generally a level down from the CODEC
> > level, for example if you look at something like wm8994 there's a couple
> > of identical FLL IPs which could make sense to enumerate individually in
> > the DT.  The top level generally doesn't get reused and is purely an
> > encoding of what Linux is currently doing.
> 
> It seems that most of the components in the PMICs are just standard
> components packed into the PMIC with a control interface provided
> over I2C or SPI.
> 
> So using compatible for things like ADC, RTC and so on makes sense
> if eventually figure out which ones are shared across various
> drivers.
> 
> Sounds like audio is a bit more fuzzy like Mark describes above.
> And by not using a compatible for audio we can have things working
> while not establishing and ABI for something that might change
> in the future.

I would agree, if there was no ABI now, but we still have the
ABI. Instead of specifying the compatible property, we now need
to specify what the node name should look like (see my binding
update). That's just a different ABI.

-- Sebastian


signature.asc
Description: PGP signature

[PATCH] staging:r8188eu: Use lib80211 to support TKIP

[Ivan Safonov]

Custom TKIP decryption replaced with lib80211 implementation.
MIC check use lib80211 too.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/Kconfig |   1 +
 drivers/staging/rtl8188eu/core/rtw_recv.c | 161 --
 drivers/staging/rtl8188eu/core/rtw_security.c |  92 +++
 3 files changed, 94 insertions(+), 160 deletions(-)

diff --git a/drivers/staging/rtl8188eu/Kconfig 
b/drivers/staging/rtl8188eu/Kconfig
index ff7832798a77..673fdce25530 100644
--- a/drivers/staging/rtl8188eu/Kconfig
+++ b/drivers/staging/rtl8188eu/Kconfig
@@ -7,6 +7,7 @@ config R8188EU
select LIB80211
select LIB80211_CRYPT_WEP
select LIB80211_CRYPT_CCMP
+   select LIB80211_CRYPT_TKIP
---help---
This option adds the Realtek RTL8188EU USB device such as TP-Link 
TL-WN725N.
If built as a module, it will be called r8188eu.
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index c6857a5be12a..05936a45eb93 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ETHERNET_HEADER_SIZE   14  /*  Ethernet Header Length */
 #define LLC_HEADER_SIZE6   /*  LLC Header Length */
@@ -220,31 +221,20 @@ u32 rtw_free_uc_swdec_pending_queue(struct adapter 
*adapter)
 static int recvframe_chkmic(struct adapter *adapter,
struct recv_frame *precvframe)
 {
-   int i, res = _SUCCESS;
-   u32 datalen;
-   u8  miccode[8];
-   u8  bmic_err = false, brpt_micerror = true;
-   u8  *pframe, *payload, *pframemic;
-   u8  *mickey;
-   struct  sta_info*stainfo;
-   struct  rx_pkt_attrib   *prxattrib = >attrib;
-   struct  security_priv   *psecuritypriv = >securitypriv;
-
-   struct mlme_ext_priv*pmlmeext = >mlmeextpriv;
-   struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
-
-   stainfo = rtw_get_stainfo(>stapriv, >ta[0]);
+   int res = _SUCCESS;
+   struct rx_pkt_attrib *prxattrib = >attrib;
+   struct sta_info *stainfo = rtw_get_stainfo(>stapriv, 
prxattrib->ta);
 
if (prxattrib->encrypt == _TKIP_) {
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: prxattrib->encrypt==_TKIP_\n", __func__));
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: 
da=0x%02x:0x%02x:0x%02x:0x%02x:0x%02x:0x%02x\n",
- __func__, prxattrib->ra[0], prxattrib->ra[1], 
prxattrib->ra[2],
- prxattrib->ra[3], prxattrib->ra[4], 
prxattrib->ra[5]));
-
-   /* calculate mic code */
if (stainfo) {
+   int key_idx;
+   const int iv_len = 8, icv_len = 4, key_length = 32;
+   struct sk_buff *skb = precvframe->pkt;
+   u8 key[32], iv[8], icv[4], *pframe = skb->data;
+   void *crypto_private = NULL;
+   struct lib80211_crypto_ops *crypto_ops = 
try_then_request_module(lib80211_get_crypto_ops("TKIP"), "lib80211_crypt_tkip");
+   struct security_priv *psecuritypriv = 
>securitypriv;
+
if (IS_MCAST(prxattrib->ra)) {
if (!psecuritypriv) {
res = _FAIL;
@@ -253,115 +243,58 @@ static int recvframe_chkmic(struct adapter *adapter,
DBG_88E("\n %s: didn't install group 
key!!\n", __func__);
goto exit;
}
-   mickey = 
>dot118021XGrprxmickey[prxattrib->key_index].skey[0];
-
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
-("\n %s: bcmc key\n", __func__));
+   key_idx = prxattrib->key_index;
+   memcpy(key, 
psecuritypriv->dot118021XGrpKey[key_idx].skey, 16);
+   memcpy(key + 16, 
psecuritypriv->dot118021XGrprxmickey[key_idx].skey, 16);
} else {
-   mickey = >dot11tkiprxmickey.skey[0];
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_err_,
-("\n %s: unicast key\n", __func__));
+   key_idx = 0;
+   memcpy(key, stainfo->dot118021x_UncstKey.skey, 
16);
+   memcpy(key + 16, 
stainfo->dot11tkiprxmickey.skey, 16);
}
 
-   /* icv_len included the mic code */
-   datalen = precvframe->pkt->len-prxattrib->hdrlen -
-   

Re: [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE

[Torsten Duwe]

On Thu, 8 Mar 2018 10:26:16 -0600
Josh Poimboeuf  wrote:

> This doesn't seem to address some of my previous concerns:

You're right. That discussion quickly headed towards objtool
and I forgot about this one paragraph with the remarks.

> - Bailing on interrupt/exception frames

That is a good question. My current code keeps unwinding as long
as the trace looks sane. If the exception frame has a valid code
pointer in the LR slot it will continue. Couldn't there be cases
where this is desirable? Should this be configurable? Not that
I have an idea how this situation could occur for a thread
that is current or sleeping...

Michael, Balbir: is that possible? Any Idea how to reliably detect
an exception frame? My approach would be to look at the next return
address and compare it to the usual suspects (i.e. collect all 
"b ret" addresses in the EXCEPTION_COMMON macro, for BookS).

> - Function graph tracing return address conversion
> 
> - kretprobes return address conversion

You mean like in arch/x86/kernel/unwind_frame.c the call to
ftrace_graph_ret_addr ?

Forgive me my directness but I don't see why these should be handled in
arch-dependent code, other than maybe a hook, if inevitable, that calls
back into the graph tracer / kretprobes in order to get the proper
address, or simply call the trace unreliable in case it finds such a
return address.

I understand that x86 has a hard time with its multiple unwinders, but
there should be a simpler, generic solution for all other architectures.

Torsten

Re: [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE

[Torsten Duwe]

On Thu, 8 Mar 2018 10:26:16 -0600
Josh Poimboeuf  wrote:

> This doesn't seem to address some of my previous concerns:

You're right. That discussion quickly headed towards objtool
and I forgot about this one paragraph with the remarks.

> - Bailing on interrupt/exception frames

That is a good question. My current code keeps unwinding as long
as the trace looks sane. If the exception frame has a valid code
pointer in the LR slot it will continue. Couldn't there be cases
where this is desirable? Should this be configurable? Not that
I have an idea how this situation could occur for a thread
that is current or sleeping...

Michael, Balbir: is that possible? Any Idea how to reliably detect
an exception frame? My approach would be to look at the next return
address and compare it to the usual suspects (i.e. collect all 
"b ret" addresses in the EXCEPTION_COMMON macro, for BookS).

> - Function graph tracing return address conversion
> 
> - kretprobes return address conversion

You mean like in arch/x86/kernel/unwind_frame.c the call to
ftrace_graph_ret_addr ?

Forgive me my directness but I don't see why these should be handled in
arch-dependent code, other than maybe a hook, if inevitable, that calls
back into the graph tracer / kretprobes in order to get the proper
address, or simply call the trace unreliable in case it finds such a
return address.

I understand that x86 has a hard time with its multiple unwinders, but
there should be a simpler, generic solution for all other architectures.

Torsten

Re: [PATCH] ntb_transport: use put_device() instead of kfree()

[Logan Gunthorpe]

Looks correct to me. Thanks!

Reviewed-by: Logan Gunthorpe 

On 09/03/18 03:33 AM, Arvind Yadav wrote:

Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
---
  drivers/ntb/ntb_transport.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 9878c48..8182a3a 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -393,7 +393,7 @@ int ntb_transport_register_client_dev(char *device_name)
  
  		rc = device_register(dev);

if (rc) {
-   kfree(client_dev);
+   put_device(dev);
goto err;
}
  

Re: [PATCH] ntb_transport: use put_device() instead of kfree()

[Logan Gunthorpe]

Looks correct to me. Thanks!

Reviewed-by: Logan Gunthorpe 

On 09/03/18 03:33 AM, Arvind Yadav wrote:

Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
---
  drivers/ntb/ntb_transport.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 9878c48..8182a3a 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -393,7 +393,7 @@ int ntb_transport_register_client_dev(char *device_name)
  
  		rc = device_register(dev);

if (rc) {
-   kfree(client_dev);
+   put_device(dev);
goto err;
}
  

[PATCH v2 15/17] mfd: tps80031: Delete an error message for a failed memory allocation in tps80031_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:45:13 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps80031.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index 0812df3b0d47..608c7f77830e 100644
--- a/drivers/mfd/tps80031.c
+++ b/drivers/mfd/tps80031.c
@@ -431,10 +431,8 @@ static int tps80031_probe(struct i2c_client *client,
}
 
tps80031 = devm_kzalloc(>dev, sizeof(*tps80031), GFP_KERNEL);
-   if (!tps80031) {
-   dev_err(>dev, "Malloc failed for tps80031\n");
+   if (!tps80031)
return -ENOMEM;
-   }
 
for (i = 0; i < TPS80031_NUM_SLAVES; i++) {
if (tps80031_slave_address[i] == client->addr)
-- 
2.16.2

[PATCH v2 15/17] mfd: tps80031: Delete an error message for a failed memory allocation in tps80031_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:45:13 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps80031.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index 0812df3b0d47..608c7f77830e 100644
--- a/drivers/mfd/tps80031.c
+++ b/drivers/mfd/tps80031.c
@@ -431,10 +431,8 @@ static int tps80031_probe(struct i2c_client *client,
}
 
tps80031 = devm_kzalloc(>dev, sizeof(*tps80031), GFP_KERNEL);
-   if (!tps80031) {
-   dev_err(>dev, "Malloc failed for tps80031\n");
+   if (!tps80031)
return -ENOMEM;
-   }
 
for (i = 0; i < TPS80031_NUM_SLAVES; i++) {
if (tps80031_slave_address[i] == client->addr)
-- 
2.16.2

Re: [PATCH AUTOSEL for 4.14 04/67] dt-bindings: net: add TI CC2560 Bluetooth chip

[Sasha Levin]

On Thu, Mar 08, 2018 at 10:09:44AM -0600, David Lechner wrote:
>On 03/07/2018 10:57 PM, Sasha Levin wrote:
>>From: David Lechner 
>>
>>[ Upstream commit 07c7edd0db441f83087470add5be280cc018 ]
>>
>>This adds a compatible string for the Texas Instruments CC2560 Bluetooth
>>chip to the existing TI WiLink shared transport bindings. These chips are
>>similar enough that the same bindings work for both. The file is renamed
>>to ti-bluetooth.txt to make it more generic.
>>
>>Signed-off-by: David Lechner 
>>Signed-off-by: Marcel Holtmann 
>>Signed-off-by: Sasha Levin 
>>---
>
>I don't see how this patch would be useful in older kernels since the
>driver support for this compatible string was not added until v4.16.

I'll drop it, thank you!

-- 

Thanks,
Sasha

Re: [PATCH AUTOSEL for 4.14 04/67] dt-bindings: net: add TI CC2560 Bluetooth chip

[Sasha Levin]

On Thu, Mar 08, 2018 at 10:09:44AM -0600, David Lechner wrote:
>On 03/07/2018 10:57 PM, Sasha Levin wrote:
>>From: David Lechner 
>>
>>[ Upstream commit 07c7edd0db441f83087470add5be280cc018 ]
>>
>>This adds a compatible string for the Texas Instruments CC2560 Bluetooth
>>chip to the existing TI WiLink shared transport bindings. These chips are
>>similar enough that the same bindings work for both. The file is renamed
>>to ti-bluetooth.txt to make it more generic.
>>
>>Signed-off-by: David Lechner 
>>Signed-off-by: Marcel Holtmann 
>>Signed-off-by: Sasha Levin 
>>---
>
>I don't see how this patch would be useful in older kernels since the
>driver support for this compatible string was not added until v4.16.

I'll drop it, thank you!

-- 

Thanks,
Sasha

[PATCH v2 14/17 4/4] mfd: tps65910: Move an assignment in tps65910_sleepinit()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:19:42 +0100

Move the assignment for the local variable "dev" so that its setting
will be performed after a configuration check by this function.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 7e7d3d1642c6..bf16cbe6fd88 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -315,11 +315,11 @@ static int tps65910_sleepinit(struct tps65910 *tps65910,
struct device *dev;
int ret;
 
-   dev = tps65910->dev;
-
if (!pmic_pdata->en_dev_slp)
return 0;
 
+   dev = tps65910->dev;
+
/* enabling SLEEP device state */
ret = tps65910_reg_set_bits(tps65910, TPS65910_DEVCTRL,
DEVCTRL_DEV_SLP_MASK);
-- 
2.16.2

[PATCH v2 14/17 4/4] mfd: tps65910: Move an assignment in tps65910_sleepinit()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:19:42 +0100

Move the assignment for the local variable "dev" so that its setting
will be performed after a configuration check by this function.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 7e7d3d1642c6..bf16cbe6fd88 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -315,11 +315,11 @@ static int tps65910_sleepinit(struct tps65910 *tps65910,
struct device *dev;
int ret;
 
-   dev = tps65910->dev;
-
if (!pmic_pdata->en_dev_slp)
return 0;
 
+   dev = tps65910->dev;
+
/* enabling SLEEP device state */
ret = tps65910_reg_set_bits(tps65910, TPS65910_DEVCTRL,
DEVCTRL_DEV_SLP_MASK);
-- 
2.16.2

Re: [PATCH v3 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

[Lina Iyer]

On Thu, Mar 08 2018 at 13:40 -0700, Stephen Boyd wrote:

Quoting Lina Iyer (2018-03-02 08:43:13)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 34e780d9670f..e9f5a1f387fd 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -170,6 +170,52 @@ static struct tcs_group *get_tcs_of_type(struct rsc_drv 
*drv, int type)
return tcs;
 }

+/**
+ * rpmh_rsc_invalidate - Invalidate sleep and wake TCSes
+ *
+ * @drv: the mailbox controller
+ */
+int rpmh_rsc_invalidate(struct rsc_drv *drv)
+{
+   struct tcs_group *tcs;
+   int m, type, ret = 0;
+   int inv_types[] = { WAKE_TCS, SLEEP_TCS };
+   unsigned long drv_flags, flags;
+
+   /* Lock the DRV and clear sleep and wake TCSes */
+   spin_lock_irqsave(>drv_lock, drv_flags);
+   for (type = 0; type < ARRAY_SIZE(inv_types); type++) {
+   tcs = get_tcs_of_type(drv, inv_types[type]);
+   if (IS_ERR(tcs))
+   continue;
+
+   spin_lock_irqsave(>tcs_lock, flags);


Should just be a spin_lock() because we already irq saved a few lines above.


Agreed.

+   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) {
+   spin_unlock_irqrestore(>tcs_lock, flags);
+   continue;
+   }
+
+   /* Clear the enable register for each TCS of the type */
+   for (m = tcs->tcs_offset;
+   m < tcs->tcs_offset + tcs->num_tcs; m++) {
+   if (!tcs_is_free(drv, m)) {
+   spin_unlock_irqrestore(>tcs_lock, flags);
+   ret = -EAGAIN;
+   goto drv_unlock;
+   }
+   write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0, 0);
+   /* Mark the TCS slots as free */
+   bitmap_zero(tcs->slots, MAX_TCS_SLOTS);
+   }
+   spin_unlock_irqrestore(>tcs_lock, flags);


Maybe make another function called rpmh_tcs_invalidate(drv, enum TCS_FOO)
and put this logic inside it? And then change from a for loop to two
direct calls:

lock()
ret = rpmh_tcs_invalidate(drv, WAKE_TCS);
if (!ret)
ret = rpmh_tcs_invalidate(drv, SLEEP_TCS);
unlock()


Agreed. That will be better. Will fix.

-- Lina

Re: [PATCH v3 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

[Lina Iyer]

On Thu, Mar 08 2018 at 13:40 -0700, Stephen Boyd wrote:

Quoting Lina Iyer (2018-03-02 08:43:13)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 34e780d9670f..e9f5a1f387fd 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -170,6 +170,52 @@ static struct tcs_group *get_tcs_of_type(struct rsc_drv 
*drv, int type)
return tcs;
 }

+/**
+ * rpmh_rsc_invalidate - Invalidate sleep and wake TCSes
+ *
+ * @drv: the mailbox controller
+ */
+int rpmh_rsc_invalidate(struct rsc_drv *drv)
+{
+   struct tcs_group *tcs;
+   int m, type, ret = 0;
+   int inv_types[] = { WAKE_TCS, SLEEP_TCS };
+   unsigned long drv_flags, flags;
+
+   /* Lock the DRV and clear sleep and wake TCSes */
+   spin_lock_irqsave(>drv_lock, drv_flags);
+   for (type = 0; type < ARRAY_SIZE(inv_types); type++) {
+   tcs = get_tcs_of_type(drv, inv_types[type]);
+   if (IS_ERR(tcs))
+   continue;
+
+   spin_lock_irqsave(>tcs_lock, flags);


Should just be a spin_lock() because we already irq saved a few lines above.


Agreed.

+   if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) {
+   spin_unlock_irqrestore(>tcs_lock, flags);
+   continue;
+   }
+
+   /* Clear the enable register for each TCS of the type */
+   for (m = tcs->tcs_offset;
+   m < tcs->tcs_offset + tcs->num_tcs; m++) {
+   if (!tcs_is_free(drv, m)) {
+   spin_unlock_irqrestore(>tcs_lock, flags);
+   ret = -EAGAIN;
+   goto drv_unlock;
+   }
+   write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0, 0);
+   /* Mark the TCS slots as free */
+   bitmap_zero(tcs->slots, MAX_TCS_SLOTS);
+   }
+   spin_unlock_irqrestore(>tcs_lock, flags);


Maybe make another function called rpmh_tcs_invalidate(drv, enum TCS_FOO)
and put this logic inside it? And then change from a for loop to two
direct calls:

lock()
ret = rpmh_tcs_invalidate(drv, WAKE_TCS);
if (!ret)
ret = rpmh_tcs_invalidate(drv, SLEEP_TCS);
unlock()


Agreed. That will be better. Will fix.

-- Lina

Re: [PATCH] drivers: vhost: vsock: fixed a brace coding style issue

[David Miller]

From: Vaibhav Murkute 
Date: Fri,  9 Mar 2018 08:26:03 +0530

> Fixed a coding style issue.
> 
> Signed-off-by: Vaibhav Murkute 

Applied to net-next, thanks.

Re: RFC: remove the "tile" architecture from glibc

[John Paul Adrian Glaubitz]

On 03/09/2018 05:31 PM, Joseph Myers wrote:
> Note that SH glibc test results need some work - there are a large number 
> of failures listed at .  
> Probably most could be addressed with the NaN fixes I outlined at 
>  - but that 
> does of course need someone to do the work to implement that in GCC and 
> glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> seem very specific on this, but the existing setting was definitely 
> determined by testing on hardware.  SH experts with access to a range of 
> different hardware may be needed to advise on what different hardware does 
> or is supposed to do in this regard.)

Ok, thanks for the explanation.

On a sidenote: Is there documentation somewhere which explains how to properly
run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
for m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] drivers: vhost: vsock: fixed a brace coding style issue

[David Miller]

From: Vaibhav Murkute 
Date: Fri,  9 Mar 2018 08:26:03 +0530

> Fixed a coding style issue.
> 
> Signed-off-by: Vaibhav Murkute 

Applied to net-next, thanks.

Re: RFC: remove the "tile" architecture from glibc

[John Paul Adrian Glaubitz]

On 03/09/2018 05:31 PM, Joseph Myers wrote:
> Note that SH glibc test results need some work - there are a large number 
> of failures listed at .  
> Probably most could be addressed with the NaN fixes I outlined at 
>  - but that 
> does of course need someone to do the work to implement that in GCC and 
> glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> seem very specific on this, but the existing setting was definitely 
> determined by testing on hardware.  SH experts with access to a range of 
> different hardware may be needed to advise on what different hardware does 
> or is supposed to do in this regard.)

Ok, thanks for the explanation.

On a sidenote: Is there documentation somewhere which explains how to properly
run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
for m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[PATCH v2 13/17 3/4] mfd: tps65910: Delete an unnecessary variable initialisation in tps65910_sleepinit()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:10:09 +0100

The local variable "dev" will be reassigned by a following statement.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 80ea1474c654..7e7d3d1642c6 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -312,7 +312,7 @@ static int tps65910_ck32k_init(struct tps65910 *tps65910,
 static int tps65910_sleepinit(struct tps65910 *tps65910,
struct tps65910_board *pmic_pdata)
 {
-   struct device *dev = NULL;
+   struct device *dev;
int ret;
 
dev = tps65910->dev;
-- 
2.16.2

[PATCH v2 13/17 3/4] mfd: tps65910: Delete an unnecessary variable initialisation in tps65910_sleepinit()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:10:09 +0100

The local variable "dev" will be reassigned by a following statement.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 80ea1474c654..7e7d3d1642c6 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -312,7 +312,7 @@ static int tps65910_ck32k_init(struct tps65910 *tps65910,
 static int tps65910_sleepinit(struct tps65910 *tps65910,
struct tps65910_board *pmic_pdata)
 {
-   struct device *dev = NULL;
+   struct device *dev;
int ret;
 
dev = tps65910->dev;
-- 
2.16.2

[PATCH] MAINTAINERS: add coverage for drivers/block

[Ross Zwisler]

To help folks like me that use scripts/get_maintainer.pl.

Signed-off-by: Ross Zwisler 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..7ff83f4c9aeb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2685,6 +2685,7 @@ L:linux-bl...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
 S: Maintained
 F: block/
+F: drivers/block/
 F: kernel/trace/blktrace.c
 F: lib/sbitmap.c
 
-- 
2.14.3

[PATCH] MAINTAINERS: add coverage for drivers/block

[Ross Zwisler]

To help folks like me that use scripts/get_maintainer.pl.

Signed-off-by: Ross Zwisler 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..7ff83f4c9aeb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2685,6 +2685,7 @@ L:linux-bl...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
 S: Maintained
 F: block/
+F: drivers/block/
 F: kernel/trace/blktrace.c
 F: lib/sbitmap.c
 
-- 
2.14.3

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

[Alan Stern]

On Fri, 9 Mar 2018, Andrea Parri wrote:

> Atomics present the same issue with locking: release and acquire
> variants need to be strengthened to meet the constraints defined
> by the Linux-kernel memory consistency model [1].
> 
> Atomics present a further issue: implementations of atomics such
> as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs,
> which do not give full-ordering with .aqrl; for example, current
> implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
> below to end up with the state indicated in the "exists" clause.
> 
> In order to "synchronize" LKMM and RISC-V's implementation, this
> commit strengthens the implementations of the atomics operations
> by replacing .rl and .aq with the use of ("lightweigth") fences,
> and by replacing .aqrl LR/SC pairs in sequences such as:
> 
>   0:  lr.w.aqrl  %0, %addr
>   bne%0, %old, 1f
>   ...
>   sc.w.aqrl  %1, %new, %addr
>   bnez   %1, 0b
>   1:
> 
> with sequences of the form:
> 
>   0:  lr.w   %0, %addr
>   bne%0, %old, 1f
>   ...
>   sc.w.rl%1, %new, %addr   /* SC-release   */
>   bnez   %1, 0b
>   fence  rw, rw/* "full" fence */
>   1:
> 
> following Daniel's suggestion.
> 
> These modifications were validated with simulation of the RISC-V
> memory consistency model.
> 
> C lr-sc-aqrl-pair-vs-full-barrier
> 
> {}
> 
> P0(int *x, int *y, atomic_t *u)
> {
>   int r0;
>   int r1;
> 
>   WRITE_ONCE(*x, 1);
>   r0 = atomic_cmpxchg(u, 0, 1);
>   r1 = READ_ONCE(*y);
> }
> 
> P1(int *x, int *y, atomic_t *v)
> {
>   int r0;
>   int r1;
> 
>   WRITE_ONCE(*y, 1);
>   r0 = atomic_cmpxchg(v, 0, 1);
>   r1 = READ_ONCE(*x);
> }
> 
> exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0)

There's another aspect to this imposed by the LKMM, and I'm not sure
whether your patch addresses it.  You add a fence after the cmpxchg
operation but nothing before it.  So what would happen with the 
following litmus test (which the LKMM forbids)?

C SB-atomic_cmpxchg-mb

{}

P0(int *x, int *y)
{
int r0;

WRITE_ONCE(*x, 1);
r0 = atomic_cmpxchg(y, 0, 0);
}

P1(int *x, int *y)
{
int r1;

WRITE_ONCE(*y, 1);
smp_mb();
r1 = READ_ONCE(*x);
}

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

This is yet another illustration showing that full fences are stronger 
than cominations of release + acquire.

Alan Stern

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

[Alan Stern]

On Fri, 9 Mar 2018, Andrea Parri wrote:

> Atomics present the same issue with locking: release and acquire
> variants need to be strengthened to meet the constraints defined
> by the Linux-kernel memory consistency model [1].
> 
> Atomics present a further issue: implementations of atomics such
> as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs,
> which do not give full-ordering with .aqrl; for example, current
> implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
> below to end up with the state indicated in the "exists" clause.
> 
> In order to "synchronize" LKMM and RISC-V's implementation, this
> commit strengthens the implementations of the atomics operations
> by replacing .rl and .aq with the use of ("lightweigth") fences,
> and by replacing .aqrl LR/SC pairs in sequences such as:
> 
>   0:  lr.w.aqrl  %0, %addr
>   bne%0, %old, 1f
>   ...
>   sc.w.aqrl  %1, %new, %addr
>   bnez   %1, 0b
>   1:
> 
> with sequences of the form:
> 
>   0:  lr.w   %0, %addr
>   bne%0, %old, 1f
>   ...
>   sc.w.rl%1, %new, %addr   /* SC-release   */
>   bnez   %1, 0b
>   fence  rw, rw/* "full" fence */
>   1:
> 
> following Daniel's suggestion.
> 
> These modifications were validated with simulation of the RISC-V
> memory consistency model.
> 
> C lr-sc-aqrl-pair-vs-full-barrier
> 
> {}
> 
> P0(int *x, int *y, atomic_t *u)
> {
>   int r0;
>   int r1;
> 
>   WRITE_ONCE(*x, 1);
>   r0 = atomic_cmpxchg(u, 0, 1);
>   r1 = READ_ONCE(*y);
> }
> 
> P1(int *x, int *y, atomic_t *v)
> {
>   int r0;
>   int r1;
> 
>   WRITE_ONCE(*y, 1);
>   r0 = atomic_cmpxchg(v, 0, 1);
>   r1 = READ_ONCE(*x);
> }
> 
> exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0)

There's another aspect to this imposed by the LKMM, and I'm not sure
whether your patch addresses it.  You add a fence after the cmpxchg
operation but nothing before it.  So what would happen with the 
following litmus test (which the LKMM forbids)?

C SB-atomic_cmpxchg-mb

{}

P0(int *x, int *y)
{
int r0;

WRITE_ONCE(*x, 1);
r0 = atomic_cmpxchg(y, 0, 0);
}

P1(int *x, int *y)
{
int r1;

WRITE_ONCE(*y, 1);
smp_mb();
r1 = READ_ONCE(*x);
}

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

This is yet another illustration showing that full fences are stronger 
than cominations of release + acquire.

Alan Stern

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

[Mike Galbraith]

On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote:
> Given the fact that thread mode had been merged into 4.14, it is now
> time to enable cpuset to be used in the default hierarchy (cgroup v2)
> as it is clearly threaded.
> 
> The cpuset controller had experienced feature creep since its
> introduction more than a decade ago. Besides the core cpus and mems
> control files to limit cpus and memory nodes, there are a bunch of
> additional features that can be controlled from the userspace. Some of
> the features are of doubtful usefulness and may not be actively used.

One rather important features is the ability to dynamically partition a
box and isolate critical loads.  How does one do that with v2?

In v1, you create two or more exclusive sets, one for generic
housekeeping, and one or more for critical load(s), RT in my case,
turning off load balancing in the critical set(s) for obvious reasons.

> This patch enables cpuset controller in the default hierarchy with
> a minimal set of features, namely just the cpus and mems and their
> effective_* counterparts.  We can certainly add more features to the
> default hierarchy in the future if there is a real user need for them
> later on.
> 
> Alternatively, with the unified hiearachy, it may make more sense
> to move some of those additional cpuset features, if desired, to
> memory controller or may be to the cpu controller instead of staying
> with cpuset.
> 
> v4:
>  - Further minimize the feature set by removing the flags control knob.
> 
> v3:
>  - Further trim the additional features down to just memory_migrate.
>  - Update Documentation/cgroup-v2.txt.
> 
> Signed-off-by: Waiman Long 
> ---
>  Documentation/cgroup-v2.txt | 96 
> -
>  kernel/cgroup/cpuset.c  | 44 +++--
>  2 files changed, 127 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index 74cdeae..8d7300f 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -48,16 +48,18 @@ v1 is available under Documentation/cgroup-v1/.
> 5-2-1. Memory Interface Files
> 5-2-2. Usage Guidelines
> 5-2-3. Memory Ownership
> - 5-3. IO
> -   5-3-1. IO Interface Files
> -   5-3-2. Writeback
> - 5-4. PID
> -   5-4-1. PID Interface Files
> - 5-5. Device
> - 5-6. RDMA
> -   5-6-1. RDMA Interface Files
> - 5-7. Misc
> -   5-7-1. perf_event
> + 5-3. Cpuset
> +   5.3-1. Cpuset Interface Files
> + 5-4. IO
> +   5-4-1. IO Interface Files
> +   5-4-2. Writeback
> + 5-5. PID
> +   5-5-1. PID Interface Files
> + 5-6. Device
> + 5-7. RDMA
> +   5-7-1. RDMA Interface Files
> + 5-8. Misc
> +   5-8-1. perf_event
>   5-N. Non-normative information
> 5-N-1. CPU controller root cgroup process behaviour
> 5-N-2. IO controller root cgroup process behaviour
> @@ -1243,6 +1245,80 @@ POSIX_FADV_DONTNEED to relinquish the ownership of 
> memory areas
>  belonging to the affected files to ensure correct memory ownership.
>  
>  
> +Cpuset
> +--
> +
> +The "cpuset" controller provides a mechanism for constraining
> +the CPU and memory node placement of tasks to only the resources
> +specified in the cpuset interface files in a task's current cgroup.
> +This is especially valuable on large NUMA systems where placing jobs
> +on properly sized subsets of the systems with careful processor and
> +memory placement to reduce cross-node memory access and contention
> +can improve overall system performance.
> +
> +The "cpuset" controller is hierarchical.  That means the controller
> +cannot use CPUs or memory nodes not allowed in its parent.
> +
> +
> +Cpuset Interface Files
> +~~
> +
> +  cpuset.cpus
> + A read-write multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the CPUs allowed to be used by tasks within this
> + cgroup.  The CPU numbers are comma-separated numbers or
> + ranges.  For example:
> +
> +   # cat cpuset.cpus
> +   0-4,6,8-10
> +
> + An empty value indicates that the cgroup is using the same
> + setting as the nearest cgroup ancestor with a non-empty
> + "cpuset.cpus" or all the available CPUs if none is found.
> +
> + The value of "cpuset.cpus" stays constant until the next update
> + and won't be affected by any CPU hotplug events.
> +
> +  cpuset.effective_cpus
> + A read-only multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the onlined CPUs that are actually allowed to be
> + used by tasks within the current cgroup. It is a subset of
> + "cpuset.cpus". Its value will be affected by CPU hotplug
> + events.
> +
> +  cpuset.mems
> + A read-write multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the memory nodes allowed to be used by tasks 

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

[Mike Galbraith]

On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote:
> Given the fact that thread mode had been merged into 4.14, it is now
> time to enable cpuset to be used in the default hierarchy (cgroup v2)
> as it is clearly threaded.
> 
> The cpuset controller had experienced feature creep since its
> introduction more than a decade ago. Besides the core cpus and mems
> control files to limit cpus and memory nodes, there are a bunch of
> additional features that can be controlled from the userspace. Some of
> the features are of doubtful usefulness and may not be actively used.

One rather important features is the ability to dynamically partition a
box and isolate critical loads.  How does one do that with v2?

In v1, you create two or more exclusive sets, one for generic
housekeeping, and one or more for critical load(s), RT in my case,
turning off load balancing in the critical set(s) for obvious reasons.

> This patch enables cpuset controller in the default hierarchy with
> a minimal set of features, namely just the cpus and mems and their
> effective_* counterparts.  We can certainly add more features to the
> default hierarchy in the future if there is a real user need for them
> later on.
> 
> Alternatively, with the unified hiearachy, it may make more sense
> to move some of those additional cpuset features, if desired, to
> memory controller or may be to the cpu controller instead of staying
> with cpuset.
> 
> v4:
>  - Further minimize the feature set by removing the flags control knob.
> 
> v3:
>  - Further trim the additional features down to just memory_migrate.
>  - Update Documentation/cgroup-v2.txt.
> 
> Signed-off-by: Waiman Long 
> ---
>  Documentation/cgroup-v2.txt | 96 
> -
>  kernel/cgroup/cpuset.c  | 44 +++--
>  2 files changed, 127 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index 74cdeae..8d7300f 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -48,16 +48,18 @@ v1 is available under Documentation/cgroup-v1/.
> 5-2-1. Memory Interface Files
> 5-2-2. Usage Guidelines
> 5-2-3. Memory Ownership
> - 5-3. IO
> -   5-3-1. IO Interface Files
> -   5-3-2. Writeback
> - 5-4. PID
> -   5-4-1. PID Interface Files
> - 5-5. Device
> - 5-6. RDMA
> -   5-6-1. RDMA Interface Files
> - 5-7. Misc
> -   5-7-1. perf_event
> + 5-3. Cpuset
> +   5.3-1. Cpuset Interface Files
> + 5-4. IO
> +   5-4-1. IO Interface Files
> +   5-4-2. Writeback
> + 5-5. PID
> +   5-5-1. PID Interface Files
> + 5-6. Device
> + 5-7. RDMA
> +   5-7-1. RDMA Interface Files
> + 5-8. Misc
> +   5-8-1. perf_event
>   5-N. Non-normative information
> 5-N-1. CPU controller root cgroup process behaviour
> 5-N-2. IO controller root cgroup process behaviour
> @@ -1243,6 +1245,80 @@ POSIX_FADV_DONTNEED to relinquish the ownership of 
> memory areas
>  belonging to the affected files to ensure correct memory ownership.
>  
>  
> +Cpuset
> +--
> +
> +The "cpuset" controller provides a mechanism for constraining
> +the CPU and memory node placement of tasks to only the resources
> +specified in the cpuset interface files in a task's current cgroup.
> +This is especially valuable on large NUMA systems where placing jobs
> +on properly sized subsets of the systems with careful processor and
> +memory placement to reduce cross-node memory access and contention
> +can improve overall system performance.
> +
> +The "cpuset" controller is hierarchical.  That means the controller
> +cannot use CPUs or memory nodes not allowed in its parent.
> +
> +
> +Cpuset Interface Files
> +~~
> +
> +  cpuset.cpus
> + A read-write multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the CPUs allowed to be used by tasks within this
> + cgroup.  The CPU numbers are comma-separated numbers or
> + ranges.  For example:
> +
> +   # cat cpuset.cpus
> +   0-4,6,8-10
> +
> + An empty value indicates that the cgroup is using the same
> + setting as the nearest cgroup ancestor with a non-empty
> + "cpuset.cpus" or all the available CPUs if none is found.
> +
> + The value of "cpuset.cpus" stays constant until the next update
> + and won't be affected by any CPU hotplug events.
> +
> +  cpuset.effective_cpus
> + A read-only multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the onlined CPUs that are actually allowed to be
> + used by tasks within the current cgroup. It is a subset of
> + "cpuset.cpus". Its value will be affected by CPU hotplug
> + events.
> +
> +  cpuset.mems
> + A read-write multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the memory nodes allowed to be used by tasks within
> + this 

Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA

[Sasha Levin]

On Thu, Mar 08, 2018 at 10:37:21AM -0800, Darren Hart wrote:
>On Thu, Mar 08, 2018 at 06:15:27PM +, Sasha Levin wrote:
>> On Thu, Mar 08, 2018 at 09:47:54AM -0800, Greg KH wrote:
>> >On Thu, Mar 08, 2018 at 09:39:14AM -0800, Darren Hart wrote:
>> >> On Thu, Mar 08, 2018 at 04:59:01AM +, Sasha Levin wrote:
>> >> > From: Santeri Toivonen 
>> >> >
>> >> > [ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
>> >> >
>> >> > Asus laptop X302UA starts up with Wi-Fi disabled,
>> >> > without a way to enable it. Set wapf=4 to fix the problem.
>> >> >
>> >> > Signed-off-by: Santeri Toivonen 
>> >> > Signed-off-by: Darren Hart (VMware) 
>> >> > Signed-off-by: Sasha Levin 
>> >>
>> >> Hi Sasha,
>> >>
>> >> I'm curious about this AUTOSEL tag, and what about this patch triggered
>> >> its selection?
>> >
>> >It's "magic"!  :)
>> >
>> >Seriously, it's close to magic, there's a tool that Sasha is using that
>> >takes "machine learning" to match patches that we have not applied in
>> >stable kernels to ones that we have, and try to catch those that we
>> >forgot to tag for the stable tree.  Not all subsystems mark stable
>> >patches, so this is an attempt to catch those fixes that should be
>> >getting backported but are not either because the developer/maintainer
>> >forgot to mark it as such, or because they just never mark those types
>> >of patches.
>> >
>> >Sasha has a better write up about how this all works somewhere, and
>> >given that this type of question keeps coming up every other week or so,
>> >I think I need to add it to a FAQ somewhere to point people at to make
>> >it more obvious what is happening.
>>
>> It's pretty much a neural network that knows how to classify a "bug
>> fixing patch" based on things such as:
>>
>>  - Code metrics
>>  - Words in the commit message (the NN knows about the 10,000 most used
>>words, and their likehood to appear in a bug fixing patch).
>>  - Which files were modified.
>>  - Authors of the commit, and persons who got Cc'ed/Signed-off/etc.
>>
>> So in this case, there are a few things that "helped" this patch get
>> selected:
>>
>>  - The word "quirk" in the subject line.
>>  - "fix" + "problem" in the commit log.
>>  - Modifies drivers/platform/x86/asus-nb-wmi.c which contains mostly
>>quirks.
>>  - The patch has minimal changes in code metrics. I don't have exact
>>numbers for this, but it seems that in general patches that do very
>> little have more odds of fixing bugs.
>>
>> And I also manually review all the stuff that get sent out, and to my
>> human brain it looks like something that should be in stable :)
>
>This is really cool to see, thanks for the effort here. Good place for the
>application of AI/ML.
>
>Have you considered having this work on patches submitted? If the machine could
>respond to patches that don't have stable or fixes tags that it thinks should,
>we could address this a bit earlier in the process, and perhaps get a more
>consistent labeling, as well as get the maintainer eyes on this, reducing the
>amount of manual auditing you have to do.

Yup, there are a few ideas on how to get this done earlier in the
process such as integration with checkpatch and a mail bot a-la 0day.

Right now it's still in the experimentation phase, I'm trying to improve
the results based on review feedback I get from maintainers/authors.

A good example of the above was that the NN was very keen on including
commits that added devicetree bindings since those usually happen with
hardware enablement which usually goes in stable. The issue was that
sometimes the code for the hardware didn't exist back in older stable
trees, and building the kernel wouldn't catch this error, so it's one of
the things I'm hoping to deal with before it goes too public.

-- 

Thanks,
Sasha

Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA

[Sasha Levin]

On Thu, Mar 08, 2018 at 10:37:21AM -0800, Darren Hart wrote:
>On Thu, Mar 08, 2018 at 06:15:27PM +, Sasha Levin wrote:
>> On Thu, Mar 08, 2018 at 09:47:54AM -0800, Greg KH wrote:
>> >On Thu, Mar 08, 2018 at 09:39:14AM -0800, Darren Hart wrote:
>> >> On Thu, Mar 08, 2018 at 04:59:01AM +, Sasha Levin wrote:
>> >> > From: Santeri Toivonen 
>> >> >
>> >> > [ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
>> >> >
>> >> > Asus laptop X302UA starts up with Wi-Fi disabled,
>> >> > without a way to enable it. Set wapf=4 to fix the problem.
>> >> >
>> >> > Signed-off-by: Santeri Toivonen 
>> >> > Signed-off-by: Darren Hart (VMware) 
>> >> > Signed-off-by: Sasha Levin 
>> >>
>> >> Hi Sasha,
>> >>
>> >> I'm curious about this AUTOSEL tag, and what about this patch triggered
>> >> its selection?
>> >
>> >It's "magic"!  :)
>> >
>> >Seriously, it's close to magic, there's a tool that Sasha is using that
>> >takes "machine learning" to match patches that we have not applied in
>> >stable kernels to ones that we have, and try to catch those that we
>> >forgot to tag for the stable tree.  Not all subsystems mark stable
>> >patches, so this is an attempt to catch those fixes that should be
>> >getting backported but are not either because the developer/maintainer
>> >forgot to mark it as such, or because they just never mark those types
>> >of patches.
>> >
>> >Sasha has a better write up about how this all works somewhere, and
>> >given that this type of question keeps coming up every other week or so,
>> >I think I need to add it to a FAQ somewhere to point people at to make
>> >it more obvious what is happening.
>>
>> It's pretty much a neural network that knows how to classify a "bug
>> fixing patch" based on things such as:
>>
>>  - Code metrics
>>  - Words in the commit message (the NN knows about the 10,000 most used
>>words, and their likehood to appear in a bug fixing patch).
>>  - Which files were modified.
>>  - Authors of the commit, and persons who got Cc'ed/Signed-off/etc.
>>
>> So in this case, there are a few things that "helped" this patch get
>> selected:
>>
>>  - The word "quirk" in the subject line.
>>  - "fix" + "problem" in the commit log.
>>  - Modifies drivers/platform/x86/asus-nb-wmi.c which contains mostly
>>quirks.
>>  - The patch has minimal changes in code metrics. I don't have exact
>>numbers for this, but it seems that in general patches that do very
>> little have more odds of fixing bugs.
>>
>> And I also manually review all the stuff that get sent out, and to my
>> human brain it looks like something that should be in stable :)
>
>This is really cool to see, thanks for the effort here. Good place for the
>application of AI/ML.
>
>Have you considered having this work on patches submitted? If the machine could
>respond to patches that don't have stable or fixes tags that it thinks should,
>we could address this a bit earlier in the process, and perhaps get a more
>consistent labeling, as well as get the maintainer eyes on this, reducing the
>amount of manual auditing you have to do.

Yup, there are a few ideas on how to get this done earlier in the
process such as integration with checkpatch and a mail bot a-la 0day.

Right now it's still in the experimentation phase, I'm trying to improve
the results based on review feedback I get from maintainers/authors.

A good example of the above was that the NN was very keen on including
commits that added devicetree bindings since those usually happen with
hardware enablement which usually goes in stable. The issue was that
sometimes the code for the hardware didn't exist back in older stable
trees, and building the kernel wouldn't catch this error, so it's one of
the things I'm hoping to deal with before it goes too public.

-- 

Thanks,
Sasha

Re: [PATCH net-next 0/9] fixes for configuration lost problems

[David Miller]

From: Peng Li 
Date: Fri, 9 Mar 2018 10:36:55 +0800

> This patchset refactors some functions and some bugs in order
> to fix the configuration loss problem when resetting and
> setting channel number.

Series applied, thank you.

Re: [PATCH net-next 0/9] fixes for configuration lost problems

[David Miller]

From: Peng Li 
Date: Fri, 9 Mar 2018 10:36:55 +0800

> This patchset refactors some functions and some bugs in order
> to fix the configuration loss problem when resetting and
> setting channel number.

Series applied, thank you.

[PATCH v2 12/17 2/4] mfd: tps65910: Delete an unnecessary variable initialisation in four functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:06:14 +0100

The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 555bd394efc3..80ea1474c654 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -229,7 +229,7 @@ static struct regmap_irq_chip tps65910_irq_chip = {
 static int tps65910_irq_init(struct tps65910 *tps65910, int irq,
struct tps65910_platform_data *pdata)
 {
-   int ret = 0;
+   int ret;
static struct regmap_irq_chip *tps6591x_irqs_chip;
 
if (!irq) {
@@ -313,7 +313,7 @@ static int tps65910_sleepinit(struct tps65910 *tps65910,
struct tps65910_board *pmic_pdata)
 {
struct device *dev = NULL;
-   int ret = 0;
+   int ret;
 
dev = tps65910->dev;
 
@@ -383,7 +383,7 @@ static struct tps65910_board *tps65910_parse_dt(struct 
i2c_client *client,
struct tps65910_board *board_info;
unsigned int prop;
const struct of_device_id *match;
-   int ret = 0;
+   int ret;
 
match = of_match_device(tps65910_of_match, >dev);
if (!match) {
@@ -460,7 +460,7 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
struct tps65910_board *of_pmic_plat_data = NULL;
struct tps65910_platform_data *init_data;
unsigned long chip_id = id->driver_data;
-   int ret = 0;
+   int ret;
 
pmic_plat_data = dev_get_platdata(>dev);
 
-- 
2.16.2

[PATCH v2 12/17 2/4] mfd: tps65910: Delete an unnecessary variable initialisation in four functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:06:14 +0100

The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 555bd394efc3..80ea1474c654 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -229,7 +229,7 @@ static struct regmap_irq_chip tps65910_irq_chip = {
 static int tps65910_irq_init(struct tps65910 *tps65910, int irq,
struct tps65910_platform_data *pdata)
 {
-   int ret = 0;
+   int ret;
static struct regmap_irq_chip *tps6591x_irqs_chip;
 
if (!irq) {
@@ -313,7 +313,7 @@ static int tps65910_sleepinit(struct tps65910 *tps65910,
struct tps65910_board *pmic_pdata)
 {
struct device *dev = NULL;
-   int ret = 0;
+   int ret;
 
dev = tps65910->dev;
 
@@ -383,7 +383,7 @@ static struct tps65910_board *tps65910_parse_dt(struct 
i2c_client *client,
struct tps65910_board *board_info;
unsigned int prop;
const struct of_device_id *match;
-   int ret = 0;
+   int ret;
 
match = of_match_device(tps65910_of_match, >dev);
if (!match) {
@@ -460,7 +460,7 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
struct tps65910_board *of_pmic_plat_data = NULL;
struct tps65910_platform_data *init_data;
unsigned long chip_id = id->driver_data;
-   int ret = 0;
+   int ret;
 
pmic_plat_data = dev_get_platdata(>dev);
 
-- 
2.16.2

Re: [PATCH] loop: Fix lost writes caused by missing flag

[Ross Zwisler]

On Fri, Mar 09, 2018 at 08:38:57AM -0700, Jens Axboe wrote:
> On 3/9/18 8:38 AM, Jens Axboe wrote:
> > On 3/8/18 5:20 PM, Ross Zwisler wrote:
> >> This has gotten Reviewed-by tags from Christoph and Ming Lei.
> >>
> >> Al, are you the right person to merge this?  Or is the correct person Jens,
> >> whom I accidentally didn't include when I sent this out?
> >>
> >> Just wanted to make sure this got merged, and to see whether it was 
> >> targeting
> >> v4.16 or v4.17.
> > 
> > I'm the right guy, but I don't see patches if I'm not cc'ed on them...
> > I have queued this up for 4.16, thanks.
> 
> I do see patches sent to linux-block as well, but you didn't CC that one
> either.

I figure out who to CC on my patches by using scripts/get_maintainer.pl, and
it didn't know about you or linux-block because drivers/block wasn't covered
in MAINTAINERS.  I'll send a patch to fix this.

As it was I just CC'd the folks involved in the original patch, and that one
went up through Al.

Thanks for picking this up.

Re: [PATCH] loop: Fix lost writes caused by missing flag

[Ross Zwisler]

On Fri, Mar 09, 2018 at 08:38:57AM -0700, Jens Axboe wrote:
> On 3/9/18 8:38 AM, Jens Axboe wrote:
> > On 3/8/18 5:20 PM, Ross Zwisler wrote:
> >> This has gotten Reviewed-by tags from Christoph and Ming Lei.
> >>
> >> Al, are you the right person to merge this?  Or is the correct person Jens,
> >> whom I accidentally didn't include when I sent this out?
> >>
> >> Just wanted to make sure this got merged, and to see whether it was 
> >> targeting
> >> v4.16 or v4.17.
> > 
> > I'm the right guy, but I don't see patches if I'm not cc'ed on them...
> > I have queued this up for 4.16, thanks.
> 
> I do see patches sent to linux-block as well, but you didn't CC that one
> either.

I figure out who to CC on my patches by using scripts/get_maintainer.pl, and
it didn't know about you or linux-block because drivers/block wasn't covered
in MAINTAINERS.  I'll send a patch to fix this.

As it was I just CC'd the folks involved in the original patch, and that one
went up through Al.

Thanks for picking this up.

Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers]

On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote:

> I have personally invested a lot of work into the SH port over the
> past three years in Debian and I was involved fixing many bugs
> and as a result, the port is quite usable. It would be really
> disappointing to see it being removed all of a sudden :(.

Note that SH glibc test results need some work - there are a large number 
of failures listed at .  
Probably most could be addressed with the NaN fixes I outlined at 
 - but that 
does of course need someone to do the work to implement that in GCC and 
glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
seem very specific on this, but the existing setting was definitely 
determined by testing on hardware.  SH experts with access to a range of 
different hardware may be needed to advise on what different hardware does 
or is supposed to do in this regard.)

The glibc port whose test results cause me the most concern that it's 
effectively unmaintained and should be considered for obsoletion is 
MicroBlaze - the results 
 are clearly a 
big mess (not something where one fix would probably resolve most failures 
as on SH) and there's no sign of activity to sort them out (nor has there 
been such activity for a long time).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers]

On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote:

> I have personally invested a lot of work into the SH port over the
> past three years in Debian and I was involved fixing many bugs
> and as a result, the port is quite usable. It would be really
> disappointing to see it being removed all of a sudden :(.

Note that SH glibc test results need some work - there are a large number 
of failures listed at .  
Probably most could be addressed with the NaN fixes I outlined at 
 - but that 
does of course need someone to do the work to implement that in GCC and 
glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
seem very specific on this, but the existing setting was definitely 
determined by testing on hardware.  SH experts with access to a range of 
different hardware may be needed to advise on what different hardware does 
or is supposed to do in this regard.)

The glibc port whose test results cause me the most concern that it's 
effectively unmaintained and should be considered for obsoletion is 
MicroBlaze - the results 
 are clearly a 
big mess (not something where one fix would probably resolve most failures 
as on SH) and there's no sign of activity to sort them out (nor has there 
been such activity for a long time).

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH v2 11/17] mfd: tps65910: Delete an error message for a failed memory allocation in tps65910_parse_dt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:00:59 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 8263605f6d2f..555bd394efc3 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -395,10 +395,8 @@ static struct tps65910_board *tps65910_parse_dt(struct 
i2c_client *client,
 
board_info = devm_kzalloc(>dev, sizeof(*board_info),
GFP_KERNEL);
-   if (!board_info) {
-   dev_err(>dev, "Failed to allocate pdata\n");
+   if (!board_info)
return NULL;
-   }
 
ret = of_property_read_u32(np, "ti,vmbch-threshold", );
if (!ret)
-- 
2.16.2

[PATCH v2 11/17] mfd: tps65910: Delete an error message for a failed memory allocation in tps65910_parse_dt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 9 Mar 2018 09:00:59 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 8263605f6d2f..555bd394efc3 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -395,10 +395,8 @@ static struct tps65910_board *tps65910_parse_dt(struct 
i2c_client *client,
 
board_info = devm_kzalloc(>dev, sizeof(*board_info),
GFP_KERNEL);
-   if (!board_info) {
-   dev_err(>dev, "Failed to allocate pdata\n");
+   if (!board_info)
return NULL;
-   }
 
ret = of_property_read_u32(np, "ti,vmbch-threshold", );
if (!ret)
-- 
2.16.2

Re: [PATCH 9/9] perf c2c report: Add cacheline address count column

[Jiri Olsa]

On Fri, Mar 09, 2018 at 11:56:43AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 09, 2018 at 11:14:42AM +0100, Jiri Olsa escreveu:
> > Adding the 'PA cnt' column grouped under data cacheline address.
> > 
> > It shows how many times the physical addresses changed for the
> > hist entry. It does not show the number of different physical
> > addresses for entry, because we don't store those. We only track
> > the number of times we got different address than we currently
> > hold, which is not expensive and gives similar info.
> > 
> >   $ perf c2c report --stdio
> > 
> >   #--- Cacheline --Total  Tot  - LLC 
> > Load Hitm -
> >   # Index Address  Node  PA cnt  records HitmTotal  
> > Lcl  Rmt
> >   # .  ..    ..  ...  ...  ...  
> > ...  ...
> >   #
> 
> 
> I'm adding this to the docs, ack?

nope.. those fields are c2c report only.. hardcoded

I'm preparing a change to share c2c fields with the
general report.. should come with other perf mem
changes later

jirka

> 
> diff --git a/tools/perf/Documentation/perf-report.txt 
> b/tools/perf/Documentation/perf-report.txt
> index cba16d8a970e..f4a280428e28 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -127,7 +127,7 @@ OPTIONS
>  
>   If the --mem-mode option is used, the following sort keys are also 
> available
>   (incompatible with --branch-stack):
> - symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline.
> + symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline, 
> dcacheline_count.
>  
>   - symbol_daddr: name of data symbol being executed on at the time of 
> sample
>   - dso_daddr: name of library or module containing the data being 
> executed
> @@ -137,6 +137,7 @@ OPTIONS
>   - mem: type of memory access for the data at the time of the sample
>   - snoop: type of snoop (if any) for the data at the time of the sample
>   - dcacheline: the cacheline the data address is on at the time of the 
> sample
> + - dcacheline_count: the number of physical addresses sampled for this 
> dcacheline
>   - phys_daddr: physical address of data being executed on at the time of 
> sample
>  
>   And the default sort keys are changed to local_weight, mem, sym, dso,

Re: [PATCH 9/9] perf c2c report: Add cacheline address count column

[Jiri Olsa]

On Fri, Mar 09, 2018 at 11:56:43AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 09, 2018 at 11:14:42AM +0100, Jiri Olsa escreveu:
> > Adding the 'PA cnt' column grouped under data cacheline address.
> > 
> > It shows how many times the physical addresses changed for the
> > hist entry. It does not show the number of different physical
> > addresses for entry, because we don't store those. We only track
> > the number of times we got different address than we currently
> > hold, which is not expensive and gives similar info.
> > 
> >   $ perf c2c report --stdio
> > 
> >   #--- Cacheline --Total  Tot  - LLC 
> > Load Hitm -
> >   # Index Address  Node  PA cnt  records HitmTotal  
> > Lcl  Rmt
> >   # .  ..    ..  ...  ...  ...  
> > ...  ...
> >   #
> 
> 
> I'm adding this to the docs, ack?

nope.. those fields are c2c report only.. hardcoded

I'm preparing a change to share c2c fields with the
general report.. should come with other perf mem
changes later

jirka

> 
> diff --git a/tools/perf/Documentation/perf-report.txt 
> b/tools/perf/Documentation/perf-report.txt
> index cba16d8a970e..f4a280428e28 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -127,7 +127,7 @@ OPTIONS
>  
>   If the --mem-mode option is used, the following sort keys are also 
> available
>   (incompatible with --branch-stack):
> - symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline.
> + symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline, 
> dcacheline_count.
>  
>   - symbol_daddr: name of data symbol being executed on at the time of 
> sample
>   - dso_daddr: name of library or module containing the data being 
> executed
> @@ -137,6 +137,7 @@ OPTIONS
>   - mem: type of memory access for the data at the time of the sample
>   - snoop: type of snoop (if any) for the data at the time of the sample
>   - dcacheline: the cacheline the data address is on at the time of the 
> sample
> + - dcacheline_count: the number of physical addresses sampled for this 
> dcacheline
>   - phys_daddr: physical address of data being executed on at the time of 
> sample
>  
>   And the default sort keys are changed to local_weight, mem, sym, dso,

[GIT PULL] fbdev fix for v4.16-rc5

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev fix for v4.16-rc5 (just a single fix to close
kernel data leak in FBIOGETCMAP_SPARC ioctl).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.16-rc5

for you to fetch changes up to 250c6c49e3b68756b14983c076183568636e2bde:

  fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in 
sbusfb_ioctl_helper(). (2018-03-07 14:00:34 +0100)


fbdev fix for v4.16-rc5:

- fix kernel data leak in FBIOGETCMAP_SPARC ioctl (Peter Malone)


Bartlomiej Zolnierkiewicz (1):
  Merge tag 'v4.16-rc4' of git://git.kernel.org/.../torvalds/linux into 
fbdev-for-next

Peter Malone (1):
  fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in 
sbusfb_ioctl_helper().

 drivers/video/fbdev/sbuslib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index af6fc97..a436d44 100644
--- a/drivers/video/fbdev/sbuslib.c
+++ b/drivers/video/fbdev/sbuslib.c
@@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
arg,
unsigned char __user *ured;
unsigned char __user *ugreen;
unsigned char __user *ublue;
-   int index, count, i;
+   unsigned int index, count, i;
 
if (get_user(index, >index) ||
__get_user(count, >count) ||
@@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
arg,
unsigned char __user *ugreen;
unsigned char __user *ublue;
struct fb_cmap *cmap = >cmap;
-   int index, count, i;
+   unsigned int index, count, i;
u8 red, green, blue;
 
if (get_user(index, >index) ||

[GIT PULL] fbdev fix for v4.16-rc5

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev fix for v4.16-rc5 (just a single fix to close
kernel data leak in FBIOGETCMAP_SPARC ioctl).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.16-rc5

for you to fetch changes up to 250c6c49e3b68756b14983c076183568636e2bde:

  fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in 
sbusfb_ioctl_helper(). (2018-03-07 14:00:34 +0100)


fbdev fix for v4.16-rc5:

- fix kernel data leak in FBIOGETCMAP_SPARC ioctl (Peter Malone)


Bartlomiej Zolnierkiewicz (1):
  Merge tag 'v4.16-rc4' of git://git.kernel.org/.../torvalds/linux into 
fbdev-for-next

Peter Malone (1):
  fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in 
sbusfb_ioctl_helper().

 drivers/video/fbdev/sbuslib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index af6fc97..a436d44 100644
--- a/drivers/video/fbdev/sbuslib.c
+++ b/drivers/video/fbdev/sbuslib.c
@@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
arg,
unsigned char __user *ured;
unsigned char __user *ugreen;
unsigned char __user *ublue;
-   int index, count, i;
+   unsigned int index, count, i;
 
if (get_user(index, >index) ||
__get_user(count, >count) ||
@@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
arg,
unsigned char __user *ugreen;
unsigned char __user *ublue;
struct fb_cmap *cmap = >cmap;
-   int index, count, i;
+   unsigned int index, count, i;
u8 red, green, blue;
 
if (get_user(index, >index) ||

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

[Florian Westphal]

David Woodhouse  wrote:
> 
> 
> On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
> > 
> > > > I did performance measurements in the following way:
> > > > 
> > > > Removed those pieces of the packet pipeline that I don't necessarily
> > > > need one-by-one.  Then measured their effect on small packet
> > > > performance.
> > > > 
> > > > This was the only part that produced considerable effect.
> > > > 
> > > > The pure speculation was about why the effect is more than 15%
> > > > increase in packet throughput, although the code path avoided
> > > > contains way less code than 15% of the packet pipeline.  It seems,
> > > > Felix Fietkau profiled similar changes, and found my guess well
> > > > founded.
> > > > 
> > > > Now could anybody explain me what else is wrong with my patch?
> > > 
> > > We have to come up with a more generic solution for this.
> > 
> > Jiri Benc suggested to allowing to attach netfilter hooks e.g. via tc
> > action, maybe that would be an option worth investigating.
> > 
> > Then you could for instance add filtering rules only to the bridge port
> > that needs it.
> > 
> > > These sysfs tweaks you're proposing look to me like an obscure way to
> > > tune this.
> > 
> > I agree, adding more tunables isn't all that helpful, in the past this
> > only helped to prolong the problem.
> 
> How feasible would it be to make it completely dynamic?
> 
> A given hook could automatically disable itself (for a given device) if
> the result of running it the first time was *tautologically* false for
> that device (i.e. regardless of the packet itself, or anything else).
> 
> The hook would need to be automatically re-enabled if the rule chain
> ever changes (and might subsequently disable itself again).
> 
> Is that something that's worth exploring for the general case?

AF_BRIDGE hooks sit in the net namespace, so its enough for
one bridge to request filtering to bring in the hook overhead for all
bridges in the same netns.

Alternatives:
- place the bridges that need filtering in different netns
- use tc ingress for filtering
- use nftables ingress hook for filtering (it sits in almost same
  location as tc ingress hook) to attach the ruleset to those bridge
  ports that need packet filtering.

(The original request came from user with tons of bridges where only
 one single bridge needed filtering).

One alternative I see is to place the bridge hooks into the
bridge device (net_bridge struct, which is in netdev private area).

But, as you already mentioned we would need to annotate the hooks
to figure out which device(s) they are for.

This sounds rather fragile to me, so i would just use nft ingress:

#!/sbin/nft -f

table netdev ingress {
  chain in_public { type filter hook ingress device eth0 priority 0;
   ip saddr 192.168.0.1 counter
 }
}

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

[Florian Westphal]

David Woodhouse  wrote:
> 
> 
> On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
> > 
> > > > I did performance measurements in the following way:
> > > > 
> > > > Removed those pieces of the packet pipeline that I don't necessarily
> > > > need one-by-one.  Then measured their effect on small packet
> > > > performance.
> > > > 
> > > > This was the only part that produced considerable effect.
> > > > 
> > > > The pure speculation was about why the effect is more than 15%
> > > > increase in packet throughput, although the code path avoided
> > > > contains way less code than 15% of the packet pipeline.  It seems,
> > > > Felix Fietkau profiled similar changes, and found my guess well
> > > > founded.
> > > > 
> > > > Now could anybody explain me what else is wrong with my patch?
> > > 
> > > We have to come up with a more generic solution for this.
> > 
> > Jiri Benc suggested to allowing to attach netfilter hooks e.g. via tc
> > action, maybe that would be an option worth investigating.
> > 
> > Then you could for instance add filtering rules only to the bridge port
> > that needs it.
> > 
> > > These sysfs tweaks you're proposing look to me like an obscure way to
> > > tune this.
> > 
> > I agree, adding more tunables isn't all that helpful, in the past this
> > only helped to prolong the problem.
> 
> How feasible would it be to make it completely dynamic?
> 
> A given hook could automatically disable itself (for a given device) if
> the result of running it the first time was *tautologically* false for
> that device (i.e. regardless of the packet itself, or anything else).
> 
> The hook would need to be automatically re-enabled if the rule chain
> ever changes (and might subsequently disable itself again).
> 
> Is that something that's worth exploring for the general case?

AF_BRIDGE hooks sit in the net namespace, so its enough for
one bridge to request filtering to bring in the hook overhead for all
bridges in the same netns.

Alternatives:
- place the bridges that need filtering in different netns
- use tc ingress for filtering
- use nftables ingress hook for filtering (it sits in almost same
  location as tc ingress hook) to attach the ruleset to those bridge
  ports that need packet filtering.

(The original request came from user with tons of bridges where only
 one single bridge needed filtering).

One alternative I see is to place the bridge hooks into the
bridge device (net_bridge struct, which is in netdev private area).

But, as you already mentioned we would need to annotate the hooks
to figure out which device(s) they are for.

This sounds rather fragile to me, so i would just use nft ingress:

#!/sbin/nft -f

table netdev ingress {
  chain in_public { type filter hook ingress device eth0 priority 0;
   ip saddr 192.168.0.1 counter
 }
}

[PATCH] ASoC: da7219: Add common clock usage for providing DAI clks

[Adam Thomson]

There is a need to use DA7219 as DAI clock master for other codecs
within a system, which means that the DAI clocks are required to
remain, regardless of whether the codec is actually running
playback/capture. To be able to expose control of the DAI clocking
the common clock framework has been employed.

The current implementation adds a simple clock gate for enabling
and disabling the DAI clocks, with no rate control supported
(this is still handled through standard hw_params() functions as
before). If DT is enabled then the clock is added to the OF
providers list, otherwise a clkdev lookup is used.

Signed-off-by: Adam Thomson 
---
 Documentation/devicetree/bindings/sound/da7219.txt |   6 +
 include/sound/da7219.h |   2 +
 sound/soc/codecs/da7219.c  | 129 +++--
 sound/soc/codecs/da7219.h  |   9 ++
 4 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/da7219.txt 
b/Documentation/devicetree/bindings/sound/da7219.txt
index 5b54d2d..c3df92d 100644
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ b/Documentation/devicetree/bindings/sound/da7219.txt
@@ -25,6 +25,9 @@ Optional properties:
   interrupt is to be used to wake system, otherwise "irq" should be used.
 - wakeup-source: Flag to indicate this device can wake system (suspend/resume).
 
+- #clock-cells :  Should be set to '<0>', only one clock source provided;
+- clock-output-names : Name given for DAI clocks output;
+
 - clocks : phandle and clock specifier for codec MCLK.
 - clock-names : Clock name string for 'clocks' attribute, should be "mclk".
 
@@ -83,6 +86,9 @@ Example:
VDDMIC-supply = <_audio>;
VDDIO-supply = <_audio>;
 
+   #clock-cells = <0>;
+   clock-output-names = "dai-clks";
+
clocks = < 201>;
clock-names = "mclk";
 
diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 409ef139..1bfcb16 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -36,6 +36,8 @@ enum da7219_mic_amp_in_sel {
 struct da7219_pdata {
bool wakeup_source;
 
+   const char *dai_clks_name;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 5e043d0..4412159 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -13,6 +13,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -772,16 +774,27 @@ static int da7219_dai_event(struct snd_soc_dapm_widget *w,
struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
u8 pll_ctrl, pll_status;
-   int i = 0;
+   int i = 0, ret;
bool srm_lock = false;
 
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
-   if (da7219->master)
+   if (da7219->master) {
/* Enable DAI clks for master mode */
-   snd_soc_component_update_bits(component, 
DA7219_DAI_CLK_MODE,
-   DA7219_DAI_CLK_EN_MASK,
-   DA7219_DAI_CLK_EN_MASK);
+   if (da7219->dai_clks) {
+   ret = clk_prepare_enable(da7219->dai_clks);
+   if (ret) {
+   dev_err(component->dev,
+   "Failed to enable dai_clks\n");
+   return ret;
+   }
+   } else {
+   snd_soc_component_update_bits(component,
+ 
DA7219_DAI_CLK_MODE,
+ 
DA7219_DAI_CLK_EN_MASK,
+ 
DA7219_DAI_CLK_EN_MASK);
+   }
+   }
 
/* PC synchronised to DAI */
snd_soc_component_update_bits(component, DA7219_PC_COUNT,
@@ -814,9 +827,16 @@ static int da7219_dai_event(struct snd_soc_dapm_widget *w,
DA7219_PC_FREERUN_MASK);
 
/* Disable DAI clks if in master mode */
-   if (da7219->master)
-   snd_soc_component_update_bits(component, 
DA7219_DAI_CLK_MODE,
-   DA7219_DAI_CLK_EN_MASK, 0);
+   if (da7219->master) {
+   if (da7219->dai_clks)
+   clk_disable_unprepare(da7219->dai_clks);
+   else
+   

[PATCH] ASoC: da7219: Add common clock usage for providing DAI clks

[Adam Thomson]

There is a need to use DA7219 as DAI clock master for other codecs
within a system, which means that the DAI clocks are required to
remain, regardless of whether the codec is actually running
playback/capture. To be able to expose control of the DAI clocking
the common clock framework has been employed.

The current implementation adds a simple clock gate for enabling
and disabling the DAI clocks, with no rate control supported
(this is still handled through standard hw_params() functions as
before). If DT is enabled then the clock is added to the OF
providers list, otherwise a clkdev lookup is used.

Signed-off-by: Adam Thomson 
---
 Documentation/devicetree/bindings/sound/da7219.txt |   6 +
 include/sound/da7219.h |   2 +
 sound/soc/codecs/da7219.c  | 129 +++--
 sound/soc/codecs/da7219.h  |   9 ++
 4 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/da7219.txt 
b/Documentation/devicetree/bindings/sound/da7219.txt
index 5b54d2d..c3df92d 100644
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ b/Documentation/devicetree/bindings/sound/da7219.txt
@@ -25,6 +25,9 @@ Optional properties:
   interrupt is to be used to wake system, otherwise "irq" should be used.
 - wakeup-source: Flag to indicate this device can wake system (suspend/resume).
 
+- #clock-cells :  Should be set to '<0>', only one clock source provided;
+- clock-output-names : Name given for DAI clocks output;
+
 - clocks : phandle and clock specifier for codec MCLK.
 - clock-names : Clock name string for 'clocks' attribute, should be "mclk".
 
@@ -83,6 +86,9 @@ Example:
VDDMIC-supply = <_audio>;
VDDIO-supply = <_audio>;
 
+   #clock-cells = <0>;
+   clock-output-names = "dai-clks";
+
clocks = < 201>;
clock-names = "mclk";
 
diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 409ef139..1bfcb16 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -36,6 +36,8 @@ enum da7219_mic_amp_in_sel {
 struct da7219_pdata {
bool wakeup_source;
 
+   const char *dai_clks_name;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 5e043d0..4412159 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -13,6 +13,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -772,16 +774,27 @@ static int da7219_dai_event(struct snd_soc_dapm_widget *w,
struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component);
u8 pll_ctrl, pll_status;
-   int i = 0;
+   int i = 0, ret;
bool srm_lock = false;
 
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
-   if (da7219->master)
+   if (da7219->master) {
/* Enable DAI clks for master mode */
-   snd_soc_component_update_bits(component, 
DA7219_DAI_CLK_MODE,
-   DA7219_DAI_CLK_EN_MASK,
-   DA7219_DAI_CLK_EN_MASK);
+   if (da7219->dai_clks) {
+   ret = clk_prepare_enable(da7219->dai_clks);
+   if (ret) {
+   dev_err(component->dev,
+   "Failed to enable dai_clks\n");
+   return ret;
+   }
+   } else {
+   snd_soc_component_update_bits(component,
+ 
DA7219_DAI_CLK_MODE,
+ 
DA7219_DAI_CLK_EN_MASK,
+ 
DA7219_DAI_CLK_EN_MASK);
+   }
+   }
 
/* PC synchronised to DAI */
snd_soc_component_update_bits(component, DA7219_PC_COUNT,
@@ -814,9 +827,16 @@ static int da7219_dai_event(struct snd_soc_dapm_widget *w,
DA7219_PC_FREERUN_MASK);
 
/* Disable DAI clks if in master mode */
-   if (da7219->master)
-   snd_soc_component_update_bits(component, 
DA7219_DAI_CLK_MODE,
-   DA7219_DAI_CLK_EN_MASK, 0);
+   if (da7219->master) {
+   if (da7219->dai_clks)
+   clk_disable_unprepare(da7219->dai_clks);
+   else
+   snd_soc_component_update_bits(component,
+ 

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

[Andy Lutomirski]

On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov  wrote:
> On 3/9/18 7:16 AM, Andy Lutomirski wrote:

 On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov  wrote:

 On 3/8/18 7:54 PM, Andy Lutomirski wrote:



> On Mar 8, 2018, at 7:06 PM, Linus Torvalds
>  wrote:
>
>
> Honestly, that "read twice" thing may be what scuttles this.
> Initially, I thought it was a non-issue, because anybody who controls
> the module subdirectory enough to rewrite files would be in a position
> to just execute the file itself directly instead.


 On further consideration, I think there’s another showstopper. This
 patch is a potentially severe ABI break. Right now, loading a module
 *copies* it into memory and does not hold a reference to the underlying fs.
 With the patch applied, all kinds of use cases can break in gnarly ways.
 Initramfs is maybe okay, but initrd may be screwed. If you load an ET_EXEC
 module from initrd, then umount it, then clear the ramdisk, something will
 go horribly wrong. Exactly what goes wrong depends on whether userspace
 notices that umount() failed. Similarly, if you load one of these modules
 over a network and then lose your connection, you have a problem.
>>>
>>>
>>> there is not abi breakage and file cannot disappear from running task.
>>> One cannot umount fs while file is still being used.
>>
>>
>> Sure it is. Without your patch, init_module doesn’t keep using the
>> file, so it’s common practice to load a module and then delete or
>> unmount it. With your patch, the unmount case breaks. This is likely
>> to break existing userspace, so, in Linux speak it’s an ABI break.
>
>
> please read the patch again.
> file is only used in case of umh modules.
> There is zero difference in default case.

Say I'm running some distro or other working Linux setup.  I upgrade
my kernel to a kernel that uses umh modules.  The user tooling
generates some kind of boot entry that references the new kernel
image, and it also generates a list of modules to be loaded at various
times in the boot process.  This list might, and probably should,
include one or more umh modules.  (You are being very careful to make
sure that depmod keeps working, so umh modules are clearly intended to
work with existing tooling.)  So now I have a kernel image and some
modules to be loaded from various places.  And I have an init script
(initramfs's '/init' or similar) that will call init_module() on that
.ko file.  That script was certainly written under the assumption
that, once init_module() returns, the kernel is done with the .ko
file.  With your patch applied, that assumption is no longer true.

RHEL 5 uses initrd and is still supported.  For all I know, some
embedded setups put their initial /lib on some block device that
literally disappears after they finish booting.  There are livecds
that let you boot in a mode that lets you remove the CD after you
finish booting.  Heck, someone must have built something that calls
init_module() on a FUSE filesystem.

Heck, on my laptop, all my .ko files are labeled
system_u:object_r:modules_object_t:s0.  I wonder how many SELinux
setups (and AppArmor, etc) will actually disallow execve() on modules?

>
>>>

 The “read twice” thing is also bad for another reason: containers.
 Suppose I have a setup where a container can load a signed module blob. 
 With
 the read twice code, the container can race and run an entirely different
 blob outside the container.
>>>
>>>
>>> Not only "read twice", but "read many".
>>> If .text sections of elf that are not yet in memory can be modified
>>> by malicious user, later they will be brought in with different code.
>>> I think the easiest fix to tighten this "umh modules" to CAP_SYS_ADMIN.
>>
>>
>> Given this issue, I think the patch would need Kees’s explicit ack. I
>> had initially thought your patch had minimal security impact, but I
>> was wrong Module security is very complicated and needs to satisfy a
>> bunch of requirements. There is a lot of code in the kernel that
>> assumes that it’s sufficient to verify a module once at load time,
>> your patch changes that, and this has all kinds of nasty interactions
>> with autoloading.
>
>
> not true. you misread the patch and making incorrect conclusions.

So please tell my exactly how I misread the patch and why Linus'
conclusion (which is what I'm echoing) is wrong.

>
> I think you need to stop overreacting on non-issue.
>

Can you please try to have a constructive discussion here?  It's not
so enjoyable to review patches when author declares review comments to
be non-issues without actually explaining *why* they're non-issues.

Alexei, I'm willing to be shown that I'm wrong, but you have to show
me how I'm wrong rather than just telling me over and over that I'm
wrong.

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

[Andy Lutomirski]

On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov  wrote:
> On 3/9/18 7:16 AM, Andy Lutomirski wrote:

 On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov  wrote:

 On 3/8/18 7:54 PM, Andy Lutomirski wrote:



> On Mar 8, 2018, at 7:06 PM, Linus Torvalds
>  wrote:
>
>
> Honestly, that "read twice" thing may be what scuttles this.
> Initially, I thought it was a non-issue, because anybody who controls
> the module subdirectory enough to rewrite files would be in a position
> to just execute the file itself directly instead.


 On further consideration, I think there’s another showstopper. This
 patch is a potentially severe ABI break. Right now, loading a module
 *copies* it into memory and does not hold a reference to the underlying fs.
 With the patch applied, all kinds of use cases can break in gnarly ways.
 Initramfs is maybe okay, but initrd may be screwed. If you load an ET_EXEC
 module from initrd, then umount it, then clear the ramdisk, something will
 go horribly wrong. Exactly what goes wrong depends on whether userspace
 notices that umount() failed. Similarly, if you load one of these modules
 over a network and then lose your connection, you have a problem.
>>>
>>>
>>> there is not abi breakage and file cannot disappear from running task.
>>> One cannot umount fs while file is still being used.
>>
>>
>> Sure it is. Without your patch, init_module doesn’t keep using the
>> file, so it’s common practice to load a module and then delete or
>> unmount it. With your patch, the unmount case breaks. This is likely
>> to break existing userspace, so, in Linux speak it’s an ABI break.
>
>
> please read the patch again.
> file is only used in case of umh modules.
> There is zero difference in default case.

Say I'm running some distro or other working Linux setup.  I upgrade
my kernel to a kernel that uses umh modules.  The user tooling
generates some kind of boot entry that references the new kernel
image, and it also generates a list of modules to be loaded at various
times in the boot process.  This list might, and probably should,
include one or more umh modules.  (You are being very careful to make
sure that depmod keeps working, so umh modules are clearly intended to
work with existing tooling.)  So now I have a kernel image and some
modules to be loaded from various places.  And I have an init script
(initramfs's '/init' or similar) that will call init_module() on that
.ko file.  That script was certainly written under the assumption
that, once init_module() returns, the kernel is done with the .ko
file.  With your patch applied, that assumption is no longer true.

RHEL 5 uses initrd and is still supported.  For all I know, some
embedded setups put their initial /lib on some block device that
literally disappears after they finish booting.  There are livecds
that let you boot in a mode that lets you remove the CD after you
finish booting.  Heck, someone must have built something that calls
init_module() on a FUSE filesystem.

Heck, on my laptop, all my .ko files are labeled
system_u:object_r:modules_object_t:s0.  I wonder how many SELinux
setups (and AppArmor, etc) will actually disallow execve() on modules?

>
>>>

 The “read twice” thing is also bad for another reason: containers.
 Suppose I have a setup where a container can load a signed module blob. 
 With
 the read twice code, the container can race and run an entirely different
 blob outside the container.
>>>
>>>
>>> Not only "read twice", but "read many".
>>> If .text sections of elf that are not yet in memory can be modified
>>> by malicious user, later they will be brought in with different code.
>>> I think the easiest fix to tighten this "umh modules" to CAP_SYS_ADMIN.
>>
>>
>> Given this issue, I think the patch would need Kees’s explicit ack. I
>> had initially thought your patch had minimal security impact, but I
>> was wrong Module security is very complicated and needs to satisfy a
>> bunch of requirements. There is a lot of code in the kernel that
>> assumes that it’s sufficient to verify a module once at load time,
>> your patch changes that, and this has all kinds of nasty interactions
>> with autoloading.
>
>
> not true. you misread the patch and making incorrect conclusions.

So please tell my exactly how I misread the patch and why Linus'
conclusion (which is what I'm echoing) is wrong.

>
> I think you need to stop overreacting on non-issue.
>

Can you please try to have a constructive discussion here?  It's not
so enjoyable to review patches when author declares review comments to
be non-issues without actually explaining *why* they're non-issues.

Alexei, I'm willing to be shown that I'm wrong, but you have to show
me how I'm wrong rather than just telling me over and over that I'm
wrong.

[PATCH v2 0/4] mfd/tps65910: Adjustments for four function implementations

[SF Markus Elfring]

From: Markus Elfring 

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete an error message for a failed memory allocation in tps65910_parse_dt()
  Delete an unnecessary variable initialisation in four functions
  Delete an unnecessary variable initialisation in tps65910_sleepinit()
  Move an assignment in tps65910_sleepinit()
---

v2:
Lee Jones requested a resend for these patches. The changes were rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

-- 
2.15.1

[PATCH v2 0/4] mfd/tps65910: Adjustments for four function implementations

[SF Markus Elfring]

From: Markus Elfring 

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete an error message for a failed memory allocation in tps65910_parse_dt()
  Delete an unnecessary variable initialisation in four functions
  Delete an unnecessary variable initialisation in tps65910_sleepinit()
  Move an assignment in tps65910_sleepinit()
---

v2:
Lee Jones requested a resend for these patches. The changes were rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65910.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

-- 
2.15.1

[PATCH v2 10/17] mfd: tps6586x: Delete an error message for a failed memory allocation in tps6586x_parse_dt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:30:54 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps6586x.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index 5628a6b5b19b..b89379782741 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -423,10 +423,8 @@ static struct tps6586x_platform_data 
*tps6586x_parse_dt(struct i2c_client *clien
struct tps6586x_platform_data *pdata;
 
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata) {
-   dev_err(>dev, "Memory allocation failed\n");
+   if (!pdata)
return NULL;
-   }
 
pdata->num_subdevs = 0;
pdata->subdevs = NULL;
-- 
2.16.2

[PATCH v2 10/17] mfd: tps6586x: Delete an error message for a failed memory allocation in tps6586x_parse_dt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:30:54 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps6586x.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index 5628a6b5b19b..b89379782741 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -423,10 +423,8 @@ static struct tps6586x_platform_data 
*tps6586x_parse_dt(struct i2c_client *clien
struct tps6586x_platform_data *pdata;
 
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata) {
-   dev_err(>dev, "Memory allocation failed\n");
+   if (!pdata)
return NULL;
-   }
 
pdata->num_subdevs = 0;
pdata->subdevs = NULL;
-- 
2.16.2

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

[Tejun Heo]

Hello,

On Thu, Mar 08, 2018 at 08:29:53AM +0800, Lai Jiangshan wrote:
> I mentioned a subtle use case that user would think it is supported
> since the comment doesn't disallow it.
> 
> It is clear that the user expects
>the work must be called at least once after the API returns
>the work must be called after an RCU grace period
> 
> But in the case when the user expects the work must be called
> at least once again after "queue_rcu_work() + an RCU grace period",
> the API is not competent to it if the work is queued.
> Although the user can detect it by the return value of
> queue_rcu_work(), the user hardly makes his expectation
> happen by adding appropriate code.

We should definitely document it better but it isn't any different
from delayed_work, and I don't see a reason to deviate.

Thanks.

-- 
tejun

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

[Tejun Heo]

Hello,

On Thu, Mar 08, 2018 at 08:29:53AM +0800, Lai Jiangshan wrote:
> I mentioned a subtle use case that user would think it is supported
> since the comment doesn't disallow it.
> 
> It is clear that the user expects
>the work must be called at least once after the API returns
>the work must be called after an RCU grace period
> 
> But in the case when the user expects the work must be called
> at least once again after "queue_rcu_work() + an RCU grace period",
> the API is not competent to it if the work is queued.
> Although the user can detect it by the return value of
> queue_rcu_work(), the user hardly makes his expectation
> happen by adding appropriate code.

We should definitely document it better but it isn't any different
from delayed_work, and I don't see a reason to deviate.

Thanks.

-- 
tejun

[PATCH v2 09/17] mfd: tps65090: Delete an error message for a failed memory allocation in tps65090_i2c_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:25:58 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65090.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index d7ec318c40c3..f13e4cd06e89 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -192,10 +192,8 @@ static int tps65090_i2c_probe(struct i2c_client *client,
irq_base = pdata->irq_base;
 
tps65090 = devm_kzalloc(>dev, sizeof(*tps65090), GFP_KERNEL);
-   if (!tps65090) {
-   dev_err(>dev, "mem alloc for tps65090 failed\n");
+   if (!tps65090)
return -ENOMEM;
-   }
 
tps65090->dev = >dev;
i2c_set_clientdata(client, tps65090);
-- 
2.16.2

[PATCH v2 09/17] mfd: tps65090: Delete an error message for a failed memory allocation in tps65090_i2c_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:25:58 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/tps65090.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index d7ec318c40c3..f13e4cd06e89 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -192,10 +192,8 @@ static int tps65090_i2c_probe(struct i2c_client *client,
irq_base = pdata->irq_base;
 
tps65090 = devm_kzalloc(>dev, sizeof(*tps65090), GFP_KERNEL);
-   if (!tps65090) {
-   dev_err(>dev, "mem alloc for tps65090 failed\n");
+   if (!tps65090)
return -ENOMEM;
-   }
 
tps65090->dev = >dev;
i2c_set_clientdata(client, tps65090);
-- 
2.16.2

Re: [PATCH v3 2/2] power: reset: gpio-poweroff: Support for timeout from device property

[Sebastian Reichel]

Hi,

On Thu, Feb 22, 2018 at 03:17:14PM -0800, Moritz Fischer wrote:
> Add support for reading a timeout value from device property.
> Fall back to previous default of 3s if nothing is specified.
> 
> Signed-off-by: Moritz Fischer 
> ---

Thanks, both queued.

-- Sebastian

> Changes from v2:
> - use device_property_read_{bool,u32} instead of of equivalent
> 
> Changes from v1:
> - of_property_read_u32() overwrites the output only if it succeeds,
>   simplify error handling
> ---
> 
>  drivers/power/reset/gpio-poweroff.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/gpio-poweroff.c 
> b/drivers/power/reset/gpio-poweroff.c
> index be3d81ff51cc..6273ad3b411d 100644
> --- a/drivers/power/reset/gpio-poweroff.c
> +++ b/drivers/power/reset/gpio-poweroff.c
> @@ -19,11 +19,13 @@
>  #include 
>  #include 
>  
> +#define DEFAULT_TIMEOUT_MS 3000
>  /*
>   * Hold configuration here, cannot be more than one instance of the driver
>   * since pm_power_off itself is global.
>   */
>  static struct gpio_desc *reset_gpio;
> +static u32 timeout = DEFAULT_TIMEOUT_MS;
>  
>  static void gpio_poweroff_do_poweroff(void)
>  {
> @@ -40,7 +42,7 @@ static void gpio_poweroff_do_poweroff(void)
>   gpiod_set_value(reset_gpio, 1);
>  
>   /* give it some time */
> - mdelay(3000);
> + mdelay(timeout);
>  
>   WARN_ON(1);
>  }
> @@ -58,12 +60,14 @@ static int gpio_poweroff_probe(struct platform_device 
> *pdev)
>   return -EBUSY;
>   }
>  
> - input = of_property_read_bool(pdev->dev.of_node, "input");
> + input = device_property_read_bool(>dev, "input");
>   if (input)
>   flags = GPIOD_IN;
>   else
>   flags = GPIOD_OUT_LOW;
>  
> + device_property_read_u32(>dev, "timeout-ms", );
> +
>   reset_gpio = devm_gpiod_get(>dev, NULL, flags);
>   if (IS_ERR(reset_gpio))
>   return PTR_ERR(reset_gpio);
> -- 
> 2.16.1
> 


signature.asc
Description: PGP signature

Re: [PATCH v3 2/2] power: reset: gpio-poweroff: Support for timeout from device property

[Sebastian Reichel]

Hi,

On Thu, Feb 22, 2018 at 03:17:14PM -0800, Moritz Fischer wrote:
> Add support for reading a timeout value from device property.
> Fall back to previous default of 3s if nothing is specified.
> 
> Signed-off-by: Moritz Fischer 
> ---

Thanks, both queued.

-- Sebastian

> Changes from v2:
> - use device_property_read_{bool,u32} instead of of equivalent
> 
> Changes from v1:
> - of_property_read_u32() overwrites the output only if it succeeds,
>   simplify error handling
> ---
> 
>  drivers/power/reset/gpio-poweroff.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/gpio-poweroff.c 
> b/drivers/power/reset/gpio-poweroff.c
> index be3d81ff51cc..6273ad3b411d 100644
> --- a/drivers/power/reset/gpio-poweroff.c
> +++ b/drivers/power/reset/gpio-poweroff.c
> @@ -19,11 +19,13 @@
>  #include 
>  #include 
>  
> +#define DEFAULT_TIMEOUT_MS 3000
>  /*
>   * Hold configuration here, cannot be more than one instance of the driver
>   * since pm_power_off itself is global.
>   */
>  static struct gpio_desc *reset_gpio;
> +static u32 timeout = DEFAULT_TIMEOUT_MS;
>  
>  static void gpio_poweroff_do_poweroff(void)
>  {
> @@ -40,7 +42,7 @@ static void gpio_poweroff_do_poweroff(void)
>   gpiod_set_value(reset_gpio, 1);
>  
>   /* give it some time */
> - mdelay(3000);
> + mdelay(timeout);
>  
>   WARN_ON(1);
>  }
> @@ -58,12 +60,14 @@ static int gpio_poweroff_probe(struct platform_device 
> *pdev)
>   return -EBUSY;
>   }
>  
> - input = of_property_read_bool(pdev->dev.of_node, "input");
> + input = device_property_read_bool(>dev, "input");
>   if (input)
>   flags = GPIOD_IN;
>   else
>   flags = GPIOD_OUT_LOW;
>  
> + device_property_read_u32(>dev, "timeout-ms", );
> +
>   reset_gpio = devm_gpiod_get(>dev, NULL, flags);
>   if (IS_ERR(reset_gpio))
>   return PTR_ERR(reset_gpio);
> -- 
> 2.16.1
> 


signature.asc
Description: PGP signature

[PATCH v2 08/17] mfd: ti_am335x_tscadc: Delete an error message for a failed memory allocation in ti_tscadc_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:15:51 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/ti_am335x_tscadc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 3cd958a31f36..47012c0899cd 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -169,10 +169,9 @@ static int ti_tscadc_probe(struct platform_device 
*pdev)
 
/* Allocate memory for device */
tscadc = devm_kzalloc(>dev, sizeof(*tscadc), GFP_KERNEL);
-   if (!tscadc) {
-   dev_err(>dev, "failed to allocate memory.\n");
+   if (!tscadc)
return -ENOMEM;
-   }
+
tscadc->dev = >dev;
 
err = platform_get_irq(pdev, 0);
-- 
2.16.2

[PATCH v2 08/17] mfd: ti_am335x_tscadc: Delete an error message for a failed memory allocation in ti_tscadc_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Mar 2018 15:15:51 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
Lee Jones requested a resend for this patch. The change was rebased
on source files from Linux next-20180308.

 drivers/mfd/ti_am335x_tscadc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 3cd958a31f36..47012c0899cd 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -169,10 +169,9 @@ static int ti_tscadc_probe(struct platform_device 
*pdev)
 
/* Allocate memory for device */
tscadc = devm_kzalloc(>dev, sizeof(*tscadc), GFP_KERNEL);
-   if (!tscadc) {
-   dev_err(>dev, "failed to allocate memory.\n");
+   if (!tscadc)
return -ENOMEM;
-   }
+
tscadc->dev = >dev;
 
err = platform_get_irq(pdev, 0);
-- 
2.16.2