[PATCH v3 5/6] ARM: at91: add SAMx7 SoC detection

From: Szemző András Add SAME70/V71/S70/V70 chip-ids to SoC detection. Signed-off-by: Szemző András Signed-off-by: Alexandre Belloni --- drivers/soc/atmel/soc.c | 24 drivers/soc/atmel/soc.h | 26

[PATCH v3 1/6] ARM: at91: Documentation: add samx7 families

The Atmel sams70, samv70 and samv71 are Cortex-M7 based MCUs that can run Linux (without MMU). Signed-off-by: Alexandre Belloni --- Documentation/arm/Atmel/README | 38 +- 1 file changed, 37 insertions(+), 1 deletion(-)

[PATCH v3 5/6] ARM: at91: add SAMx7 SoC detection

From: Szemző András Add SAME70/V71/S70/V70 chip-ids to SoC detection. Signed-off-by: Szemző András Signed-off-by: Alexandre Belloni --- drivers/soc/atmel/soc.c | 24 drivers/soc/atmel/soc.h | 26 ++ 2 files changed, 50 insertions(+) diff

[PATCH v3 1/6] ARM: at91: Documentation: add samx7 families

The Atmel sams70, samv70 and samv71 are Cortex-M7 based MCUs that can run Linux (without MMU). Signed-off-by: Alexandre Belloni --- Documentation/arm/Atmel/README | 38 +- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

On 05/19/2017 11:47 PM, Yisheng Xie wrote: > When ioremap a 67112960 bytes vm_area with the vmallocinfo: > [..] > 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc > 0xec80-0xecbe1000 4067328 kbox_proc_mem_write+0x104/0x1c4 phys=8b52 > ioremap > > we get result: >

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

On 05/19/2017 11:47 PM, Yisheng Xie wrote: > When ioremap a 67112960 bytes vm_area with the vmallocinfo: > [..] > 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc > 0xec80-0xecbe1000 4067328 kbox_proc_mem_write+0x104/0x1c4 phys=8b52 > ioremap > > we get result: >

Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and

Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), >> > this

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

Note Before: I might not have the address list correct, as I have re-created this e-mail from the web page archive, having found the thread after bisecting the kernel. On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote: > On Sun, 28 May 2017, Andy Lutomirski wrote: >> On Sun, May 28, 2017

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

Note Before: I might not have the address list correct, as I have re-created this e-mail from the web page archive, having found the thread after bisecting the kernel. On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote: > On Sun, 28 May 2017, Andy Lutomirski wrote: >> On Sun, May 28, 2017

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

On Tue, May 30, 2017 at 05:16:27PM -0700, Florian Fainelli wrote: > On 05/30/2017 05:06 PM, Andrew Lunn wrote: > >> - past the initial setup, if we start creating bridge devices and so on, > >> we have no way to tell: group Ports 0-3 together and send traffic to CPU > >> port 0, then let Port 5

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

On Tue, May 30, 2017 at 05:16:27PM -0700, Florian Fainelli wrote: > On 05/30/2017 05:06 PM, Andrew Lunn wrote: > >> - past the initial setup, if we start creating bridge devices and so on, > >> we have no way to tell: group Ports 0-3 together and send traffic to CPU > >> port 0, then let Port 5

Re: [net-bluetooth] question about potential null pointer dereference

Hi Gustavo, > While looking into Coverity ID 1357456 I ran into the following piece of code > at net/bluetooth/smp.c:166 > > 166/* The following functions map to the LE SC SMP crypto functions > 167 * AES-CMAC, f4, f5, f6, g2 and h6. > 168 */ > 169 > 170static int aes_cmac(struct crypto_shash

Re: [net-bluetooth] question about potential null pointer dereference

Hi Gustavo, > While looking into Coverity ID 1357456 I ran into the following piece of code > at net/bluetooth/smp.c:166 > > 166/* The following functions map to the LE SC SMP crypto functions > 167 * AES-CMAC, f4, f5, f6, g2 and h6. > 168 */ > 169 > 170static int aes_cmac(struct crypto_shash

[rcu:rcu/next 96/97] init/main.o:undefined reference to `rcu_scheduler_starting'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 19223c8730d289cd4c65b46250b3e02a6752803c commit: 9c6175ccfb30f974cd87ac2dbbbd53a2e201a3b9 [96/97] srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU config: parisc-allnoconfig (attached as

[rcu:rcu/next 96/97] init/main.o:undefined reference to `rcu_scheduler_starting'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 19223c8730d289cd4c65b46250b3e02a6752803c commit: 9c6175ccfb30f974cd87ac2dbbbd53a2e201a3b9 [96/97] srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU config: parisc-allnoconfig (attached as

[rcu:rcu/next 97/97] arch/blackfin/kernel/module.c:20:25: error: expected ')' before 'fmt'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 19223c8730d289cd4c65b46250b3e02a6752803c commit: 19223c8730d289cd4c65b46250b3e02a6752803c [97/97] module: Fix pr_fmt() bug for header use of printk config: blackfin-allmodconfig (attached as .config)

[rcu:rcu/next 97/97] arch/blackfin/kernel/module.c:20:25: error: expected ')' before 'fmt'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 19223c8730d289cd4c65b46250b3e02a6752803c commit: 19223c8730d289cd4c65b46250b3e02a6752803c [97/97] module: Fix pr_fmt() bug for header use of printk config: blackfin-allmodconfig (attached as .config)

Re: [PATCH V1 02/15] spmi: pmic-arb: rename spmi_pmic_arb_dev to spmi_pmic_arb

On 05/30, Kiran Gunda wrote: > From: Abhijeet Dharmapurikar > > Usually *_dev best used for structures that embed a struct device in > them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data > structure. Use an appropriate name for it. > > Also there are

Re: [PATCH V1 02/15] spmi: pmic-arb: rename spmi_pmic_arb_dev to spmi_pmic_arb

On 05/30, Kiran Gunda wrote: > From: Abhijeet Dharmapurikar > > Usually *_dev best used for structures that embed a struct device in > them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data > structure. Use an appropriate name for it. > > Also there are many places in the driver

[PATCHv2 1/2] arm64:vdso: Rewrite gettimeofday into C.

This allows the compiler to optimize the divide by 1000. And remove the other divide. On ThunderX, gettimeofday improves by 32%. On ThunderX 2, gettimeofday improves by 18%. Note I noticed a bug in the old implementation of __kernel_clock_getres; it was checking only the lower 32bits of the

[PATCHv2 1/2] arm64:vdso: Rewrite gettimeofday into C.

This allows the compiler to optimize the divide by 1000. And remove the other divide. On ThunderX, gettimeofday improves by 32%. On ThunderX 2, gettimeofday improves by 18%. Note I noticed a bug in the old implementation of __kernel_clock_getres; it was checking only the lower 32bits of the

[PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

ISB is normally required before mrs CNTVCT if we want the mrs to completed after the loads. In this case it is not. As we are taking the difference and if that difference was going to be negative, we just use the last counter value instead. Signed-off-by: Andrew Pinski ---

[PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

ISB is normally required before mrs CNTVCT if we want the mrs to completed after the loads. In this case it is not. As we are taking the difference and if that difference was going to be negative, we just use the last counter value instead. Signed-off-by: Andrew Pinski ---

Re: [PATCH 4/7] driver core: fix automatic pinctrl management

On Tue, May 30, 2017 at 6:25 PM, Johan Hovold wrote: > Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device > core") added automatic pin-control management to driver core by looking > up and setting any default pinctrl state found in device tree while a >

Re: [PATCH 4/7] driver core: fix automatic pinctrl management

On Tue, May 30, 2017 at 6:25 PM, Johan Hovold wrote: > Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device > core") added automatic pin-control management to driver core by looking > up and setting any default pinctrl state found in device tree while a > device is being

Re: [PATCH V1 01/15] spmi: pmic_arb: block access of invalid read and writes

On 05/30, Kiran Gunda wrote: > From: Abhijeet Dharmapurikar > > The system crashes due to bad access when reading from an non configured > peripheral and when writing to peripheral which is not owned by current > ee. This patch verifies ownership to avoid crashing on >

Re: [PATCH V1 01/15] spmi: pmic_arb: block access of invalid read and writes

On 05/30, Kiran Gunda wrote: > From: Abhijeet Dharmapurikar > > The system crashes due to bad access when reading from an non configured > peripheral and when writing to peripheral which is not owned by current > ee. This patch verifies ownership to avoid crashing on > write. What systems? As

Re: [PATCH] pinctrl: stm32: Fix bad function call

On Tue, May 30, 2017 at 4:43 PM, Alexandre TORGUE wrote: > In stm32_pconf_parse_conf function, stm32_pmx_gpio_set_direction is > called with wrong parameter value. Indeed, using NULL value for range > will raise an oops. > > Fixes: aceb16dc2da5 ("pinctrl: Add STM32 MCUs

Re: [PATCH] pinctrl: stm32: Fix bad function call

On Tue, May 30, 2017 at 4:43 PM, Alexandre TORGUE wrote: > In stm32_pconf_parse_conf function, stm32_pmx_gpio_set_direction is > called with wrong parameter value. Indeed, using NULL value for range > will raise an oops. > > Fixes: aceb16dc2da5 ("pinctrl: Add STM32 MCUs support") > Reported-by:

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

On 05/30/2017 05:06 PM, Andrew Lunn wrote: >> - past the initial setup, if we start creating bridge devices and so on, >> we have no way to tell: group Ports 0-3 together and send traffic to CPU >> port 0, then let Port 5 alone and send traffic to CPU port 1, that's a >> DSA-only problem though,

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

On 05/30/2017 05:06 PM, Andrew Lunn wrote: >> - past the initial setup, if we start creating bridge devices and so on, >> we have no way to tell: group Ports 0-3 together and send traffic to CPU >> port 0, then let Port 5 alone and send traffic to CPU port 1, that's a >> DSA-only problem though,

Re: [PATCH] gpio: xra1403: select REGMAP_SPI

On Tue, May 30, 2017 at 1:13 PM, Arnd Bergmann wrote: > Without the regmap code, we get a link error: > > drivers/gpio/built-in.o: In function `xra1403_probe': > (.text+0x132e0): undefined reference to `__devm_regmap_init_spi' > > Fixes: 5704520d7880 ("gpio: xra1403: Add EXAR

Re: [PATCH] gpio: xra1403: select REGMAP_SPI

On Tue, May 30, 2017 at 1:13 PM, Arnd Bergmann wrote: > Without the regmap code, we get a link error: > > drivers/gpio/built-in.o: In function `xra1403_probe': > (.text+0x132e0): undefined reference to `__devm_regmap_init_spi' > > Fixes: 5704520d7880 ("gpio: xra1403: Add EXAR XRA1403 SPI GPIO

Re: [RFC][PATCH 0/4] Fixes for two recently found timekeeping bugs

I successfully tested these four patches on a HiKey (ARMv8) board using a 4.9 kernel. I cherry picked various commits from upstream that touched kernel/time/timekeeping.c to ensure that John's patches apply cleanly. The inconsistency-check from kselftest that previously failed because of

Re: [RFC][PATCH 0/4] Fixes for two recently found timekeeping bugs

I successfully tested these four patches on a HiKey (ARMv8) board using a 4.9 kernel. I cherry picked various commits from upstream that touched kernel/time/timekeeping.c to ensure that John's patches apply cleanly. The inconsistency-check from kselftest that previously failed because of

Re: [patch] compiler, clang: suppress warning for unused static inline functions

On Wed, 24 May 2017, Doug Anderson wrote: > * Matthias has been sending out individual patches that take each > particular case into account to try to remove the warnings. In some > cases this removes totally dead code. In other cases this adds > __maybe_unused. ...and as a last resort it uses

Re: [patch] compiler, clang: suppress warning for unused static inline functions

On Wed, 24 May 2017, Doug Anderson wrote: > * Matthias has been sending out individual patches that take each > particular case into account to try to remove the warnings. In some > cases this removes totally dead code. In other cases this adds > __maybe_unused. ...and as a last resort it uses

Re: [PATCH v2 2/3] pinctrl: stm32: Implement .get_direction gpio_chip callback

On Mon, May 29, 2017 at 6:17 PM, Alexandre TORGUE wrote: > Add .get_direction() gpiochip callback in STM32 pinctrl driver. > > Signed-off-by: Alexandre TORGUE Good feature. Patch applied. Yours, Linus Walleij

Re: [PATCH v2 2/3] pinctrl: stm32: Implement .get_direction gpio_chip callback

On Mon, May 29, 2017 at 6:17 PM, Alexandre TORGUE wrote: > Add .get_direction() gpiochip callback in STM32 pinctrl driver. > > Signed-off-by: Alexandre TORGUE Good feature. Patch applied. Yours, Linus Walleij

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

> - past the initial setup, if we start creating bridge devices and so on, > we have no way to tell: group Ports 0-3 together and send traffic to CPU > port 0, then let Port 5 alone and send traffic to CPU port 1, that's a > DSA-only problem though, because we still have the CPU port(s) as >

Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support

> - past the initial setup, if we start creating bridge devices and so on, > we have no way to tell: group Ports 0-3 together and send traffic to CPU > port 0, then let Port 5 alone and send traffic to CPU port 1, that's a > DSA-only problem though, because we still have the CPU port(s) as >

[PATCH] char: tpm: remove unnecessary code

Remove unnecessary code. Pointer chip cannot be NULL in st33zp24_send(). Addresses-Coverity-ID: 1397648 Cc: Jason Gunthorpe Signed-off-by: Gustavo A. R. Silva --- drivers/char/tpm/st33zp24/st33zp24.c | 2 -- 1 file changed, 2

[PATCH] char: tpm: remove unnecessary code

Remove unnecessary code. Pointer chip cannot be NULL in st33zp24_send(). Addresses-Coverity-ID: 1397648 Cc: Jason Gunthorpe Signed-off-by: Gustavo A. R. Silva --- drivers/char/tpm/st33zp24/st33zp24.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/char/tpm/st33zp24/st33zp24.c

Re: [PATCH] xen: avoid type warning in xchg_xen_ulong

On Mon, 29 May 2017, Arnd Bergmann wrote: > The improved type-checking version of container_of() triggers a warning for > xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t > contains a signed value: > > drivers/xen/events/events_2l.c: In function

Re: [PATCH] xen: avoid type warning in xchg_xen_ulong

On Mon, 29 May 2017, Arnd Bergmann wrote: > The improved type-checking version of container_of() triggers a warning for > xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t > contains a signed value: > > drivers/xen/events/events_2l.c: In function

Re: [PATCH v2 1/3] pinctrl: stm32: set pin to gpio input when used as interrupt

On Mon, May 29, 2017 at 6:17 PM, Alexandre TORGUE wrote: > This patch ensures that pin is correctly set as gpio input when it is used > as an interrupt. > > Signed-off-by: Alexandre TORGUE Nice! Patch applied. Yours, Linus Walleij

Re: [PATCH v2 1/3] pinctrl: stm32: set pin to gpio input when used as interrupt

On Mon, May 29, 2017 at 6:17 PM, Alexandre TORGUE wrote: > This patch ensures that pin is correctly set as gpio input when it is used > as an interrupt. > > Signed-off-by: Alexandre TORGUE Nice! Patch applied. Yours, Linus Walleij

Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi

Hi Alexey, I am interested in validating this fix. Can you please share some of your testcases or let me know if you use any standard OpenMP benchmarks? - Arun

Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi

Hi Alexey, I am interested in validating this fix. Can you please share some of your testcases or let me know if you use any standard OpenMP benchmarks? - Arun

Re: [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Mon, May 29, 2017 at 3:41 PM, Jan Kiszka wrote: > On 2017-05-29 14:39, Linus Walleij wrote: >> Should I merge them all? Should Greg merge them all? >> Should one of us produce an immutable branch? > > Half of the patch are affecting both serial and GPIO subsystem, most

Re: [PATCH v3 00/10] serial/gpio: exar: Fixes and support for IOT2000

On Mon, May 29, 2017 at 3:41 PM, Jan Kiszka wrote: > On 2017-05-29 14:39, Linus Walleij wrote: >> Should I merge them all? Should Greg merge them all? >> Should one of us produce an immutable branch? > > Half of the patch are affecting both serial and GPIO subsystem, most > have GPIO focus,

Re: [PATCH] pinctrl: mcp23s08: improve I2C Kconfig dependency

On Tue, May 30, 2017 at 11:11 AM, Arnd Bergmann wrote: > With "SPI_MASTER=y && I2C=m", we can build mcp23s08 as a built-in driver, > which then results in a link failure: > > drivers/pinctrl/built-in.o: In function `mcp23s08_probe_one.isra.0': > :(.text+0x7910): undefined

Re: [PATCH] pinctrl: mcp23s08: improve I2C Kconfig dependency

On Tue, May 30, 2017 at 11:11 AM, Arnd Bergmann wrote: > With "SPI_MASTER=y && I2C=m", we can build mcp23s08 as a built-in driver, > which then results in a link failure: > > drivers/pinctrl/built-in.o: In function `mcp23s08_probe_one.isra.0': > :(.text+0x7910): undefined reference to

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 7:40 PM, Daniel Micay wrote: > On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: >> On 5/30/17 4:22 PM, Daniel Micay wrote: Thanks, I didn't know that android was doing this. I still think this feature is worthwhile for people to be able to harden their systems

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 7:40 PM, Daniel Micay wrote: > On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: >> On 5/30/17 4:22 PM, Daniel Micay wrote: Thanks, I didn't know that android was doing this. I still think this feature is worthwhile for people to be able to harden their systems

Re: [PATCH] gpiolib: remove unused variable

On Tue, May 30, 2017 at 11:21 AM, Arnd Bergmann wrote: > This was left behind by a cleanup patch: > > drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask': > drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' > [-Werror=unused-variable] > > Fixes:

Re: [PATCH] gpiolib: remove unused variable

On Tue, May 30, 2017 at 11:21 AM, Arnd Bergmann wrote: > This was left behind by a cleanup patch: > > drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask': > drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' > [-Werror=unused-variable] > > Fixes: 923a654c186c

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> This is my point. Apps will continue to shoot themselves in the foot. Of > course > the correct response to one of these vulns is to not pass ttys across a > security boundary. We have an opportunity here to reduce the impact of this > bug > class at the kernel level. Not really. If you

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> This is my point. Apps will continue to shoot themselves in the foot. Of > course > the correct response to one of these vulns is to not pass ttys across a > security boundary. We have an opportunity here to reduce the impact of this > bug > class at the kernel level. Not really. If you

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: > On 5/30/17 4:22 PM, Daniel Micay wrote: > > > Thanks, I didn't know that android was doing this. I still think > > > this > > > feature > > > is worthwhile for people to be able to harden their systems > > > against > > > this attack > > >

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: > On 5/30/17 4:22 PM, Daniel Micay wrote: > > > Thanks, I didn't know that android was doing this. I still think > > > this > > > feature > > > is worthwhile for people to be able to harden their systems > > > against > > > this attack > > >

[PATCH] drm: Use vsnprintf extension %ph

Using the extension saves a bit of code. Miscellanea: o Neaten and simplify dump_dp_payload_table o Removed trailing blank space from output $ size drivers/gpu/drm/drm_dp_mst_topology.o.* drivers/gpu/drm/tinydrm/*.o* textdata bss dec hex filename 25848 0 16

[PATCH] drm: Use vsnprintf extension %ph

Using the extension saves a bit of code. Miscellanea: o Neaten and simplify dump_dp_payload_table o Removed trailing blank space from output $ size drivers/gpu/drm/drm_dp_mst_topology.o.* drivers/gpu/drm/tinydrm/*.o* textdata bss dec hex filename 25848 0 16

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Tue, 30 May 2017 18:07:18 -0500, Bjorn Helgaas wrote: > On Fri, May 26, 2017 at 04:58:20PM -0700, Jakub Kicinski wrote: > > On Fri, 26 May 2017 18:47:26 -0500, Bjorn Helgaas wrote: > > > On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > > > > PCI core sets the driver pointer

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Tue, 30 May 2017 18:07:18 -0500, Bjorn Helgaas wrote: > On Fri, May 26, 2017 at 04:58:20PM -0700, Jakub Kicinski wrote: > > On Fri, 26 May 2017 18:47:26 -0500, Bjorn Helgaas wrote: > > > On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > > > > PCI core sets the driver pointer

Re: [PATCH] staging: android: uapi: drop definitions of removed ION_IOC_{FREE,SHARE} ioctls

On 05/30/2017 07:11 AM, Gleb Fotengauer-Malinovskiy wrote: > This problem was found by strace ioctl list generator. > > Fixes: 15c6098cfec5 ("staging: android: ion: Remove ion_handle and > ion_client") > Signed-off-by: Gleb Fotengauer-Malinovskiy > --- >

Re: [PATCH] staging: android: uapi: drop definitions of removed ION_IOC_{FREE,SHARE} ioctls

On 05/30/2017 07:11 AM, Gleb Fotengauer-Malinovskiy wrote: > This problem was found by strace ioctl list generator. > > Fixes: 15c6098cfec5 ("staging: android: ion: Remove ion_handle and > ion_client") > Signed-off-by: Gleb Fotengauer-Malinovskiy > --- > drivers/staging/android/uapi/ion.h | 18

Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown

Sorry to respond to myself. Thomas, your reply to another mail in this series helped me to notice: On Tue, May 30, 2017 at 04:19:58PM -0700, Brian Norris wrote: > Side note: for issues like the first problem above, I wonder why there > isn't a flag that once could pass to request_irq() that

Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown

Sorry to respond to myself. Thomas, your reply to another mail in this series helped me to notice: On Tue, May 30, 2017 at 04:19:58PM -0700, Brian Norris wrote: > Side note: for issues like the first problem above, I wonder why there > isn't a flag that once could pass to request_irq() that

Re: [PATCH] ARM64: dts: meson-gx: Add SPICC nodes

Kevin Hilman writes: > Neil Armstrong writes: > >> Add nodes for the SPICC controller on GX common dtsi, GXBB and >> GXL dtsi files. >> >> Signed-off-by: Neil Armstrong > > Applied to v4.13/dt64, Oops, this one will have

Re: [PATCH] ARM64: dts: meson-gx: Add SPICC nodes

Kevin Hilman writes: > Neil Armstrong writes: > >> Add nodes for the SPICC controller on GX common dtsi, GXBB and >> GXL dtsi files. >> >> Signed-off-by: Neil Armstrong > > Applied to v4.13/dt64, Oops, this one will have to wait until we have an immutable branch in the clk tree. Kevin

Re: [PATCH 3/3] zswap: Delete an error message for a failed memory allocation in zswap_dstmem_prepare()

On Sun, May 21, 2017 at 4:27 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 21 May 2017 09:29:25 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using

Re: [PATCH 3/3] zswap: Delete an error message for a failed memory allocation in zswap_dstmem_prepare()

On Sun, May 21, 2017 at 4:27 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 21 May 2017 09:29:25 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Link: >

Re: [PATCH 2/3] zswap: Improve a size determination in zswap_frontswap_init()

On Sun, May 21, 2017 at 4:26 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 May 2017 22:44:03 +0200 > > Replace the specification of a data structure by a pointer dereference > as the parameter for the operator

Re: [PATCH 2/3] zswap: Improve a size determination in zswap_frontswap_init()

On Sun, May 21, 2017 at 4:26 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 May 2017 22:44:03 +0200 > > Replace the specification of a data structure by a pointer dereference > as the parameter for the operator "sizeof" to make the corresponding size > determination a bit

Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown

Hi, To address a tangent brought up here: On Sat, May 27, 2017 at 10:16:37AM +0200, Thomas Gleixner wrote: > On Sat, 27 May 2017, jeffy wrote: > > for example when a driver(drivers/net/wireless/marvell/mwifiex/main.c) try > > to > > do these: > > > > devm_request_irq->irq_startup->irq_enable >

Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown

Hi, To address a tangent brought up here: On Sat, May 27, 2017 at 10:16:37AM +0200, Thomas Gleixner wrote: > On Sat, 27 May 2017, jeffy wrote: > > for example when a driver(drivers/net/wireless/marvell/mwifiex/main.c) try > > to > > do these: > > > > devm_request_irq->irq_startup->irq_enable >

Re: [PATCH 1/3] zswap: Delete an error message for a failed memory allocation in zswap_pool_create()

On Sun, May 21, 2017 at 4:25 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 May 2017 22:33:21 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 6:51 PM, Alan Cox wrote: > On Tue, 30 May 2017 12:28:59 -0400 > Matt Brown wrote: > >> On 5/30/17 8:24 AM, Alan Cox wrote: >>> Look there are two problems here >>> >>> 1. TIOCSTI has users >> >> I don't see how this is a problem. > > Which is unfortunate. To start

Re: [PATCH 1/3] zswap: Delete an error message for a failed memory allocation in zswap_pool_create()

On Sun, May 21, 2017 at 4:25 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 May 2017 22:33:21 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Link: >

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 6:51 PM, Alan Cox wrote: > On Tue, 30 May 2017 12:28:59 -0400 > Matt Brown wrote: > >> On 5/30/17 8:24 AM, Alan Cox wrote: >>> Look there are two problems here >>> >>> 1. TIOCSTI has users >> >> I don't see how this is a problem. > > Which is unfortunate. To start with if it didn't

Re: [PATCH 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume

On Tue, 2017-05-30 at 15:19 -0700, Florian Fainelli wrote: > On 05/30/2017 03:08 PM, Leonard Crestez wrote: > > On Tue, 2017-05-30 at 11:05 -0700, Florian Fainelli wrote: > > > Should not we actually call kszphy_config_init() in order to restore > > > broadcast and nand disable bits as well? > >

Re: [PATCH 2/2] net: phy: micrel: Restore led_mode and clk_sel on resume

On Tue, 2017-05-30 at 15:19 -0700, Florian Fainelli wrote: > On 05/30/2017 03:08 PM, Leonard Crestez wrote: > > On Tue, 2017-05-30 at 11:05 -0700, Florian Fainelli wrote: > > > Should not we actually call kszphy_config_init() in order to restore > > > broadcast and nand disable bits as well? > >

Re: [PATCH 1/4] dt-bindings: mtk-sysirq: Correct bindings for supported SoCs

On Mon, May 22, 2017 at 11:40:18AM +0200, Matthias Brugger wrote: > All SoCs supported up to now rely on the fallback binding of mt6577. > Fix the binding description to reflect this. > > Signed-off-by: Matthias Brugger > --- >

Re: [PATCH 1/4] dt-bindings: mtk-sysirq: Correct bindings for supported SoCs

On Mon, May 22, 2017 at 11:40:18AM +0200, Matthias Brugger wrote: > All SoCs supported up to now rely on the fallback binding of mt6577. > Fix the binding description to reflect this. > > Signed-off-by: Matthias Brugger > --- > .../interrupt-controller/mediatek,sysirq.txt | 24 >

Re: [RFC 2/3] misc: Add w2sg0004 (gps receiver) power control driver

On Sun, May 21, 2017 at 12:44:03PM +0200, H. Nikolaus Schaller wrote: > Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart. > > Use serdev API hooks to monitor and forward the UART traffic to /dev/BTn > and turn on/off the module. It also detects if the module is turned on (sends

Re: [RFC 2/3] misc: Add w2sg0004 (gps receiver) power control driver

On Sun, May 21, 2017 at 12:44:03PM +0200, H. Nikolaus Schaller wrote: > Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart. > > Use serdev API hooks to monitor and forward the UART traffic to /dev/BTn > and turn on/off the module. It also detects if the module is turned on (sends

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Fri, May 26, 2017 at 04:58:20PM -0700, Jakub Kicinski wrote: > On Fri, 26 May 2017 18:47:26 -0500, Bjorn Helgaas wrote: > > On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > > > PCI core sets the driver pointer before calling ->probe() and only > > > clears it after ->remove().

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Fri, May 26, 2017 at 04:58:20PM -0700, Jakub Kicinski wrote: > On Fri, 26 May 2017 18:47:26 -0500, Bjorn Helgaas wrote: > > On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > > > PCI core sets the driver pointer before calling ->probe() and only > > > clears it after ->remove().

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

On Tue, 30 May 2017, Alan Cox wrote: > On Tue, 30 May 2017 23:29:10 +0900 > Tetsuo Handa wrote: > > > James Morris wrote: > > > On Sun, 28 May 2017, Tetsuo Handa wrote: > > > > > > > can afford enabling". And we know that we cannot merge all security > >

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head

On Tue, 30 May 2017, Alan Cox wrote: > On Tue, 30 May 2017 23:29:10 +0900 > Tetsuo Handa wrote: > > > James Morris wrote: > > > On Sun, 28 May 2017, Tetsuo Handa wrote: > > > > > > > can afford enabling". And we know that we cannot merge all security > > > > modules > > > > into mainline.

Re: [PATCH v5 08/10] x86/hyper-v: use hypercall for remote TLB flush

On Tue, 30 May 2017 19:17:46 + Jork Loeser wrote: > > -Original Message- > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > > Sent: Tuesday, May 30, 2017 09:53 > > To: Vitaly Kuznetsov > > Cc: x...@kernel.org;

Re: [PATCH v5 08/10] x86/hyper-v: use hypercall for remote TLB flush

On Tue, 30 May 2017 19:17:46 + Jork Loeser wrote: > > -Original Message- > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > > Sent: Tuesday, May 30, 2017 09:53 > > To: Vitaly Kuznetsov > > Cc: x...@kernel.org; de...@linuxdriverproject.org; linux- > >

Re: [PATCH v3] genirq: Check irq disabled & masked states in irq_shutdown

On Mon, 29 May 2017, jeffy.chen wrote: > i think if we want to make all irq enable/disable balance, maybe we can: > > 1/ only call irq_enable/disable from enable/disable_irq(change other > irq_enable/disable to enable/disable_irq), so they would be protected by the > refcnt(deph) You cannot call

Re: [PATCH v3] genirq: Check irq disabled & masked states in irq_shutdown

On Mon, 29 May 2017, jeffy.chen wrote: > i think if we want to make all irq enable/disable balance, maybe we can: > > 1/ only call irq_enable/disable from enable/disable_irq(change other > irq_enable/disable to enable/disable_irq), so they would be protected by the > refcnt(deph) You cannot call

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 4:22 PM, Daniel Micay wrote: >> Thanks, I didn't know that android was doing this. I still think this >> feature >> is worthwhile for people to be able to harden their systems against >> this attack >> vector without having to implement a MAC. > > Since there's a capable LSM hook for

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 4:22 PM, Daniel Micay wrote: >> Thanks, I didn't know that android was doing this. I still think this >> feature >> is worthwhile for people to be able to harden their systems against >> this attack >> vector without having to implement a MAC. > > Since there's a capable LSM hook for

Re: [PATCH 6/7] thermal: max77620: fix device-node reference imbalance

On 05/30/2017 09:25 AM, Johan Hovold wrote: > The thermal child device reuses the parent MFD-device device-tree node > when registering a thermal zone, but did not take a reference to the > node. > > This leads to a reference imbalance, and potential use-after-free, when > the node reference is

Re: [PATCH 6/7] thermal: max77620: fix device-node reference imbalance

On 05/30/2017 09:25 AM, Johan Hovold wrote: > The thermal child device reuses the parent MFD-device device-tree node > when registering a thermal zone, but did not take a reference to the > node. > > This leads to a reference imbalance, and potential use-after-free, when > the node reference is

<    1   2   3   4   5   6   7   8   9   10   >