RE: [PATCH 08/15] ACPICA: Dispatcher: Update thread ID for recursive method calls

> -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, May 4, 2016 2:23 PM > To: Prarit Bhargava > Cc: Lv Zheng ; Rafael J. Wysocki > ; Rafael J.

RE: [PATCH 08/15] ACPICA: Dispatcher: Update thread ID for recursive method calls

> -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, May 4, 2016 2:23 PM > To: Prarit Bhargava > Cc: Lv Zheng ; Rafael J. Wysocki > ; Rafael J. Wysocki ; Len > Brown ; Lv Zheng ; Linux > Kernel Mailing List ;

Re: [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset

On Wed, May 04, 2016 at 11:14:50AM -0600, Stephen Warren wrote: > On 05/04/2016 08:39 AM, Thierry Reding wrote: > > From: Thierry Reding > > > > There are three EHCI controllers on Tegra SoCs, each with its own reset > > line. However, the first controller contains a set of

Re: [PATCH v3 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset

On Wed, May 04, 2016 at 11:14:50AM -0600, Stephen Warren wrote: > On 05/04/2016 08:39 AM, Thierry Reding wrote: > > From: Thierry Reding > > > > There are three EHCI controllers on Tegra SoCs, each with its own reset > > line. However, the first controller contains a set of UTMI configuration >

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c |

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c | 283 >

Re: [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

On Wed, May 04, 2016 at 11:23:20AM -0600, Stephen Warren wrote: > On 05/04/2016 08:40 AM, Thierry Reding wrote: > > From: Thierry Reding > > > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > > controls") there is a reference count for reset control

Re: [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

On Wed, May 04, 2016 at 11:23:20AM -0600, Stephen Warren wrote: > On 05/04/2016 08:40 AM, Thierry Reding wrote: > > From: Thierry Reding > > > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > > controls") there is a reference count for reset control assertions. The > >

[PATCH v2] Input: CM109: Fix handling of volume and mute buttons

The CM109 driver reported key press events of volume up / down and record / playback mute buttons, but no release events. Report those events properly by handling volume and mute keys seperately. For the record and playback mute buttons, only presses are registered by the CM109, therefore simulate

[PATCH v2] Input: CM109: Fix handling of volume and mute buttons

The CM109 driver reported key press events of volume up / down and record / playback mute buttons, but no release events. Report those events properly by handling volume and mute keys seperately. For the record and playback mute buttons, only presses are registered by the CM109, therefore simulate

Re: [PATCH] fix infoleak in llc

From: Kangjie Lu Date: Tue, 3 May 2016 16:35:05 -0400 > The stack object “info” has a total size of 12 bytes. Its last byte > is padding which is not initialized and leaked via “put_cmsg”. > > Signed-off-by: Kangjie Lu Applied.

[PATCH v9 0/9] i2c mux cleanup and locking update

Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B denotes the boundary between the

Re: [PATCH] fix infoleak in llc

From: Kangjie Lu Date: Tue, 3 May 2016 16:35:05 -0400 > The stack object “info” has a total size of 12 bytes. Its last byte > is padding which is not initialized and leaked via “put_cmsg”. > > Signed-off-by: Kangjie Lu Applied.

[PATCH v9 0/9] i2c mux cleanup and locking update

Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B denotes the boundary between the

Re: [PATCH] fix infoleak in rtnetlink

From: Kangjie Lu Date: Tue, 3 May 2016 16:46:24 -0400 > The stack object “map” has a total size of 32 bytes. Its last 4 > bytes are padding generated by compiler. These padding bytes are > not initialized and sent out via “nla_put”. > > Signed-off-by: Kangjie Lu

Re: [PATCH] fix infoleak in rtnetlink

From: Kangjie Lu Date: Tue, 3 May 2016 16:46:24 -0400 > The stack object “map” has a total size of 32 bytes. Its last 4 > bytes are padding generated by compiler. These padding bytes are > not initialized and sent out via “nla_put”. > > Signed-off-by: Kangjie Lu Applied.

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 04, 2016 at 12:49:17PM -0700, H. Peter Anvin wrote: > Sigh. Doesn't look like -Wa is going to help due to the lack of the > equivalent of an -include option in gas. So much for the register "freedom" - I'll resurrect the hardcoded insn bytes. :-\ Unless my gcc friends have some

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 04, 2016 at 12:49:17PM -0700, H. Peter Anvin wrote: > Sigh. Doesn't look like -Wa is going to help due to the lack of the > equivalent of an -include option in gas. So much for the register "freedom" - I'll resurrect the hardcoded insn bytes. :-\ Unless my gcc friends have some

Re: task_diag: add a new interface to get information about processes

I understand how reading /proc or /sys can be a bottleneck, but this proposed method using a system call is the wrong way to do this. Why not use netlink like other systems do which allows a message based response which allows for future changes (no fixed datastructures), and is message based.

[PATCH v9 1/9] i2c: allow adapter drivers to override the adapter locking

Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both

Re: task_diag: add a new interface to get information about processes

I understand how reading /proc or /sys can be a bottleneck, but this proposed method using a system call is the wrong way to do this. Why not use netlink like other systems do which allows a message based response which allows for future changes (no fixed datastructures), and is message based.

[PATCH v9 1/9] i2c: allow adapter drivers to override the adapter locking

Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both

Re: mm: pages are not freed from lru_add_pvecs after process termination

On 05/04/2016 12:41 PM, Odzioba, Lukasz wrote: > Do you see any advantages of dropping THP from pagevecs over this solution? It's a more foolproof solution. Even with this patch, there might still be some corner cases where the draining doesn't occur. That "two minutes" might be come 20 or 200

[PATCH v9 3/9] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

With a i2c topology like the following GPIO ---| -- BAT1 | v / I2C -+--+ MUX | \ EEPROM -- BAT2 there is a locking problem with the GPIO controller since it

Re: mm: pages are not freed from lru_add_pvecs after process termination

On 05/04/2016 12:41 PM, Odzioba, Lukasz wrote: > Do you see any advantages of dropping THP from pagevecs over this solution? It's a more foolproof solution. Even with this patch, there might still be some corner cases where the draining doesn't occur. That "two minutes" might be come 20 or 200

[PATCH v9 3/9] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

With a i2c topology like the following GPIO ---| -- BAT1 | v / I2C -+--+ MUX | \ EEPROM -- BAT2 there is a locking problem with the GPIO controller since it

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

On Wed, May 04, 2016 at 02:17:15PM -0500, Bin Liu wrote: > Hi, > > On Wed, May 04, 2016 at 10:02:16PM +0300, Sergei Shtylyov wrote: > > Hello. > > > > On 05/04/2016 09:56 PM, Bin Liu wrote: > > > > yes, it also works with that reset and go to finish: > > > > diff --git

[PATCH v9 5/9] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

On Wed, May 04, 2016 at 02:17:15PM -0500, Bin Liu wrote: > Hi, > > On Wed, May 04, 2016 at 10:02:16PM +0300, Sergei Shtylyov wrote: > > Hello. > > > > On 05/04/2016 09:56 PM, Bin Liu wrote: > > > > yes, it also works with that reset and go to finish: > > > > diff --git

[PATCH v9 5/9] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use

Re: [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

On Wed, May 04, 2016 at 07:22:54PM +0200, Philipp Zabel wrote: > Hi Thierry, > > Am Mittwoch, den 04.05.2016, 16:40 +0200 schrieb Thierry Reding: > > From: Thierry Reding > > > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > > controls") there is

Re: [PATCH v3 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

On Wed, May 04, 2016 at 07:22:54PM +0200, Philipp Zabel wrote: > Hi Thierry, > > Am Mittwoch, den 04.05.2016, 16:40 +0200 schrieb Thierry Reding: > > From: Thierry Reding > > > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > > controls") there is a reference count

[PATCH v9 8/9] [media] rtl2832_sdr: get rid of empty regmap wrappers

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832_sdr.c | 302 +- 1 file changed, 132 insertions(+), 170 deletions(-) diff --git

[PATCH v9 7/9] [media] rtl2832: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the regmap overrides that makes the i2c accesses unlocked and

[PATCH v9 6/9] [media] si2168: change the i2c gate to be mux-locked

From: Antti Palosaari The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the

[PATCH v9 8/9] [media] rtl2832_sdr: get rid of empty regmap wrappers

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832_sdr.c | 302 +- 1 file changed, 132 insertions(+), 170 deletions(-) diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c

[PATCH v9 7/9] [media] rtl2832: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the regmap overrides that makes the i2c accesses unlocked and

[PATCH v9 6/9] [media] si2168: change the i2c gate to be mux-locked

From: Antti Palosaari The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the i2c accesses

[PATCH v9 9/9] [media] rtl2832: regmap is aware of lockdep, drop local locking hack

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832.c | 30 -- drivers/media/dvb-frontends/rtl2832_priv.h | 1 - 2 files changed, 31

[PATCH v9 9/9] [media] rtl2832: regmap is aware of lockdep, drop local locking hack

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832.c | 30 -- drivers/media/dvb-frontends/rtl2832_priv.h | 1 - 2 files changed, 31 deletions(-) diff --git

[PATCH v9 4/9] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

Signed-off-by: Peter Rosin --- Documentation/i2c/i2c-topology | 370 + MAINTAINERS| 1 + 2 files changed, 371 insertions(+) create mode 100644 Documentation/i2c/i2c-topology diff --git

[PATCH v9 4/9] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

Signed-off-by: Peter Rosin --- Documentation/i2c/i2c-topology | 370 + MAINTAINERS| 1 + 2 files changed, 371 insertions(+) create mode 100644 Documentation/i2c/i2c-topology diff --git a/Documentation/i2c/i2c-topology

[PATCH v9 2/9] i2c: muxes always lock the parent adapter

Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin --- drivers/i2c/i2c-core.c | 21 +++-- drivers/i2c/i2c-mux.c | 30

[PATCH v9 2/9] i2c: muxes always lock the parent adapter

Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin --- drivers/i2c/i2c-core.c | 21 +++-- drivers/i2c/i2c-mux.c | 30

RE: [PATCH] ie31200_edac: add skylake support

> I verified that at least the memory sizes, ie the 'size_mb' files > are correct on the old h/w. I don't have bad dimms atm to test > the old h/w error paths though. That said this driver does get a > lot indirect testing here (just from being loaded), - so I would > likely find out if there were

RE: [PATCH] ie31200_edac: add skylake support

> I verified that at least the memory sizes, ie the 'size_mb' files > are correct on the old h/w. I don't have bad dimms atm to test > the old h/w error paths though. That said this driver does get a > lot indirect testing here (just from being loaded), - so I would > likely find out if there were

RE: [PATCH] kasan: improve double-free detection

> >> I missed that Alexander already landed patches that reduce header size > >> to 16 bytes. > >> It is not OK to increase them again. Please leave state as bitfield > >> and update it with CAS (if we introduce helper functions for state > >> manipulation, they will hide the CAS loop, which is

RE: [PATCH] kasan: improve double-free detection

> >> I missed that Alexander already landed patches that reduce header size > >> to 16 bytes. > >> It is not OK to increase them again. Please leave state as bitfield > >> and update it with CAS (if we introduce helper functions for state > >> manipulation, they will hide the CAS loop, which is

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On 04/05/16 12:56, Arnd Bergmann wrote: > On Wednesday 04 May 2016 12:36:17 Florian Fainelli wrote: >> On 03/05/16 02:57, Arnd Bergmann wrote: +static const struct pcie_cfg_data generic_cfg = { + .offsets= pcie_offsets, + .type = GENERIC, +}; >>> >>> The way

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On 04/05/16 12:56, Arnd Bergmann wrote: > On Wednesday 04 May 2016 12:36:17 Florian Fainelli wrote: >> On 03/05/16 02:57, Arnd Bergmann wrote: +static const struct pcie_cfg_data generic_cfg = { + .offsets= pcie_offsets, + .type = GENERIC, +}; >>> >>> The way

Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Even though timespec might be sufficient to represent > timeouts, use struct timespec64 here as the plan is to > get rid of all timespec reference in the kernel. > > The patch

Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Even though timespec might be sufficient to represent > timeouts, use struct timespec64 here as the plan is to > get rid of all timespec reference in the kernel. > > The patch transitions the common

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On Wednesday 04 May 2016 12:36:17 Florian Fainelli wrote: > On 03/05/16 02:57, Arnd Bergmann wrote: > >> +static const struct pcie_cfg_data generic_cfg = { > >> + .offsets= pcie_offsets, > >> + .type = GENERIC, > >> +}; > > > > The way you access the config space here seems

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On Wednesday 04 May 2016 12:36:17 Florian Fainelli wrote: > On 03/05/16 02:57, Arnd Bergmann wrote: > >> +static const struct pcie_cfg_data generic_cfg = { > >> + .offsets= pcie_offsets, > >> + .type = GENERIC, > >> +}; > > > > The way you access the config space here seems

Re: [PATCH] ARM: dts: omap5-board-common: Describe the voltage supply mapping accurately

On 05/04/2016 02:20 PM, Nishanth Menon wrote: [...] > @@ -551,6 +590,8 @@ > > ldo9_reg: ldo9 { > /* VCC_DV_SDIO: vdds_sdcard */ > + vin-supply = <_fixed>; > + There is an extra white space

Re: [PATCH] ARM: dts: omap5-board-common: Describe the voltage supply mapping accurately

On 05/04/2016 02:20 PM, Nishanth Menon wrote: [...] > @@ -551,6 +590,8 @@ > > ldo9_reg: ldo9 { > /* VCC_DV_SDIO: vdds_sdcard */ > + vin-supply = <_fixed>; > + There is an extra white space

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:41 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: >> Most likely not. It would be nice to have some more uniform solution to >> that. I'm wondering if we could use the -Wa option to load some kind of >> macro package. > > Lemme try

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:41 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: >> Most likely not. It would be nice to have some more uniform solution to >> that. I'm wondering if we could use the -Wa option to load some kind of >> macro package. > > Lemme try

Re: [PATCH 0/7] mm: Improve swap path scalability with batched operations

On Wed 04-05-16 10:13:06, Tim Chen wrote: > On Wed, 2016-05-04 at 14:45 +0200, Michal Hocko wrote: > > On Tue 03-05-16 14:00:39, Tim Chen wrote: > > [...] > > > > > >  include/linux/swap.h |  29 ++- > > >  mm/swap_state.c  | 253 +- > > >  mm/swapfile.c| 215

Re: [PATCH 0/7] mm: Improve swap path scalability with batched operations

On Wed 04-05-16 10:13:06, Tim Chen wrote: > On Wed, 2016-05-04 at 14:45 +0200, Michal Hocko wrote: > > On Tue 03-05-16 14:00:39, Tim Chen wrote: > > [...] > > > > > >  include/linux/swap.h |  29 ++- > > >  mm/swap_state.c  | 253 +- > > >  mm/swapfile.c| 215

[PATCH v3] media: fix use-after-free in cdev_put() when app exits after driver unbind

When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets a reference to it and releases it in cdev_del() ensuring that the devnode is not deallocated as long as the

Re: [PATCH v4 3/7] phy: Add set_mode callback

On 05/04/2016 01:39 PM, Bin Liu wrote: Have you already tested this? I never tried changing mode via sysfs, but by quickly reviewing the code, I am wondering how it works. the core only calls ops->set_mode() but nothing else. To really switch the mode, the driver has to talk to the root hub,

[PATCH v3] media: fix use-after-free in cdev_put() when app exits after driver unbind

When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets a reference to it and releases it in cdev_del() ensuring that the devnode is not deallocated as long as the

Re: [PATCH v4 3/7] phy: Add set_mode callback

On 05/04/2016 01:39 PM, Bin Liu wrote: Have you already tested this? I never tried changing mode via sysfs, but by quickly reviewing the code, I am wondering how it works. the core only calls ops->set_mode() but nothing else. To really switch the mode, the driver has to talk to the root hub,

Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

On Wed, May 04, 2016 at 03:09:27PM +0200, Krzysztof Hałasa wrote: > Bjorn Helgaas writes: > > > It looks like 498a92d42596 merely fixed a warning, at the expense of > > breaking DMA on Cavium. Reverting it would bring the warning back, but > > that's better than broken DMA.

Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

On Wed, May 04, 2016 at 03:09:27PM +0200, Krzysztof Hałasa wrote: > Bjorn Helgaas writes: > > > It looks like 498a92d42596 merely fixed a warning, at the expense of > > breaking DMA on Cavium. Reverting it would bring the warning back, but > > that's better than broken DMA. > > Perhaps we

RE: mm: pages are not freed from lru_add_pvecs after process termination

On Thu 02-05-16 03:00:00, Michal Hocko wrote: > So I have given this a try (not tested yet) and it doesn't look terribly > complicated. It is hijacking vmstat for a purpose it wasn't intended for > originally but creating a dedicated kenrnel threads/WQ sounds like an > overkill to me. Does this

RE: mm: pages are not freed from lru_add_pvecs after process termination

On Thu 02-05-16 03:00:00, Michal Hocko wrote: > So I have given this a try (not tested yet) and it doesn't look terribly > complicated. It is hijacking vmstat for a purpose it wasn't intended for > originally but creating a dedicated kenrnel threads/WQ sounds like an > overkill to me. Does this

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

On Thu 05-05-16 00:45:45, Joonsoo Kim wrote: > 2016-05-05 0:30 GMT+09:00 Joonsoo Kim : > > 2016-05-04 18:21 GMT+09:00 Michal Hocko : > >> On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: > >>> On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > >>> > On

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

On Thu 05-05-16 00:45:45, Joonsoo Kim wrote: > 2016-05-05 0:30 GMT+09:00 Joonsoo Kim : > > 2016-05-04 18:21 GMT+09:00 Michal Hocko : > >> On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: > >>> On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > >>> > On Tue 03-05-16 14:23:04, Joonsoo Kim

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: > Most likely not. It would be nice to have some more uniform solution to > that. I'm wondering if we could use the -Wa option to load some kind of > macro package. Lemme try out some old compilers first, I'm guessing 3.2 won't

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: > Most likely not. It would be nice to have some more uniform solution to > that. I'm wondering if we could use the -Wa option to load some kind of > macro package. Lemme try out some old compilers first, I'm guessing 3.2 won't

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

On Thu 05-05-16 00:30:35, Joonsoo Kim wrote: > 2016-05-04 18:21 GMT+09:00 Michal Hocko : [...] > > Do we really consume 512B of stack during reclaim. That sounds more than > > worrying to me. > > Hmm...I checked it by ./script/stackusage and result is as below. > >

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

On Thu 05-05-16 00:30:35, Joonsoo Kim wrote: > 2016-05-04 18:21 GMT+09:00 Michal Hocko : [...] > > Do we really consume 512B of stack during reclaim. That sounds more than > > worrying to me. > > Hmm...I checked it by ./script/stackusage and result is as below. > > shrink_zone() 128 >

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On 03/05/16 02:57, Arnd Bergmann wrote: >> +static const struct pcie_cfg_data generic_cfg = { >> +.offsets= pcie_offsets, >> +.type = GENERIC, >> +}; > > The way you access the config space here seems very indirect. I'd > suggest instead writing two sets of pci_ops, with

Re: [PATCH 2/2] pci: host: Add Broadcom STB PCIE RC controller

On 03/05/16 02:57, Arnd Bergmann wrote: >> +static const struct pcie_cfg_data generic_cfg = { >> +.offsets= pcie_offsets, >> +.type = GENERIC, >> +}; > > The way you access the config space here seems very indirect. I'd > suggest instead writing two sets of pci_ops, with

Re: ftrace use of pci_resource_to_user()

On Wed, 4 May 2016 14:17:13 -0500 Bjorn Helgaas wrote: > 138295373ccf ("ftrace: mmiotrace update, #2") added this use of > pci_resource_to_user(): > > +static int mmio_print_pcidev(struct trace_seq *s, const struct pci_dev > *dev) > +{ > ... > + /* > +

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:31 PM, Brian Gerst wrote: >> >> - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) >> -: "="REG_OUT (res) >> -: REG_IN (w)); >> + if (likely(static_cpu_has(X86_FEATURE_POPCNT))) { >> + asm

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:31 PM, Brian Gerst wrote: >> >> - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) >> -: "="REG_OUT (res) >> -: REG_IN (w)); >> + if (likely(static_cpu_has(X86_FEATURE_POPCNT))) { >> + asm

Re: ftrace use of pci_resource_to_user()

On Wed, 4 May 2016 14:17:13 -0500 Bjorn Helgaas wrote: > 138295373ccf ("ftrace: mmiotrace update, #2") added this use of > pci_resource_to_user(): > > +static int mmio_print_pcidev(struct trace_seq *s, const struct pci_dev > *dev) > +{ > ... > + /* > +* XXX: is

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 4, 2016 at 2:46 PM, Borislav Petkov wrote: > On Thu, Apr 07, 2016 at 11:43:33AM +0200, Borislav Petkov wrote: >> I guess we can do something like this: >> >>if (likely(static_cpu_has(X86_FEATURE_POPCNT))) >>asm volatile(POPCNT32 >>

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On Wed, May 4, 2016 at 2:46 PM, Borislav Petkov wrote: > On Thu, Apr 07, 2016 at 11:43:33AM +0200, Borislav Petkov wrote: >> I guess we can do something like this: >> >>if (likely(static_cpu_has(X86_FEATURE_POPCNT))) >>asm volatile(POPCNT32 >> :

[PATCH v1 2/2] dmaengine: rename cmd_pause to cmd_suspend

Rename cmd_pause to cmd_suspend to be clear that latter capability reflects pause AND resume. Signed-off-by: Andy Shevchenko --- drivers/dma/dmaengine.c | 4 ++-- drivers/tty/serial/8250/8250_dma.c| 2 +- include/linux/dmaengine.h

[PATCH v1 2/2] dmaengine: rename cmd_pause to cmd_suspend

Rename cmd_pause to cmd_suspend to be clear that latter capability reflects pause AND resume. Signed-off-by: Andy Shevchenko --- drivers/dma/dmaengine.c | 4 ++-- drivers/tty/serial/8250/8250_dma.c| 2 +- include/linux/dmaengine.h | 4 ++--

[PATCH v1 0/2] dmaengine: urgent fix to prevent regression in UART

There are two patches, first of which is an urgent fix to prevent a regression when UART driver can't acquire DMA channel due to DMA engine which doesn't support DMA_CYCLIC. Andy Shevchenko (2): dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC dmaengine: rename cmd_pause to

[PATCH v1 0/2] dmaengine: urgent fix to prevent regression in UART

There are two patches, first of which is an urgent fix to prevent a regression when UART driver can't acquire DMA channel due to DMA engine which doesn't support DMA_CYCLIC. Andy Shevchenko (2): dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC dmaengine: rename cmd_pause to

[PATCH v1 1/2] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

When check for capabilities recognize slave support by eother DMA_SLAVE or DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked DMA support for engines that doesn't have one of the mentioned bits set. Signed-off-by: Andy Shevchenko ---

[PATCH v1 1/2] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

When check for capabilities recognize slave support by eother DMA_SLAVE or DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked DMA support for engines that doesn't have one of the mentioned bits set. Signed-off-by: Andy Shevchenko --- drivers/dma/dmaengine.c | 4 ++-- 1

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

Hi On 2016-05-04, Linus Torvalds wrote: > On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote: > > > > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx > > aren't needed/ loaded on my system) crude revert avoids the problem for > > me on

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

Hi On 2016-05-04, Linus Torvalds wrote: > On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote: > > > > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx > > aren't needed/ loaded on my system) crude revert avoids the problem for > > me on v4.6-rc6-113-g83858a7.

[RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

struct timespec is not y2038 safe. Even though timespec might be sufficient to represent timeouts, use struct timespec64 here as the plan is to get rid of all timespec reference in the kernel. The patch transitions the common functions: poll_select_set_timeout() and select_estimate_accuracy() to

[RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

struct timespec is not y2038 safe. Even though timespec might be sufficient to represent timeouts, use struct timespec64 here as the plan is to get rid of all timespec reference in the kernel. The patch transitions the common functions: poll_select_set_timeout() and select_estimate_accuracy() to

[PATCH -v2 0/4] random: replace urandom pool with a CRNG

By using a CRNG to replace the urandom pool, we address a number of complaints which Stephan Mueller has been concerned about. We now use a much more aggressive interrupt sampling system to quickly initialize a CRNG which gets used in place of the original non-blocking pool. This tends to get

[PATCH 4/4] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o --- drivers/char/random.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 897c75e..028d085 100644 --- a/drivers/char/random.c +++

[PATCH -v2 0/4] random: replace urandom pool with a CRNG

By using a CRNG to replace the urandom pool, we address a number of complaints which Stephan Mueller has been concerned about. We now use a much more aggressive interrupt sampling system to quickly initialize a CRNG which gets used in place of the original non-blocking pool. This tends to get

[PATCH 4/4] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o --- drivers/char/random.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 897c75e..028d085 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@

[PATCH 3/4] random: add interrupt callback to VMBus IRQ handler

From: Stephan Mueller The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy

[PATCH 3/4] random: add interrupt callback to VMBus IRQ handler

From: Stephan Mueller The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy collector is not

[PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o --- crypto/chacha20_generic.c | 61 -- drivers/char/random.c | 283 +++--- include/crypto/chacha20.h | 1 +

[PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o --- crypto/chacha20_generic.c | 61 -- drivers/char/random.c | 283 +++--- include/crypto/chacha20.h | 1 + lib/Makefile

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