Re: [PATCH v3] writeback: safer lock nesting

[Michal Hocko]

On Tue 10-04-18 13:48:37, Andrew Morton wrote:
> On Tue, 10 Apr 2018 08:33:57 +0200 Michal Hocko  wrote:
> 
> > > Reported-by: Wang Long 
> > > Signed-off-by: Greg Thelen 
> > > Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613
> > 
> > Not a stable material IMHO
> 
> Why's that?  Wang Long said he's observed the deadlock three times?

I thought it is just too unlikely to hit all the conditions. My fault,
I have completely missed/forgot the fact Wang Long is seeing the issue
happening.

No real objection for the stable backport from me.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3] writeback: safer lock nesting

[Michal Hocko]

On Tue 10-04-18 13:48:37, Andrew Morton wrote:
> On Tue, 10 Apr 2018 08:33:57 +0200 Michal Hocko  wrote:
> 
> > > Reported-by: Wang Long 
> > > Signed-off-by: Greg Thelen 
> > > Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613
> > 
> > Not a stable material IMHO
> 
> Why's that?  Wang Long said he's observed the deadlock three times?

I thought it is just too unlikely to hit all the conditions. My fault,
I have completely missed/forgot the fact Wang Long is seeing the issue
happening.

No real objection for the stable backport from me.

-- 
Michal Hocko
SUSE Labs

Re: KMSAN: uninit-value in tipc_subscrb_rcv_cb

[syzbot]

syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=75e6e042c5bbf691fc82


So far this crash happened 3 times on  
https://github.com/google/kmsan.git/master.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6676653019234304
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5693411524870144
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5043527943716864
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+75e6e042c5bbf691f...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

==
BUG: KMSAN: uninit-value in htohl net/tipc/subscr.c:66 [inline]
BUG: KMSAN: uninit-value in tipc_subscrb_rcv_cb+0x418/0xe80  
net/tipc/subscr.c:339

CPU: 0 PID: 19 Comm: kworker/u4:1 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: tipc_rcv tipc_recv_work
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 htohl net/tipc/subscr.c:66 [inline]
 tipc_subscrb_rcv_cb+0x418/0xe80 net/tipc/subscr.c:339
 tipc_receive_from_sock+0x64c/0x800 net/tipc/server.c:271
 tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
 tipc_receive_from_sock+0x15c/0x800 net/tipc/server.c:253
 tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406
==

Re: KMSAN: uninit-value in tipc_subscrb_rcv_cb

[syzbot]

syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=75e6e042c5bbf691fc82


So far this crash happened 3 times on  
https://github.com/google/kmsan.git/master.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6676653019234304
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5693411524870144
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5043527943716864
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+75e6e042c5bbf691f...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

==
BUG: KMSAN: uninit-value in htohl net/tipc/subscr.c:66 [inline]
BUG: KMSAN: uninit-value in tipc_subscrb_rcv_cb+0x418/0xe80  
net/tipc/subscr.c:339

CPU: 0 PID: 19 Comm: kworker/u4:1 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: tipc_rcv tipc_recv_work
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 htohl net/tipc/subscr.c:66 [inline]
 tipc_subscrb_rcv_cb+0x418/0xe80 net/tipc/subscr.c:339
 tipc_receive_from_sock+0x64c/0x800 net/tipc/server.c:271
 tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 kmem_cache_alloc+0xaab/0xb90 mm/slub.c:2756
 tipc_receive_from_sock+0x15c/0x800 net/tipc/server.c:253
 tipc_recv_work+0xd8/0x1f0 net/tipc/server.c:618
 process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2113
 worker_thread+0x113c/0x24f0 kernel/workqueue.c:2247
 kthread+0x539/0x720 kernel/kthread.c:239
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:406
==

Re: [PATCH v2 00/14] chrome_laptop: stop being a platform driver

[Benson Leung]

Hi Dmitry,

On Tue, Mar 20, 2018 at 03:31:24PM -0700, Dmitry Torokhov wrote:
> Hi,
> 
> This series is a combination of Atmel touchscreen driver stopping using
> platform data and moving over to generic device properties, and
> chromeos-laptop switching from being platform driver, which is the wrong
> abstraction for it, and moving to using i2c bis notifier. Switching from
> platform driver to the notifiers allows us to get rid of the ugly code that
> manually tries to handle deferrals in case i2c bus is not ready at the time
> we start initializing the module.
> 
> Thanks!

This series is in next now. I will roll up a pull request for v4.17 soon.

Thanks!
Benson

> 
> Changes v1->v2:
> 
> - switched suspend mode handling to use DMI quirk. We'll clean it up properly
>   in the Atmel driver later, for now we just want to untangle Atmel and
>   chromeos-laptop
> 
> - added Nick's Acks.
> 
> Dmitry Torokhov (14):
>   Input: atmel_mxt_ts - do not pass suspend mode in platform data
>   Input: atmel_mxt_ts - switch from OF to generic device properties
>   Input: atmel_mxt_ts - switch ChromeOS ACPI devices to generic props
>   platform/chrome: chromeos_laptop - add SPDX identifier
>   platform/chrome: chromeos_laptop - stop setting suspend mode for Atmel 
> devices
>   platform/chrome: chromeos_laptop - introduce pr_fmt()
>   platform/chrome: chromeos_laptop - factor out getting IRQ from DMI
>   platform/chrome: chromeos_laptop - rework i2c peripherals initialization
>   platform/chrome: chromeos_laptop - parse DMI IRQ data once
>   platform/chrome: chromeos_laptop - use I2C notifier to create devices
>   platform/chrome: chromeos_laptop - rely on I2C to set up interrupt trigger
>   platform/chrome: chromeos_laptop - use device properties for Pixel
>   platform/chrome: chromeos_laptop - discard data for unneeded boards
>   Input: atmel_mxt_ts - remove platform data support
> 
>  MAINTAINERS|   1 -
>  drivers/input/touchscreen/atmel_mxt_ts.c   | 231 +++---
>  drivers/platform/chrome/chromeos_laptop.c  | 896 +++--
>  include/linux/platform_data/atmel_mxt_ts.h |  31 -
>  4 files changed, 579 insertions(+), 580 deletions(-)
>  delete mode 100644 include/linux/platform_data/atmel_mxt_ts.h
> 
> -- 
> Dmitry

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 00/14] chrome_laptop: stop being a platform driver

[Benson Leung]

Hi Dmitry,

On Tue, Mar 20, 2018 at 03:31:24PM -0700, Dmitry Torokhov wrote:
> Hi,
> 
> This series is a combination of Atmel touchscreen driver stopping using
> platform data and moving over to generic device properties, and
> chromeos-laptop switching from being platform driver, which is the wrong
> abstraction for it, and moving to using i2c bis notifier. Switching from
> platform driver to the notifiers allows us to get rid of the ugly code that
> manually tries to handle deferrals in case i2c bus is not ready at the time
> we start initializing the module.
> 
> Thanks!

This series is in next now. I will roll up a pull request for v4.17 soon.

Thanks!
Benson

> 
> Changes v1->v2:
> 
> - switched suspend mode handling to use DMI quirk. We'll clean it up properly
>   in the Atmel driver later, for now we just want to untangle Atmel and
>   chromeos-laptop
> 
> - added Nick's Acks.
> 
> Dmitry Torokhov (14):
>   Input: atmel_mxt_ts - do not pass suspend mode in platform data
>   Input: atmel_mxt_ts - switch from OF to generic device properties
>   Input: atmel_mxt_ts - switch ChromeOS ACPI devices to generic props
>   platform/chrome: chromeos_laptop - add SPDX identifier
>   platform/chrome: chromeos_laptop - stop setting suspend mode for Atmel 
> devices
>   platform/chrome: chromeos_laptop - introduce pr_fmt()
>   platform/chrome: chromeos_laptop - factor out getting IRQ from DMI
>   platform/chrome: chromeos_laptop - rework i2c peripherals initialization
>   platform/chrome: chromeos_laptop - parse DMI IRQ data once
>   platform/chrome: chromeos_laptop - use I2C notifier to create devices
>   platform/chrome: chromeos_laptop - rely on I2C to set up interrupt trigger
>   platform/chrome: chromeos_laptop - use device properties for Pixel
>   platform/chrome: chromeos_laptop - discard data for unneeded boards
>   Input: atmel_mxt_ts - remove platform data support
> 
>  MAINTAINERS|   1 -
>  drivers/input/touchscreen/atmel_mxt_ts.c   | 231 +++---
>  drivers/platform/chrome/chromeos_laptop.c  | 896 +++--
>  include/linux/platform_data/atmel_mxt_ts.h |  31 -
>  4 files changed, 579 insertions(+), 580 deletions(-)
>  delete mode 100644 include/linux/platform_data/atmel_mxt_ts.h
> 
> -- 
> Dmitry

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

[Jan Kiszka]

On 2018-04-05 23:12, Rob Herring wrote:
> On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand  wrote:
>> On 04/05/18 12:13, Jan Kiszka wrote:
>>> On 2018-04-05 20:59, Frank Rowand wrote:
 Hi Jan,

 On 04/04/18 15:35, Jan Kiszka wrote:
> Hi Frank,
>
> On 2018-03-04 01:17, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>>
>> Move duplicating and unflattening of an overlay flattened devicetree
>> (FDT) into the overlay application code.  To accomplish this,
>> of_overlay_apply() is replaced by of_overlay_fdt_apply().
>>
>> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
>> code, which is thus responsible for freeing the duplicate FDT.  The
>> caller of of_overlay_fdt_apply() remains responsible for freeing the
>> original FDT.
>>
>> The unflattened devicetree now belongs to devicetree code, which is
>> thus responsible for freeing the unflattened devicetree.
>>
>> These ownership changes prevent early freeing of the duplicated FDT
>> or the unflattened devicetree, which could result in use after free
>> errors.
>>
>> of_overlay_fdt_apply() is a private function for the anticipated
>> overlay loader.
>
> We are using of_fdt_unflatten_tree + of_overlay_apply in the
> (out-of-tree) Jailhouse loader driver in order to register a virtual
> device during hypervisor activation with Linux. The DT overlay is
> created from a a template but modified prior to application to account
> for runtime-specific parameters. See [1] for the current implementation.
>
> I'm now wondering how to model that scenario best with the new API.
> Given that the loader lost ownership of the unflattened tree but the
> modification API exist only for the that DT state, I'm not yet seeing a
> clear solution. Should we apply the template in disabled form (status =
> "disabled"), modify it, and then activate it while it is already applied?

 Thank you for the pointer to the driver - that makes it much easier to
 understand the use case and consider solutions.

 If you can make the changes directly on the FDT instead of on the
 expanded devicetree, then you could move to the new API.
>>>
>>> Are there some examples/references on how to edit FDTs in-place in the
>>> kernel? I'd like to avoid writing the n-th FDT parser/generator.
>>
>> I don't know of any existing in-kernel edits of the FDT (but they might
>> exist).  The functions to access an FDT are in libfdt, which is in
>> scripts/dtc/libfdt/.
> 
> Let's please not go down that route of doing FDT modifications. There
> is little reason to other than for early boot changes. And it is much
> easier to work on unflattened trees.

I just briefly looked into libfdt, and it would have meant building it
into the module as there are no library functions exported by the kernel
either. Another reason to drop that.

What's apparently working now is the pattern I initially suggested:
Register template with status = "disabled" as overlay, then prepare and
apply changeset that contains all needed modifications and sets the
status to "ok". I might be leaking additional resources, but to find
that out, I will now finally have to resolve clean unbinding of the
generic PCI host controller [1] first.

Thanks,
Jan

[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

[Jan Kiszka]

On 2018-04-05 23:12, Rob Herring wrote:
> On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand  wrote:
>> On 04/05/18 12:13, Jan Kiszka wrote:
>>> On 2018-04-05 20:59, Frank Rowand wrote:
 Hi Jan,

 On 04/04/18 15:35, Jan Kiszka wrote:
> Hi Frank,
>
> On 2018-03-04 01:17, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>>
>> Move duplicating and unflattening of an overlay flattened devicetree
>> (FDT) into the overlay application code.  To accomplish this,
>> of_overlay_apply() is replaced by of_overlay_fdt_apply().
>>
>> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
>> code, which is thus responsible for freeing the duplicate FDT.  The
>> caller of of_overlay_fdt_apply() remains responsible for freeing the
>> original FDT.
>>
>> The unflattened devicetree now belongs to devicetree code, which is
>> thus responsible for freeing the unflattened devicetree.
>>
>> These ownership changes prevent early freeing of the duplicated FDT
>> or the unflattened devicetree, which could result in use after free
>> errors.
>>
>> of_overlay_fdt_apply() is a private function for the anticipated
>> overlay loader.
>
> We are using of_fdt_unflatten_tree + of_overlay_apply in the
> (out-of-tree) Jailhouse loader driver in order to register a virtual
> device during hypervisor activation with Linux. The DT overlay is
> created from a a template but modified prior to application to account
> for runtime-specific parameters. See [1] for the current implementation.
>
> I'm now wondering how to model that scenario best with the new API.
> Given that the loader lost ownership of the unflattened tree but the
> modification API exist only for the that DT state, I'm not yet seeing a
> clear solution. Should we apply the template in disabled form (status =
> "disabled"), modify it, and then activate it while it is already applied?

 Thank you for the pointer to the driver - that makes it much easier to
 understand the use case and consider solutions.

 If you can make the changes directly on the FDT instead of on the
 expanded devicetree, then you could move to the new API.
>>>
>>> Are there some examples/references on how to edit FDTs in-place in the
>>> kernel? I'd like to avoid writing the n-th FDT parser/generator.
>>
>> I don't know of any existing in-kernel edits of the FDT (but they might
>> exist).  The functions to access an FDT are in libfdt, which is in
>> scripts/dtc/libfdt/.
> 
> Let's please not go down that route of doing FDT modifications. There
> is little reason to other than for early boot changes. And it is much
> easier to work on unflattened trees.

I just briefly looked into libfdt, and it would have meant building it
into the module as there are no library functions exported by the kernel
either. Another reason to drop that.

What's apparently working now is the pattern I initially suggested:
Register template with status = "disabled" as overlay, then prepare and
apply changeset that contains all needed modifications and sets the
status to "ok". I might be leaking additional resources, but to find
that out, I will now finally have to resolve clean unbinding of the
generic PCI host controller [1] first.

Thanks,
Jan

[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html

[GIT PULL] Immutable branch between MFD and Platform due for the v4.17 merge window

[Benson Leung]

Hi Lee,

Please take a look at this IB that incorporates v4 of Enric's cros_ec debugfs
and sysfs series.

Thanks!
Benson

The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274:

  Linux 4.16-rc7 (2018-03-25 12:44:30 -1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
ib-chrome-platform-cros-ec-sysfs-debugfs-for-v4.17

for you to fetch changes up to c1d1e91aff3d1183d6b16a282c2575e3e006cee4:

  platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid 
angle (2018-04-10 22:25:07 -0700)


Enric Balletbo i Serra (3):
  platform/chrome: cros_ec_sysfs: introduce to_cros_ec_dev define.
  platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR 
variants
  platform/chrome: cros_ec_debugfs: Use octal permissions '0444'

Gwendal Grignou (2):
  platform/chrome: cros_ec_sysfs: Modify error handling
  platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake 
lid angle

Shawn Nematbakhsh (1):
  platform/chrome: cros_ec_debugfs: Add PD port info to debugfs

 drivers/mfd/cros_ec_dev.c |  31 +++
 drivers/platform/chrome/cros_ec_debugfs.c |  76 +++-
 drivers/platform/chrome/cros_ec_sysfs.c   | 141 +-
 include/linux/mfd/cros_ec.h   |   2 +
 include/linux/mfd/cros_ec_commands.h  |   3 +
 5 files changed, 194 insertions(+), 59 deletions(-)


-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[GIT PULL] Immutable branch between MFD and Platform due for the v4.17 merge window

[Benson Leung]

Hi Lee,

Please take a look at this IB that incorporates v4 of Enric's cros_ec debugfs
and sysfs series.

Thanks!
Benson

The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274:

  Linux 4.16-rc7 (2018-03-25 12:44:30 -1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
ib-chrome-platform-cros-ec-sysfs-debugfs-for-v4.17

for you to fetch changes up to c1d1e91aff3d1183d6b16a282c2575e3e006cee4:

  platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid 
angle (2018-04-10 22:25:07 -0700)


Enric Balletbo i Serra (3):
  platform/chrome: cros_ec_sysfs: introduce to_cros_ec_dev define.
  platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR 
variants
  platform/chrome: cros_ec_debugfs: Use octal permissions '0444'

Gwendal Grignou (2):
  platform/chrome: cros_ec_sysfs: Modify error handling
  platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake 
lid angle

Shawn Nematbakhsh (1):
  platform/chrome: cros_ec_debugfs: Add PD port info to debugfs

 drivers/mfd/cros_ec_dev.c |  31 +++
 drivers/platform/chrome/cros_ec_debugfs.c |  76 +++-
 drivers/platform/chrome/cros_ec_sysfs.c   | 141 +-
 include/linux/mfd/cros_ec.h   |   2 +
 include/linux/mfd/cros_ec_commands.h  |   3 +
 5 files changed, 194 insertions(+), 59 deletions(-)


-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

[Phil Reid]

On 11/04/2018 09:51, Jia-Ju Bai wrote:

b53_switch_reset_gpio() is never called in atomic context.

The call chain ending up at b53_switch_reset_gpio() is:
[1] b53_switch_reset_gpio() <- b53_switch_reset() <-
b53_reset_switch() <- b53_setup()

b53_switch_reset_gpio() is set as ".setup" in struct dsa_switch_ops.
This function is not called in atomic context.

Despite never getting called from atomic context, b53_switch_reset_gpio()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/dsa/b53/b53_common.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 274f367..e070ff6 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -597,10 +597,10 @@ static void b53_switch_reset_gpio(struct b53_device *dev)
/* Reset sequence: RESET low(50ms)->high(20ms)
 */
gpio_set_value(gpio, 0);
-   mdelay(50);
+   msleep(50);
  
  	gpio_set_value(gpio, 1);

-   mdelay(20);
+   msleep(20);
  
  	dev->current_page = 0xff;

  }


Would that also imply gpio_set_value could be gpio_set_value_cansleep?


--
Regards
Phil Reid

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

[Phil Reid]

On 11/04/2018 09:51, Jia-Ju Bai wrote:

b53_switch_reset_gpio() is never called in atomic context.

The call chain ending up at b53_switch_reset_gpio() is:
[1] b53_switch_reset_gpio() <- b53_switch_reset() <-
b53_reset_switch() <- b53_setup()

b53_switch_reset_gpio() is set as ".setup" in struct dsa_switch_ops.
This function is not called in atomic context.

Despite never getting called from atomic context, b53_switch_reset_gpio()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/dsa/b53/b53_common.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 274f367..e070ff6 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -597,10 +597,10 @@ static void b53_switch_reset_gpio(struct b53_device *dev)
/* Reset sequence: RESET low(50ms)->high(20ms)
 */
gpio_set_value(gpio, 0);
-   mdelay(50);
+   msleep(50);
  
  	gpio_set_value(gpio, 1);

-   mdelay(20);
+   msleep(20);
  
  	dev->current_page = 0xff;

  }


Would that also imply gpio_set_value could be gpio_set_value_cansleep?


--
Regards
Phil Reid

[GIT PULL] apparmor updates for v4.17

[John Johansen]

Hi,


Please pull these apparmor changes for v4.17

Thanks!

- John

The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:

  Linux 4.15 (2018-01-28 13:20:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor 
tags/apparmor-pr-2018-04-10

for you to fetch changes up to 588558eb6d0e0b6edfa65a67e906c2ffeba63ff1:

  apparmor: fix memory leak on buffer on error exit path (2018-03-30 21:14:04 
-0700)


+ Features
  - add base infrastructure for socket mediation. ABI bump and
additional checks to ensure only v8 compliant policy uses
socket af mediation.
  - improve and cleanup dfa verification
  - improve profile attachment logic
- improve overlapping expression handling
- add the xattr matching to the attachment logic
  - improve signal mediation handling with stacked labels
  - improve handling of no_new_privs in a label stack

+ Cleanups and changes
  - use dfa to parse string split
  - bounded version of label_parse
  - proper line wrap nulldfa.in
  - split context out into task and cred naming to better match usage
  - simplify code in aafs

+ Bug fixes
  - fix display of .ns_name for containers
  - fix resource audit messages when auditing peer
  - fix logging of the existence test for signals
  - fix resource audit messages when auditing peer
  - fix display of .ns_name for containers
  - fix an error code in verify_table_headers()
  - fix memory leak on buffer on error exit path
  - fix error returns checks by making size a ssize_t


Colin Ian King (2):
  apparmor: fix error returns checks by making size a ssize_t
  apparmor: fix memory leak on buffer on error exit path

Dan Carpenter (1):
  apparmor: Fix an error code in verify_table_headers()

John Johansen (31):
  apparmor: fix display of .ns_name for containers
  apparmor: fix resource audit messages when auditing peer
  apparmor: fix logging of the existence test for signals
  apparmor: split load data into management struct and data blob
  apparmor: add first substr match to dfa
  apparmor: use the dfa to do label parse string splitting
  apparmor: provide a bounded version of label_parse
  apparmor: cleanup add proper line wrapping to nulldfa.in
  apparmor: root view labels should not be under user control
  apparmor: make signal label match work when matching stacked labels
  apparmor: audit unknown signal numbers
  apparmor: rename task_ctx to the more accurate cred_ctx
  apparmor: move task domain change info to task security
  apparmor: drop cred_ctx and reference the label directly
  apparmor: rename tctx to ctx
  apparmor: cleanup fixup description of aa_replace_profiles
  apparmor: cleanup, drop unused fn __aa_task_is_confined()
  apparmor: move task related defines and fns to task.X files
  apparmor: move context.h to cred.h
  apparmor: update domain transitions that are subsets of confinement at nnp
  apparmor: dfa move character match into a macro
  apparmor: dfa add support for state differential encoding
  apparmor: dfa split verification of table headers
  apparmor: cleanup create_aafs() error path
  apparmor: cleanup: simplify code to get ns symlink name
  apparmor: convert attaching profiles via xattrs to use dfa matching
  apparmor: improve overlapping domain attachment resolution
  apparmor: add base infastructure for socket mediation
  apparmor: remove POLICY_MEDIATES_SAFE
  apparmor: update MAINTAINERS file git and wiki locations
  apparmor: fix dangling symlinks to policy rawdata after replacement

Matthew Garrett (1):
  apparmor: Add support for attaching profiles via xattr, presence and value

Pravin Shedge (1):
  security: apparmor: remove duplicate includes

 MAINTAINERS |   4 +-
 security/apparmor/.gitignore|   1 +
 security/apparmor/Makefile  |  45 ++-
 security/apparmor/apparmorfs.c  | 203 ++
 security/apparmor/capability.c  |   2 +-
 security/apparmor/domain.c  | 355 +-
 security/apparmor/file.c|  32 +-
 security/apparmor/include/apparmor.h|   3 +-
 security/apparmor/include/audit.h   |  19 +-
 security/apparmor/include/{context.h => cred.h} |  63 +---
 security/apparmor/include/label.h   |  28 ++
 security/apparmor/include/match.h   |  28 ++
 security/apparmor/include/net.h | 106 ++
 security/apparmor/include/perms.h   |   5 +-
 security/apparmor/include/policy.h  |  23 +-
 security/apparmor/include/policy_unpack.h   |   2 +-
 security/apparmor/include/sig_names.h   |   5 +-
 

[GIT PULL] apparmor updates for v4.17

[John Johansen]

Hi,


Please pull these apparmor changes for v4.17

Thanks!

- John

The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:

  Linux 4.15 (2018-01-28 13:20:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor 
tags/apparmor-pr-2018-04-10

for you to fetch changes up to 588558eb6d0e0b6edfa65a67e906c2ffeba63ff1:

  apparmor: fix memory leak on buffer on error exit path (2018-03-30 21:14:04 
-0700)


+ Features
  - add base infrastructure for socket mediation. ABI bump and
additional checks to ensure only v8 compliant policy uses
socket af mediation.
  - improve and cleanup dfa verification
  - improve profile attachment logic
- improve overlapping expression handling
- add the xattr matching to the attachment logic
  - improve signal mediation handling with stacked labels
  - improve handling of no_new_privs in a label stack

+ Cleanups and changes
  - use dfa to parse string split
  - bounded version of label_parse
  - proper line wrap nulldfa.in
  - split context out into task and cred naming to better match usage
  - simplify code in aafs

+ Bug fixes
  - fix display of .ns_name for containers
  - fix resource audit messages when auditing peer
  - fix logging of the existence test for signals
  - fix resource audit messages when auditing peer
  - fix display of .ns_name for containers
  - fix an error code in verify_table_headers()
  - fix memory leak on buffer on error exit path
  - fix error returns checks by making size a ssize_t


Colin Ian King (2):
  apparmor: fix error returns checks by making size a ssize_t
  apparmor: fix memory leak on buffer on error exit path

Dan Carpenter (1):
  apparmor: Fix an error code in verify_table_headers()

John Johansen (31):
  apparmor: fix display of .ns_name for containers
  apparmor: fix resource audit messages when auditing peer
  apparmor: fix logging of the existence test for signals
  apparmor: split load data into management struct and data blob
  apparmor: add first substr match to dfa
  apparmor: use the dfa to do label parse string splitting
  apparmor: provide a bounded version of label_parse
  apparmor: cleanup add proper line wrapping to nulldfa.in
  apparmor: root view labels should not be under user control
  apparmor: make signal label match work when matching stacked labels
  apparmor: audit unknown signal numbers
  apparmor: rename task_ctx to the more accurate cred_ctx
  apparmor: move task domain change info to task security
  apparmor: drop cred_ctx and reference the label directly
  apparmor: rename tctx to ctx
  apparmor: cleanup fixup description of aa_replace_profiles
  apparmor: cleanup, drop unused fn __aa_task_is_confined()
  apparmor: move task related defines and fns to task.X files
  apparmor: move context.h to cred.h
  apparmor: update domain transitions that are subsets of confinement at nnp
  apparmor: dfa move character match into a macro
  apparmor: dfa add support for state differential encoding
  apparmor: dfa split verification of table headers
  apparmor: cleanup create_aafs() error path
  apparmor: cleanup: simplify code to get ns symlink name
  apparmor: convert attaching profiles via xattrs to use dfa matching
  apparmor: improve overlapping domain attachment resolution
  apparmor: add base infastructure for socket mediation
  apparmor: remove POLICY_MEDIATES_SAFE
  apparmor: update MAINTAINERS file git and wiki locations
  apparmor: fix dangling symlinks to policy rawdata after replacement

Matthew Garrett (1):
  apparmor: Add support for attaching profiles via xattr, presence and value

Pravin Shedge (1):
  security: apparmor: remove duplicate includes

 MAINTAINERS |   4 +-
 security/apparmor/.gitignore|   1 +
 security/apparmor/Makefile  |  45 ++-
 security/apparmor/apparmorfs.c  | 203 ++
 security/apparmor/capability.c  |   2 +-
 security/apparmor/domain.c  | 355 +-
 security/apparmor/file.c|  32 +-
 security/apparmor/include/apparmor.h|   3 +-
 security/apparmor/include/audit.h   |  19 +-
 security/apparmor/include/{context.h => cred.h} |  63 +---
 security/apparmor/include/label.h   |  28 ++
 security/apparmor/include/match.h   |  28 ++
 security/apparmor/include/net.h | 106 ++
 security/apparmor/include/perms.h   |   5 +-
 security/apparmor/include/policy.h  |  23 +-
 security/apparmor/include/policy_unpack.h   |   2 +-
 security/apparmor/include/sig_names.h   |   5 +-
 

[PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

[Matheus Castello]

To keep driver up to date we add generic pinctrl binding support, which covers
the features used in this driver and has additional node properties that this
SoC has compatibility, so enabling future implementations of these properties
without the need to create new node properties in the device trees.

The logic of this change maintain the old brcm legacy binding support in order
to keep the ABI stable.

Signed-off-by: Matheus Castello 
---

A brief explanation of what I did:

Add pinconf-generic header for use the defines and pinctrl-generic API.

Add dt-bindings pinctrl bcm2835 header to use functions selections and
pulls definitions, which functions definitions where duplicated in the
enum bcm2835_fsel, I removed the duplicate defines from enum.

In the bcm2835_pctl_dt_node_to_map_pull I used the generic macro for
pack the legacy param and arguments, since it will be unpacked along with
generic properties that is packed with this same macro.

In bcm2835_pctl_dt_node_to_map I thougt it was better, and simpler, to use
pinctrl-generic parse code instead of parsing it inside the driver, so code
first check for generic binding parse, if something is parsed then it is
assumed that are using the new generic style, and when nothing is found then
parse continues to search for legacy properties.

In the bcm2835_pinconf_set was changed the unpack legacy by the generic, and
was added a switch for the parameter tests, since pinctrl generic uses 3
properties to define the states of the pull instead of one with arguments, that
was the reason too that bcm2835_pull_config_set function was added, for reuse
the code that set state of pull.

 drivers/pinctrl/bcm/Kconfig   |  1 +
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 87 ++-
 2 files changed, 55 insertions(+), 33 deletions(-)

diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index e8c4e4f..0f38d51 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -20,6 +20,7 @@ config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
+   select GENERIC_PINCONF
select GPIOLIB_IRQCHIP

 config PINCTRL_IPROC_GPIO
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 785c366..010c565 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -36,11 +36,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 

 #define MODULE_NAME "pinctrl-bcm2835"
 #define BCM2835_NUM_GPIOS 54
@@ -75,10 +77,6 @@ enum bcm2835_pinconf_param {
BCM2835_PINCONF_PARAM_PULL,
 };

-#define BCM2835_PINCONF_PACK(_param_, _arg_) ((_param_) << 16 | (_arg_))
-#define BCM2835_PINCONF_UNPACK_PARAM(_conf_) ((_conf_) >> 16)
-#define BCM2835_PINCONF_UNPACK_ARG(_conf_) ((_conf_) & 0x)
-
 struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
@@ -213,14 +211,6 @@ static const char * const bcm2835_gpio_groups[] = {
 };

 enum bcm2835_fsel {
-   BCM2835_FSEL_GPIO_IN = 0,
-   BCM2835_FSEL_GPIO_OUT = 1,
-   BCM2835_FSEL_ALT0 = 4,
-   BCM2835_FSEL_ALT1 = 5,
-   BCM2835_FSEL_ALT2 = 6,
-   BCM2835_FSEL_ALT3 = 7,
-   BCM2835_FSEL_ALT4 = 3,
-   BCM2835_FSEL_ALT5 = 2,
BCM2835_FSEL_COUNT = 8,
BCM2835_FSEL_MASK = 0x7,
 };
@@ -714,7 +704,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
bcm2835_pinctrl *pc,
configs = kzalloc(sizeof(*configs), GFP_KERNEL);
if (!configs)
return -ENOMEM;
-   configs[0] = BCM2835_PINCONF_PACK(BCM2835_PINCONF_PARAM_PULL, pull);
+   configs[0] = pinconf_to_config_packed(BCM2835_PINCONF_PARAM_PULL, pull);

map->type = PIN_MAP_TYPE_CONFIGS_PIN;
map->data.configs.group_or_pin = bcm2835_gpio_pins[pin].name;
@@ -736,6 +726,12 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
*pctldev,
int i, err;
u32 pin, func, pull;

+   /* Check for generic binding in this node */
+   err = pinconf_generic_dt_node_to_map_all(pctldev, np, map, num_maps);
+   if (err || *num_maps)
+   return err;
+
+   /* Generic binding did not find anything continue with legacy parse */
pins = of_find_property(np, "brcm,pins", NULL);
if (!pins) {
dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
@@ -917,37 +913,62 @@ static int bcm2835_pinconf_get(struct pinctrl_dev 
*pctldev,
return -ENOTSUPP;
 }

+static void bcm2835_pull_config_set(struct bcm2835_pinctrl *pc,
+   unsigned pin, unsigned arg)
+{
+   u32 off, bit;
+
+   off = GPIO_REG_OFFSET(pin);
+   bit = GPIO_REG_SHIFT(pin);
+
+   bcm2835_gpio_wr(pc, GPPUD, arg & 3);
+   /*
+   * BCM2835 datasheet say to wait 150 cycles, but not of what.
+   * But the VideoCore firmware delay for this operation
+   * based nearly on 

[PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

[Matheus Castello]

To keep driver up to date we add generic pinctrl binding support, which covers
the features used in this driver and has additional node properties that this
SoC has compatibility, so enabling future implementations of these properties
without the need to create new node properties in the device trees.

The logic of this change maintain the old brcm legacy binding support in order
to keep the ABI stable.

Signed-off-by: Matheus Castello 
---

A brief explanation of what I did:

Add pinconf-generic header for use the defines and pinctrl-generic API.

Add dt-bindings pinctrl bcm2835 header to use functions selections and
pulls definitions, which functions definitions where duplicated in the
enum bcm2835_fsel, I removed the duplicate defines from enum.

In the bcm2835_pctl_dt_node_to_map_pull I used the generic macro for
pack the legacy param and arguments, since it will be unpacked along with
generic properties that is packed with this same macro.

In bcm2835_pctl_dt_node_to_map I thougt it was better, and simpler, to use
pinctrl-generic parse code instead of parsing it inside the driver, so code
first check for generic binding parse, if something is parsed then it is
assumed that are using the new generic style, and when nothing is found then
parse continues to search for legacy properties.

In the bcm2835_pinconf_set was changed the unpack legacy by the generic, and
was added a switch for the parameter tests, since pinctrl generic uses 3
properties to define the states of the pull instead of one with arguments, that
was the reason too that bcm2835_pull_config_set function was added, for reuse
the code that set state of pull.

 drivers/pinctrl/bcm/Kconfig   |  1 +
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 87 ++-
 2 files changed, 55 insertions(+), 33 deletions(-)

diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index e8c4e4f..0f38d51 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -20,6 +20,7 @@ config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
+   select GENERIC_PINCONF
select GPIOLIB_IRQCHIP

 config PINCTRL_IPROC_GPIO
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 785c366..010c565 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -36,11 +36,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 

 #define MODULE_NAME "pinctrl-bcm2835"
 #define BCM2835_NUM_GPIOS 54
@@ -75,10 +77,6 @@ enum bcm2835_pinconf_param {
BCM2835_PINCONF_PARAM_PULL,
 };

-#define BCM2835_PINCONF_PACK(_param_, _arg_) ((_param_) << 16 | (_arg_))
-#define BCM2835_PINCONF_UNPACK_PARAM(_conf_) ((_conf_) >> 16)
-#define BCM2835_PINCONF_UNPACK_ARG(_conf_) ((_conf_) & 0x)
-
 struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
@@ -213,14 +211,6 @@ static const char * const bcm2835_gpio_groups[] = {
 };

 enum bcm2835_fsel {
-   BCM2835_FSEL_GPIO_IN = 0,
-   BCM2835_FSEL_GPIO_OUT = 1,
-   BCM2835_FSEL_ALT0 = 4,
-   BCM2835_FSEL_ALT1 = 5,
-   BCM2835_FSEL_ALT2 = 6,
-   BCM2835_FSEL_ALT3 = 7,
-   BCM2835_FSEL_ALT4 = 3,
-   BCM2835_FSEL_ALT5 = 2,
BCM2835_FSEL_COUNT = 8,
BCM2835_FSEL_MASK = 0x7,
 };
@@ -714,7 +704,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
bcm2835_pinctrl *pc,
configs = kzalloc(sizeof(*configs), GFP_KERNEL);
if (!configs)
return -ENOMEM;
-   configs[0] = BCM2835_PINCONF_PACK(BCM2835_PINCONF_PARAM_PULL, pull);
+   configs[0] = pinconf_to_config_packed(BCM2835_PINCONF_PARAM_PULL, pull);

map->type = PIN_MAP_TYPE_CONFIGS_PIN;
map->data.configs.group_or_pin = bcm2835_gpio_pins[pin].name;
@@ -736,6 +726,12 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
*pctldev,
int i, err;
u32 pin, func, pull;

+   /* Check for generic binding in this node */
+   err = pinconf_generic_dt_node_to_map_all(pctldev, np, map, num_maps);
+   if (err || *num_maps)
+   return err;
+
+   /* Generic binding did not find anything continue with legacy parse */
pins = of_find_property(np, "brcm,pins", NULL);
if (!pins) {
dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
@@ -917,37 +913,62 @@ static int bcm2835_pinconf_get(struct pinctrl_dev 
*pctldev,
return -ENOTSUPP;
 }

+static void bcm2835_pull_config_set(struct bcm2835_pinctrl *pc,
+   unsigned pin, unsigned arg)
+{
+   u32 off, bit;
+
+   off = GPIO_REG_OFFSET(pin);
+   bit = GPIO_REG_SHIFT(pin);
+
+   bcm2835_gpio_wr(pc, GPPUD, arg & 3);
+   /*
+   * BCM2835 datasheet say to wait 150 cycles, but not of what.
+   * But the VideoCore firmware delay for this operation
+   * based nearly on the same amount of VPU 

[PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

[Matheus Castello]

Properties to set initial value of pin output buffer.
This can be useful for configure hardware in overlay files, and in early boot
for checking it states in QA sanity tests.

Signed-off-by: Matheus Castello 
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 010c565..28acd06 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -965,6 +965,11 @@ static int bcm2835_pinconf_set(struct pinctrl_dev *pctldev,
bcm2835_pull_config_set(pc, pin, BCM2835_PUD_UP);
break;

+   /* Set output-high or output-low */
+   case PIN_CONFIG_OUTPUT:
+   bcm2835_gpio_set_bit(pc, arg ? GPSET0 : GPCLR0, pin);
+   break;
+
default:
return -EINVAL;

--
2.7.4

[PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

[Matheus Castello]

Properties to set initial value of pin output buffer.
This can be useful for configure hardware in overlay files, and in early boot
for checking it states in QA sanity tests.

Signed-off-by: Matheus Castello 
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 010c565..28acd06 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -965,6 +965,11 @@ static int bcm2835_pinconf_set(struct pinctrl_dev *pctldev,
bcm2835_pull_config_set(pc, pin, BCM2835_PUD_UP);
break;

+   /* Set output-high or output-low */
+   case PIN_CONFIG_OUTPUT:
+   bcm2835_gpio_set_bit(pc, arg ? GPSET0 : GPCLR0, pin);
+   break;
+
default:
return -EINVAL;

--
2.7.4

[PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

[Matheus Castello]

Added generic pin configuration and multiplexing support,
and should be preferred than brcm legacy one.

Signed-off-by: Matheus Castello 
---
 .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 2569866..51fe305 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -36,6 +36,24 @@ listed. In other words, a subnode that lists only a mux 
function implies no
 information about any pull configuration. Similarly, a subnode that lists only
 a pul parameter implies no information about the mux function.

+The BCM2835 pin configuration and multiplexing supports the generic bindings.
+For details on each properties, you can refer to ./pinctrl-bindings.txt.
+
+Required sub-node properties:
+  - pins
+  - function
+
+Optional sub-node properties:
+  - bias-disable
+  - bias-pull-up
+  - bias-pull-down
+  - output-high
+  - output-low
+
+Legacy pin configuration and multiplexing binding:
+*** (Its use is deprecated, use generic multiplexing and configuration
+bindings instead)
+
 Required subnode-properties:
 - brcm,pins: An array of cells. Each cell contains the ID of a pin. Valid IDs
   are the integer GPIO IDs; 0==GPIO0, 1==GPIO1, ... 53==GPIO53.
--
2.7.4

[PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

[Matheus Castello]

Added generic pin configuration and multiplexing support,
and should be preferred than brcm legacy one.

Signed-off-by: Matheus Castello 
---
 .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 2569866..51fe305 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -36,6 +36,24 @@ listed. In other words, a subnode that lists only a mux 
function implies no
 information about any pull configuration. Similarly, a subnode that lists only
 a pul parameter implies no information about the mux function.

+The BCM2835 pin configuration and multiplexing supports the generic bindings.
+For details on each properties, you can refer to ./pinctrl-bindings.txt.
+
+Required sub-node properties:
+  - pins
+  - function
+
+Optional sub-node properties:
+  - bias-disable
+  - bias-pull-up
+  - bias-pull-down
+  - output-high
+  - output-low
+
+Legacy pin configuration and multiplexing binding:
+*** (Its use is deprecated, use generic multiplexing and configuration
+bindings instead)
+
 Required subnode-properties:
 - brcm,pins: An array of cells. Each cell contains the ID of a pin. Valid IDs
   are the integer GPIO IDs; 0==GPIO0, 1==GPIO1, ... 53==GPIO53.
--
2.7.4

Re: [PATCH v5 0/3] pinctrl: bcm2835: Add generic pinctrl support

[Matheus Castello]

This series adds support for generic binding for pinctrl bcm2835 driver,
and add the code for set output buffer of a pin using the output-low and
output-high generic properties.

Tested on Raspberry Pi Zero W, based on bcm2835 SoC.

Changes since v4:
(Suggested by Rob Herring)
- Change dt-bindings docs driver reference to hardware in case the BCM2835 pin
configuration and multiplexing

Changes since v3:
(Suggested by Stefan Wahren)
- Change dt-bindings docs patch order and subject

Changes since v2:
(Suggested by Eric Anholt)
- Remove PACK and UNPACK macros
- Use pinconf_to_config_* functions
(Suggested by Stefan Wahren)
- Fold Kconfig changes with the driver changes in a single patch
- Add devicetree bindings documentations about generic properties support
- Add devicetree bindings maintainers

Matheus Castello (3):
  dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support
  pinctrl: bcm2835: Add support for generic pinctrl binding
  pinctrl: bcm2835: Add support for output-low output-high properties

 .../bindings/pinctrl/brcm,bcm2835-gpio.txt | 18 +
 drivers/pinctrl/bcm/Kconfig|  1 +
 drivers/pinctrl/bcm/pinctrl-bcm2835.c  | 92 ++
 3 files changed, 78 insertions(+), 33 deletions(-)

--
2.7.4

Re: [PATCH v5 0/3] pinctrl: bcm2835: Add generic pinctrl support

[Matheus Castello]

This series adds support for generic binding for pinctrl bcm2835 driver,
and add the code for set output buffer of a pin using the output-low and
output-high generic properties.

Tested on Raspberry Pi Zero W, based on bcm2835 SoC.

Changes since v4:
(Suggested by Rob Herring)
- Change dt-bindings docs driver reference to hardware in case the BCM2835 pin
configuration and multiplexing

Changes since v3:
(Suggested by Stefan Wahren)
- Change dt-bindings docs patch order and subject

Changes since v2:
(Suggested by Eric Anholt)
- Remove PACK and UNPACK macros
- Use pinconf_to_config_* functions
(Suggested by Stefan Wahren)
- Fold Kconfig changes with the driver changes in a single patch
- Add devicetree bindings documentations about generic properties support
- Add devicetree bindings maintainers

Matheus Castello (3):
  dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support
  pinctrl: bcm2835: Add support for generic pinctrl binding
  pinctrl: bcm2835: Add support for output-low output-high properties

 .../bindings/pinctrl/brcm,bcm2835-gpio.txt | 18 +
 drivers/pinctrl/bcm/Kconfig|  1 +
 drivers/pinctrl/bcm/pinctrl-bcm2835.c  | 92 ++
 3 files changed, 78 insertions(+), 33 deletions(-)

--
2.7.4

[PATCH] sched/fair: remove stale comments about tg_unthrottle_up

[Li RongQing]

After commit 82958366cfea ("sched: Replace update_shares weight
distribution with per-entity computation"), tg_unthrottle_up
did not update the weight

Signed-off-by: Li RongQing 
---
 kernel/sched/fair.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0951d1c58d2f..b885ed6fd97b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4703,7 +4703,6 @@ static inline int throttled_lb_pair(struct task_group *tg,
   throttled_hierarchy(dest_cfs_rq);
 }
 
-/* updated child weight may affect parent so we have to do this bottom up */
 static int tg_unthrottle_up(struct task_group *tg, void *data)
 {
struct rq *rq = data;
-- 
2.11.0

[PATCH] sched/fair: remove stale comments about tg_unthrottle_up

[Li RongQing]

After commit 82958366cfea ("sched: Replace update_shares weight
distribution with per-entity computation"), tg_unthrottle_up
did not update the weight

Signed-off-by: Li RongQing 
---
 kernel/sched/fair.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0951d1c58d2f..b885ed6fd97b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4703,7 +4703,6 @@ static inline int throttled_lb_pair(struct task_group *tg,
   throttled_hierarchy(dest_cfs_rq);
 }
 
-/* updated child weight may affect parent so we have to do this bottom up */
 static int tg_unthrottle_up(struct task_group *tg, void *data)
 {
struct rq *rq = data;
-- 
2.11.0

[PATCH] dt-bindings: pinctrl: sunxi: Fix reference to driver

[Matheus Castello]

Bindings describe hardware, not drivers.
Use reference to hardware Allwinner A1X Pin Controller instead driver.

Signed-off-by: Matheus Castello 
---
 .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index ed5eb54..c854cf0 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -56,9 +56,9 @@ pins it needs, and how they should be configured, with regard 
to muxer
 configuration, drive strength and pullups. If one of these options is
 not set, its actual value will be unspecified.

-This driver supports the generic pin multiplexing and configuration
-bindings. For details on each properties, you can refer to
-./pinctrl-bindings.txt.
+Allwinner A1X Pin Controller supports the generic pin multiplexing and
+configuration bindings. For details on each properties, you can refer to
+ ./pinctrl-bindings.txt.

 Required sub-node properties:
   - pins
--
2.7.4

[PATCH] dt-bindings: pinctrl: sunxi: Fix reference to driver

[Matheus Castello]

Bindings describe hardware, not drivers.
Use reference to hardware Allwinner A1X Pin Controller instead driver.

Signed-off-by: Matheus Castello 
---
 .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index ed5eb54..c854cf0 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -56,9 +56,9 @@ pins it needs, and how they should be configured, with regard 
to muxer
 configuration, drive strength and pullups. If one of these options is
 not set, its actual value will be unspecified.

-This driver supports the generic pin multiplexing and configuration
-bindings. For details on each properties, you can refer to
-./pinctrl-bindings.txt.
+Allwinner A1X Pin Controller supports the generic pin multiplexing and
+configuration bindings. For details on each properties, you can refer to
+ ./pinctrl-bindings.txt.

 Required sub-node properties:
   - pins
--
2.7.4

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Vivek Gautam]

Hi Yisheng,


On 4/11/2018 6:52 AM, Yisheng Xie wrote:

Hi Tomasz,

On 2018/4/10 21:14, Tomasz Figa wrote:

Hi Yisheng,

Sorry, I think we missed your question here.

On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie  wrote:


Hi Vivek,
On 2018/3/28 12:37, Vivek Gautam wrote:

Hi Yisheng


On 3/28/2018 6:54 AM, Yisheng Xie wrote:

Hi Vivek,

On 2018/3/13 16:55, Vivek Gautam wrote:

+- power-domains:  Specifiers for power domains required to be

powered on for

+  the SMMU to operate, as per generic power domain

bindings.

+

In this patchset, power-domains is not used right? And you just do the

clock gating,

but not power gating, right?

We are handling the power-domains too. Please see the example in this

binding doc.


I see, but I do not find the point in code of these patchset, do you mean

PMIC(e.g mmcc)

will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC

suspend?


If respective SoC power domains is registered as a standard genpd PM
domain, then the runtime PM subsystem will take care of power domain
control at runtime suspend and resume.


Get it, thanks for your explain, I should have learned about this.


Sorry, i missed your subsequent question, and Tomasz has explained it now.
Let me know if you have further questions.

regards
Vivek


Thanks
Yisheng


Best regards,
Tomasz

.


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Vivek Gautam]

Hi Yisheng,


On 4/11/2018 6:52 AM, Yisheng Xie wrote:

Hi Tomasz,

On 2018/4/10 21:14, Tomasz Figa wrote:

Hi Yisheng,

Sorry, I think we missed your question here.

On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie  wrote:


Hi Vivek,
On 2018/3/28 12:37, Vivek Gautam wrote:

Hi Yisheng


On 3/28/2018 6:54 AM, Yisheng Xie wrote:

Hi Vivek,

On 2018/3/13 16:55, Vivek Gautam wrote:

+- power-domains:  Specifiers for power domains required to be

powered on for

+  the SMMU to operate, as per generic power domain

bindings.

+

In this patchset, power-domains is not used right? And you just do the

clock gating,

but not power gating, right?

We are handling the power-domains too. Please see the example in this

binding doc.


I see, but I do not find the point in code of these patchset, do you mean

PMIC(e.g mmcc)

will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC

suspend?


If respective SoC power domains is registered as a standard genpd PM
domain, then the runtime PM subsystem will take care of power domain
control at runtime suspend and resume.


Get it, thanks for your explain, I should have learned about this.


Sorry, i missed your subsequent question, and Tomasz has explained it now.
Let me know if you have further questions.

regards
Vivek


Thanks
Yisheng


Best regards,
Tomasz

.


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

[Julia Lawall]

On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote:

> Fix most checkpatch.pl issues of type:
>
> CHECK: Alignment should match open parenthesis
>
> Signed-off-by: Gabriel Francisco Mandaji 
> ---
>  drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c 
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
> index fdd81c3..631a703 100644
> --- a/drivers/staging/comedi/drivers/cb_pcidas64.c
> +++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
> @@ -2268,14 +2268,14 @@ static inline unsigned int dma_transfer_size(struct 
> comedi_device *dev)
>  }
>
>  static u32 ai_convert_counter_6xxx(const struct comedi_device *dev,
> - const struct comedi_cmd *cmd)
> +const struct comedi_cmd *cmd)

Someone has made the effort to put const on these parameters, but not on
the other similar functions.  Perhaps this can be improved as well.

julia

>  {
>   /* supposed to load counter with desired divisor minus 3 */
>   return cmd->convert_arg / TIMER_BASE - 3;
>  }
>
>  static u32 ai_scan_counter_6xxx(struct comedi_device *dev,
> -  struct comedi_cmd *cmd)
> + struct comedi_cmd *cmd)
>  {
>   u32 count;
>
> @@ -2296,7 +2296,7 @@ static u32 ai_scan_counter_6xxx(struct comedi_device 
> *dev,
>  }
>
>  static u32 ai_convert_counter_4020(struct comedi_device *dev,
> - struct comedi_cmd *cmd)
> +struct comedi_cmd *cmd)
>  {
>   struct pcidas64_private *devpriv = dev->private;
>   unsigned int divisor;
> --
> 1.9.1
>
>

Re: [PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

[Julia Lawall]

On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote:

> Fix most checkpatch.pl issues of type:
>
> CHECK: Alignment should match open parenthesis
>
> Signed-off-by: Gabriel Francisco Mandaji 
> ---
>  drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c 
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
> index fdd81c3..631a703 100644
> --- a/drivers/staging/comedi/drivers/cb_pcidas64.c
> +++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
> @@ -2268,14 +2268,14 @@ static inline unsigned int dma_transfer_size(struct 
> comedi_device *dev)
>  }
>
>  static u32 ai_convert_counter_6xxx(const struct comedi_device *dev,
> - const struct comedi_cmd *cmd)
> +const struct comedi_cmd *cmd)

Someone has made the effort to put const on these parameters, but not on
the other similar functions.  Perhaps this can be improved as well.

julia

>  {
>   /* supposed to load counter with desired divisor minus 3 */
>   return cmd->convert_arg / TIMER_BASE - 3;
>  }
>
>  static u32 ai_scan_counter_6xxx(struct comedi_device *dev,
> -  struct comedi_cmd *cmd)
> + struct comedi_cmd *cmd)
>  {
>   u32 count;
>
> @@ -2296,7 +2296,7 @@ static u32 ai_scan_counter_6xxx(struct comedi_device 
> *dev,
>  }
>
>  static u32 ai_convert_counter_4020(struct comedi_device *dev,
> - struct comedi_cmd *cmd)
> +struct comedi_cmd *cmd)
>  {
>   struct pcidas64_private *devpriv = dev->private;
>   unsigned int divisor;
> --
> 1.9.1
>
>

Re: AMD graphics performance regression in 4.15 and later

[Gabriel C]

>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different* 
> storry.
>

Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver
are broken now in this one.

radeon tells:

...

[6.337838] [drm] PCIE GART of 2048M enabled (table at 0x001D6000).
[6.338210] radeon :21:00.0: (-12) create WB bo failed
[6.338214] radeon :21:00.0: disabling GPU acceleration

...

And no way to start X .. flickering and hangs.

amdgpu hits an bug:

http://ftp.frugalware.org/pub/other/people/crazy/trace.txt


Do you have some git tree I can test from ?

Also if you need full , logs or any other infos just  let me know.

Regards

Re: AMD graphics performance regression in 4.15 and later

[Gabriel C]

>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different* 
> storry.
>

Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver
are broken now in this one.

radeon tells:

...

[6.337838] [drm] PCIE GART of 2048M enabled (table at 0x001D6000).
[6.338210] radeon :21:00.0: (-12) create WB bo failed
[6.338214] radeon :21:00.0: disabling GPU acceleration

...

And no way to start X .. flickering and hangs.

amdgpu hits an bug:

http://ftp.frugalware.org/pub/other/people/crazy/trace.txt


Do you have some git tree I can test from ?

Also if you need full , logs or any other infos just  let me know.

Regards

Re: [PATCH v3 2/4] gpio: pca953x: add register definitions for pcal6524 and fix address calculation

[H. Nikolaus Schaller]

Hi Andy,

> Am 10.04.2018 um 20:06 schrieb Andy Shevchenko :
> 
> On Tue, Apr 10, 2018 at 7:07 PM, H. Nikolaus Schaller  
> wrote:
>> PCAL chips ("L" seems to stand for "latched") have additional
>> registers starting at address 0x40 to control the latches,
>> interrupt mask, pull-up and pull down etc.
>> 
>> The constants are so far defined in a way that they fit for
>> the pcal9555a when shifted by the number of banks, i.e. multiplied
>> by 2.
>> 
>> Now the pcal6524 has 3 banks which means the relative offset
>> must be multiplied by 4 which gives a wrong result if not done
>> carefully, since the base offset is already included in the offset.
>> 
>> For the basic registers shared with all pca93xx/tca64xx chips
>> there is no such offset.
>> 
>> Therefore, we add code to adjust the register number for exended
>> registers to the 24 bit accessor functions.
>> 
>> And we add additional register offset constants (not yet used by
>> the driver code) which are specific to the pcal6524.
>> 
> 
> First of all, as I said, please split this to two patches. Don't mix the 
> things.

Ok. Queued for v4.

> 
> 
>> +   /* adjust register address for pcal6524 */
>> +   if (reg >= PCAL953X_OUT_STRENGTH)
>> +   reg -= PCAL953X_OUT_STRENGTH >> 1;
>> +
> 
> Give me some days to think about it.

No problem. I'll wait with v4.

The only alternative I would see is to add new accessor function
pointers for the extended registers and have 0x00 based offsets,
but that is IMHO more ugly.

BR and thanks,
Nikolaus

Re: [PATCH v3 2/4] gpio: pca953x: add register definitions for pcal6524 and fix address calculation

[H. Nikolaus Schaller]

Hi Andy,

> Am 10.04.2018 um 20:06 schrieb Andy Shevchenko :
> 
> On Tue, Apr 10, 2018 at 7:07 PM, H. Nikolaus Schaller  
> wrote:
>> PCAL chips ("L" seems to stand for "latched") have additional
>> registers starting at address 0x40 to control the latches,
>> interrupt mask, pull-up and pull down etc.
>> 
>> The constants are so far defined in a way that they fit for
>> the pcal9555a when shifted by the number of banks, i.e. multiplied
>> by 2.
>> 
>> Now the pcal6524 has 3 banks which means the relative offset
>> must be multiplied by 4 which gives a wrong result if not done
>> carefully, since the base offset is already included in the offset.
>> 
>> For the basic registers shared with all pca93xx/tca64xx chips
>> there is no such offset.
>> 
>> Therefore, we add code to adjust the register number for exended
>> registers to the 24 bit accessor functions.
>> 
>> And we add additional register offset constants (not yet used by
>> the driver code) which are specific to the pcal6524.
>> 
> 
> First of all, as I said, please split this to two patches. Don't mix the 
> things.

Ok. Queued for v4.

> 
> 
>> +   /* adjust register address for pcal6524 */
>> +   if (reg >= PCAL953X_OUT_STRENGTH)
>> +   reg -= PCAL953X_OUT_STRENGTH >> 1;
>> +
> 
> Give me some days to think about it.

No problem. I'll wait with v4.

The only alternative I would see is to add new accessor function
pointers for the extended registers and have 0x00 based offsets,
but that is IMHO more ugly.

BR and thanks,
Nikolaus

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180410:

The parisc-hd tree still had its build failure for which I applied a patch.

Non-merge commits (relative to Linus' tree): 1234
 1303 files changed, 45581 insertions(+), 24758 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (b284d4d5a678 Merge tag 'ceph-for-4.17-rc1' of 
git://github.com/ceph/ceph-client)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (2a141cd0d83b ARM: 8758/1: decompressor: restore r1 
and r2 just before jumping to the kernel)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1cc5954f4415 ip_gre: clear feature flags when incompatible 
o_flags are set)
Merging bpf/master (3a38bb98d9ab bpf/tracing: fix a deadlock in 
perf_event_detach_bpf_prog)
Merging ipsec/master (4b66af2d6356 af_key: Always verify length of provided 
sadb_key)
Merging netfilter/master (3f1e53abff84 netfilter: ebtables: don't attempt to 
allocate 0-sized compat array)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (77e30e10ee28 iwlwifi: mvm: query regdb for wmm 
rule if needed)
Merging mac80211/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (e1a3a981e320 ALSA: pcm: Remove WARN_ON() at 
snd_pcm_hw_params() error)
Merging pci-current/for-linus (3252435a097f PCI: Remove messages about 
reassigning resources)
Merging driver-core.current/driver-core-linus (38c23685b273 Merge tag 
'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging tty.current/tty-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb.current/usb-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 
support for Harman FirmwareHubEmulator)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180410:

The parisc-hd tree still had its build failure for which I applied a patch.

Non-merge commits (relative to Linus' tree): 1234
 1303 files changed, 45581 insertions(+), 24758 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (b284d4d5a678 Merge tag 'ceph-for-4.17-rc1' of 
git://github.com/ceph/ceph-client)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (2a141cd0d83b ARM: 8758/1: decompressor: restore r1 
and r2 just before jumping to the kernel)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1cc5954f4415 ip_gre: clear feature flags when incompatible 
o_flags are set)
Merging bpf/master (3a38bb98d9ab bpf/tracing: fix a deadlock in 
perf_event_detach_bpf_prog)
Merging ipsec/master (4b66af2d6356 af_key: Always verify length of provided 
sadb_key)
Merging netfilter/master (3f1e53abff84 netfilter: ebtables: don't attempt to 
allocate 0-sized compat array)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (77e30e10ee28 iwlwifi: mvm: query regdb for wmm 
rule if needed)
Merging mac80211/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (e1a3a981e320 ALSA: pcm: Remove WARN_ON() at 
snd_pcm_hw_params() error)
Merging pci-current/for-linus (3252435a097f PCI: Remove messages about 
reassigning resources)
Merging driver-core.current/driver-core-linus (38c23685b273 Merge tag 
'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging tty.current/tty-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb.current/usb-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 
support for Harman FirmwareHubEmulator)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Andreas Kemnade]

Hi Ladis,

On Tue, 10 Apr 2018 22:56:43 +0200
Ladislav Michl  wrote:

> Hi Nikolaus,
> 
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > Hi,
> > we just started testing the v4.16 kernel and found the
> > device no longer bootable (works with v4.15). It turned
> > out that there was a harmful modification somewhere between
> > v4.15.0 and v4.16-rc1.
> > 
> > A git bisect points to this patch:  
> 
> Well, that's a shame... However, this code is in production for several
> months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
> condition is met, ie:
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> *mtd, int area,
>   if (buf >= high_memory) {
>   struct page *p1;
>  
> + goto out_copy;
>   if (((size_t)buf & PAGE_MASK) !=
>   ((size_t)(buf + count - 1) & PAGE_MASK))
>   goto out_copy;

I had the same problem here, and that snippet  helps here. ubiattach
-p /dev/mtdX does not cause kernel oopses here anymore


Regards,
Andreas


pgpMtvtkaSvQW.pgp
Description: OpenPGP digital signature

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Andreas Kemnade]

Hi Ladis,

On Tue, 10 Apr 2018 22:56:43 +0200
Ladislav Michl  wrote:

> Hi Nikolaus,
> 
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > Hi,
> > we just started testing the v4.16 kernel and found the
> > device no longer bootable (works with v4.15). It turned
> > out that there was a harmful modification somewhere between
> > v4.15.0 and v4.16-rc1.
> > 
> > A git bisect points to this patch:  
> 
> Well, that's a shame... However, this code is in production for several
> months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
> condition is met, ie:
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> *mtd, int area,
>   if (buf >= high_memory) {
>   struct page *p1;
>  
> + goto out_copy;
>   if (((size_t)buf & PAGE_MASK) !=
>   ((size_t)(buf + count - 1) & PAGE_MASK))
>   goto out_copy;

I had the same problem here, and that snippet  helps here. ubiattach
-p /dev/mtdX does not cause kernel oopses here anymore


Regards,
Andreas


pgpMtvtkaSvQW.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/4] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

[H. Nikolaus Schaller]

> Am 10.04.2018 um 20:10 schrieb Andy Shevchenko :
> 
> #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)

Looks the best.

I have queued it for v4.

BR and thanks,
Nikolaus

Re: [PATCH v3 1/4] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

[H. Nikolaus Schaller]

> Am 10.04.2018 um 20:10 schrieb Andy Shevchenko :
> 
> #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)

Looks the best.

I have queued it for v4.

BR and thanks,
Nikolaus

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

[Jia He]

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 09:49, Jia He  wrote:


On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 04:30, Jia He  wrote:

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

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

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

And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm{,64} and move
the related codes to arm64 arch directory.

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 

Hello Jia,

Apologies for chiming in late.

no problem, thanks for your comments  ;-)


If we are going to rearchitect this, I'd rather we change the loop in
memmap_init_zone() so that we skip to the next valid PFN directly
rather than skipping to the last invalid PFN so that the pfn++ in the

hmm... Maybe this macro name makes you confused

pfn = skip_to_last_invalid_pfn(pfn);

how about skip_to_next_valid_pfn?


for () results in the next value. Can we replace the pfn++ there with
a function calls that defaults to 'return pfn + 1', but does the skip
for architectures that implement it?

I am not sure I understand your question here.
With this patch, on !arm arches, skip_to_last_invalid_pfn is equal to (pfn),
and will be increased
when for{} loop continue. We only *skip* to the start pfn of next valid
region when
CONFIG_HAVE_MEMBLOCK and CONFIG_HAVE_ARCH_PFN_VALID(arm/arm64 supports
both).


What I am saying is that the loop in memmap_init_zone

for (pfn = start_pfn; pfn < end_pfn; pfn++) { ... }

should be replaced by something like

for (pfn = start_pfn; pfn < end_pfn; pfn = next_valid_pfn(pfn))

After further thinking, IMO, pfn = next_valid_pfn(pfn) might have impact on

memmap_init_zone loop.

e.g.context != MEMMAP_EARLY, pfn will not be checked by early_pfn_valid, thus
It will change the memhotplug logic.

So I would choose the old implementation:
if (!early_pfn_valid(pfn)) {
pfn = next_valid_pfn(pfn) - 1;
continue;
}
Any comments? Thanks

--
Cheers,
Jia

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

[Jia He]

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 09:49, Jia He  wrote:


On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 04:30, Jia He  wrote:

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

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

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

And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm{,64} and move
the related codes to arm64 arch directory.

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 

Hello Jia,

Apologies for chiming in late.

no problem, thanks for your comments  ;-)


If we are going to rearchitect this, I'd rather we change the loop in
memmap_init_zone() so that we skip to the next valid PFN directly
rather than skipping to the last invalid PFN so that the pfn++ in the

hmm... Maybe this macro name makes you confused

pfn = skip_to_last_invalid_pfn(pfn);

how about skip_to_next_valid_pfn?


for () results in the next value. Can we replace the pfn++ there with
a function calls that defaults to 'return pfn + 1', but does the skip
for architectures that implement it?

I am not sure I understand your question here.
With this patch, on !arm arches, skip_to_last_invalid_pfn is equal to (pfn),
and will be increased
when for{} loop continue. We only *skip* to the start pfn of next valid
region when
CONFIG_HAVE_MEMBLOCK and CONFIG_HAVE_ARCH_PFN_VALID(arm/arm64 supports
both).


What I am saying is that the loop in memmap_init_zone

for (pfn = start_pfn; pfn < end_pfn; pfn++) { ... }

should be replaced by something like

for (pfn = start_pfn; pfn < end_pfn; pfn = next_valid_pfn(pfn))

After further thinking, IMO, pfn = next_valid_pfn(pfn) might have impact on

memmap_init_zone loop.

e.g.context != MEMMAP_EARLY, pfn will not be checked by early_pfn_valid, thus
It will change the memhotplug logic.

So I would choose the old implementation:
if (!early_pfn_valid(pfn)) {
pfn = next_valid_pfn(pfn) - 1;
continue;
}
Any comments? Thanks

--
Cheers,
Jia

[PATCH] dm/raid1: Remove VLA usage

[Kees Cook]

On the quest to remove all VLAs from the kernel[1], this avoids VLAs
in dm-raid1.c by just using the maximum size for the stack arrays.
The nr_mirrors value was already capped at 9, so this makes it a trivial
adjustment to the array sizes.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Kees Cook 
---
 drivers/md/dm-raid1.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index 580c49cc8079..5903e492bb34 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -23,6 +23,8 @@
 
 #define MAX_RECOVERY 1 /* Maximum number of regions recovered in parallel. */
 
+#define MAX_NR_MIRRORS (DM_KCOPYD_MAX_REGIONS + 1)
+
 #define DM_RAID1_HANDLE_ERRORS 0x01
 #define DM_RAID1_KEEP_LOG  0x02
 #define errors_handled(p)  ((p)->features & DM_RAID1_HANDLE_ERRORS)
@@ -255,7 +257,7 @@ static int mirror_flush(struct dm_target *ti)
unsigned long error_bits;
 
unsigned int i;
-   struct dm_io_region io[ms->nr_mirrors];
+   struct dm_io_region io[MAX_NR_MIRRORS];
struct mirror *m;
struct dm_io_request io_req = {
.bi_op = REQ_OP_WRITE,
@@ -651,7 +653,7 @@ static void write_callback(unsigned long error, void 
*context)
 static void do_write(struct mirror_set *ms, struct bio *bio)
 {
unsigned int i;
-   struct dm_io_region io[ms->nr_mirrors], *dest = io;
+   struct dm_io_region io[MAX_NR_MIRRORS], *dest = io;
struct mirror *m;
struct dm_io_request io_req = {
.bi_op = REQ_OP_WRITE,
@@ -1083,7 +1085,7 @@ static int mirror_ctr(struct dm_target *ti, unsigned int 
argc, char **argv)
argc -= args_used;
 
if (!argc || sscanf(argv[0], "%u%c", _mirrors, ) != 1 ||
-   nr_mirrors < 2 || nr_mirrors > DM_KCOPYD_MAX_REGIONS + 1) {
+   nr_mirrors < 2 || nr_mirrors > MAX_NR_MIRRORS) {
ti->error = "Invalid number of mirrors";
dm_dirty_log_destroy(dl);
return -EINVAL;
@@ -1404,7 +1406,7 @@ static void mirror_status(struct dm_target *ti, 
status_type_t type,
int num_feature_args = 0;
struct mirror_set *ms = (struct mirror_set *) ti->private;
struct dm_dirty_log *log = dm_rh_dirty_log(ms->rh);
-   char buffer[ms->nr_mirrors + 1];
+   char buffer[MAX_NR_MIRRORS + 1];
 
switch (type) {
case STATUSTYPE_INFO:
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] dm/raid1: Remove VLA usage

[Kees Cook]

On the quest to remove all VLAs from the kernel[1], this avoids VLAs
in dm-raid1.c by just using the maximum size for the stack arrays.
The nr_mirrors value was already capped at 9, so this makes it a trivial
adjustment to the array sizes.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Kees Cook 
---
 drivers/md/dm-raid1.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index 580c49cc8079..5903e492bb34 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -23,6 +23,8 @@
 
 #define MAX_RECOVERY 1 /* Maximum number of regions recovered in parallel. */
 
+#define MAX_NR_MIRRORS (DM_KCOPYD_MAX_REGIONS + 1)
+
 #define DM_RAID1_HANDLE_ERRORS 0x01
 #define DM_RAID1_KEEP_LOG  0x02
 #define errors_handled(p)  ((p)->features & DM_RAID1_HANDLE_ERRORS)
@@ -255,7 +257,7 @@ static int mirror_flush(struct dm_target *ti)
unsigned long error_bits;
 
unsigned int i;
-   struct dm_io_region io[ms->nr_mirrors];
+   struct dm_io_region io[MAX_NR_MIRRORS];
struct mirror *m;
struct dm_io_request io_req = {
.bi_op = REQ_OP_WRITE,
@@ -651,7 +653,7 @@ static void write_callback(unsigned long error, void 
*context)
 static void do_write(struct mirror_set *ms, struct bio *bio)
 {
unsigned int i;
-   struct dm_io_region io[ms->nr_mirrors], *dest = io;
+   struct dm_io_region io[MAX_NR_MIRRORS], *dest = io;
struct mirror *m;
struct dm_io_request io_req = {
.bi_op = REQ_OP_WRITE,
@@ -1083,7 +1085,7 @@ static int mirror_ctr(struct dm_target *ti, unsigned int 
argc, char **argv)
argc -= args_used;
 
if (!argc || sscanf(argv[0], "%u%c", _mirrors, ) != 1 ||
-   nr_mirrors < 2 || nr_mirrors > DM_KCOPYD_MAX_REGIONS + 1) {
+   nr_mirrors < 2 || nr_mirrors > MAX_NR_MIRRORS) {
ti->error = "Invalid number of mirrors";
dm_dirty_log_destroy(dl);
return -EINVAL;
@@ -1404,7 +1406,7 @@ static void mirror_status(struct dm_target *ti, 
status_type_t type,
int num_feature_args = 0;
struct mirror_set *ms = (struct mirror_set *) ti->private;
struct dm_dirty_log *log = dm_rh_dirty_log(ms->rh);
-   char buffer[ms->nr_mirrors + 1];
+   char buffer[MAX_NR_MIRRORS + 1];
 
switch (type) {
case STATUSTYPE_INFO:
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[ianwmorrison]

From: Ian W MORRISON 

As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.

This removes the error message in the dmesg log: 

i915 :00:02.0: Direct firmware load for 
i915/glk_dmc_ver1_04.bin failed with error -2
i915 :00:02.0: Failed to load DMC firmware 
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware

and now shows that the firmware has correctly loaded:

[drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)

Cc: sta...@vger.kernel.org
Signed-off-by: Ian W MORRISON 
---
 drivers/gpu/drm/i915/intel_csr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 41e6c75a7f3c..f9550ea46c26 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -35,6 +35,7 @@
  */
 
 #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
+MODULE_FIRMWARE(I915_CSR_GLK);
 #define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
 
 #define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin"
-- 
2.11.0

[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[ianwmorrison]

From: Ian W MORRISON 

As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.

This removes the error message in the dmesg log: 

i915 :00:02.0: Direct firmware load for 
i915/glk_dmc_ver1_04.bin failed with error -2
i915 :00:02.0: Failed to load DMC firmware 
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware

and now shows that the firmware has correctly loaded:

[drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)

Cc: sta...@vger.kernel.org
Signed-off-by: Ian W MORRISON 
---
 drivers/gpu/drm/i915/intel_csr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 41e6c75a7f3c..f9550ea46c26 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -35,6 +35,7 @@
  */
 
 #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
+MODULE_FIRMWARE(I915_CSR_GLK);
 #define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
 
 #define I915_CSR_CNL "i915/cnl_dmc_ver1_07.bin"
-- 
2.11.0

Re: [PATCH V7 00/13] drivers: Boot Constraint core

[Viresh Kumar]

On 10-04-18, 15:40, Lucas Stach wrote:
> Can you please describe how this bootconstraints core integration is
> simpler than a "run things at max performance until late kernel init",
> which could be triggered by a simple initcall similar to what is done
> for clocks and regulators?
> 
> To me the bootcontraints stuff looks like a fairly complex solution and
> your use-case doesn't even sound like you strictly want to keep a
> bootloader configuration, but rather run things at max performance
> until you are reasonably sure that you got all the necessary bandwidth
> requests.

What about this case where drivers of some of the devices used during
boot are built as modules, like display, HDMI, etc., and would be
available only after userspace is up. We need to take care of their
bandwidth requirements as well, until the time their driver comes up.

-- 
viresh

Re: [PATCH V7 00/13] drivers: Boot Constraint core

[Viresh Kumar]

On 10-04-18, 15:40, Lucas Stach wrote:
> Can you please describe how this bootconstraints core integration is
> simpler than a "run things at max performance until late kernel init",
> which could be triggered by a simple initcall similar to what is done
> for clocks and regulators?
> 
> To me the bootcontraints stuff looks like a fairly complex solution and
> your use-case doesn't even sound like you strictly want to keep a
> bootloader configuration, but rather run things at max performance
> until you are reasonably sure that you got all the necessary bandwidth
> requests.

What about this case where drivers of some of the devices used during
boot are built as modules, like display, HDMI, etc., and would be
available only after userspace is up. We need to take care of their
bandwidth requirements as well, until the time their driver comes up.

-- 
viresh

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

[Stephen Boyd]

Quoting Lina Iyer (2018-04-05 09:18:25)
> Add controller driver for QCOM SoCs that have hardware based shared
> resource management. The hardware IP known as RSC (Resource State
> Coordinator) houses multiple Direct Resource Voter (DRV) for different
> execution levels. A DRV is a unique voter on the state of a shared
> resource. A Trigger Control Set (TCS) is a bunch of slots that can house
> multiple resource state requests, that when triggered will issue those
> requests through an internal bus to the Resource Power Manager Hardened
> (RPMH) blocks. These hardware blocks are capable of adjusting clocks,
> voltages, etc. The resource state request from a DRV are aggregated along
> with state requests from other processors in the SoC and the aggregate
> value is applied on the resource.
> 
> Some important aspects of the RPMH communication -
> - Requests are  with some header information
> - Multiple requests (upto 16) may be sent through a TCS, at a time
> - Requests in a TCS are sent in sequence
> - Requests may be fire-n-forget or completion (response expected)
> - Multiple TCS from the same DRV may be triggered simultaneously
> - Cannot send a request if another requesit for the same addr is in

s/requesit/request/

>   progress from the same DRV
> - When all the requests from a TCS are complete, an IRQ is raised
> - The IRQ handler needs to clear the TCS before it is available for
>   reuse
> - TCS configuration is specific to a DRV
> - Platform drivers may use DRV from different RSCs to make requests

This last point is sort of not true anymore? At least my understanding
is that platform drivers are children of the rsc and that they can only
use that rsc to do anything with rpmh.

> 
> Resource state requests made when CPUs are active are called 'active'
> state requests. Requests made when all the CPUs are powered down (idle
> state) are called 'sleep' state requests. They are matched by a
> corresponding 'wake' state requests which puts the resources back in to
> previously requested active state before resuming any CPU. TCSes are
> dedicated for each type of requests. Control TCS are used to provide
> specific information to the controller.

Can you mention AMC here too? I see the acronym but no definition of
what it is besides "Active or AMC" which may indicate A == Active.

> 
> diff --git a/drivers/soc/qcom/rpmh-internal.h 
> b/drivers/soc/qcom/rpmh-internal.h
> new file mode 100644
> index ..aa73ec4b3e42
> --- /dev/null
> +++ b/drivers/soc/qcom/rpmh-internal.h
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
> + */
> +
> +
> +#ifndef __RPM_INTERNAL_H__
> +#define __RPM_INTERNAL_H__
> +
> +#include 
> +#include 
> +
> +#define TCS_TYPE_NR4
> +#define MAX_CMDS_PER_TCS   16
> +#define MAX_TCS_PER_TYPE   3
> +#define MAX_TCS_NR (MAX_TCS_PER_TYPE * TCS_TYPE_NR)
> +
> +struct rsc_drv;
> +
> +/**
> + * struct tcs_response: Response object for a request
> + *
> + * @drv:   the controller
> + * @msg:   the request for this response
> + * @m: the tcs identifier
> + * @err:   error reported in the response
> + * @list:  element in list of pending response objects
> + */
> +struct tcs_response {
> +   struct rsc_drv *drv;
> +   const struct tcs_request *msg;
> +   u32 m;
> +   int err;
> +   struct list_head list;
> +};
> +
> +/**
> + * struct tcs_group: group of Trigger Command Sets for a request state

Put (ACRONYM) for the acronyms that are spelled out the first time
please. Also, make sure we know what 'request state' is.

> + *
> + * @drv:   the controller
> + * @type:  type of the TCS in this group - active, sleep, wake

Now 'group' means 'request state'?

> + * @mask:  mask of the TCSes relative to all the TCSes in the RSC
> + * @offset:start of the TCS group relative to the TCSes in the RSC
> + * @num_tcs:   number of TCSes in this type
> + * @ncpt:  number of commands in each TCS
> + * @lock:  lock for synchronizing this TCS writes
> + * @responses: response objects for requests sent from each TCS
> + */
> +struct tcs_group {
> +   struct rsc_drv *drv;
> +   int type;

Is type supposed to be an enum?

> +   u32 mask;
> +   u32 offset;
> +   int num_tcs;
> +   int ncpt;
> +   spinlock_t lock;
> +   struct tcs_response *responses[MAX_TCS_PER_TYPE];
> +};
> +
> +/**
> + * struct rsc_drv: the Resource State Coordinator controller
> + *
> + * @name:   controller identifier
> + * @tcs_base:   start address of the TCS registers in this controller
> + * @id: instance id in the controller (Direct Resource Voter)
> + * @num_tcs:number of TCSes in this DRV

It changed from an RSC to a DRV here?

> + * @tasklet:handle responses, off-load work from IRQ handler
> + * @response_pending:
> + *  list of responses that needs 

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

[Stephen Boyd]

Quoting Lina Iyer (2018-04-05 09:18:25)
> Add controller driver for QCOM SoCs that have hardware based shared
> resource management. The hardware IP known as RSC (Resource State
> Coordinator) houses multiple Direct Resource Voter (DRV) for different
> execution levels. A DRV is a unique voter on the state of a shared
> resource. A Trigger Control Set (TCS) is a bunch of slots that can house
> multiple resource state requests, that when triggered will issue those
> requests through an internal bus to the Resource Power Manager Hardened
> (RPMH) blocks. These hardware blocks are capable of adjusting clocks,
> voltages, etc. The resource state request from a DRV are aggregated along
> with state requests from other processors in the SoC and the aggregate
> value is applied on the resource.
> 
> Some important aspects of the RPMH communication -
> - Requests are  with some header information
> - Multiple requests (upto 16) may be sent through a TCS, at a time
> - Requests in a TCS are sent in sequence
> - Requests may be fire-n-forget or completion (response expected)
> - Multiple TCS from the same DRV may be triggered simultaneously
> - Cannot send a request if another requesit for the same addr is in

s/requesit/request/

>   progress from the same DRV
> - When all the requests from a TCS are complete, an IRQ is raised
> - The IRQ handler needs to clear the TCS before it is available for
>   reuse
> - TCS configuration is specific to a DRV
> - Platform drivers may use DRV from different RSCs to make requests

This last point is sort of not true anymore? At least my understanding
is that platform drivers are children of the rsc and that they can only
use that rsc to do anything with rpmh.

> 
> Resource state requests made when CPUs are active are called 'active'
> state requests. Requests made when all the CPUs are powered down (idle
> state) are called 'sleep' state requests. They are matched by a
> corresponding 'wake' state requests which puts the resources back in to
> previously requested active state before resuming any CPU. TCSes are
> dedicated for each type of requests. Control TCS are used to provide
> specific information to the controller.

Can you mention AMC here too? I see the acronym but no definition of
what it is besides "Active or AMC" which may indicate A == Active.

> 
> diff --git a/drivers/soc/qcom/rpmh-internal.h 
> b/drivers/soc/qcom/rpmh-internal.h
> new file mode 100644
> index ..aa73ec4b3e42
> --- /dev/null
> +++ b/drivers/soc/qcom/rpmh-internal.h
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
> + */
> +
> +
> +#ifndef __RPM_INTERNAL_H__
> +#define __RPM_INTERNAL_H__
> +
> +#include 
> +#include 
> +
> +#define TCS_TYPE_NR4
> +#define MAX_CMDS_PER_TCS   16
> +#define MAX_TCS_PER_TYPE   3
> +#define MAX_TCS_NR (MAX_TCS_PER_TYPE * TCS_TYPE_NR)
> +
> +struct rsc_drv;
> +
> +/**
> + * struct tcs_response: Response object for a request
> + *
> + * @drv:   the controller
> + * @msg:   the request for this response
> + * @m: the tcs identifier
> + * @err:   error reported in the response
> + * @list:  element in list of pending response objects
> + */
> +struct tcs_response {
> +   struct rsc_drv *drv;
> +   const struct tcs_request *msg;
> +   u32 m;
> +   int err;
> +   struct list_head list;
> +};
> +
> +/**
> + * struct tcs_group: group of Trigger Command Sets for a request state

Put (ACRONYM) for the acronyms that are spelled out the first time
please. Also, make sure we know what 'request state' is.

> + *
> + * @drv:   the controller
> + * @type:  type of the TCS in this group - active, sleep, wake

Now 'group' means 'request state'?

> + * @mask:  mask of the TCSes relative to all the TCSes in the RSC
> + * @offset:start of the TCS group relative to the TCSes in the RSC
> + * @num_tcs:   number of TCSes in this type
> + * @ncpt:  number of commands in each TCS
> + * @lock:  lock for synchronizing this TCS writes
> + * @responses: response objects for requests sent from each TCS
> + */
> +struct tcs_group {
> +   struct rsc_drv *drv;
> +   int type;

Is type supposed to be an enum?

> +   u32 mask;
> +   u32 offset;
> +   int num_tcs;
> +   int ncpt;
> +   spinlock_t lock;
> +   struct tcs_response *responses[MAX_TCS_PER_TYPE];
> +};
> +
> +/**
> + * struct rsc_drv: the Resource State Coordinator controller
> + *
> + * @name:   controller identifier
> + * @tcs_base:   start address of the TCS registers in this controller
> + * @id: instance id in the controller (Direct Resource Voter)
> + * @num_tcs:number of TCSes in this DRV

It changed from an RSC to a DRV here?

> + * @tasklet:handle responses, off-load work from IRQ handler
> + * @response_pending:
> + *  list of responses that needs to be sent 

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

[Viresh Kumar]

On 10-04-18, 16:59, Patrick Bellasi wrote:
> The iowait boosting code has been recently updated to add a progressive
> boosting behavior which allows to be less aggressive in boosting tasks
> doing only sporadic IO operations, thus being more energy efficient for
> example on mobile platforms.
> 
> The current code is now however a bit convoluted. Some functionalities
> (e.g. iowait boost reset) are replicated in different paths and their
> documentation is slightly misaligned.
> 
> Moreover, from a functional stadpoint, the iowait boosting is also not
> always reset in systems where cpufreq policies are not shared, each CPU
> has his own policy. Indeed, when a CPU is idle for a long time we keep
> doubling the boosting instead of resetting it to the minimum frequency,
> as expected by the TICK_NSEC logic, whenever a task wakes up from IO.
> 
> Let's cleanup the code by consolidating all the IO wait boosting related
> functionality inside the already existing functions and better define
> their role:
> 
> - sugov_set_iowait_boost: is now in charge only to set/increase the IO
>  wait boost, every time a task wakes up from an IO wait.
> 
> - sugov_iowait_boost: is now in charge to reset/reduce the IO wait
>  boost, every time a sugov update is triggered, as well as
>  to (eventually) enforce the currently required IO boost value.
> 
> This is possible since these two functions are already used one after
> the other, both in single and shared frequency domains, following the
> same template:
> 
>/* Configure IO boost, if required */
>sugov_set_iowait_boost()
> 
>/* Return here if freq change is in progress or throttled */
> 
>/* Collect and aggregate utilization information */
>sugov_get_util()
>sugov_aggregate_util()
> 
>/* Add IO boost if currently enabled */
>sugov_iowait_boost()
> 
> As a extra bonus, let's also add the documentation for these two
> functions and better align the in-code documentation.
> 
> Signed-off-by: Patrick Bellasi 
> Reported-by: Viresh Kumar 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Joel Fernandes 
> Cc: Steve Muckle 
> Cc: Juri Lelli 
> Cc: Dietmar Eggemann 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> Changes in v2:
> - Fix return in sugov_iowait_boost()'s reset code (Viresh)
> - Add iowait boost reset for sugov_update_single() (Viresh)
> - Title changed to reflact the fix from previous point
> 
> Based on today's tip/sched/core:
>b720342 sched/core: Update preempt_notifier_key to modern API
> ---
>  kernel/sched/cpufreq_schedutil.c | 120 
> ++-
>  1 file changed, 81 insertions(+), 39 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 2b124811947d..2a2ae3a0e41f 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -51,7 +51,7 @@ struct sugov_cpu {
>   booliowait_boost_pending;
>   unsigned intiowait_boost;
>   unsigned intiowait_boost_max;
> - u64 last_update;
> + u64 last_update;
>  
>   /* The fields below are only needed when sharing a policy: */
>   unsigned long   util_cfs;
> @@ -201,43 +201,97 @@ static unsigned long sugov_aggregate_util(struct 
> sugov_cpu *sg_cpu)
>   return min(util, sg_cpu->max);
>  }
>  
> -static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, 
> unsigned int flags)
> +/**
> + * sugov_set_iowait_boost updates the IO boost at each wakeup from IO.
> + * @sg_cpu: the sugov data for the CPU to boost
> + * @time:   the update time from the caller
> + * @flags:  SCHED_CPUFREQ_IOWAIT if the task is waking up after an IO wait
> + *
> + * Each time a task wakes up after an IO operation, the CPU utilization can 
> be
> + * boosted to a certain utilization which is doubled at each wakeup
> + * from IO, starting from the utilization of the minimum OPP to that of the
> + * maximum one.
> + */
> +static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
> +unsigned int flags)
>  {
> - if (flags & SCHED_CPUFREQ_IOWAIT) {
> - if (sg_cpu->iowait_boost_pending)
> - return;
> -
> - sg_cpu->iowait_boost_pending = true;
> + bool iowait = flags & SCHED_CPUFREQ_IOWAIT;
>  
> - if (sg_cpu->iowait_boost) {
> - sg_cpu->iowait_boost <<= 1;
> - if (sg_cpu->iowait_boost > sg_cpu->iowait_boost_max)
> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
> - } else {
> - 

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

[Viresh Kumar]

On 10-04-18, 16:59, Patrick Bellasi wrote:
> The iowait boosting code has been recently updated to add a progressive
> boosting behavior which allows to be less aggressive in boosting tasks
> doing only sporadic IO operations, thus being more energy efficient for
> example on mobile platforms.
> 
> The current code is now however a bit convoluted. Some functionalities
> (e.g. iowait boost reset) are replicated in different paths and their
> documentation is slightly misaligned.
> 
> Moreover, from a functional stadpoint, the iowait boosting is also not
> always reset in systems where cpufreq policies are not shared, each CPU
> has his own policy. Indeed, when a CPU is idle for a long time we keep
> doubling the boosting instead of resetting it to the minimum frequency,
> as expected by the TICK_NSEC logic, whenever a task wakes up from IO.
> 
> Let's cleanup the code by consolidating all the IO wait boosting related
> functionality inside the already existing functions and better define
> their role:
> 
> - sugov_set_iowait_boost: is now in charge only to set/increase the IO
>  wait boost, every time a task wakes up from an IO wait.
> 
> - sugov_iowait_boost: is now in charge to reset/reduce the IO wait
>  boost, every time a sugov update is triggered, as well as
>  to (eventually) enforce the currently required IO boost value.
> 
> This is possible since these two functions are already used one after
> the other, both in single and shared frequency domains, following the
> same template:
> 
>/* Configure IO boost, if required */
>sugov_set_iowait_boost()
> 
>/* Return here if freq change is in progress or throttled */
> 
>/* Collect and aggregate utilization information */
>sugov_get_util()
>sugov_aggregate_util()
> 
>/* Add IO boost if currently enabled */
>sugov_iowait_boost()
> 
> As a extra bonus, let's also add the documentation for these two
> functions and better align the in-code documentation.
> 
> Signed-off-by: Patrick Bellasi 
> Reported-by: Viresh Kumar 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Joel Fernandes 
> Cc: Steve Muckle 
> Cc: Juri Lelli 
> Cc: Dietmar Eggemann 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> Changes in v2:
> - Fix return in sugov_iowait_boost()'s reset code (Viresh)
> - Add iowait boost reset for sugov_update_single() (Viresh)
> - Title changed to reflact the fix from previous point
> 
> Based on today's tip/sched/core:
>b720342 sched/core: Update preempt_notifier_key to modern API
> ---
>  kernel/sched/cpufreq_schedutil.c | 120 
> ++-
>  1 file changed, 81 insertions(+), 39 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 2b124811947d..2a2ae3a0e41f 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -51,7 +51,7 @@ struct sugov_cpu {
>   booliowait_boost_pending;
>   unsigned intiowait_boost;
>   unsigned intiowait_boost_max;
> - u64 last_update;
> + u64 last_update;
>  
>   /* The fields below are only needed when sharing a policy: */
>   unsigned long   util_cfs;
> @@ -201,43 +201,97 @@ static unsigned long sugov_aggregate_util(struct 
> sugov_cpu *sg_cpu)
>   return min(util, sg_cpu->max);
>  }
>  
> -static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, 
> unsigned int flags)
> +/**
> + * sugov_set_iowait_boost updates the IO boost at each wakeup from IO.
> + * @sg_cpu: the sugov data for the CPU to boost
> + * @time:   the update time from the caller
> + * @flags:  SCHED_CPUFREQ_IOWAIT if the task is waking up after an IO wait
> + *
> + * Each time a task wakes up after an IO operation, the CPU utilization can 
> be
> + * boosted to a certain utilization which is doubled at each wakeup
> + * from IO, starting from the utilization of the minimum OPP to that of the
> + * maximum one.
> + */
> +static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
> +unsigned int flags)
>  {
> - if (flags & SCHED_CPUFREQ_IOWAIT) {
> - if (sg_cpu->iowait_boost_pending)
> - return;
> -
> - sg_cpu->iowait_boost_pending = true;
> + bool iowait = flags & SCHED_CPUFREQ_IOWAIT;
>  
> - if (sg_cpu->iowait_boost) {
> - sg_cpu->iowait_boost <<= 1;
> - if (sg_cpu->iowait_boost > sg_cpu->iowait_boost_max)
> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
> - } else {
> - sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->min;
> - }
> - } else if (sg_cpu->iowait_boost) {
> + /* Reset boost if the CPU appears to have been idle enough */
> + if (sg_cpu->iowait_boost) {
>  

RE: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

[廖崇榮]

Hi Benjamin,

-Original Message-
From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] 
Sent: Tuesday, April 10, 2018 3:35 PM
To: 廖崇榮
Cc: Dmitry Torokhov; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; 
lkml
Subject: Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

Hi KT,

On Tue, Apr 10, 2018 at 7:45 AM, 廖崇榮  wrote:
> Hi Benjamin,
>
> Thanks so much for your patch.
>
> I have tested them for Elan Gen5/Gen6(new) touchpad with SMbus/PS2.
> It works fine in my thinkpad so far but I find an issue today after 
> lid-close/open.
>
> I am not sure if you can see it in T480S , I "guess" it may be relative to 
> i2c_i801.
>
> The lid-close will enter deep sleep and cut touchpad power.
> I can see the resume flow after lid-open and SMbus-initial try to request 
> hello package but fail.
> Strangely, I can't see any SMbus host signal on LA scope after power-on.

That's weird. I do not see this, by either closing the lid or directly calling 
'systemctl suspend'.
On my system, i2c-i801 is also compiled as a module but psmouse is not 
(directly in vmlinuz).
[KT] : It's good to know your system doesn't meet this problem. 
 My SMbus laptop is an engineer sample in 2015, and PM tell me that NFC 
attaches to the same bus.
 I guess it's a single case because it's not a stable platform.

>
> I can't switch to SMbus after rmmod/modprobe psmouse because error happen in 
> elantech_create_smbus.

If the SMBus adapter is failing, it is somewhat expected. Reloading psmouse 
will force a re-trigger of the SMBus probe function, but if the underlying 
communication fails, there is no way for psmouse to know it failed, so the PS/2 
node will disappear. And the SMBus device will not be there.
[KT] : It switch to PS/2 interface after rmmod/modprobe psmouse.

> It will be recovered only if I rmmod/modprobe i2c_i801 first.

Just to be sure, what happens if you rmmod/modprobe elan_i2c instead of 
i2c_i801?
[KT] :I tried rmmod/modprobe elan_i2c first , but can't recover touchpad. 
No error printed in the dmesg. I will add more message to check it later.

And which kernel are you running? On a vanilla 4.16 + Dmitry's next branch I do 
not see such issues.
[KT]: I use 4.15, I may try 4.16 later.

>
> Do you have any idea about it?

If reloading elan_i2c doesn't fix the situation, it must be in i2c_i801. But 
this is weird that this happens on your platform but not on my t480s going into 
S3.
[KT] I think so. As I mention that I can't see bus signal on scope. That make 
me guess it's the bus adaptor issue.
It's an early-stage engineer system, power Issue will be expected.

Cheers,
Benjamin

>
> Thanks
> KT
> -Original Message-
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Sent: Friday, April 06, 2018 2:51 PM
> To: Dmitry Torokhov
> Cc: 廖崇榮; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; 
> lkml
> Subject: Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads 
> (series 80)
>
> Hi Dmitry,
>
> On Fri, Apr 6, 2018 at 1:51 AM, Dmitry Torokhov  
> wrote:
>> Hi Benjamin,
>>
>> On Thu, Apr 05, 2018 at 03:25:29PM +0200, Benjamin Tissoires wrote:
>>> Hi Dmitry,
>>>
>>> well, this year, Lenovo gave us a surprise and decided to not use 
>>> the same touchpad/trackstick in all its model. And by default, the 
>>> support under Linux is less than ideal.
>>>
>>> Please find a series that should fix those issues. Compared to the 
>>> 60 series, there do not seem to e BIOS table issues this time, and 
>>> suspend/resume works fine thanks to your latest trackstick fixes.
>>>
>>> The T480s is a different beast, as it uses an Elan touchpad.
>>> I have been carrying the patches 3-6 for a while and tested previous 
>>> versions on various Elan PS/2 hardware without an issue as far as I 
>>> could tell. I was lacking tests from users with SMBus as all the 
>>> laptops I tried where puer PS/2.
>>>
>>> Anyway, it would be cool if you could have a look at the series.
>>
>> I am mostly happy with the series, but I would love to hear KT's take 
>> on it.
>
> thanks for the quick review.
> I worked closely with KT for this series. He helped me a lot for the tiny 
> firmware changes that were required. However, quoting his email from Tuesday:
> "There will be a spring vacation in Taiwan from tomorrow." I guess we won't 
> hear from him until the end of next week as we always have a backlog of 
> urgent things to do after holidays...
>
> Cheers,
> Benjamin
>

RE: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

[廖崇榮]

Hi Benjamin,

-Original Message-
From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] 
Sent: Tuesday, April 10, 2018 3:35 PM
To: 廖崇榮
Cc: Dmitry Torokhov; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; 
lkml
Subject: Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

Hi KT,

On Tue, Apr 10, 2018 at 7:45 AM, 廖崇榮  wrote:
> Hi Benjamin,
>
> Thanks so much for your patch.
>
> I have tested them for Elan Gen5/Gen6(new) touchpad with SMbus/PS2.
> It works fine in my thinkpad so far but I find an issue today after 
> lid-close/open.
>
> I am not sure if you can see it in T480S , I "guess" it may be relative to 
> i2c_i801.
>
> The lid-close will enter deep sleep and cut touchpad power.
> I can see the resume flow after lid-open and SMbus-initial try to request 
> hello package but fail.
> Strangely, I can't see any SMbus host signal on LA scope after power-on.

That's weird. I do not see this, by either closing the lid or directly calling 
'systemctl suspend'.
On my system, i2c-i801 is also compiled as a module but psmouse is not 
(directly in vmlinuz).
[KT] : It's good to know your system doesn't meet this problem. 
 My SMbus laptop is an engineer sample in 2015, and PM tell me that NFC 
attaches to the same bus.
 I guess it's a single case because it's not a stable platform.

>
> I can't switch to SMbus after rmmod/modprobe psmouse because error happen in 
> elantech_create_smbus.

If the SMBus adapter is failing, it is somewhat expected. Reloading psmouse 
will force a re-trigger of the SMBus probe function, but if the underlying 
communication fails, there is no way for psmouse to know it failed, so the PS/2 
node will disappear. And the SMBus device will not be there.
[KT] : It switch to PS/2 interface after rmmod/modprobe psmouse.

> It will be recovered only if I rmmod/modprobe i2c_i801 first.

Just to be sure, what happens if you rmmod/modprobe elan_i2c instead of 
i2c_i801?
[KT] :I tried rmmod/modprobe elan_i2c first , but can't recover touchpad. 
No error printed in the dmesg. I will add more message to check it later.

And which kernel are you running? On a vanilla 4.16 + Dmitry's next branch I do 
not see such issues.
[KT]: I use 4.15, I may try 4.16 later.

>
> Do you have any idea about it?

If reloading elan_i2c doesn't fix the situation, it must be in i2c_i801. But 
this is weird that this happens on your platform but not on my t480s going into 
S3.
[KT] I think so. As I mention that I can't see bus signal on scope. That make 
me guess it's the bus adaptor issue.
It's an early-stage engineer system, power Issue will be expected.

Cheers,
Benjamin

>
> Thanks
> KT
> -Original Message-
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Sent: Friday, April 06, 2018 2:51 PM
> To: Dmitry Torokhov
> Cc: 廖崇榮; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; 
> lkml
> Subject: Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads 
> (series 80)
>
> Hi Dmitry,
>
> On Fri, Apr 6, 2018 at 1:51 AM, Dmitry Torokhov  
> wrote:
>> Hi Benjamin,
>>
>> On Thu, Apr 05, 2018 at 03:25:29PM +0200, Benjamin Tissoires wrote:
>>> Hi Dmitry,
>>>
>>> well, this year, Lenovo gave us a surprise and decided to not use 
>>> the same touchpad/trackstick in all its model. And by default, the 
>>> support under Linux is less than ideal.
>>>
>>> Please find a series that should fix those issues. Compared to the 
>>> 60 series, there do not seem to e BIOS table issues this time, and 
>>> suspend/resume works fine thanks to your latest trackstick fixes.
>>>
>>> The T480s is a different beast, as it uses an Elan touchpad.
>>> I have been carrying the patches 3-6 for a while and tested previous 
>>> versions on various Elan PS/2 hardware without an issue as far as I 
>>> could tell. I was lacking tests from users with SMBus as all the 
>>> laptops I tried where puer PS/2.
>>>
>>> Anyway, it would be cool if you could have a look at the series.
>>
>> I am mostly happy with the series, but I would love to hear KT's take 
>> on it.
>
> thanks for the quick review.
> I worked closely with KT for this series. He helped me a lot for the tiny 
> firmware changes that were required. However, quoting his email from Tuesday:
> "There will be a spring vacation in Taiwan from tomorrow." I guess we won't 
> hear from him until the end of next week as we always have a backlog of 
> urgent things to do after holidays...
>
> Cheers,
> Benjamin
>

Re: update-binfmts breaking suspend

[Matthew Wilcox]

Ping?

On Fri, Apr 06, 2018 at 07:43:55AM -0700, Matthew Wilcox wrote:
> Pavel Machek  wrote:
> > > Failure is not a hang, as they expect, but... machine locks up, but
> > > does not suspend, and then continues running after a delay..
> > > 
> > > [   35.038766] PM: Syncing filesystems ... done.
> > > [   35.051246] Freezing user space processes ...
> > > [   55.060528] Freezing of tasks failed after 20.009 seconds (1 tasks
> > > refusing to freeze, wq_busy
> > > =0):
> > > [   55.060552] update-binfmts  D0  2727  1 0x8004
> > > [   55.060576] Call Trace:
> > > [   55.060600]  __schedule+0x37a/0x7e0
> > > [   55.060618]  schedule+0x29/0x70
> > > [   55.060635]  autofs4_wait+0x359/0x7a0
> > > [   55.060653]  ? wait_woken+0x70/0x70
> > > [   55.060668]  autofs4_mount_wait+0x4a/0xe0
> > > [   55.060684]  ? autofs4_mount_wait+0x4a/0xe0
> > > [   55.060699]  autofs4_d_automount+0xe0/0x200
> > > [   55.060715]  ? autofs4_d_automount+0xe0/0x200
> > > 
> > > Did the rework of freezing start already in -next?
> > 
> > Hmm, so I did git bisect, and it pointed to:
> > 
> > commit 7cb03edf112fea6ead2fcd3c5fd639756d6d114b
> > Author: Matthew Wilcox 
> > Date:   Thu Mar 29 10:15:17 2018 +1100
> > 
> > autofs4: use wait_event_killable
> > 
> > This playing with signals to allow only fatal signals appears to
> > predate
> > the introduction of wait_event_killable(), and I'm fairly sure
> > that
> > wait_event_killable is what was meant to happen here.
> 
> Umm.  I'm not familiar with the freezer.  Help me out here ...
> 
> I see the message coming from here:
> 
> pr_err("Freezing of tasks %s after %d.%03d seconds "
>"(%d tasks refusing to freeze, wq_busy=%d):\n",
>wakeup ? "aborted" : "failed",
>elapsed_msecs / 1000, elapsed_msecs % 1000,
>todo - wq_busy, wq_busy);
> 
> and then backtracking in that function, I see this:
> 
> for_each_process_thread(g, p) {
> if (p == current || !freeze_task(p))
> continue;
> 
> in freeze_task(), I see this:
> 
> if (!(p->flags & PF_KTHREAD))
> fake_signal_wake_up(p);
> else
> wake_up_state(p, TASK_INTERRUPTIBLE);
> 
> which does this:
> 
> if (lock_task_sighand(p, )) {
> signal_wake_up(p, 0);
> unlock_task_sighand(p, );
> }
> 
> which does this:
> 
> static inline void signal_wake_up(struct task_struct *t, bool resume)
> {
> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0);
> }
> 
> which does this:
> 
> void signal_wake_up_state(struct task_struct *t, unsigned int state)
> {
> set_tsk_thread_flag(t, TIF_SIGPENDING);
> /*
>  * TASK_WAKEKILL also means wake it up in the stopped/traced/killable
>  * case. We don't check t->state here because there is a race with it
>  * executing another processor and just now entering stopped state.
>  * By using wake_up_state, we ensure the process will wake up and
>  * handle its death signal.
>  */
> if (!wake_up_state(t, state | TASK_INTERRUPTIBLE))
> kick_process(t);
> }
> 
> Now I don't know why we only wake interruptible tasks here and not killable
> tasks.  I've trawled git history all the way back to 2.6.12-rc2, and the
> reasoning behind signal_wake_up() (as it originally was) is lost to pre-git
> history.
> 
> So ... why do we only wake interruptible tasks on suspend?  Why not wake
> uninterruptible tasks too?
> 
> if (lock_task_sighand(p, )) {
> -   signal_wake_up(p, 0);
> +   signal_wake_up_state(p, TASK_WAKEKILL);
> unlock_task_sighand(p, );
> }
> 
> or why do we consider tasks waiting uninterruptibly to block freezing?
> Is it because they're (probably) waiting for I/O and we want the I/O
> to complete?

Re: update-binfmts breaking suspend

[Matthew Wilcox]

Ping?

On Fri, Apr 06, 2018 at 07:43:55AM -0700, Matthew Wilcox wrote:
> Pavel Machek  wrote:
> > > Failure is not a hang, as they expect, but... machine locks up, but
> > > does not suspend, and then continues running after a delay..
> > > 
> > > [   35.038766] PM: Syncing filesystems ... done.
> > > [   35.051246] Freezing user space processes ...
> > > [   55.060528] Freezing of tasks failed after 20.009 seconds (1 tasks
> > > refusing to freeze, wq_busy
> > > =0):
> > > [   55.060552] update-binfmts  D0  2727  1 0x8004
> > > [   55.060576] Call Trace:
> > > [   55.060600]  __schedule+0x37a/0x7e0
> > > [   55.060618]  schedule+0x29/0x70
> > > [   55.060635]  autofs4_wait+0x359/0x7a0
> > > [   55.060653]  ? wait_woken+0x70/0x70
> > > [   55.060668]  autofs4_mount_wait+0x4a/0xe0
> > > [   55.060684]  ? autofs4_mount_wait+0x4a/0xe0
> > > [   55.060699]  autofs4_d_automount+0xe0/0x200
> > > [   55.060715]  ? autofs4_d_automount+0xe0/0x200
> > > 
> > > Did the rework of freezing start already in -next?
> > 
> > Hmm, so I did git bisect, and it pointed to:
> > 
> > commit 7cb03edf112fea6ead2fcd3c5fd639756d6d114b
> > Author: Matthew Wilcox 
> > Date:   Thu Mar 29 10:15:17 2018 +1100
> > 
> > autofs4: use wait_event_killable
> > 
> > This playing with signals to allow only fatal signals appears to
> > predate
> > the introduction of wait_event_killable(), and I'm fairly sure
> > that
> > wait_event_killable is what was meant to happen here.
> 
> Umm.  I'm not familiar with the freezer.  Help me out here ...
> 
> I see the message coming from here:
> 
> pr_err("Freezing of tasks %s after %d.%03d seconds "
>"(%d tasks refusing to freeze, wq_busy=%d):\n",
>wakeup ? "aborted" : "failed",
>elapsed_msecs / 1000, elapsed_msecs % 1000,
>todo - wq_busy, wq_busy);
> 
> and then backtracking in that function, I see this:
> 
> for_each_process_thread(g, p) {
> if (p == current || !freeze_task(p))
> continue;
> 
> in freeze_task(), I see this:
> 
> if (!(p->flags & PF_KTHREAD))
> fake_signal_wake_up(p);
> else
> wake_up_state(p, TASK_INTERRUPTIBLE);
> 
> which does this:
> 
> if (lock_task_sighand(p, )) {
> signal_wake_up(p, 0);
> unlock_task_sighand(p, );
> }
> 
> which does this:
> 
> static inline void signal_wake_up(struct task_struct *t, bool resume)
> {
> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0);
> }
> 
> which does this:
> 
> void signal_wake_up_state(struct task_struct *t, unsigned int state)
> {
> set_tsk_thread_flag(t, TIF_SIGPENDING);
> /*
>  * TASK_WAKEKILL also means wake it up in the stopped/traced/killable
>  * case. We don't check t->state here because there is a race with it
>  * executing another processor and just now entering stopped state.
>  * By using wake_up_state, we ensure the process will wake up and
>  * handle its death signal.
>  */
> if (!wake_up_state(t, state | TASK_INTERRUPTIBLE))
> kick_process(t);
> }
> 
> Now I don't know why we only wake interruptible tasks here and not killable
> tasks.  I've trawled git history all the way back to 2.6.12-rc2, and the
> reasoning behind signal_wake_up() (as it originally was) is lost to pre-git
> history.
> 
> So ... why do we only wake interruptible tasks on suspend?  Why not wake
> uninterruptible tasks too?
> 
> if (lock_task_sighand(p, )) {
> -   signal_wake_up(p, 0);
> +   signal_wake_up_state(p, TASK_WAKEKILL);
> unlock_task_sighand(p, );
> }
> 
> or why do we consider tasks waiting uninterruptibly to block freezing?
> Is it because they're (probably) waiting for I/O and we want the I/O
> to complete?

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Ravi Bangoria]

Hi Oleg,

On 04/10/2018 04:36 PM, Oleg Nesterov wrote:
> Hi Ravi,
>
> On 04/10, Ravi Bangoria wrote:
>>> and what if __mmu_notifier_register() fails simply because signal_pending() 
>>> == T?
>>> see mm_take_all_locks().
>>>
>>> at first glance this all look suspicious and sub-optimal,
>> Yes. I should have added checks for failure cases.
>> Will fix them in v3.
> And what can you do if it fails? Nothing except report the problem. But
> signal_pending() is not the unlikely or error condition, it should not
> cause the tracing errors.

...

> Plus mm_take_all_locks() is very heavy... BTW, uprobe_mmap_callback() is
> called unconditionally. Whatever it does, can we at least move it after
> the no_uprobe_events() check? Can't we also check MMF_HAS_UPROBES?

Sure, I'll move it after these conditions.

> Either way, I do not feel that mmu_notifier is the right tool... Did you
> consider the uprobe_clear_state() hook we already have?

Ah! This is really a good idea. We don't need mmu_notifier then.

Thanks for suggestion,
Ravi

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Ravi Bangoria]

Hi Oleg,

On 04/10/2018 04:36 PM, Oleg Nesterov wrote:
> Hi Ravi,
>
> On 04/10, Ravi Bangoria wrote:
>>> and what if __mmu_notifier_register() fails simply because signal_pending() 
>>> == T?
>>> see mm_take_all_locks().
>>>
>>> at first glance this all look suspicious and sub-optimal,
>> Yes. I should have added checks for failure cases.
>> Will fix them in v3.
> And what can you do if it fails? Nothing except report the problem. But
> signal_pending() is not the unlikely or error condition, it should not
> cause the tracing errors.

...

> Plus mm_take_all_locks() is very heavy... BTW, uprobe_mmap_callback() is
> called unconditionally. Whatever it does, can we at least move it after
> the no_uprobe_events() check? Can't we also check MMF_HAS_UPROBES?

Sure, I'll move it after these conditions.

> Either way, I do not feel that mmu_notifier is the right tool... Did you
> consider the uprobe_clear_state() hook we already have?

Ah! This is really a good idea. We don't need mmu_notifier then.

Thanks for suggestion,
Ravi

Re: Q: Can we get rid of __copy_siginfo_to_user32?

[Andy Lutomirski]

> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman  wrote:
>
>
> Andy,
>
> I am looking at copy_siginfo_to_user32 and find it very unfortunate
> that x86 with _sigchld_x32 needs to be the odd man out.  I am looking
> at ways to simplify the special case.
>
> The core of the special case comes from:
> exit_to_usermode_loop
>  do_signal
>handle_signal
>   setup_rt_frame
>
>
> In setup_rt_frame the code looks at ksig to see which kind of signal
> frame should be written for the signal.
>
> This leads to the one case in the kernel where copy_siginfo_to_user32
> does not use is_ia32_syscall() or is_x32_syscall() to see which kind of
> signal frame it needs to create.
>
> Andy, since you have been all over the entry point code in recent years
> do you know if we allow tasks that can do both ia32 and x86_64 system
> calls?  That seems to be what we the testing of ksig to see which kind
> of signal frame to setup is all about.

We do :(

> If we don't allow mixed abi's on x86_64 then can I see if I have a ia32
> task in setup_rt_frame by just calling is_ia32_syscall()?
>
> If we do allow mixed abi's do you know if it would be safe to
> temporarily play with orig_ax or current_thread_info()->status?

Maybe, but it’s a real minefield. I think the right fix is to use
sa_flags's SA_X32_ABI bit instead for the sigchld bit.  In general,
the is_..._syscall() helpers can't be expected to return anything
valid in any context other than a syscall, and handle_signal() is not
a syscall.

>
> My goal is to write two wrappers: copy_siginfo_to_user32_ia32, and
> copy_siginfo_to_user32_x32 around the ordinary copy_siginfo_to_user32.
> With only a runtime test to see which ABI we need to implement.
>
> Aka change:
>>case SIL_CHLD:
>>to->si_pid= from->si_pid;
>>to->si_uid= from->si_uid;
>>to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>if (x32_ABI) {
>>to->_sifields._sigchld_x32._utime = from->si_utime;
>>to->_sifields._sigchld_x32._stime = from->si_stime;
>>} else
>> #endif
>>{
>>to->si_utime = from->si_utime;
>>to->si_stime = from->si_stime;
>>}
>>break;
> to something like:
>>case SIL_CHLD:
>>to->si_pid= from->si_pid;
>>to->si_uid= from->si_uid;
>>to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>if (!is_ia32_syscall()) {
>>to->_sifields._sigchld_x32._utime = from->si_utime;
>>to->_sifields._sigchld_x32._stime = from->si_stime;
>>} else
>> #endif
>>{
>>to->si_utime = from->si_utime;
>>to->si_stime = from->si_stime;
>>}
>>break;
>

Makes sense, but can you get to sa_flags in there instead?

FWIW, I have a branch here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=execve

that contains a *massive* cleanup of some other x86 signal stuff.  I
need to dust it off and test it better.

Re: Q: Can we get rid of __copy_siginfo_to_user32?

[Andy Lutomirski]

> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman  wrote:
>
>
> Andy,
>
> I am looking at copy_siginfo_to_user32 and find it very unfortunate
> that x86 with _sigchld_x32 needs to be the odd man out.  I am looking
> at ways to simplify the special case.
>
> The core of the special case comes from:
> exit_to_usermode_loop
>  do_signal
>handle_signal
>   setup_rt_frame
>
>
> In setup_rt_frame the code looks at ksig to see which kind of signal
> frame should be written for the signal.
>
> This leads to the one case in the kernel where copy_siginfo_to_user32
> does not use is_ia32_syscall() or is_x32_syscall() to see which kind of
> signal frame it needs to create.
>
> Andy, since you have been all over the entry point code in recent years
> do you know if we allow tasks that can do both ia32 and x86_64 system
> calls?  That seems to be what we the testing of ksig to see which kind
> of signal frame to setup is all about.

We do :(

> If we don't allow mixed abi's on x86_64 then can I see if I have a ia32
> task in setup_rt_frame by just calling is_ia32_syscall()?
>
> If we do allow mixed abi's do you know if it would be safe to
> temporarily play with orig_ax or current_thread_info()->status?

Maybe, but it’s a real minefield. I think the right fix is to use
sa_flags's SA_X32_ABI bit instead for the sigchld bit.  In general,
the is_..._syscall() helpers can't be expected to return anything
valid in any context other than a syscall, and handle_signal() is not
a syscall.

>
> My goal is to write two wrappers: copy_siginfo_to_user32_ia32, and
> copy_siginfo_to_user32_x32 around the ordinary copy_siginfo_to_user32.
> With only a runtime test to see which ABI we need to implement.
>
> Aka change:
>>case SIL_CHLD:
>>to->si_pid= from->si_pid;
>>to->si_uid= from->si_uid;
>>to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>if (x32_ABI) {
>>to->_sifields._sigchld_x32._utime = from->si_utime;
>>to->_sifields._sigchld_x32._stime = from->si_stime;
>>} else
>> #endif
>>{
>>to->si_utime = from->si_utime;
>>to->si_stime = from->si_stime;
>>}
>>break;
> to something like:
>>case SIL_CHLD:
>>to->si_pid= from->si_pid;
>>to->si_uid= from->si_uid;
>>to->si_status = from->si_status;
>> #ifdef CONFIG_X86_X32_ABI
>>if (!is_ia32_syscall()) {
>>to->_sifields._sigchld_x32._utime = from->si_utime;
>>to->_sifields._sigchld_x32._stime = from->si_stime;
>>} else
>> #endif
>>{
>>to->si_utime = from->si_utime;
>>to->si_stime = from->si_stime;
>>}
>>break;
>

Makes sense, but can you get to sa_flags in there instead?

FWIW, I have a branch here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=execve

that contains a *massive* cleanup of some other x86 signal stuff.  I
need to dust it off and test it better.

Re: [PATCH] MAINTAINERS: Update ASPEED entry with details

[Joel Stanley]

Hey Arnd,

On 22 February 2018 at 15:33, Joel Stanley  wrote:
> I am interested in all ASPEED drivers, and the previous match wasn't
> grabbing files in nested directories. Use N instead.
>
> Add the arm kernel mailing list so that patches get reviewed there, and
> the linux-aspeed list which exists only so I can use patchwork to track
> patches.
>
> Add Andrew as a reviewer, because he is involved in reviewing ASPEED
> stuff.
>
> Signed-off-by: Joel Stanley 

can you please pick this one up? It would be great to get it into
fixes as Andrew and I have been missing being cc'd on stuff we would
have like to review.

Cheers,

Joel

> ---
>  MAINTAINERS | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9a7f76eadae9..1ebf49797175 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1226,10 +1226,15 @@ F:  
> Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>
>  ARM/ASPEED MACHINE SUPPORT
>  M: Joel Stanley 
> -S: Maintained
> +R: Andrew Jeffery 
> +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> +L: linux-asp...@lists.ozlabs.org (moderated for non-subscribers)
> +Q: https://patchwork.ozlabs.org/project/linux-aspeed/list/
> +S: Supported
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
>  F: arch/arm/mach-aspeed/
>  F: arch/arm/boot/dts/aspeed-*
> -F: drivers/*/*aspeed*
> +N: aspeed
>
>  ARM/ATMEL AT91 Clock Support
>  M: Boris Brezillon 
> --
> 2.15.1
>

Re: [PATCH] MAINTAINERS: Update ASPEED entry with details

[Joel Stanley]

Hey Arnd,

On 22 February 2018 at 15:33, Joel Stanley  wrote:
> I am interested in all ASPEED drivers, and the previous match wasn't
> grabbing files in nested directories. Use N instead.
>
> Add the arm kernel mailing list so that patches get reviewed there, and
> the linux-aspeed list which exists only so I can use patchwork to track
> patches.
>
> Add Andrew as a reviewer, because he is involved in reviewing ASPEED
> stuff.
>
> Signed-off-by: Joel Stanley 

can you please pick this one up? It would be great to get it into
fixes as Andrew and I have been missing being cc'd on stuff we would
have like to review.

Cheers,

Joel

> ---
>  MAINTAINERS | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9a7f76eadae9..1ebf49797175 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1226,10 +1226,15 @@ F:  
> Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>
>  ARM/ASPEED MACHINE SUPPORT
>  M: Joel Stanley 
> -S: Maintained
> +R: Andrew Jeffery 
> +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> +L: linux-asp...@lists.ozlabs.org (moderated for non-subscribers)
> +Q: https://patchwork.ozlabs.org/project/linux-aspeed/list/
> +S: Supported
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
>  F: arch/arm/mach-aspeed/
>  F: arch/arm/boot/dts/aspeed-*
> -F: drivers/*/*aspeed*
> +N: aspeed
>
>  ARM/ATMEL AT91 Clock Support
>  M: Boris Brezillon 
> --
> 2.15.1
>

Re: AMD graphics performance regression in 4.15 and later

[Gabriel C]

2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to comment since you have a better understanding of what's
>> going on.
>>
>> One last question: right now I'm running 4.15.0 with the "offending"
>> patch reverted. Is that safe to run or are there possible bad
>> interactions with other changes.
>
>
> That should work without problems.
>
> But I just had another idea as well, if you want you could still test the
> new code path which will be using in 4.17.
>

While Firefox may do some strange things is not about only Firefox.

With your patches my EPYC box is unusable with  4.15++ kernels.
The whole Desktop is acting weird.  This one is using
an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.

Box is  2 * EPYC 7281 with 128 GB ECC RAM

Also a 14C Xeon box with a HD7700 is broken same way.

Everything breaks in X .. scrolling , moving windows , flickering etc.


reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and
648bc3574716400acc06f99915815f80d9563783
from an 4.15 kernel makes things work again.


> Backporting all the detection logic is to invasive, but you could just go
> into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other
> code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
>

Well you really can't be serious about these suggestions ? Are you ?

Telling peoples to #if 0 random code is not a solution.

You broke existsing working userland with your patches and at least
please fix that for 4.16.

I can help testing code for 4.17/++ if you wish but that is *different* storry.

Regards,

Gabriel C

Re: AMD graphics performance regression in 4.15 and later

[Gabriel C]

2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to comment since you have a better understanding of what's
>> going on.
>>
>> One last question: right now I'm running 4.15.0 with the "offending"
>> patch reverted. Is that safe to run or are there possible bad
>> interactions with other changes.
>
>
> That should work without problems.
>
> But I just had another idea as well, if you want you could still test the
> new code path which will be using in 4.17.
>

While Firefox may do some strange things is not about only Firefox.

With your patches my EPYC box is unusable with  4.15++ kernels.
The whole Desktop is acting weird.  This one is using
an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.

Box is  2 * EPYC 7281 with 128 GB ECC RAM

Also a 14C Xeon box with a HD7700 is broken same way.

Everything breaks in X .. scrolling , moving windows , flickering etc.


reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and
648bc3574716400acc06f99915815f80d9563783
from an 4.15 kernel makes things work again.


> Backporting all the detection logic is to invasive, but you could just go
> into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other
> code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
>

Well you really can't be serious about these suggestions ? Are you ?

Telling peoples to #if 0 random code is not a solution.

You broke existsing working userland with your patches and at least
please fix that for 4.16.

I can help testing code for 4.17/++ if you wish but that is *different* storry.

Regards,

Gabriel C

[PATCH 2/2] module: Allow to always show the status of modsign

[Jia Zhang]

The sig_enforce parameter could be always shown to reflect the
current status of modsign. For the case of CONFIG_MODULE_SIG_FORCE=y,
this modification does nothing harmless.

Signed-off-by: Jia Zhang 
---
 kernel/module.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index f695474..1e3337b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -274,9 +274,7 @@ static void module_assert_mutex_or_preempt(void)
 }
 
 static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
-#ifndef CONFIG_MODULE_SIG_FORCE
 module_param(sig_enforce, bool_enable_only, 0644);
-#endif /* !CONFIG_MODULE_SIG_FORCE */
 
 /*
  * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
-- 
1.8.3.1

[PATCH 2/2] module: Allow to always show the status of modsign

[Jia Zhang]

The sig_enforce parameter could be always shown to reflect the
current status of modsign. For the case of CONFIG_MODULE_SIG_FORCE=y,
this modification does nothing harmless.

Signed-off-by: Jia Zhang 
---
 kernel/module.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index f695474..1e3337b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -274,9 +274,7 @@ static void module_assert_mutex_or_preempt(void)
 }
 
 static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
-#ifndef CONFIG_MODULE_SIG_FORCE
 module_param(sig_enforce, bool_enable_only, 0644);
-#endif /* !CONFIG_MODULE_SIG_FORCE */
 
 /*
  * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
-- 
1.8.3.1

[PATCH 1/2] module: Do not access sig_enforce directly

[Jia Zhang]

Call is_module_sig_enforced() instead.

Signed-off-by: Jia Zhang 
---
 kernel/module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index a6e43a5..f695474 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2785,7 +2785,7 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !is_module_sig_enforced())
err = 0;
 
return err;
-- 
1.8.3.1

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

[Buddy Lumpkin]

> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox  wrote:
> 
> On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote:
>> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote:
>>> The presence of direct reclaims 10 years ago was a fairly reliable
>>> indicator that too much was being asked of a Linux system. Kswapd was
>>> likely wasting time scanning pages that were ineligible for eviction.
>>> Adding RAM or reducing the working set size would usually make the problem
>>> go away. Since then hardware has evolved to bring a new struggle for
>>> kswapd. Storage speeds have increased by orders of magnitude while CPU
>>> clock speeds stayed the same or even slowed down in exchange for more
>>> cores per package. This presents a throughput problem for a single
>>> threaded kswapd that will get worse with each generation of new hardware.
>> 
>> AFAIR we used to scale the number of kswapd workers many years ago. It
>> just turned out to be not all that great. We have a kswapd reclaim
>> window for quite some time and that can allow to tune how much proactive
>> kswapd should be.
>> 
>> Also please note that the direct reclaim is a way to throttle overly
>> aggressive memory consumers. The more we do in the background context
>> the easier for them it will be to allocate faster. So I am not really
>> sure that more background threads will solve the underlying problem. It
>> is just a matter of memory hogs tunning to end in the very same
>> situtation AFAICS. Moreover the more they are going to allocate the more
>> less CPU time will _other_ (non-allocating) task get.
>> 
>>> Test Details
>> 
>> I will have to study this more to comment.
>> 
>> [...]
>>> By increasing the number of kswapd threads, throughput increased by ~50%
>>> while kernel mode CPU utilization decreased or stayed the same, likely due
>>> to a decrease in the number of parallel tasks at any given time doing page
>>> replacement.
>> 
>> Well, isn't that just an effect of more work being done on behalf of
>> other workload that might run along with your tests (and which doesn't
>> really need to allocate a lot of memory)? In other words how
>> does the patch behaves with a non-artificial mixed workloads?
>> 
>> Please note that I am not saying that we absolutely have to stick with the
>> current single-thread-per-node implementation but I would really like to
>> see more background on why we should be allowing heavy memory hogs to
>> allocate faster or how to prevent that. I would be also very interested
>> to see how to scale the number of threads based on how CPUs are utilized
>> by other workloads.
> 
> Yes, very much this.  If you have a single-threaded workload which is
> using the entirety of memory and would like to use even more, then it
> makes sense to use as many CPUs as necessary getting memory out of its
> way.  If you have N CPUs and N-1 threads happily occupying themselves in
> their own reasonably-sized working sets with one monster process trying
> to use as much RAM as possible, then I'd be pretty unimpressed to see
> the N-1 well-behaved threads preempted by kswapd.

A single thread cannot create the demand to keep any number of kswapd tasks
busy, so this memory hog is going to need to have multiple threads if it is 
going
to do any measurable damage to the amount of work performed by the compute
bound tasks, and once we increase the number of tasks used for the memory
hog, preemption is already happening.

So let’s say we are willing to accept that it is going to take multiple threads 
to
create enough demand to keep multiple kswapd tasks busy, we just do not want
any additional preemptions strictly due to additional kswapd tasks. You have to
consider, If we managed to create enough demand to keep multiple kswapd tasks
busy, then we are creating enough demand to trigger direct reclaims. A _lot_ of
direct reclaims, and direct reclaims consume A _lot_ of cpu. So if we are 
running
multiple kswapd threads, they might be preempting your N-1 threads, but if they
were not running, the memory hog tasks would be preempting your N-1 threads.

> 
> My biggest problem with the patch-as-presented is that it's yet one more
> thing for admins to get wrong.  We should spawn more threads automatically
> if system conditions are right to do that.

One thing about this patch-as-presented that an admin could get wrong is by
starting with a setting of 16, deciding that it didn’t help and reducing it 
back to
one. It allows for 16 threads because I actually saw a benefit with large 
numbers
of kswapd threads when a substantial amount of the memory pressure was 
created using anonymous memory mappings that do not involve the page cache.
This really is a special case, and the maximum number of threads allowed should
probably be reduced to a more sensible value like 8 or even 6 if there is 
concern
about admins doing the wrong thing.

[PATCH 1/2] module: Do not access sig_enforce directly

[Jia Zhang]

Call is_module_sig_enforced() instead.

Signed-off-by: Jia Zhang 
---
 kernel/module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index a6e43a5..f695474 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2785,7 +2785,7 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !is_module_sig_enforced())
err = 0;
 
return err;
-- 
1.8.3.1

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

[Buddy Lumpkin]

> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox  wrote:
> 
> On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote:
>> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote:
>>> The presence of direct reclaims 10 years ago was a fairly reliable
>>> indicator that too much was being asked of a Linux system. Kswapd was
>>> likely wasting time scanning pages that were ineligible for eviction.
>>> Adding RAM or reducing the working set size would usually make the problem
>>> go away. Since then hardware has evolved to bring a new struggle for
>>> kswapd. Storage speeds have increased by orders of magnitude while CPU
>>> clock speeds stayed the same or even slowed down in exchange for more
>>> cores per package. This presents a throughput problem for a single
>>> threaded kswapd that will get worse with each generation of new hardware.
>> 
>> AFAIR we used to scale the number of kswapd workers many years ago. It
>> just turned out to be not all that great. We have a kswapd reclaim
>> window for quite some time and that can allow to tune how much proactive
>> kswapd should be.
>> 
>> Also please note that the direct reclaim is a way to throttle overly
>> aggressive memory consumers. The more we do in the background context
>> the easier for them it will be to allocate faster. So I am not really
>> sure that more background threads will solve the underlying problem. It
>> is just a matter of memory hogs tunning to end in the very same
>> situtation AFAICS. Moreover the more they are going to allocate the more
>> less CPU time will _other_ (non-allocating) task get.
>> 
>>> Test Details
>> 
>> I will have to study this more to comment.
>> 
>> [...]
>>> By increasing the number of kswapd threads, throughput increased by ~50%
>>> while kernel mode CPU utilization decreased or stayed the same, likely due
>>> to a decrease in the number of parallel tasks at any given time doing page
>>> replacement.
>> 
>> Well, isn't that just an effect of more work being done on behalf of
>> other workload that might run along with your tests (and which doesn't
>> really need to allocate a lot of memory)? In other words how
>> does the patch behaves with a non-artificial mixed workloads?
>> 
>> Please note that I am not saying that we absolutely have to stick with the
>> current single-thread-per-node implementation but I would really like to
>> see more background on why we should be allowing heavy memory hogs to
>> allocate faster or how to prevent that. I would be also very interested
>> to see how to scale the number of threads based on how CPUs are utilized
>> by other workloads.
> 
> Yes, very much this.  If you have a single-threaded workload which is
> using the entirety of memory and would like to use even more, then it
> makes sense to use as many CPUs as necessary getting memory out of its
> way.  If you have N CPUs and N-1 threads happily occupying themselves in
> their own reasonably-sized working sets with one monster process trying
> to use as much RAM as possible, then I'd be pretty unimpressed to see
> the N-1 well-behaved threads preempted by kswapd.

A single thread cannot create the demand to keep any number of kswapd tasks
busy, so this memory hog is going to need to have multiple threads if it is 
going
to do any measurable damage to the amount of work performed by the compute
bound tasks, and once we increase the number of tasks used for the memory
hog, preemption is already happening.

So let’s say we are willing to accept that it is going to take multiple threads 
to
create enough demand to keep multiple kswapd tasks busy, we just do not want
any additional preemptions strictly due to additional kswapd tasks. You have to
consider, If we managed to create enough demand to keep multiple kswapd tasks
busy, then we are creating enough demand to trigger direct reclaims. A _lot_ of
direct reclaims, and direct reclaims consume A _lot_ of cpu. So if we are 
running
multiple kswapd threads, they might be preempting your N-1 threads, but if they
were not running, the memory hog tasks would be preempting your N-1 threads.

> 
> My biggest problem with the patch-as-presented is that it's yet one more
> thing for admins to get wrong.  We should spawn more threads automatically
> if system conditions are right to do that.

One thing about this patch-as-presented that an admin could get wrong is by
starting with a setting of 16, deciding that it didn’t help and reducing it 
back to
one. It allows for 16 threads because I actually saw a benefit with large 
numbers
of kswapd threads when a substantial amount of the memory pressure was 
created using anonymous memory mappings that do not involve the page cache.
This really is a special case, and the maximum number of threads allowed should
probably be reduced to a more sensible value like 8 or even 6 if there is 
concern
about admins doing the wrong thing.

[PATCH] spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()

[sxauwsk]

In case of xspi work in busy condition, may send bytes failed.
Add one bytes delay

Signed-off-by: sxauwsk 
Signed-off-by: guojian 
Signed-off-by: wangshikai 
---
 drivers/spi/spi-cadence.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index 5c9516a..66ae055 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -313,6 +313,12 @@ static void cdns_spi_fill_tx_fifo(struct cdns_spi *xspi)
 
while ((trans_cnt < CDNS_SPI_FIFO_DEPTH) &&
   (xspi->tx_bytes > 0)) {
+
+   /* When xspi in busy condition, bytes may send failed,
+* caused communication failure so add one byte delay
+*/
+   usleep_range(10, 20);
+
if (xspi->txbuf)
cdns_spi_write(xspi, CDNS_SPI_TXD, *xspi->txbuf++);
else
-- 
1.7.9.5

[PATCH] spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()

[sxauwsk]

In case of xspi work in busy condition, may send bytes failed.
Add one bytes delay

Signed-off-by: sxauwsk 
Signed-off-by: guojian 
Signed-off-by: wangshikai 
---
 drivers/spi/spi-cadence.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index 5c9516a..66ae055 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -313,6 +313,12 @@ static void cdns_spi_fill_tx_fifo(struct cdns_spi *xspi)
 
while ((trans_cnt < CDNS_SPI_FIFO_DEPTH) &&
   (xspi->tx_bytes > 0)) {
+
+   /* When xspi in busy condition, bytes may send failed,
+* caused communication failure so add one byte delay
+*/
+   usleep_range(10, 20);
+
if (xspi->txbuf)
cdns_spi_write(xspi, CDNS_SPI_TXD, *xspi->txbuf++);
else
-- 
1.7.9.5

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

[Kai Heng Feng]

Hi,


On Apr 3, 2018, at 4:51 PM, Thomas Gleixner  wrote:
Bah. The patch is broken. New version written with brain awake below.


Actually I can't reproduce this issue anymore on latest Linus' tree.

I'll do a bisect and ask linux-stable maintainer to include the commit.

Thanks for your help!

Kai-Heng



Thanks,

tglx

8<-
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -134,6 +134,10 @@ static bool migrate_one_irq(struct irq_d
brokeaff = false;
}

+   pr_info("IRQ%u: New affinity: %*pbl effective: %*pbl\n",
+   d->irq, cpumask_pr_args(affinity),
+   cpumask_pr_args(irq_data_get_effective_affinity_mask(d)));
+
if (maskchip && chip->irq_unmask)
chip->irq_unmask(d);

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

[Kai Heng Feng]

Hi,


On Apr 3, 2018, at 4:51 PM, Thomas Gleixner  wrote:
Bah. The patch is broken. New version written with brain awake below.


Actually I can't reproduce this issue anymore on latest Linus' tree.

I'll do a bisect and ask linux-stable maintainer to include the commit.

Thanks for your help!

Kai-Heng



Thanks,

tglx

8<-
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -134,6 +134,10 @@ static bool migrate_one_irq(struct irq_d
brokeaff = false;
}

+   pr_info("IRQ%u: New affinity: %*pbl effective: %*pbl\n",
+   d->irq, cpumask_pr_args(affinity),
+   cpumask_pr_args(irq_data_get_effective_affinity_mask(d)));
+
if (maskchip && chip->irq_unmask)
chip->irq_unmask(d);

Re: [PATCH v2] selftests/livepatch: introduce tests

[kbuild test robot]

Hi Joe,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16]
[also build test ERROR on next-20180410]
[cannot apply to linus/master jikos-livepatching/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joe-Lawrence/selftests-livepatch-introduce-tests/20180411-093112
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   lib/livepatch/test_klp_shadow_vars.c:76:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:76:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:79:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:79:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:79:16: sparse: got ret
   lib/livepatch/test_klp_shadow_vars.c:80:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:80:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:88:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:88:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:91:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:91:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:91:16: sparse: got ret
   lib/livepatch/test_klp_shadow_vars.c:92:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:92:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:97:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:97:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:99:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:99:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:104:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:104:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:106:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:106:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:114:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:114:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:117:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:117:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:117:16: sparse: got 0
   lib/livepatch/test_klp_shadow_vars.c:118:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:118:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:124:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:124:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:138:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:138:16: sparse: got 0
   lib/livepatch/test_klp_shadow_vars.c:139:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:139:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:140:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:140:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:141:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:141:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:142:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:142:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:149:13: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:149:13: sparse: got !
   lib/livepatch/test_klp_shadow_vars.c:149:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:164:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:164:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:164:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:168:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:168:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:168:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:172:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:172:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:172:9: sparse: Trying to use reserved 
word 'if' as ide

Re: [PATCH v2] selftests/livepatch: introduce tests

[kbuild test robot]

Hi Joe,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16]
[also build test ERROR on next-20180410]
[cannot apply to linus/master jikos-livepatching/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joe-Lawrence/selftests-livepatch-introduce-tests/20180411-093112
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   lib/livepatch/test_klp_shadow_vars.c:76:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:76:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:79:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:79:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:79:16: sparse: got ret
   lib/livepatch/test_klp_shadow_vars.c:80:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:80:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:88:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:88:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:91:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:91:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:91:16: sparse: got ret
   lib/livepatch/test_klp_shadow_vars.c:92:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:92:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:97:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:97:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:99:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:99:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:104:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:104:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:106:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:106:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:114:9: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:114:9: sparse: got "\001"
   lib/livepatch/test_klp_shadow_vars.c:117:9: sparse: Trying to use reserved 
word 'return' as identifier
   lib/livepatch/test_klp_shadow_vars.c:117:16: sparse: Expected ; at end of 
declaration
   lib/livepatch/test_klp_shadow_vars.c:117:16: sparse: got 0
   lib/livepatch/test_klp_shadow_vars.c:118:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:118:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:124:1: sparse: Expected ; at the end of 
type declaration
   lib/livepatch/test_klp_shadow_vars.c:124:1: sparse: got }
   lib/livepatch/test_klp_shadow_vars.c:138:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:138:16: sparse: got 0
   lib/livepatch/test_klp_shadow_vars.c:139:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:139:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:140:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:140:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:141:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:141:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:142:16: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:142:16: sparse: got &
   lib/livepatch/test_klp_shadow_vars.c:149:13: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:149:13: sparse: got !
   lib/livepatch/test_klp_shadow_vars.c:149:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:164:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:164:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:164:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:168:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:168:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:168:9: sparse: Trying to use reserved 
word 'if' as identifier
   lib/livepatch/test_klp_shadow_vars.c:172:17: sparse: Expected ) in function 
declarator
   lib/livepatch/test_klp_shadow_vars.c:172:17: sparse: got ==
   lib/livepatch/test_klp_shadow_vars.c:172:9: sparse: Trying to use reserved 
word 'if' as ide

[PATCH 1/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpci_init

[Jia-Ju Bai]

fcpci_init() is never called in atomic context.

The call chain ending up at fcpci_init() is:
[1] fcpci_init() <- fcpcipnp_setup() <- fcpnp_probe()

fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, fcpci_init()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/isdn/hisax/hisax_fcpcipnp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/hisax/hisax_fcpcipnp.c 
b/drivers/isdn/hisax/hisax_fcpcipnp.c
index e4f7573..4789c9d 100644
--- a/drivers/isdn/hisax/hisax_fcpcipnp.c
+++ b/drivers/isdn/hisax/hisax_fcpcipnp.c
@@ -706,7 +706,7 @@ static inline void fcpci_init(struct fritz_adapter *adapter)
 
outb(AVM_STATUS1_ENA_IOM | adapter->irq,
 adapter->io + AVM_STATUS1);
-   mdelay(10);
+   usleep_range(1, 11000);
 }
 
 // --
-- 
1.9.1

[PATCH 1/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpci_init

[Jia-Ju Bai]

fcpci_init() is never called in atomic context.

The call chain ending up at fcpci_init() is:
[1] fcpci_init() <- fcpcipnp_setup() <- fcpnp_probe()

fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, fcpci_init()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/isdn/hisax/hisax_fcpcipnp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/hisax/hisax_fcpcipnp.c 
b/drivers/isdn/hisax/hisax_fcpcipnp.c
index e4f7573..4789c9d 100644
--- a/drivers/isdn/hisax/hisax_fcpcipnp.c
+++ b/drivers/isdn/hisax/hisax_fcpcipnp.c
@@ -706,7 +706,7 @@ static inline void fcpci_init(struct fritz_adapter *adapter)
 
outb(AVM_STATUS1_ENA_IOM | adapter->irq,
 adapter->io + AVM_STATUS1);
-   mdelay(10);
+   usleep_range(1, 11000);
 }
 
 // --
-- 
1.9.1

Re: [PATCH v3 0/2] vhost: fix vhost_vq_access_ok() log check

[Jason Wang]

On 2018年04月11日 10:35, Stefan Hajnoczi wrote:

v3:
  * Rebased onto net/master and resolved conflict [DaveM]

v2:
  * Rewrote the conditional to make the vq access check clearer [Linus]
  * Added Patch 2 to make the return type consistent and harder to misuse 
[Linus]

The first patch fixes the vhost virtqueue access check which was recently
broken.  The second patch replaces the int return type with bool to prevent
future bugs.

Stefan Hajnoczi (2):
   vhost: fix vhost_vq_access_ok() log check
   vhost: return bool from *_access_ok() functions

  drivers/vhost/vhost.h |  4 +--
  drivers/vhost/vhost.c | 70 ++-
  2 files changed, 38 insertions(+), 36 deletions(-)



Acked-by: Jason Wang 

Thanks

[PATCH 2/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpcipnp_setup

[Jia-Ju Bai]

fcpcipnp_setup() is never called in atomic context.

The call chain ending up at fcpcipnp_setup() is:
[1] fcpcipnp_setup() <- fcpnp_probe()

fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, fcpcipnp_setup()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/isdn/hisax/hisax_fcpcipnp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/isdn/hisax/hisax_fcpcipnp.c 
b/drivers/isdn/hisax/hisax_fcpcipnp.c
index e4f7573..06068a42 100644
--- a/drivers/isdn/hisax/hisax_fcpcipnp.c
+++ b/drivers/isdn/hisax/hisax_fcpcipnp.c
@@ -772,11 +772,11 @@ static int fcpcipnp_setup(struct fritz_adapter *adapter)
 
// Reset
outb(0, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
outb(AVM_STATUS0_RESET, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
outb(0, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
 
switch (adapter->type) {
case AVM_FRITZ_PCIV2:
-- 
1.9.1

Re: [PATCH v3 0/2] vhost: fix vhost_vq_access_ok() log check

[Jason Wang]

On 2018年04月11日 10:35, Stefan Hajnoczi wrote:

v3:
  * Rebased onto net/master and resolved conflict [DaveM]

v2:
  * Rewrote the conditional to make the vq access check clearer [Linus]
  * Added Patch 2 to make the return type consistent and harder to misuse 
[Linus]

The first patch fixes the vhost virtqueue access check which was recently
broken.  The second patch replaces the int return type with bool to prevent
future bugs.

Stefan Hajnoczi (2):
   vhost: fix vhost_vq_access_ok() log check
   vhost: return bool from *_access_ok() functions

  drivers/vhost/vhost.h |  4 +--
  drivers/vhost/vhost.c | 70 ++-
  2 files changed, 38 insertions(+), 36 deletions(-)



Acked-by: Jason Wang 

Thanks

[PATCH 2/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpcipnp_setup

[Jia-Ju Bai]

fcpcipnp_setup() is never called in atomic context.

The call chain ending up at fcpcipnp_setup() is:
[1] fcpcipnp_setup() <- fcpnp_probe()

fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, fcpcipnp_setup()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/isdn/hisax/hisax_fcpcipnp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/isdn/hisax/hisax_fcpcipnp.c 
b/drivers/isdn/hisax/hisax_fcpcipnp.c
index e4f7573..06068a42 100644
--- a/drivers/isdn/hisax/hisax_fcpcipnp.c
+++ b/drivers/isdn/hisax/hisax_fcpcipnp.c
@@ -772,11 +772,11 @@ static int fcpcipnp_setup(struct fritz_adapter *adapter)
 
// Reset
outb(0, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
outb(AVM_STATUS0_RESET, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
outb(0, adapter->io + AVM_STATUS0);
-   mdelay(10);
+   usleep_range(1, 11000);
 
switch (adapter->type) {
case AVM_FRITZ_PCIV2:
-- 
1.9.1

[PATCH 3/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_isoc_urb_init

[Jia-Ju Bai]

usb_isoc_urb_init() is never called in atomic context.

The call chains ending up at usb_isoc_urb_init() are:
[1] usb_isoc_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_isoc_urb_init() calls usb_alloc_urb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..1efa4bd5 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -177,7 +177,7 @@ static int usb_isoc_urb_init(struct usb_data_stream *stream)
struct urb *urb;
int frame_offset = 0;
 
-   stream->urb_list[i] = 
usb_alloc_urb(stream->props.u.isoc.framesperurb, GFP_ATOMIC);
+   stream->urb_list[i] = 
usb_alloc_urb(stream->props.u.isoc.framesperurb, GFP_KERNEL);
if (!stream->urb_list[i]) {
deb_mem("not enough memory for urb_alloc_urb!\n");
for (j = 0; j < i; j++)
-- 
1.9.1

[PATCH 3/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_isoc_urb_init

[Jia-Ju Bai]

usb_isoc_urb_init() is never called in atomic context.

The call chains ending up at usb_isoc_urb_init() are:
[1] usb_isoc_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_isoc_urb_init() calls usb_alloc_urb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..1efa4bd5 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -177,7 +177,7 @@ static int usb_isoc_urb_init(struct usb_data_stream *stream)
struct urb *urb;
int frame_offset = 0;
 
-   stream->urb_list[i] = 
usb_alloc_urb(stream->props.u.isoc.framesperurb, GFP_ATOMIC);
+   stream->urb_list[i] = 
usb_alloc_urb(stream->props.u.isoc.framesperurb, GFP_KERNEL);
if (!stream->urb_list[i]) {
deb_mem("not enough memory for urb_alloc_urb!\n");
for (j = 0; j < i; j++)
-- 
1.9.1

Re: [PATCH] selftests/filesystems: Don't run dnotify_test by default

[Michael Ellerman]

Shuah Khan  writes:
> On 04/10/2018 03:45 AM, Christian Brauner wrote:
>> On Tue, Apr 10, 2018 at 04:20:53PM +1000, Michael Ellerman wrote:
>>> In commit ce290a19609d ("selftests: add devpts selftests"), the
>>> filesystems directory was added to the top-level selftests Makefile.
>>>
>>> That had the effect of causing the existing dnotify_test in the
>>> filesystems directory to now be run as part of the default selftests
>>> test-run. Unfortunately dnotify_test is actually an infinite loop.
>>>
>>> Fix it by moving dnotify_test to TEST_GEN_PROGS_EXTENDED, which says
>>> that it's a generated file (ie. built) but should not be run as part
>>> of the default test suite run (it's an "extendend" test).
>
> Typo - I can fix it when I apply it.

Oops, thanks.

>>> While we're here cleanup a few other things, devpts_pts should be in
>>> TEST_GEN_PROGS to indicate that it's built, and with the above two
>>> changes we no longer need a custom all or clean rule.
>>>
>>> Fixes: ce290a19609d ("selftests: add devpts selftests")
>>> Signed-off-by: Michael Ellerman 
>> 
>> I'm not sure if I should've made it to be built given that it wasn't
>> before but it probably doesn't hurt. It's either that or remove it I
>> guess.
>
> This way the test gets built and gets included in the installed tests.
> This way somebody can run it by itself.
>> 
>> Acked-by: Christian brauner 
>
> Thanks Michael. I will get this into 4.17-rc2 or rc3.

Thanks.

cheers

Re: [PATCH] selftests/filesystems: Don't run dnotify_test by default

[Michael Ellerman]

Shuah Khan  writes:
> On 04/10/2018 03:45 AM, Christian Brauner wrote:
>> On Tue, Apr 10, 2018 at 04:20:53PM +1000, Michael Ellerman wrote:
>>> In commit ce290a19609d ("selftests: add devpts selftests"), the
>>> filesystems directory was added to the top-level selftests Makefile.
>>>
>>> That had the effect of causing the existing dnotify_test in the
>>> filesystems directory to now be run as part of the default selftests
>>> test-run. Unfortunately dnotify_test is actually an infinite loop.
>>>
>>> Fix it by moving dnotify_test to TEST_GEN_PROGS_EXTENDED, which says
>>> that it's a generated file (ie. built) but should not be run as part
>>> of the default test suite run (it's an "extendend" test).
>
> Typo - I can fix it when I apply it.

Oops, thanks.

>>> While we're here cleanup a few other things, devpts_pts should be in
>>> TEST_GEN_PROGS to indicate that it's built, and with the above two
>>> changes we no longer need a custom all or clean rule.
>>>
>>> Fixes: ce290a19609d ("selftests: add devpts selftests")
>>> Signed-off-by: Michael Ellerman 
>> 
>> I'm not sure if I should've made it to be built given that it wasn't
>> before but it probably doesn't hurt. It's either that or remove it I
>> guess.
>
> This way the test gets built and gets included in the installed tests.
> This way somebody can run it by itself.
>> 
>> Acked-by: Christian brauner 
>
> Thanks Michael. I will get this into 4.17-rc2 or rc3.

Thanks.

cheers

[PATCH 2/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_bulk_urb_init

[Jia-Ju Bai]

usb_bulk_urb_init() is never called in atomic context.

The call chains ending up at usb_bulk_urb_init() are:
[1] usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_bulk_urb_init() calls usb_alloc_urb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..d6d62e8 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -144,7 +144,7 @@ static int usb_bulk_urb_init(struct usb_data_stream *stream)
 
/* allocate the URBs */
for (i = 0; i < stream->props.count; i++) {
-   stream->urb_list[i] = usb_alloc_urb(0, GFP_ATOMIC);
+   stream->urb_list[i] = usb_alloc_urb(0, GFP_KERNEL);
if (!stream->urb_list[i]) {
deb_mem("not enough memory for urb_alloc_urb!.\n");
for (j = 0; j < i; j++)
-- 
1.9.1

[PATCH 2/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_bulk_urb_init

[Jia-Ju Bai]

usb_bulk_urb_init() is never called in atomic context.

The call chains ending up at usb_bulk_urb_init() are:
[1] usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_bulk_urb_init() calls usb_alloc_urb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..d6d62e8 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -144,7 +144,7 @@ static int usb_bulk_urb_init(struct usb_data_stream *stream)
 
/* allocate the URBs */
for (i = 0; i < stream->props.count; i++) {
-   stream->urb_list[i] = usb_alloc_urb(0, GFP_ATOMIC);
+   stream->urb_list[i] = usb_alloc_urb(0, GFP_KERNEL);
if (!stream->urb_list[i]) {
deb_mem("not enough memory for urb_alloc_urb!.\n");
for (j = 0; j < i; j++)
-- 
1.9.1

[PATCH 1/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_allocate_stream_buffers

[Jia-Ju Bai]

usb_allocate_stream_buffers() is never called in atomic context.

The call chains ending up at usb_allocate_stream_buffers() are:
[1] usb_allocate_stream_buffers() <- usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
[2] usb_allocate_stream_buffers() <- usb_isoc_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_allocate_stream_buffers() calls usb_alloc_coherent() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..96be721 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -117,7 +117,7 @@ static int usb_allocate_stream_buffers(struct 
usb_data_stream *stream, int num,
for (stream->buf_num = 0; stream->buf_num < num; stream->buf_num++) {
deb_mem("allocating buffer %d\n",stream->buf_num);
if (( stream->buf_list[stream->buf_num] =
-   usb_alloc_coherent(stream->udev, size, 
GFP_ATOMIC,
+   usb_alloc_coherent(stream->udev, size, 
GFP_KERNEL,
>dma_addr[stream->buf_num]) ) 
== NULL) {
deb_mem("not enough memory for urb-buffer 
allocation.\n");
usb_free_stream_buffers(stream);
-- 
1.9.1

[PATCH 1/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_allocate_stream_buffers

[Jia-Ju Bai]

usb_allocate_stream_buffers() is never called in atomic context.

The call chains ending up at usb_allocate_stream_buffers() are:
[1] usb_allocate_stream_buffers() <- usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
[2] usb_allocate_stream_buffers() <- usb_isoc_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init 
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe including ttusb2_probe, vp7045_usb_probe, a800_probe, and so on.
These xxx_probe() functions are set as ".probe" in struct usb_driver.
And these functions are not called in atomic context.

Despite never getting called from atomic context,
usb_allocate_stream_buffers() calls usb_alloc_coherent() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/usb/dvb-usb/usb-urb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/usb-urb.c 
b/drivers/media/usb/dvb-usb/usb-urb.c
index 8917360..96be721 100644
--- a/drivers/media/usb/dvb-usb/usb-urb.c
+++ b/drivers/media/usb/dvb-usb/usb-urb.c
@@ -117,7 +117,7 @@ static int usb_allocate_stream_buffers(struct 
usb_data_stream *stream, int num,
for (stream->buf_num = 0; stream->buf_num < num; stream->buf_num++) {
deb_mem("allocating buffer %d\n",stream->buf_num);
if (( stream->buf_list[stream->buf_num] =
-   usb_alloc_coherent(stream->udev, size, 
GFP_ATOMIC,
+   usb_alloc_coherent(stream->udev, size, 
GFP_KERNEL,
>dma_addr[stream->buf_num]) ) 
== NULL) {
deb_mem("not enough memory for urb-buffer 
allocation.\n");
usb_free_stream_buffers(stream);
-- 
1.9.1

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

[Wei Yang]

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He  wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

[Wei Yang]

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>> 
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He  wrote:
>> > The struct resource uses singly linked list to link siblings. It's not
>> > easy to do reverse iteration on sibling list. So replace it with list_head.
>> 
>> Why is reverse iteration needed?
>
>This is the explanation I made when Andrew helped to review the v1 post:
>https://lkml.org/lkml/2018/3/23/78
>
>Because we have been using kexec-tools utility to search available
>System RAM space for loading kernel/initrd/purgatory from top to down.
>That is done in user space by searching /proc/iomem. While later added
>kexec_file interface, the searching code happened in kernel, and it
>only search System RAM region bottom up, then take an area in that found
>RAM region from top to down. We need unify these two interfaces on
>behaviour since they are the same on essense from the users' point of
>view, though implementation is different. As you know, the singly linked
>list implementation of the current resource's sibling linking, makes the
>searching from top to down very hard to satisfy people. 
>
>Below is the v1 post, we make an temporary array to copy iomem_resource's
>first level of children, then iterate the array reversedly. Andrew
>suggested me to try list_head after reviewing. In fact we can optimize
>that patch to only copy resource pointer into array, still the way is
>ugly.
>https://lkml.org/lkml/2018/3/21/952
>
>Then Wei pasted a patch he had made as below. He didn't mention if he
>also has requirement on reversed iteration of resource. That is an O(n*n)
>way, from personal feelings, hard to say if it's bettern than v1 post.
>https://lkml.org/lkml/2018/3/24/157

I don't have requirement on reverse iteration of resource structure.

My approach is almost the same as current walk_system_ram_res(). Since each
resource keeps parent, we could get previous resource by search on
res->parent->child.

The complexity of a whole iteration is O(N * W / 2), where N is the number of
resources in the tree and W is the average number of siblings of each
resource.

And this approach doesn't need to change current structure.

>
>That's why I would like to have a try of the list_head linking.
>

-- 
Wei Yang
Help you, Help me

RE: Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[Wang, Dongsheng]

> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Robin Murphy
> Sent: Monday, April 09, 2018 8:11 PM
> To: Wang, Dongsheng ; Lorenzo Pieralisi
> 
> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org; hanjun@linaro.org;
> sudeep.ho...@arm.com; Zheng, Joey ;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [此邮件可能存在风险] Re: [RFC PATCH 2/2] ACPI/IORT: use
> swiotlb_dma_ops when smmu probe failed
> 
> On 08/04/18 09:10, Wang, Dongsheng wrote:
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: Thursday, April 05, 2018 2:57 AM
> >> To: Lorenzo Pieralisi ; Wang, Dongsheng
> >> 
> >> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org;
> hanjun@linaro.org;
> >> sudeep.ho...@arm.com; Zheng, Joey ;
> >> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: [此邮件可能存在风险] Re: [RFC PATCH 2/2] ACPI/IORT: use
> >> swiotlb_dma_ops when smmu probe failed
> >>
> >> On 04/04/18 17:01, Lorenzo Pieralisi wrote:
> >>> [+cc Robin]
> >>>
> >>> On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote:
>  If SMMU probe failed, master should use swiotlb as dma ops.
>  SMMU may probe failed with specified environment, so there
>  are not any iommu resources in iommu_device_list.
> 
>  The master will always get EPROBE_DEFER from really_probe
>  (dma_configure) but in fact SMMU has probe failed. The issue
>  causes all of masters failed to be driven.
> >>
> >> Let's just take a step back - why is SMMU probe failing? That seems to
> >> be the primary issue here, because it implies that either your hardware,
> >> firmware or kernel is broken, any of which would make boot failure
> >> somewhat unsurprising anyway.
> >>
> > It's actually not a hardware issue. This is my test case, just return
> > -EINVAL in arm_smmu_device_probe. The HW
> probe(arm_smmu_device_hw_probe)
> > is just part of SMMU driver probe and the failure may be caused by SW. So
> > I design this case, just make sure even if SMMU probe failed that cause by 
> > SW,
> > the MASTER also can work. _Because of our SMMU default mode is bypass._
> 
> I don't think it's particularly justifiable to make core API changes for
> the sake of contrived testcases. On real systems, the SMMU is a
> fundamental system component which is no more expected to fail probe
> than, say, the GIC, and as such if it *does* fail then further progress
> is on a best-effort basis at most.
Yes. Agree with you.


> Just because *your* system happens to work fine in this state doesn't make it 
> true for every SMMU
> implementation and integration that Linux may ever run on.
:(, yes, this is my mistake.


>   
> If you want the kernel to ignore an SMMU, either configure out the
> driver or don't describe that SMMU in firmware in the first place.
> 
> >>> I added Robin to pick his brain. An alternative would consist
> >>> in using a bus notifier to prevent deferred probing once the SMMU
> >>> driver probing failed but that seems backwards given that a major
> >>> reason to move to deferred probing was to remove the bus notifiers
> >>> dependency in the first place.
> >>>
> >>> It seems to me this is both an OF/ACPI issue - it is not an IORT
> >>> only problem.
> >>
> >> Yes, this is just an instance of the general probe-deferral problem,
> >> e.g. once you have multiple dependencies it's possible to end up in a
> >> stalemate where everything including the IOMMU ends up on the deferred
> >> probe list with nothing to kick it and make progress again.
> >>
> >> Furthermore it seems to me that the whole premise in this patch is
> >> flawed,
> > Ditto. :)
> >
> >
> >> since even genuine probe failure may well be transient - just
> >> because one attempt failed doesn't mean a later attempt can't succeed.
> >> Thus "the most recent probe attempt failed" cannot be considered a
> >> fundamentally different state from "no driver is currently bound".
> >>
> > Agree, the genuine probe failure may well be transient. But there is
> > depend on SMMU probe(IOMMU instance) status. There are two situations:
> >
> > 1. MASTER probing, SMMU doesn't probe yet.
> > This case will match "the transient failure".
> > really_probe get an EPROBE_DEFER from IORT and the MASTER probe will
> be
> > delayed until SMMU probe successful.
> > 2. MASTER probing, SMMU probe has failed.
> > really_probe will always get an EPROBE_DEFER from IORT, because kernel
> > has build in SMMU driver.(iort_iommu_driver_enabled) And the master
> > never cannot do probe.
> >
> > The case 2 is I want to handle.
> 
> Handle it by not deliberately breaking the SMMU driver. In all other
> cases, either re-triggering SMMU probe might make it 

RE: Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[Wang, Dongsheng]

> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Robin Murphy
> Sent: Monday, April 09, 2018 8:11 PM
> To: Wang, Dongsheng ; Lorenzo Pieralisi
> 
> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org; hanjun@linaro.org;
> sudeep.ho...@arm.com; Zheng, Joey ;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [此邮件可能存在风险] Re: [RFC PATCH 2/2] ACPI/IORT: use
> swiotlb_dma_ops when smmu probe failed
> 
> On 08/04/18 09:10, Wang, Dongsheng wrote:
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: Thursday, April 05, 2018 2:57 AM
> >> To: Lorenzo Pieralisi ; Wang, Dongsheng
> >> 
> >> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org;
> hanjun@linaro.org;
> >> sudeep.ho...@arm.com; Zheng, Joey ;
> >> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: [此邮件可能存在风险] Re: [RFC PATCH 2/2] ACPI/IORT: use
> >> swiotlb_dma_ops when smmu probe failed
> >>
> >> On 04/04/18 17:01, Lorenzo Pieralisi wrote:
> >>> [+cc Robin]
> >>>
> >>> On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote:
>  If SMMU probe failed, master should use swiotlb as dma ops.
>  SMMU may probe failed with specified environment, so there
>  are not any iommu resources in iommu_device_list.
> 
>  The master will always get EPROBE_DEFER from really_probe
>  (dma_configure) but in fact SMMU has probe failed. The issue
>  causes all of masters failed to be driven.
> >>
> >> Let's just take a step back - why is SMMU probe failing? That seems to
> >> be the primary issue here, because it implies that either your hardware,
> >> firmware or kernel is broken, any of which would make boot failure
> >> somewhat unsurprising anyway.
> >>
> > It's actually not a hardware issue. This is my test case, just return
> > -EINVAL in arm_smmu_device_probe. The HW
> probe(arm_smmu_device_hw_probe)
> > is just part of SMMU driver probe and the failure may be caused by SW. So
> > I design this case, just make sure even if SMMU probe failed that cause by 
> > SW,
> > the MASTER also can work. _Because of our SMMU default mode is bypass._
> 
> I don't think it's particularly justifiable to make core API changes for
> the sake of contrived testcases. On real systems, the SMMU is a
> fundamental system component which is no more expected to fail probe
> than, say, the GIC, and as such if it *does* fail then further progress
> is on a best-effort basis at most.
Yes. Agree with you.


> Just because *your* system happens to work fine in this state doesn't make it 
> true for every SMMU
> implementation and integration that Linux may ever run on.
:(, yes, this is my mistake.


>   
> If you want the kernel to ignore an SMMU, either configure out the
> driver or don't describe that SMMU in firmware in the first place.
> 
> >>> I added Robin to pick his brain. An alternative would consist
> >>> in using a bus notifier to prevent deferred probing once the SMMU
> >>> driver probing failed but that seems backwards given that a major
> >>> reason to move to deferred probing was to remove the bus notifiers
> >>> dependency in the first place.
> >>>
> >>> It seems to me this is both an OF/ACPI issue - it is not an IORT
> >>> only problem.
> >>
> >> Yes, this is just an instance of the general probe-deferral problem,
> >> e.g. once you have multiple dependencies it's possible to end up in a
> >> stalemate where everything including the IOMMU ends up on the deferred
> >> probe list with nothing to kick it and make progress again.
> >>
> >> Furthermore it seems to me that the whole premise in this patch is
> >> flawed,
> > Ditto. :)
> >
> >
> >> since even genuine probe failure may well be transient - just
> >> because one attempt failed doesn't mean a later attempt can't succeed.
> >> Thus "the most recent probe attempt failed" cannot be considered a
> >> fundamentally different state from "no driver is currently bound".
> >>
> > Agree, the genuine probe failure may well be transient. But there is
> > depend on SMMU probe(IOMMU instance) status. There are two situations:
> >
> > 1. MASTER probing, SMMU doesn't probe yet.
> > This case will match "the transient failure".
> > really_probe get an EPROBE_DEFER from IORT and the MASTER probe will
> be
> > delayed until SMMU probe successful.
> > 2. MASTER probing, SMMU probe has failed.
> > really_probe will always get an EPROBE_DEFER from IORT, because kernel
> > has build in SMMU driver.(iort_iommu_driver_enabled) And the master
> > never cannot do probe.
> >
> > The case 2 is I want to handle.
> 
> Handle it by not deliberately breaking the SMMU driver. In all other
> cases, either re-triggering SMMU probe might make it succeed (i.e. the
> DL_DEV_PROBE_FAILED state is meaningless), or things are so broken that
> you're probably dead in the water anyway.
> 
Drop this patch.

Thanks for your 

Re: [PATCH] writeback: safer lock nesting

[Greg Thelen]

On Tue, Apr 10, 2018 at 7:44 PM Wang Long  wrote:

> > Hi,
> >
> > [This is an automated email]
> >
> > This commit has been processed by the -stable helper bot and determined
> > to be a high probability candidate for -stable trees. (score: 44.5575)
> >
> > The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33,
v4.9.93, v4.4.127.
> >
> > v4.16.1: Build OK!
> > v4.15.16: Build OK!
> > v4.14.33: Build OK!
> > v4.9.93: Build OK!
> > v4.4.127: Failed to apply! Possible dependencies:
> >  62cccb8c8e7a ("mm: simplify lock_page_memcg()")
> Hi Sasha,

> I test the memory cgroup in lts v4.4, for this issue, 62cccb8c8e7a ("mm:
> simplify lock_page_memcg()")
> need to adjust and there are several other places that need to be fixed.

> I will make the patch for lts v4.4 if no one did.

I'm testing a 4.4-stable patch right now.  ETA is a few hours.

Re: [PATCH] writeback: safer lock nesting

[Greg Thelen]

On Tue, Apr 10, 2018 at 7:44 PM Wang Long  wrote:

> > Hi,
> >
> > [This is an automated email]
> >
> > This commit has been processed by the -stable helper bot and determined
> > to be a high probability candidate for -stable trees. (score: 44.5575)
> >
> > The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33,
v4.9.93, v4.4.127.
> >
> > v4.16.1: Build OK!
> > v4.15.16: Build OK!
> > v4.14.33: Build OK!
> > v4.9.93: Build OK!
> > v4.4.127: Failed to apply! Possible dependencies:
> >  62cccb8c8e7a ("mm: simplify lock_page_memcg()")
> Hi Sasha,

> I test the memory cgroup in lts v4.4, for this issue, 62cccb8c8e7a ("mm:
> simplify lock_page_memcg()")
> need to adjust and there are several other places that need to be fixed.

> I will make the patch for lts v4.4 if no one did.

I'm testing a 4.4-stable patch right now.  ETA is a few hours.

Re: usercopy whitelist woe in scsi_sense_cache

[Kees Cook]

On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
 wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :(
>
>
> For your convenience I've prepared a VM that contains a reproducer.

Awesome. :)

> Under the /root folder there is a reproducer script (reproducer.sh). It does
> trivial things like enabling sysrq, opening LUKS device, mounting a volume,
> running a background I/O (this is an important part, actually, since I
> wasn't able to trigger the issue without the background I/O) and, finally,
> running the smartctl in a loop. If you are lucky, within a minute or two
> you'll get the first warning followed shortly by subsequent bugs and I/O
> stall (htop is pre-installed for your convenience too).

Yup!

[   27.729498] Bad or missing usercopy whitelist? Kernel memory
exposure attempt detected from SLUB object 'scsi_sense_cache' (offset
76, size 22)!

I'll see about booting with my own kernels, etc, and try to narrow this down. :)

-Kees

-- 
Kees Cook
Pixel Security

Re: usercopy whitelist woe in scsi_sense_cache

[Kees Cook]

On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
 wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :(
>
>
> For your convenience I've prepared a VM that contains a reproducer.

Awesome. :)

> Under the /root folder there is a reproducer script (reproducer.sh). It does
> trivial things like enabling sysrq, opening LUKS device, mounting a volume,
> running a background I/O (this is an important part, actually, since I
> wasn't able to trigger the issue without the background I/O) and, finally,
> running the smartctl in a loop. If you are lucky, within a minute or two
> you'll get the first warning followed shortly by subsequent bugs and I/O
> stall (htop is pre-installed for your convenience too).

Yup!

[   27.729498] Bad or missing usercopy whitelist? Kernel memory
exposure attempt detected from SLUB object 'scsi_sense_cache' (offset
76, size 22)!

I'll see about booting with my own kernels, etc, and try to narrow this down. :)

-Kees

-- 
Kees Cook
Pixel Security

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Jason Wang]

On 2018年04月10日 05:11, Jonathan Helman wrote:



On 03/22/2018 07:38 PM, Jason Wang wrote:



On 2018年03月22日 11:10, Michael S. Tsirkin wrote:

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:

On 2018年03月20日 12:26, Jonathan Helman wrote:

On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:



On 2018年03月20日 06:14, Jonathan Helman wrote:

Export the number of successful and failed hugetlb page
allocations via the virtio balloon driver. These 2 counts
come directly from the vm_events HTLB_BUDDY_PGALLOC and
HTLB_BUDDY_PGALLOC_FAIL.

Signed-off-by: Jonathan Helman

Reviewed-by: Jason Wang

Thanks.


---
   drivers/virtio/virtio_balloon.c | 6 ++
   include/uapi/linux/virtio_balloon.h | 4 +++-
   2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c 
b/drivers/virtio/virtio_balloon.c

index dfe5684..6b237e3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -272,6 +272,12 @@ static unsigned int 
update_balloon_stats(struct virtio_balloon *vb)

   pages_to_bytes(events[PSWPOUT]));
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, 
events[PGMAJFAULT]);
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, 
events[PGFAULT]);

+#ifdef CONFIG_HUGETLB_PAGE
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
+    events[HTLB_BUDDY_PGALLOC]);
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
+    events[HTLB_BUDDY_PGALLOC_FAIL]);
+#endif
   #endif
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
   pages_to_bytes(i.freeram));
diff --git a/include/uapi/linux/virtio_balloon.h 
b/include/uapi/linux/virtio_balloon.h

index 4e8b830..40297a3 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -53,7 +53,9 @@ struct virtio_balloon_config {
   #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of 
memory */
   #define VIRTIO_BALLOON_S_AVAIL    6   /* Available memory as 
in /proc */

   #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
-#define VIRTIO_BALLOON_S_NR   8
+#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page 
allocations */
+#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page 
allocation failures */

+#define VIRTIO_BALLOON_S_NR   10
 /*
    * Memory statistics structure.
Not for this patch, but it looks to me that exporting such nr 
through uapi is fragile.

Sorry, can you explain what you mean here?

Jon
Spec said "Within an output buffer submitted to the statsq, the 
device MUST
ignore entries with tag values that it does not recognize". So 
exporting
VIRTIO_BALLOON_S_NR seems useless and device implementation can not 
depend

on such number in uapi.

Thanks

Suggestions? I don't like to break build for people ...



Didn't have a good idea. But maybe we should keep VIRTIO_BALLOON_S_NR 
unchanged, and add a comment here.


Thanks


I think Jason's comment is for a future patch. Didn't see this patch 
get applied, so wondering if it could be.


Thanks,
Jon


Hi Jon:

Have you tested new driver with old qemu?

Thanks

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Jason Wang]

On 2018年04月10日 05:11, Jonathan Helman wrote:



On 03/22/2018 07:38 PM, Jason Wang wrote:



On 2018年03月22日 11:10, Michael S. Tsirkin wrote:

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:

On 2018年03月20日 12:26, Jonathan Helman wrote:

On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:



On 2018年03月20日 06:14, Jonathan Helman wrote:

Export the number of successful and failed hugetlb page
allocations via the virtio balloon driver. These 2 counts
come directly from the vm_events HTLB_BUDDY_PGALLOC and
HTLB_BUDDY_PGALLOC_FAIL.

Signed-off-by: Jonathan Helman

Reviewed-by: Jason Wang

Thanks.


---
   drivers/virtio/virtio_balloon.c | 6 ++
   include/uapi/linux/virtio_balloon.h | 4 +++-
   2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c 
b/drivers/virtio/virtio_balloon.c

index dfe5684..6b237e3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -272,6 +272,12 @@ static unsigned int 
update_balloon_stats(struct virtio_balloon *vb)

   pages_to_bytes(events[PSWPOUT]));
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, 
events[PGMAJFAULT]);
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, 
events[PGFAULT]);

+#ifdef CONFIG_HUGETLB_PAGE
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
+    events[HTLB_BUDDY_PGALLOC]);
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
+    events[HTLB_BUDDY_PGALLOC_FAIL]);
+#endif
   #endif
   update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
   pages_to_bytes(i.freeram));
diff --git a/include/uapi/linux/virtio_balloon.h 
b/include/uapi/linux/virtio_balloon.h

index 4e8b830..40297a3 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -53,7 +53,9 @@ struct virtio_balloon_config {
   #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of 
memory */
   #define VIRTIO_BALLOON_S_AVAIL    6   /* Available memory as 
in /proc */

   #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
-#define VIRTIO_BALLOON_S_NR   8
+#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page 
allocations */
+#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page 
allocation failures */

+#define VIRTIO_BALLOON_S_NR   10
 /*
    * Memory statistics structure.
Not for this patch, but it looks to me that exporting such nr 
through uapi is fragile.

Sorry, can you explain what you mean here?

Jon
Spec said "Within an output buffer submitted to the statsq, the 
device MUST
ignore entries with tag values that it does not recognize". So 
exporting
VIRTIO_BALLOON_S_NR seems useless and device implementation can not 
depend

on such number in uapi.

Thanks

Suggestions? I don't like to break build for people ...



Didn't have a good idea. But maybe we should keep VIRTIO_BALLOON_S_NR 
unchanged, and add a comment here.


Thanks


I think Jason's comment is for a future patch. Didn't see this patch 
get applied, so wondering if it could be.


Thanks,
Jon


Hi Jon:

Have you tested new driver with old qemu?

Thanks