[PATCH] fix infoleak in wilc_wfi_cfgoperations

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, copy the mac address to it. Signed-off-by: Kangjie Lu

[PATCH] fix infoleak in wilc_wfi_cfgoperations

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, copy the mac address to it. Signed-off-by: Kangjie Lu ---

Re: [PATCH 02/12] eeprom: at24: remove nvmem regmap dependency

On Mon, May 02, 2016 at 09:32:54AM +0200, Wolfram Sang wrote: > On Sun, Apr 24, 2016 at 08:28:06PM +0100, Srinivas Kandagatla wrote: > > This patch moves to nvmem support in the driver to use callback instead > > of regmap. > > > > Signed-off-by: Srinivas Kandagatla

Re: [PATCH 02/12] eeprom: at24: remove nvmem regmap dependency

On Mon, May 02, 2016 at 09:32:54AM +0200, Wolfram Sang wrote: > On Sun, Apr 24, 2016 at 08:28:06PM +0100, Srinivas Kandagatla wrote: > > This patch moves to nvmem support in the driver to use callback instead > > of regmap. > > > > Signed-off-by: Srinivas Kandagatla > > Andrew, since you did

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote: > > BenH and DavidM, > > Are you ok to let /proc/bus/pci/devices to expose resource value > > instead of > > BAR value? > > powerpc already expose MMIO as resource value,

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote: > > BenH and DavidM, > > Are you ok to let /proc/bus/pci/devices to expose resource value > > instead of > > BAR value? > > powerpc already expose MMIO as resource value,

Re: [PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend

On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote: > Hi, > > chunfeng yun writes: > >> chunfeng yun writes: > >> > On Thu, 2016-04-21 at 10:04 +0800, Chunfeng Yun wrote: > >> >> Click mouse after xhci suspend completion but before system

Re: [PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend

On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote: > Hi, > > chunfeng yun writes: > >> chunfeng yun writes: > >> > On Thu, 2016-04-21 at 10:04 +0800, Chunfeng Yun wrote: > >> >> Click mouse after xhci suspend completion but before system suspend > >> >> completion, system will not be waken

Linux 3.4.112

I'm announcing the release of the 3.4.112 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser:

Linux 3.4.112

I'm announcing the release of the 3.4.112 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser:

Re: [PATCH] sched/fair: Update rq clock before updating nohz cpu load

2016-05-04 3:46 GMT+08:00 Matt Fleming : > If we're accessing rq_clock() (e.g. in sched_avg_update()) we should > update the rq clock before calling cpu_load_update(), otherwise any > time calculations will be stale. > > All other paths currently call update_rq_clock(). >

Re: [PATCH] sched/fair: Update rq clock before updating nohz cpu load

2016-05-04 3:46 GMT+08:00 Matt Fleming : > If we're accessing rq_clock() (e.g. in sched_avg_update()) we should > update the rq clock before calling cpu_load_update(), otherwise any > time calculations will be stale. > > All other paths currently call update_rq_clock(). > > Cc: Peter Zijlstra >

Re: [PATCH v2 1/3] checkpatch: add Kconfig 'default n' test

On Fri, 2016-04-22 at 22:32 +0800, Yingjoe Chen wrote: > If a Kconfig config option doesn't specify 'default', the default > will be n. Adding 'default n' is unnecessary. > > Add a test to warn about this. > > Signed-off-by: Yingjoe Chen > --- > Change in v2: > -

Re: [PATCH v2 1/3] checkpatch: add Kconfig 'default n' test

On Fri, 2016-04-22 at 22:32 +0800, Yingjoe Chen wrote: > If a Kconfig config option doesn't specify 'default', the default > will be n. Adding 'default n' is unnecessary. > > Add a test to warn about this. > > Signed-off-by: Yingjoe Chen > --- > Change in v2: > - Change according to Joe

Re: [PATCH 0/2] scop GFP_NOFS api

On Sun, May 01, 2016 at 08:19:44AM +1000, NeilBrown wrote: > On Sat, Apr 30 2016, Dave Chinner wrote: > > Indeed, blocking the superblock shrinker in reclaim is a key part of > > balancing inode cache pressure in XFS. If the shrinker starts > > hitting dirty inodes, it blocks on cleaning them,

Re: [PATCH 0/2] scop GFP_NOFS api

On Sun, May 01, 2016 at 08:19:44AM +1000, NeilBrown wrote: > On Sat, Apr 30 2016, Dave Chinner wrote: > > Indeed, blocking the superblock shrinker in reclaim is a key part of > > balancing inode cache pressure in XFS. If the shrinker starts > > hitting dirty inodes, it blocks on cleaning them,

Re: [lkp] [sched/fair] 41e0d37f7a: divide error: 0000 [#1] SMP

2016-05-03 20:15 GMT+08:00 Rafael J. Wysocki : > On Tue, May 3, 2016 at 10:32 AM, Peter Zijlstra wrote: >> On Tue, May 03, 2016 at 09:10:51AM +0800, kernel test robot wrote: >>> FYI, we noticed the following commit: >>> >>>

Re: [lkp] [sched/fair] 41e0d37f7a: divide error: 0000 [#1] SMP

2016-05-03 20:15 GMT+08:00 Rafael J. Wysocki : > On Tue, May 3, 2016 at 10:32 AM, Peter Zijlstra wrote: >> On Tue, May 03, 2016 at 09:10:51AM +0800, kernel test robot wrote: >>> FYI, we noticed the following commit: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core

Re: [lkp] [sched/fair] 41e0d37f7a: divide error: 0000 [#1] SMP

2016-05-03 21:33 GMT+08:00 Rafael J. Wysocki : > On Tue, May 3, 2016 at 11:25 AM, Wanpeng Li wrote: >> 2016-05-03 17:19 GMT+08:00 Wanpeng Li : >>> 2016-05-03 16:32 GMT+08:00 Peter Zijlstra : On Tue, May 03,

Re: [lkp] [sched/fair] 41e0d37f7a: divide error: 0000 [#1] SMP

2016-05-03 21:33 GMT+08:00 Rafael J. Wysocki : > On Tue, May 3, 2016 at 11:25 AM, Wanpeng Li wrote: >> 2016-05-03 17:19 GMT+08:00 Wanpeng Li : >>> 2016-05-03 16:32 GMT+08:00 Peter Zijlstra : On Tue, May 03, 2016 at 09:10:51AM +0800, kernel test robot wrote: > FYI, we noticed the

[PATCH v4 2/3] USB: serial: cp210x: Got rid of magic numbers in CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- v4: Same series of patches, fixed names and defines by feedback. v3: Regenerated the patches correctly against the latest

[PATCH v4 2/3] USB: serial: cp210x: Got rid of magic numbers in CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- v4: Same series of patches, fixed names and defines by feedback. v3: Regenerated the patches correctly against the latest usb-next branch. v2 Improved

[PATCH v4 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- v4: Same series of patches, fixed names and defines by feedback. v3: Regenerated the

[PATCH v4 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

[PATCH v4 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- v4: Same series of patches, fixed names and defines by feedback. v3: Regenerated the patches correctly against the latest

[PATCH v4 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

Re: [RFC PATCH 0/0] VFS:userns: support portable root filesystems

On Wed, May 04, 2016 at 01:21:46AM +0200, Djalal Harouni wrote: > This RFC tries to explore how to support filesystem operations inside > user namespace using only VFS and a per mount namespace solution. This > allows to take advantage of user namespace separations without > introducing any change

Re: [RFC PATCH 0/0] VFS:userns: support portable root filesystems

On Wed, May 04, 2016 at 01:21:46AM +0200, Djalal Harouni wrote: > This RFC tries to explore how to support filesystem operations inside > user namespace using only VFS and a per mount namespace solution. This > allows to take advantage of user namespace separations without > introducing any change

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote: > BenH and DavidM, > Are you ok to let /proc/bus/pci/devices to expose resource value > instead of > BAR value? > powerpc already expose MMIO as resource value, but still keep IO as > BAR value? > > Or can we just dump /proc/bus/pci support

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote: > BenH and DavidM, > Are you ok to let /proc/bus/pci/devices to expose resource value > instead of > BAR value? > powerpc already expose MMIO as resource value, but still keep IO as > BAR value? > > Or can we just dump /proc/bus/pci support

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 2016-05-03 17:16, Dean Jenkins wrote: On 03/05/16 15:42, David B. Robins wrote: I don't think the first one is giving you problems (except as triggered by the second) but I had concerns about the second myself (and emailed the author off-list, but received no reply), and we did not take

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 2016-05-03 17:16, Dean Jenkins wrote: On 03/05/16 15:42, David B. Robins wrote: I don't think the first one is giving you problems (except as triggered by the second) but I had concerns about the second myself (and emailed the author off-list, but received no reply), and we did not take

Re: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

Hi, On 05/03/2016 07:49 PM, Mark Brown wrote: > On Tue, May 03, 2016 at 09:43:58AM +0800, Lu Baolu wrote: >> On 05/02/2016 07:00 PM, Mark Brown wrote: >>> On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote: + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS); + if (IS_ERR(gpiod))

Re: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

Hi, On 05/03/2016 07:49 PM, Mark Brown wrote: > On Tue, May 03, 2016 at 09:43:58AM +0800, Lu Baolu wrote: >> On 05/02/2016 07:00 PM, Mark Brown wrote: >>> On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote: + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS); + if (IS_ERR(gpiod))

Re: [PATCH] locking/rwsem: Add reader-owned state to the owner field

On Wed, 27 Apr 2016, Waiman Long wrote: This patch adds a new state RWSEM_READER_OWNED to the owner field to indicate that readers currently own the lock. This enables us to address the following 2 issues in the rwsem optimistic spinning code: 1) rwsem_can_spin_on_owner() will disallow

Re: [PATCH] locking/rwsem: Add reader-owned state to the owner field

On Wed, 27 Apr 2016, Waiman Long wrote: This patch adds a new state RWSEM_READER_OWNED to the owner field to indicate that readers currently own the lock. This enables us to address the following 2 issues in the rwsem optimistic spinning code: 1) rwsem_can_spin_on_owner() will disallow

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Tue, May 03, 2016 at 05:38:23PM +0200, Michal Hocko wrote: > On Sat 30-04-16 09:40:08, Dave Chinner wrote: > > On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: > [...] > > > - was it > > > "inconsistent {RECLAIM_FS-ON-[RW]} -> {IN-RECLAIM_FS-[WR]} usage" > > > or a different class

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Tue, May 03, 2016 at 05:38:23PM +0200, Michal Hocko wrote: > On Sat 30-04-16 09:40:08, Dave Chinner wrote: > > On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: > [...] > > > - was it > > > "inconsistent {RECLAIM_FS-ON-[RW]} -> {IN-RECLAIM_FS-[WR]} usage" > > > or a different class

Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

On Tue, 3 May 2016, Peter Zijlstra wrote: On Mon, Apr 25, 2016 at 02:12:09PM -0700, Vikas Shivappa wrote: start: prev_count = read_hw_counter(); I am assuming this means we keep the prev_count when event is initialized. This is done in the mbm_init which calls update_sample with

Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

On Tue, 3 May 2016, Peter Zijlstra wrote: On Mon, Apr 25, 2016 at 02:12:09PM -0700, Vikas Shivappa wrote: start: prev_count = read_hw_counter(); I am assuming this means we keep the prev_count when event is initialized. This is done in the mbm_init which calls update_sample with

[PATCH 2/2] irqchip/gic-v2m: Add workaround for Broadcom NS2 GICv2m erratum

Alex Barba discovered Broadcom NS2 GICv2m implementation has an erratum where the MSI data needs to be the SPI number subtracted by an offset of 32, for the correct MSI interrupt to be triggered. We are aware that APM X-Gene GICv2m has a similar erratum where the MSI

[PATCH 1/2] dt-bindings: arm,gic: Indtroduce optional property 'arm,msi-offset-spi' for gicv2m

Update the GICv2m binding document by adding an optional property 'arm,msi-offset-spi'. Some implementations of gicv2m have an erratum where the MSI data is the SPI number subtracted by an offset. This is required for the correct MSI interrupt to be triggered. Signed-off-by: Ray Jui

[PATCH 0/2] Add DT based gicv2m spi offset support

Alex Barba discovered Broadcom NS2 GICv2m implementation has an erratum where the MSI data needs to be the SPI number subtracted by an offset of 32, for the correct MSI interrupt to be triggered. We are aware that APM X-Gene GICv2m has a similar erratum where the MSI

[PATCH 1/2] dt-bindings: arm,gic: Indtroduce optional property 'arm,msi-offset-spi' for gicv2m

Update the GICv2m binding document by adding an optional property 'arm,msi-offset-spi'. Some implementations of gicv2m have an erratum where the MSI data is the SPI number subtracted by an offset. This is required for the correct MSI interrupt to be triggered. Signed-off-by: Ray Jui ---

[PATCH 0/2] Add DT based gicv2m spi offset support

Alex Barba discovered Broadcom NS2 GICv2m implementation has an erratum where the MSI data needs to be the SPI number subtracted by an offset of 32, for the correct MSI interrupt to be triggered. We are aware that APM X-Gene GICv2m has a similar erratum where the MSI data needs to be the

[PATCH 2/2] irqchip/gic-v2m: Add workaround for Broadcom NS2 GICv2m erratum

Alex Barba discovered Broadcom NS2 GICv2m implementation has an erratum where the MSI data needs to be the SPI number subtracted by an offset of 32, for the correct MSI interrupt to be triggered. We are aware that APM X-Gene GICv2m has a similar erratum where the MSI data needs to be the offset

Re: [PATCH 0/2] scop GFP_NOFS api

On Wed, May 04 2016, Michal Hocko wrote: > Hi, > > On Sun 01-05-16 07:55:31, NeilBrown wrote: > [...] >> One particular problem with your process-context idea is that it isn't >> inherited across threads. >> Steve Whitehouse's example in gfs shows how allocation dependencies can >> even cross

Re: [PATCH 0/2] scop GFP_NOFS api

On Wed, May 04 2016, Michal Hocko wrote: > Hi, > > On Sun 01-05-16 07:55:31, NeilBrown wrote: > [...] >> One particular problem with your process-context idea is that it isn't >> inherited across threads. >> Steve Whitehouse's example in gfs shows how allocation dependencies can >> even cross

[PATCH 2/2] i2c: qup: support SMBus block read

I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one byte. Once the message length is known

[PATCH 2/2] i2c: qup: support SMBus block read

I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one byte. Once the message length is known

[PATCH 1/2] i2c: qup: add ACPI support

Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje --- drivers/i2c/busses/i2c-qup.c | 61 +--- 1 file changed, 46 insertions(+), 15 deletions(-) diff --git

[PATCH 1/2] i2c: qup: add ACPI support

Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje --- drivers/i2c/busses/i2c-qup.c | 61 +--- 1 file changed, 46 insertions(+), 15 deletions(-) diff --git

[GIT PULL][PATCH] tracing: Don't display trigger file for events that can't be enabled

Linus, Chunyu Hu noticed that if one writes into the trigger files within the ftrace subsystem of events that it can cause an oops. This file is only writable by root, but still is a bug that needs to be fixed. Please pull the latest trace-fixes-v4.6-rc6 tree, which can be found at:

[GIT PULL][PATCH] tracing: Don't display trigger file for events that can't be enabled

Linus, Chunyu Hu noticed that if one writes into the trigger files within the ftrace subsystem of events that it can cause an oops. This file is only writable by root, but still is a bug that needs to be fixed. Please pull the latest trace-fixes-v4.6-rc6 tree, which can be found at:

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

On 05/03/2016 01:08 PM, Tero Kristo wrote: > On 03/05/16 20:49, J.D. Schroeder wrote: >> On 05/03/2016 12:32 PM, Tero Kristo wrote: >>> Personally I would not recommend using this clock for any timing sensitive >>> applications. May I ask why you are interested in the exact clock rate of >>> this

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

On 05/03/2016 01:08 PM, Tero Kristo wrote: > On 03/05/16 20:49, J.D. Schroeder wrote: >> On 05/03/2016 12:32 PM, Tero Kristo wrote: >>> Personally I would not recommend using this clock for any timing sensitive >>> applications. May I ask why you are interested in the exact clock rate of >>> this

[PATCH] igb: adjust ptp timestamps for tx/rx latency

Table 7-62 on page 338 of the i210 datasheet lists TX and RX latencies for the various speeds the chip supports. To give better ptp timestamp accuracy, adjust the timestamps by the amounts Intel gives based on current link speed. Signed-off-by: Nathan Sullivan ---

[PATCH] igb: adjust ptp timestamps for tx/rx latency

Table 7-62 on page 338 of the i210 datasheet lists TX and RX latencies for the various speeds the chip supports. To give better ptp timestamp accuracy, adjust the timestamps by the amounts Intel gives based on current link speed. Signed-off-by: Nathan Sullivan ---

[PATCH net v3 1/2] udp_tunnel: Remove redundant udp_tunnel_gro_complete().

The setting of the UDP tunnel GSO type is already performed by udp[46]_gro_complete(). Signed-off-by: Jarno Rajahalme --- drivers/net/geneve.c | 2 -- drivers/net/vxlan.c | 2 -- include/net/udp_tunnel.h | 9 - net/ipv4/fou.c | 2 -- 4 files changed, 15

[PATCH net v3 1/2] udp_tunnel: Remove redundant udp_tunnel_gro_complete().

The setting of the UDP tunnel GSO type is already performed by udp[46]_gro_complete(). Signed-off-by: Jarno Rajahalme --- drivers/net/geneve.c | 2 -- drivers/net/vxlan.c | 2 -- include/net/udp_tunnel.h | 9 - net/ipv4/fou.c | 2 -- 4 files changed, 15 deletions(-)

[PATCH net v3 2/2] udp_offload: Set encapsulation before inner completes.

UDP tunnel segmentation code relies on the inner offsets being set for an UDP tunnel GSO packet, but the inner *_complete() functions will set the inner offsets only if 'encapsulation' is set before calling them. Currently, udp_gro_complete() sets 'encapsulation' only after the inner *_complete()

[PATCH net v3 2/2] udp_offload: Set encapsulation before inner completes.

UDP tunnel segmentation code relies on the inner offsets being set for an UDP tunnel GSO packet, but the inner *_complete() functions will set the inner offsets only if 'encapsulation' is set before calling them. Currently, udp_gro_complete() sets 'encapsulation' only after the inner *_complete()

Re: [PATCH] fix infoleak in wilc_wfi_cfgoperations

On Tue, May 03, 2016 at 06:17:28PM -0400, Kangjie Lu wrote: > "mac" is an array allocated in stack without being initialized, > and will be sent out via "nla_put". The dump_station() is supposed > to initialize the mac address; otherwise, sensitive data in kernel > stack will be leaked. To fix

Re: [PATCH] fix infoleak in wilc_wfi_cfgoperations

On Tue, May 03, 2016 at 06:17:28PM -0400, Kangjie Lu wrote: > "mac" is an array allocated in stack without being initialized, > and will be sent out via "nla_put". The dump_station() is supposed > to initialize the mac address; otherwise, sensitive data in kernel > stack will be leaked. To fix

Re: [PATCH] fix infoleak in ioctl_cfg80211

On Tue, May 03, 2016 at 06:11:46PM -0400, Kangjie Lu wrote: > "mac" is an array allocated in stack without being initialized, > and will be sent out via "nla_put". The dump_station() is supposed > to initialize the mac address; otherwise, sensitive data in kernel > stack will be leaked. To fix

Re: [PATCH] fix infoleak in ioctl_cfg80211

On Tue, May 03, 2016 at 06:11:46PM -0400, Kangjie Lu wrote: > "mac" is an array allocated in stack without being initialized, > and will be sent out via "nla_put". The dump_station() is supposed > to initialize the mac address; otherwise, sensitive data in kernel > stack will be leaked. To fix

Re: [PATCH v3 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Wed, Apr 27, 2016 at 04:48:03PM +0300, Andy Shevchenko wrote: > This is combined series of two things: > - split out the Intel LPSS specific driver from 8250_pci into 8250_lpss > - enable DMA support on Intel Quark UART > > The patch has been tested on few Intel SoCs / platforms. In any case I

Re: [PATCH v3 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Wed, Apr 27, 2016 at 04:48:03PM +0300, Andy Shevchenko wrote: > This is combined series of two things: > - split out the Intel LPSS specific driver from 8250_pci into 8250_lpss > - enable DMA support on Intel Quark UART > > The patch has been tested on few Intel SoCs / platforms. In any case I

Re: [PATCH 0/6] MCB patches for v4.7

On Tue, May 03, 2016 at 10:02:57AM +0200, Johannes Thumshirn wrote: > On Tue, May 03, 2016 at 09:46:21AM +0200, Johannes Thumshirn wrote: > > Hi Greg, > > > > The following patches are the MCB updates for v4.7. These are mainly > > cleanups > > and some bug fixes from Andreas and me. The only

Re: [PATCH 0/6] MCB patches for v4.7

On Tue, May 03, 2016 at 10:02:57AM +0200, Johannes Thumshirn wrote: > On Tue, May 03, 2016 at 09:46:21AM +0200, Johannes Thumshirn wrote: > > Hi Greg, > > > > The following patches are the MCB updates for v4.7. These are mainly > > cleanups > > and some bug fixes from Andreas and me. The only

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Fri, Apr 29, 2016 at 12:19 AM, Yinghai Lu wrote: > On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote: >> >> 1) The sysfs path uses offsets between 0 and BAR size. This path >> should work identically on all arches. "User" addresses are not >>

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Fri, Apr 29, 2016 at 12:19 AM, Yinghai Lu wrote: > On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote: >> >> 1) The sysfs path uses offsets between 0 and BAR size. This path >> should work identically on all arches. "User" addresses are not >> involved, so it doesn't make sense that this

Re: [RFC PATCH] livepatch: allow removal of a disabled patch

On Tue, 3 May 2016, Josh Poimboeuf wrote: > > 1. Do we really need a completion? If I am not missing something > > kobject_del() always waits for sysfs callers to leave thanks to kernfs > > active protection. > > What do you mean by "kernfs active protection"? I see that > kernfs_remove() gets

Re: [RFC PATCH] livepatch: allow removal of a disabled patch

On Tue, 3 May 2016, Josh Poimboeuf wrote: > > 1. Do we really need a completion? If I am not missing something > > kobject_del() always waits for sysfs callers to leave thanks to kernfs > > active protection. > > What do you mean by "kernfs active protection"? I see that > kernfs_remove() gets

Re: kcompactd hang during memory offlining

On 05/03/2016 07:02 PM, Reza Arbab wrote: > Assume memory47 is the last online block left in node1. This will hang: > > # echo offline > /sys/devices/system/node/node1/memory47/state > > After a couple of minutes, the following pops up in dmesg: > > INFO: task bash:957 blocked for more than 120

Re: kcompactd hang during memory offlining

On 05/03/2016 07:02 PM, Reza Arbab wrote: > Assume memory47 is the last online block left in node1. This will hang: > > # echo offline > /sys/devices/system/node/node1/memory47/state > > After a couple of minutes, the following pops up in dmesg: > > INFO: task bash:957 blocked for more than 120

[PATCH] fix infoleak in wilc_wfi_cfgoperations

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, initialize it with memset or fill it with meaningful mac address.

[PATCH] fix infoleak in wilc_wfi_cfgoperations

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, initialize it with memset or fill it with meaningful mac address.

[PATCH] fix infoleak in ioctl_cfg80211

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, either initialize it (e.g., memset) or completely remove this

[PATCH] fix infoleak in ioctl_cfg80211

"mac" is an array allocated in stack without being initialized, and will be sent out via "nla_put". The dump_station() is supposed to initialize the mac address; otherwise, sensitive data in kernel stack will be leaked. To fix this, either initialize it (e.g., memset) or completely remove this

Re: [PATCH 01/27] coresight: no need to do the forced type conversion

On Tue, May 03, 2016 at 11:33:35AM -0600, Mathieu Poirier wrote: > From: lipengcheng That name, doesn't match: > > activated and enable are already unsigned type, > no need to change them to unsigned. > > Signed-off-by: Li Pengcheng That

Re: [PATCH 01/27] coresight: no need to do the forced type conversion

On Tue, May 03, 2016 at 11:33:35AM -0600, Mathieu Poirier wrote: > From: lipengcheng That name, doesn't match: > > activated and enable are already unsigned type, > no need to change them to unsigned. > > Signed-off-by: Li Pengcheng That name :( Please be more careful here. I'll edit this

Re: [GIT PULL for v4.6-rc1] media updates

On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann wrote: > Hi > [...] >> Mauro Carvalho Chehab (95): > [...] >> [media] use v4l2_mc_usb_media_device_init() on most USB devices > [...] > > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each > equipped

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:43 PM, Dave Hansen wrote: > On 05/03/2016 02:31 PM, Andy Lutomirski wrote: >> Having actually read the erratum: how can this affect Linux at all >> under any scenario where user code hasn't already completely >> compromised the kernel? >> >> I.e.

Re: [GIT PULL for v4.6-rc1] media updates

On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann wrote: > Hi > [...] >> Mauro Carvalho Chehab (95): > [...] >> [media] use v4l2_mc_usb_media_device_init() on most USB devices > [...] > > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each > equipped with a TeVii

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:43 PM, Dave Hansen wrote: > On 05/03/2016 02:31 PM, Andy Lutomirski wrote: >> Having actually read the erratum: how can this affect Linux at all >> under any scenario where user code hasn't already completely >> compromised the kernel? >> >> I.e. why do we care about this

Re: [GIT PULL] phy: for 4.7

On Mon, May 02, 2016 at 09:52:51AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find below the pull request for 4.7 merge window. > > It adds a new PHY driver for USB2 PHY on Northstar SoC and > reuses existing PHY drivers to add support for Broadcom NS2 > SATA3 PHY, MIPI DPHYs in

Re: [GIT PULL] phy: for 4.7

On Mon, May 02, 2016 at 09:52:51AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find below the pull request for 4.7 merge window. > > It adds a new PHY driver for USB2 PHY on Northstar SoC and > reuses existing PHY drivers to add support for Broadcom NS2 > SATA3 PHY, MIPI DPHYs in

Re: [PATCH] fix infoleak in wireless

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: [PATCH] fix infoleak in wireless

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 03, 2016 at 02:28:18PM -0700, Dave Hansen wrote: > Generally, I'm not sure we need the no$foo options at all. There's > always "clearcpuid=" which does the same thing. It just requires you to > go look up the X86_FEATURE_* bit first. Yeah, the "no-" things are all chicken bits which

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 03, 2016 at 02:28:18PM -0700, Dave Hansen wrote: > Generally, I'm not sure we need the no$foo options at all. There's > always "clearcpuid=" which does the same thing. It just requires you to > go look up the X86_FEATURE_* bit first. Yeah, the "no-" things are all chicken bits which

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:39 PM, Linus Torvalds wrote: > On Tue, May 3, 2016 at 2:31 PM, Andy Lutomirski wrote: >> >> Having actually read the erratum: how can this affect Linux at all >> under any scenario where user code hasn't already

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:39 PM, Linus Torvalds wrote: > On Tue, May 3, 2016 at 2:31 PM, Andy Lutomirski wrote: >> >> Having actually read the erratum: how can this affect Linux at all >> under any scenario where user code hasn't already completely >> compromised the kernel? > > If it matches

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/03/2016 02:31 PM, Andy Lutomirski wrote: > Having actually read the erratum: how can this affect Linux at all > under any scenario where user code hasn't already completely > compromised the kernel? > > I.e. why do we care about this erratum? First of all, with SMEP, it doesn't affect us.

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/03/2016 02:31 PM, Andy Lutomirski wrote: > Having actually read the erratum: how can this affect Linux at all > under any scenario where user code hasn't already completely > compromised the kernel? > > I.e. why do we care about this erratum? First of all, with SMEP, it doesn't affect us.

Re: [PATCH v7 18/24] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

> +static int i2c_mux_trylock_bus(struct i2c_adapter *adapter, int flags) > +{ > + struct i2c_mux_priv *priv = adapter->algo_data; > + struct i2c_adapter *parent = priv->muxc->parent; > + > + if (!rt_mutex_trylock(>mux_lock)) > + return 0; > + if (!(flags &

Re: [GIT PULL for v4.6-rc1] media updates

Hi On 2016-03-15, Mauro Carvalho Chehab wrote: [...] > The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d: > > Linux 4.5 (2016-03-13 21:28:54 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media >

Re: [PATCH v7 18/24] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

> +static int i2c_mux_trylock_bus(struct i2c_adapter *adapter, int flags) > +{ > + struct i2c_mux_priv *priv = adapter->algo_data; > + struct i2c_adapter *parent = priv->muxc->parent; > + > + if (!rt_mutex_trylock(>mux_lock)) > + return 0; > + if (!(flags &

Re: [GIT PULL for v4.6-rc1] media updates

Hi On 2016-03-15, Mauro Carvalho Chehab wrote: [...] > The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d: > > Linux 4.5 (2016-03-13 21:28:54 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media >

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