Re: [PATCH] HID: picolcd: remove unused variable

[Bruno Prémont]

Hi Jiapeng,

This is a dupe of a fix already sent two weeks ago by Lee Jones.

see series "Rid W=1 warnings from HID".


@Benjamin: At first glance the patch will not break anything.
   I've had no time though to check what 
 struct hid_device_id.raw_event
   expects as return value to verify if we can just drop ret
   or rather effectively should return something specific based
   on it.

Bruno

On Wed,  7 Apr 2021 14:39:22 +0800 Jiapeng Chong wrote:
> Fix the following gcc warning:
> 
> drivers/hid/hid-picolcd_core.c:332:6: warning: variable ‘ret’ set but
> not used [-Wunused-but-set-variable].
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/hid/hid-picolcd_core.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> index 1b5c632..682c2a2 100644
> --- a/drivers/hid/hid-picolcd_core.c
> +++ b/drivers/hid/hid-picolcd_core.c
> @@ -329,7 +329,6 @@ static int picolcd_raw_event(struct hid_device *hdev,
>  {
>   struct picolcd_data *data = hid_get_drvdata(hdev);
>   unsigned long flags;
> - int ret = 0;
>  
>   if (!data)
>   return 1;
> @@ -342,9 +341,9 @@ static int picolcd_raw_event(struct hid_device *hdev,
>  
>   if (report->id == REPORT_KEY_STATE) {
>   if (data->input_keys)
> - ret = picolcd_raw_keypad(data, report, raw_data+1, 
> size-1);
> + picolcd_raw_keypad(data, report, raw_data+1, size-1);
>   } else if (report->id == REPORT_IR_DATA) {
> - ret = picolcd_raw_cir(data, report, raw_data+1, size-1);
> + picolcd_raw_cir(data, report, raw_data+1, size-1);
>   } else {
>   spin_lock_irqsave(>lock, flags);
>   /*

Re: [PATCH 1/2] HID: do not call hid_set_drvdata(hdev, NULL) in drivers

[Bruno Prémont]

On Mon, 12 Aug 2019 18:27:39 +0200 Benjamin Tissoires wrote:
> This is a common pattern in the HID drivers to reset the drvdata. Some
> do it properly, some do it only in case of failure.
> 
> But, this is actually already handled by driver core, so there is no need
> to do it manually.
> 
> Signed-off-by: Benjamin Tissoires 

For hid-picolcd_core.c:
  Acked-by: Bruno Prémont 

> ---
>  drivers/hid/hid-cougar.c   | 6 ++
>  drivers/hid/hid-gfrm.c | 7 ---
>  drivers/hid/hid-lenovo.c   | 2 --
>  drivers/hid/hid-picolcd_core.c | 7 +--
>  drivers/hid/hid-sensor-hub.c   | 1 -
>  5 files changed, 3 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/hid/hid-cougar.c b/drivers/hid/hid-cougar.c
> index e0bb7b34f3a4..4ff3bc1d25e2 100644
> --- a/drivers/hid/hid-cougar.c
> +++ b/drivers/hid/hid-cougar.c
> @@ -207,7 +207,7 @@ static int cougar_probe(struct hid_device *hdev,
>   error = hid_parse(hdev);
>   if (error) {
>   hid_err(hdev, "parse failed\n");
> - goto fail;
> + return error;
>   }
>  
>   if (hdev->collection->usage == COUGAR_VENDOR_USAGE) {
> @@ -219,7 +219,7 @@ static int cougar_probe(struct hid_device *hdev,
>   error = hid_hw_start(hdev, connect_mask);
>   if (error) {
>   hid_err(hdev, "hw start failed\n");
> - goto fail;
> + return error;
>   }
>  
>   error = cougar_bind_shared_data(hdev, cougar);
> @@ -249,8 +249,6 @@ static int cougar_probe(struct hid_device *hdev,
>  
>  fail_stop_and_cleanup:
>   hid_hw_stop(hdev);
> -fail:
> - hid_set_drvdata(hdev, NULL);
>   return error;
>  }
>  
> diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
> index 86c317320bf2..699186ff2349 100644
> --- a/drivers/hid/hid-gfrm.c
> +++ b/drivers/hid/hid-gfrm.c
> @@ -123,12 +123,6 @@ static int gfrm_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   return ret;
>  }
>  
> -static void gfrm_remove(struct hid_device *hdev)
> -{
> - hid_hw_stop(hdev);
> - hid_set_drvdata(hdev, NULL);
> -}
> -
>  static const struct hid_device_id gfrm_devices[] = {
>   { HID_BLUETOOTH_DEVICE(0x58, 0x2000),
>   .driver_data = GFRM100 },
> @@ -142,7 +136,6 @@ static struct hid_driver gfrm_driver = {
>   .name = "gfrm",
>   .id_table = gfrm_devices,
>   .probe = gfrm_probe,
> - .remove = gfrm_remove,
>   .input_mapping = gfrm_input_mapping,
>   .raw_event = gfrm_raw_event,
>   .input_configured = gfrm_input_configured,
> diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
> index 364bc7f11d9d..96fa2a2c2cd3 100644
> --- a/drivers/hid/hid-lenovo.c
> +++ b/drivers/hid/hid-lenovo.c
> @@ -866,8 +866,6 @@ static void lenovo_remove_tpkbd(struct hid_device *hdev)
>  
>   led_classdev_unregister(_pointer->led_micmute);
>   led_classdev_unregister(_pointer->led_mute);
> -
> - hid_set_drvdata(hdev, NULL);
>  }
>  
>  static void lenovo_remove_cptkbd(struct hid_device *hdev)
> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> index 5f7a39a5d4af..1b5c63241af0 100644
> --- a/drivers/hid/hid-picolcd_core.c
> +++ b/drivers/hid/hid-picolcd_core.c
> @@ -534,8 +534,7 @@ static int picolcd_probe(struct hid_device *hdev,
>   data = kzalloc(sizeof(struct picolcd_data), GFP_KERNEL);
>   if (data == NULL) {
>   hid_err(hdev, "can't allocate space for Minibox PicoLCD device 
> data\n");
> - error = -ENOMEM;
> - goto err_no_cleanup;
> + return -ENOMEM;
>   }
>  
>   spin_lock_init(>lock);
> @@ -597,9 +596,6 @@ static int picolcd_probe(struct hid_device *hdev,
>   hid_hw_stop(hdev);
>  err_cleanup_data:
>   kfree(data);
> -err_no_cleanup:
> - hid_set_drvdata(hdev, NULL);
> -
>   return error;
>  }
>  
> @@ -635,7 +631,6 @@ static void picolcd_remove(struct hid_device *hdev)
>   picolcd_exit_cir(data);
>   picolcd_exit_keys(data);
>  
> - hid_set_drvdata(hdev, NULL);
>   mutex_destroy(>mutex);
>   /* Finally, clean up the picolcd data itself */
>   kfree(data);
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index be92a6f79687..94c7398b5c27 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -742,7 +742,6 @@ static void sensor_hub_remove(struct hid_device *hdev)
>   }
>   spin_unlock_irqrestore(>lock, flags);
>   mfd_remove_devices(>dev);
> - hid_set_drvdata(hdev, NULL);
>   mutex_destroy(>mutex);
>  }
>  

CGroup-v2: Memory: current impossibly high for empty cgroup

[Bruno Prémont]

With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is
considering itself as permanently over-limit and OOM-kill any process
I try to move into it (it's currently empty!)


I can't hand out a simple reproducer right now, but it seems during
accounting the counter went "negative".

CGroupv2 is mounted on /sys/fs/cgroup/hosting/ and the leaf-cgroup is
/sys/fs/cgroup/hosting/websrv/:
cgroup.controllers:cpu io memory pids
cgroup.events:populated 0
cgroup.max.depth:max
cgroup.max.descendants:max
cgroup.stat:nr_descendants 0
cgroup.stat:nr_dying_descendants 0
cgroup.type:domain
cpu.max:max 10
cpu.stat:usage_usec 48830679
cpu.stat:user_usec 25448590
cpu.stat:system_usec 23382088
cpu.stat:nr_periods 0
cpu.stat:nr_throttled 0
cpu.stat:throttled_usec 0
cpu.weight:100
cpu.weight.nice:0
io.bfq.weight:100
io.stat:8:0 rbytes=143360 wbytes=32768 rios=24 wios=7
io.stat:7:0 rbytes=51687424 wbytes=0 rios=12619 wios=0
io.weight:default 100
memory.current:18446744073694965760
memory.events:low 0
memory.events:high 0
memory.events:max 114
memory.events:oom 15
memory.events:oom_kill 8
memory.high:8589934592
memory.low:4294967296
memory.max:17179869184
memory.stat:anon 0
memory.stat:file 0
memory.stat:kernel_stack 0
memory.stat:slab 593920
memory.stat:sock 0
memory.stat:shmem 0
memory.stat:file_mapped 0
memory.stat:file_dirty 0
memory.stat:file_writeback 0
memory.stat:inactive_anon 0
memory.stat:active_anon 0
memory.stat:inactive_file 0
memory.stat:active_file 0
memory.stat:unevictable 0
memory.stat:slab_reclaimable 204800
memory.stat:slab_unreclaimable 389120
memory.stat:pgfault 80983
memory.stat:pgmajfault 259
memory.stat:pgrefill 115
memory.stat:pgscan 384
memory.stat:pgsteal 263
memory.stat:pgactivate 100
memory.stat:pgdeactivate 115
memory.stat:pglazyfree 0
memory.stat:pglazyfreed 0
memory.stat:workingset_refault 0
memory.stat:workingset_activate 0
memory.stat:workingset_nodereclaim 3
pids.current:0
pids.events:max 0
pids.max:max

cgroup.procs is empty.


Possibly interesting content in kernel log:
[580391.746367] WARNING: CPU: 1 PID: 24354 at 
/data/kernel/linux-4.15/mm/page_counter.c:27 page_counter_cancel+0x10/0x20
[580391.746498] Modules linked in: floppy
[580391.746551] CPU: 1 PID: 24354 Comm: image-starter Not tainted 
4.15.2-x86_64-vmware #2
[580391.746612] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference 
Platform, BIOS VMW71.00V.0.B64.1508272355 08/27/2015
[580391.746716] RIP: 0010:page_counter_cancel+0x10/0x20
[580391.746767] RSP: 0018:ad4f8475fb08 EFLAGS: 00010293
[580391.746819] RAX: 0005 RBX: ad4f8475fb38 RCX: 
000e
[580391.746877] RDX: a058b6a51148 RSI: 000e RDI: 
a058b6a51148
[580391.746935] RBP: 000e R08: 00022b30 R09: 
0c4c
[580391.746993] R10: 0004 R11:  R12: 
ad4f8475fb38
[580391.747051] R13: bbc68df8 R14: ad4f8475fd30 R15: 
0001
[580391.747117] FS:  7fd5e3b84740() GS:a058bdd0() 
knlGS:
[580391.747178] CS:  0010 DS:  ES:  CR0: 80050033
[580391.747233] CR2: 016fa3e8 CR3: 05c0a001 CR4: 
000606a0
[580391.747344] Call Trace:
[580391.747400]  page_counter_uncharge+0x16/0x20
[580391.747450]  uncharge_batch+0x2e/0x150
[580391.747503]  mem_cgroup_uncharge_list+0x54/0x60
[580391.747555]  release_pages+0x2f6/0x330
[580391.747609]  __pagevec_release+0x25/0x30
[580391.747659]  truncate_inode_pages_range+0x251/0x6e0
[580391.747712]  ? write_cache_pages+0x311/0x350
[580391.747763]  __blkdev_put+0x6f/0x1e0
[580391.747815]  deactivate_locked_super+0x2a/0x60
[580391.747870]  cleanup_mnt+0x40/0x60
[580391.747921]  task_work_run+0x7b/0xa0
[580391.747975]  do_exit+0x38d/0x960
[580391.749543]  do_group_exit+0x99/0xa0
[580391.750525]  SyS_exit_group+0xb/0x10
[580391.751457]  do_syscall_64+0x74/0x120
[580391.752427]  entry_SYSCALL_64_after_hwframe+0x21/0x86
[580391.753370] RIP: 0033:0x7fd5e3463529
[580391.754290] RSP: 002b:7ffdaad73478 EFLAGS: 0206 ORIG_RAX: 
00e7
[580391.755205] RAX: ffda RBX: 2d220011 RCX: 
7fd5e3463529
[580391.756119] RDX:  RSI: 7ffdaad732dc RDI: 

[580391.758421] RBP:  R08: 003c R09: 
00e7
[580391.759590] R10: ff80 R11: 0206 R12: 
7ffdaad72480
[580391.760499] R13: 1000 R14: 016f8080 R15: 

[580391.761366] Code: eb 07 e8 f4 26 fb ff eb d0 48 c7 c7 00 40 c3 bb e8 46 50 
44 00 89 d8 5b 5d c3 90 48 89 f0 48 f7 d8 f0 48 0f c1 07 48 39 f0 79 02 <0f> ff 
c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 eb 19 48 89 f0
[580391.763136] ---[ end trace 60c773f283acdb6f ]---
[580393.195186] image-starter invoked oom-killer: 
gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
[580393.199401] image-starter cpuset=/ mems_allowed=0
[580393.201491] CPU: 1 PID: 28447 Comm: 

CGroup-v2: Memory: current impossibly high for empty cgroup

[Bruno Prémont]

With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is
considering itself as permanently over-limit and OOM-kill any process
I try to move into it (it's currently empty!)


I can't hand out a simple reproducer right now, but it seems during
accounting the counter went "negative".

CGroupv2 is mounted on /sys/fs/cgroup/hosting/ and the leaf-cgroup is
/sys/fs/cgroup/hosting/websrv/:
cgroup.controllers:cpu io memory pids
cgroup.events:populated 0
cgroup.max.depth:max
cgroup.max.descendants:max
cgroup.stat:nr_descendants 0
cgroup.stat:nr_dying_descendants 0
cgroup.type:domain
cpu.max:max 10
cpu.stat:usage_usec 48830679
cpu.stat:user_usec 25448590
cpu.stat:system_usec 23382088
cpu.stat:nr_periods 0
cpu.stat:nr_throttled 0
cpu.stat:throttled_usec 0
cpu.weight:100
cpu.weight.nice:0
io.bfq.weight:100
io.stat:8:0 rbytes=143360 wbytes=32768 rios=24 wios=7
io.stat:7:0 rbytes=51687424 wbytes=0 rios=12619 wios=0
io.weight:default 100
memory.current:18446744073694965760
memory.events:low 0
memory.events:high 0
memory.events:max 114
memory.events:oom 15
memory.events:oom_kill 8
memory.high:8589934592
memory.low:4294967296
memory.max:17179869184
memory.stat:anon 0
memory.stat:file 0
memory.stat:kernel_stack 0
memory.stat:slab 593920
memory.stat:sock 0
memory.stat:shmem 0
memory.stat:file_mapped 0
memory.stat:file_dirty 0
memory.stat:file_writeback 0
memory.stat:inactive_anon 0
memory.stat:active_anon 0
memory.stat:inactive_file 0
memory.stat:active_file 0
memory.stat:unevictable 0
memory.stat:slab_reclaimable 204800
memory.stat:slab_unreclaimable 389120
memory.stat:pgfault 80983
memory.stat:pgmajfault 259
memory.stat:pgrefill 115
memory.stat:pgscan 384
memory.stat:pgsteal 263
memory.stat:pgactivate 100
memory.stat:pgdeactivate 115
memory.stat:pglazyfree 0
memory.stat:pglazyfreed 0
memory.stat:workingset_refault 0
memory.stat:workingset_activate 0
memory.stat:workingset_nodereclaim 3
pids.current:0
pids.events:max 0
pids.max:max

cgroup.procs is empty.


Possibly interesting content in kernel log:
[580391.746367] WARNING: CPU: 1 PID: 24354 at 
/data/kernel/linux-4.15/mm/page_counter.c:27 page_counter_cancel+0x10/0x20
[580391.746498] Modules linked in: floppy
[580391.746551] CPU: 1 PID: 24354 Comm: image-starter Not tainted 
4.15.2-x86_64-vmware #2
[580391.746612] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference 
Platform, BIOS VMW71.00V.0.B64.1508272355 08/27/2015
[580391.746716] RIP: 0010:page_counter_cancel+0x10/0x20
[580391.746767] RSP: 0018:ad4f8475fb08 EFLAGS: 00010293
[580391.746819] RAX: 0005 RBX: ad4f8475fb38 RCX: 
000e
[580391.746877] RDX: a058b6a51148 RSI: 000e RDI: 
a058b6a51148
[580391.746935] RBP: 000e R08: 00022b30 R09: 
0c4c
[580391.746993] R10: 0004 R11:  R12: 
ad4f8475fb38
[580391.747051] R13: bbc68df8 R14: ad4f8475fd30 R15: 
0001
[580391.747117] FS:  7fd5e3b84740() GS:a058bdd0() 
knlGS:
[580391.747178] CS:  0010 DS:  ES:  CR0: 80050033
[580391.747233] CR2: 016fa3e8 CR3: 05c0a001 CR4: 
000606a0
[580391.747344] Call Trace:
[580391.747400]  page_counter_uncharge+0x16/0x20
[580391.747450]  uncharge_batch+0x2e/0x150
[580391.747503]  mem_cgroup_uncharge_list+0x54/0x60
[580391.747555]  release_pages+0x2f6/0x330
[580391.747609]  __pagevec_release+0x25/0x30
[580391.747659]  truncate_inode_pages_range+0x251/0x6e0
[580391.747712]  ? write_cache_pages+0x311/0x350
[580391.747763]  __blkdev_put+0x6f/0x1e0
[580391.747815]  deactivate_locked_super+0x2a/0x60
[580391.747870]  cleanup_mnt+0x40/0x60
[580391.747921]  task_work_run+0x7b/0xa0
[580391.747975]  do_exit+0x38d/0x960
[580391.749543]  do_group_exit+0x99/0xa0
[580391.750525]  SyS_exit_group+0xb/0x10
[580391.751457]  do_syscall_64+0x74/0x120
[580391.752427]  entry_SYSCALL_64_after_hwframe+0x21/0x86
[580391.753370] RIP: 0033:0x7fd5e3463529
[580391.754290] RSP: 002b:7ffdaad73478 EFLAGS: 0206 ORIG_RAX: 
00e7
[580391.755205] RAX: ffda RBX: 2d220011 RCX: 
7fd5e3463529
[580391.756119] RDX:  RSI: 7ffdaad732dc RDI: 

[580391.758421] RBP:  R08: 003c R09: 
00e7
[580391.759590] R10: ff80 R11: 0206 R12: 
7ffdaad72480
[580391.760499] R13: 1000 R14: 016f8080 R15: 

[580391.761366] Code: eb 07 e8 f4 26 fb ff eb d0 48 c7 c7 00 40 c3 bb e8 46 50 
44 00 89 d8 5b 5d c3 90 48 89 f0 48 f7 d8 f0 48 0f c1 07 48 39 f0 79 02 <0f> ff 
c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 eb 19 48 89 f0
[580391.763136] ---[ end trace 60c773f283acdb6f ]---
[580393.195186] image-starter invoked oom-killer: 
gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
[580393.199401] image-starter cpuset=/ mems_allowed=0
[580393.201491] CPU: 1 PID: 28447 Comm: 

Re: CGroup-v2: Memory: current impossibly high for empty cgroup

[Bruno Prémont]

On Thu, 15 Feb 2018 09:40:24 +0100 Bruno Prémont wrote:
> With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is
> considering itself as permanently over-limit and OOM-kill any process
> I try to move into it (it's currently empty!)
> 
> 
> I can't hand out a simple reproducer right now, but it seems during
> accounting the counter went "negative".
> 
> CGroupv2 is mounted on /sys/fs/cgroup/hosting/ and the leaf-cgroup is
> /sys/fs/cgroup/hosting/websrv/:
> cgroup.controllers:cpu io memory pids
> cgroup.events:populated 0
> cgroup.max.depth:max
> cgroup.max.descendants:max
> cgroup.stat:nr_descendants 0
> cgroup.stat:nr_dying_descendants 0
> cgroup.type:domain
> cpu.max:max 10
> cpu.stat:usage_usec 48830679
> cpu.stat:user_usec 25448590
> cpu.stat:system_usec 23382088
> cpu.stat:nr_periods 0
> cpu.stat:nr_throttled 0
> cpu.stat:throttled_usec 0
> cpu.weight:100
> cpu.weight.nice:0
> io.bfq.weight:100
> io.stat:8:0 rbytes=143360 wbytes=32768 rios=24 wios=7
> io.stat:7:0 rbytes=51687424 wbytes=0 rios=12619 wios=0
> io.weight:default 100
> memory.current:18446744073694965760
> memory.events:low 0
> memory.events:high 0
> memory.events:max 114
> memory.events:oom 15
> memory.events:oom_kill 8
> memory.high:8589934592
> memory.low:4294967296
> memory.max:17179869184
> memory.stat:anon 0
> memory.stat:file 0
> memory.stat:kernel_stack 0
> memory.stat:slab 593920
> memory.stat:sock 0
> memory.stat:shmem 0
> memory.stat:file_mapped 0
> memory.stat:file_dirty 0
> memory.stat:file_writeback 0
> memory.stat:inactive_anon 0
> memory.stat:active_anon 0
> memory.stat:inactive_file 0
> memory.stat:active_file 0
> memory.stat:unevictable 0
> memory.stat:slab_reclaimable 204800
> memory.stat:slab_unreclaimable 389120
> memory.stat:pgfault 80983
> memory.stat:pgmajfault 259
> memory.stat:pgrefill 115
> memory.stat:pgscan 384
> memory.stat:pgsteal 263
> memory.stat:pgactivate 100
> memory.stat:pgdeactivate 115
> memory.stat:pglazyfree 0
> memory.stat:pglazyfreed 0
> memory.stat:workingset_refault 0
> memory.stat:workingset_activate 0
> memory.stat:workingset_nodereclaim 3
> pids.current:0
> pids.events:max 0
> pids.max:max
> 
> cgroup.procs is empty.
> 
> 
> Possibly interesting content in kernel log:
> [580391.746367] WARNING: CPU: 1 PID: 24354 at 
> /data/kernel/linux-4.15/mm/page_counter.c:27 page_counter_cancel+0x10/0x20
> [580391.746498] Modules linked in: floppy
> [580391.746551] CPU: 1 PID: 24354 Comm: image-starter Not tainted 
> 4.15.2-x86_64-vmware #2
> [580391.746612] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference 
> Platform, BIOS VMW71.00V.0.B64.1508272355 08/27/2015
> [580391.746716] RIP: 0010:page_counter_cancel+0x10/0x20
> [580391.746767] RSP: 0018:ad4f8475fb08 EFLAGS: 00010293
> [580391.746819] RAX: 0005 RBX: ad4f8475fb38 RCX: 
> 000e
> [580391.746877] RDX: a058b6a51148 RSI: 000e RDI: 
> a058b6a51148
> [580391.746935] RBP: 000e R08: 00022b30 R09: 
> 0c4c
> [580391.746993] R10: 0004 R11:  R12: 
> ad4f8475fb38
> [580391.747051] R13: bbc68df8 R14: ad4f8475fd30 R15: 
> 0001
> [580391.747117] FS:  7fd5e3b84740() GS:a058bdd0() 
> knlGS:
> [580391.747178] CS:  0010 DS:  ES:  CR0: 80050033
> [580391.747233] CR2: 016fa3e8 CR3: 05c0a001 CR4: 
> 000606a0
> [580391.747344] Call Trace:
> [580391.747400]  page_counter_uncharge+0x16/0x20
> [580391.747450]  uncharge_batch+0x2e/0x150
> [580391.747503]  mem_cgroup_uncharge_list+0x54/0x60
> [580391.747555]  release_pages+0x2f6/0x330
> [580391.747609]  __pagevec_release+0x25/0x30
> [580391.747659]  truncate_inode_pages_range+0x251/0x6e0
> [580391.747712]  ? write_cache_pages+0x311/0x350
> [580391.747763]  __blkdev_put+0x6f/0x1e0
> [580391.747815]  deactivate_locked_super+0x2a/0x60
> [580391.747870]  cleanup_mnt+0x40/0x60
> [580391.747921]  task_work_run+0x7b/0xa0
> [580391.747975]  do_exit+0x38d/0x960
> [580391.749543]  do_group_exit+0x99/0xa0
> [580391.750525]  SyS_exit_group+0xb/0x10
> [580391.751457]  do_syscall_64+0x74/0x120
> [580391.752427]  entry_SYSCALL_64_after_hwframe+0x21/0x86
> [580391.753370] RIP: 0033:0x7fd5e3463529
> [580391.754290] RSP: 002b:7ffdaad73478 EFLAGS: 0206 ORIG_RAX: 
> 00e7
> [580391.755205] RAX: ffda RBX: 2d220011 RCX: 
> 7fd5e3463529
> [580391.756119] RDX:  RSI: 7ffdaad732dc RDI: 
> 
> [580391.758421] RBP:  R08: 003c R09:

Re: CGroup-v2: Memory: current impossibly high for empty cgroup

[Bruno Prémont]

On Thu, 15 Feb 2018 09:40:24 +0100 Bruno Prémont wrote:
> With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is
> considering itself as permanently over-limit and OOM-kill any process
> I try to move into it (it's currently empty!)
> 
> 
> I can't hand out a simple reproducer right now, but it seems during
> accounting the counter went "negative".
> 
> CGroupv2 is mounted on /sys/fs/cgroup/hosting/ and the leaf-cgroup is
> /sys/fs/cgroup/hosting/websrv/:
> cgroup.controllers:cpu io memory pids
> cgroup.events:populated 0
> cgroup.max.depth:max
> cgroup.max.descendants:max
> cgroup.stat:nr_descendants 0
> cgroup.stat:nr_dying_descendants 0
> cgroup.type:domain
> cpu.max:max 10
> cpu.stat:usage_usec 48830679
> cpu.stat:user_usec 25448590
> cpu.stat:system_usec 23382088
> cpu.stat:nr_periods 0
> cpu.stat:nr_throttled 0
> cpu.stat:throttled_usec 0
> cpu.weight:100
> cpu.weight.nice:0
> io.bfq.weight:100
> io.stat:8:0 rbytes=143360 wbytes=32768 rios=24 wios=7
> io.stat:7:0 rbytes=51687424 wbytes=0 rios=12619 wios=0
> io.weight:default 100
> memory.current:18446744073694965760
> memory.events:low 0
> memory.events:high 0
> memory.events:max 114
> memory.events:oom 15
> memory.events:oom_kill 8
> memory.high:8589934592
> memory.low:4294967296
> memory.max:17179869184
> memory.stat:anon 0
> memory.stat:file 0
> memory.stat:kernel_stack 0
> memory.stat:slab 593920
> memory.stat:sock 0
> memory.stat:shmem 0
> memory.stat:file_mapped 0
> memory.stat:file_dirty 0
> memory.stat:file_writeback 0
> memory.stat:inactive_anon 0
> memory.stat:active_anon 0
> memory.stat:inactive_file 0
> memory.stat:active_file 0
> memory.stat:unevictable 0
> memory.stat:slab_reclaimable 204800
> memory.stat:slab_unreclaimable 389120
> memory.stat:pgfault 80983
> memory.stat:pgmajfault 259
> memory.stat:pgrefill 115
> memory.stat:pgscan 384
> memory.stat:pgsteal 263
> memory.stat:pgactivate 100
> memory.stat:pgdeactivate 115
> memory.stat:pglazyfree 0
> memory.stat:pglazyfreed 0
> memory.stat:workingset_refault 0
> memory.stat:workingset_activate 0
> memory.stat:workingset_nodereclaim 3
> pids.current:0
> pids.events:max 0
> pids.max:max
> 
> cgroup.procs is empty.
> 
> 
> Possibly interesting content in kernel log:
> [580391.746367] WARNING: CPU: 1 PID: 24354 at 
> /data/kernel/linux-4.15/mm/page_counter.c:27 page_counter_cancel+0x10/0x20
> [580391.746498] Modules linked in: floppy
> [580391.746551] CPU: 1 PID: 24354 Comm: image-starter Not tainted 
> 4.15.2-x86_64-vmware #2
> [580391.746612] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference 
> Platform, BIOS VMW71.00V.0.B64.1508272355 08/27/2015
> [580391.746716] RIP: 0010:page_counter_cancel+0x10/0x20
> [580391.746767] RSP: 0018:ad4f8475fb08 EFLAGS: 00010293
> [580391.746819] RAX: 0005 RBX: ad4f8475fb38 RCX: 
> 000e
> [580391.746877] RDX: a058b6a51148 RSI: 000e RDI: 
> a058b6a51148
> [580391.746935] RBP: 000e R08: 00022b30 R09: 
> 0c4c
> [580391.746993] R10: 0004 R11:  R12: 
> ad4f8475fb38
> [580391.747051] R13: bbc68df8 R14: ad4f8475fd30 R15: 
> 0001
> [580391.747117] FS:  7fd5e3b84740() GS:a058bdd0() 
> knlGS:
> [580391.747178] CS:  0010 DS:  ES:  CR0: 80050033
> [580391.747233] CR2: 016fa3e8 CR3: 05c0a001 CR4: 
> 000606a0
> [580391.747344] Call Trace:
> [580391.747400]  page_counter_uncharge+0x16/0x20
> [580391.747450]  uncharge_batch+0x2e/0x150
> [580391.747503]  mem_cgroup_uncharge_list+0x54/0x60
> [580391.747555]  release_pages+0x2f6/0x330
> [580391.747609]  __pagevec_release+0x25/0x30
> [580391.747659]  truncate_inode_pages_range+0x251/0x6e0
> [580391.747712]  ? write_cache_pages+0x311/0x350
> [580391.747763]  __blkdev_put+0x6f/0x1e0
> [580391.747815]  deactivate_locked_super+0x2a/0x60
> [580391.747870]  cleanup_mnt+0x40/0x60
> [580391.747921]  task_work_run+0x7b/0xa0
> [580391.747975]  do_exit+0x38d/0x960
> [580391.749543]  do_group_exit+0x99/0xa0
> [580391.750525]  SyS_exit_group+0xb/0x10
> [580391.751457]  do_syscall_64+0x74/0x120
> [580391.752427]  entry_SYSCALL_64_after_hwframe+0x21/0x86
> [580391.753370] RIP: 0033:0x7fd5e3463529
> [580391.754290] RSP: 002b:7ffdaad73478 EFLAGS: 0206 ORIG_RAX: 
> 00e7
> [580391.755205] RAX: ffda RBX: 2d220011 RCX: 
> 7fd5e3463529
> [580391.756119] RDX:  RSI: 7ffdaad732dc RDI: 
> 
> [580391.758421] RBP:  R08: 003c R09:

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sun, 12 Nov 2017 18:29:06 Bruno Prémont wrote:
> On Sun, 12 November 2017 "Paul E. McKenney" wrote:
> > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote:  
> > > On Sat, 11 November 2017 "Paul E. McKenney" wrote:
> > > > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:
> > > > > Hi,
> > > > > 
> > > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > > > > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > > > > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > > > > reason.
> > > > > 
> > > > > All info I have is following console dump (from 4.13.11):
> > > > > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > > > > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > > > > softirq=37393463/37393463 fqs=0
> > > > > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > > > > [526415.290012] rcu_sched kthread starved for 745854 jiffies! 
> > > > > g23779976 c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0  
> > > > 
> > > > The above line says that the rcu_sched kthread asked to sleep for three
> > > > jiffies, but ended up sleeping for more than 745,854 jiffies.
> > > > 
> > > > If your system does not let the RCU's kernel threads run, RCU cannot
> > > > help you much.
> > > > 
> > > > The ->state of 0x0 indicates that the kthread is in fact runnable, but
> > > > did not get a chance to run.  Was the system heavily loaded to the
> > > > point where you would expect a kthread to remain preempted for many
> > > > minutes?
> > > > 
> > > > I am guessing that the answer is no, given that CPU 0 is actually idle
> > > > (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> > > > kthread to a specific CPU?
> > > 
> > > The system should be lightly loaded (about 5-10% CPU usage on average), so
> > > plenty of time for RCU to do its work.
> > > 
> > > I didn't bind processes (be it userspace process or kthread) to a specific
> > > CPU, thus it's all auto-configured.
> > > 
> > > I guess the question then is what is the system busy with or waiting for
> > > that prevents RCU to get its work done...
> > > Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I 
> > > might need
> > > to check at which log level and make sure that loglevel reaches console.
> > > Nothing did hit the disk though.
> > 
> > Do you have a high-speed interface to capture and store console output?
> > (As in something that can handle, say, 50MB in a reasonable period of
> > time.)  
> 
> The only option I could have is netconsole, in the hope it does not cause
> issues by itself!
> 
> Other than that I have a poor man's web-VNC kind of view on VGA-sized
> text console, which is slow and small (it's a virtual server at a hosting
> company).

Got a new stall "caught early" with some partial trace output. System
had been running for nearly 24 hours though did have some IO load (rsync
over SSH of data mountpoint) at the time of stall.

Attaching the screen-shotted output which might help pointing in some
direction.
This time there is a stack-trace with some possibly useful content
(I did tune console log level to include everything `dmesg -n 8`)

It seems to point to native_safe_halt+0x6/0x10 with some interrupt
interaction. Unfortunately one of the trace halves was never rendered on
the web-VNC console...

Partially transcribed trace:
  __do_softirq+0xe5/0x1f0
  irq_exit+0xbf/0xd0
  do_IRQ+0x4a/0xc0
  comon_interrupt+0x89/0x89
 RIP: 0010:native_safe_halt+0x6/0x10
 ... (register dump)
  
  default_idle+0x9/0x10
  arch_cup_idle+0xa/0x10
  default_idle_Call+0x1e/0x30
  do_idle+0x16d/0x190
  cpu_startup_entry+0x5f/0x70
  rest_init+0xab/0xb0
  start_kernel+0x3b7/0x3c4
  ? early_idt_handler_array+0x120/0x120
  x86_64_start_reservations+0x2/0x2c
  x86_64_start_kernel+0xe6/0xf3
  secondary_startup_64+0x9f/0x9f


Thanks,
Bruno

> > Thanx, Paul
> >   
> > > Thanks,
> > > Bruno
> > > 
> > > > Thanx, Paul
> > > > 
> > > > > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > > [swapper/0:0]
> > > > > [526468.020005]

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sun, 12 Nov 2017 18:29:06 Bruno Prémont wrote:
> On Sun, 12 November 2017 "Paul E. McKenney" wrote:
> > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote:  
> > > On Sat, 11 November 2017 "Paul E. McKenney" wrote:
> > > > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:
> > > > > Hi,
> > > > > 
> > > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > > > > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > > > > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > > > > reason.
> > > > > 
> > > > > All info I have is following console dump (from 4.13.11):
> > > > > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > > > > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > > > > softirq=37393463/37393463 fqs=0
> > > > > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > > > > [526415.290012] rcu_sched kthread starved for 745854 jiffies! 
> > > > > g23779976 c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0  
> > > > 
> > > > The above line says that the rcu_sched kthread asked to sleep for three
> > > > jiffies, but ended up sleeping for more than 745,854 jiffies.
> > > > 
> > > > If your system does not let the RCU's kernel threads run, RCU cannot
> > > > help you much.
> > > > 
> > > > The ->state of 0x0 indicates that the kthread is in fact runnable, but
> > > > did not get a chance to run.  Was the system heavily loaded to the
> > > > point where you would expect a kthread to remain preempted for many
> > > > minutes?
> > > > 
> > > > I am guessing that the answer is no, given that CPU 0 is actually idle
> > > > (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> > > > kthread to a specific CPU?
> > > 
> > > The system should be lightly loaded (about 5-10% CPU usage on average), so
> > > plenty of time for RCU to do its work.
> > > 
> > > I didn't bind processes (be it userspace process or kthread) to a specific
> > > CPU, thus it's all auto-configured.
> > > 
> > > I guess the question then is what is the system busy with or waiting for
> > > that prevents RCU to get its work done...
> > > Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I 
> > > might need
> > > to check at which log level and make sure that loglevel reaches console.
> > > Nothing did hit the disk though.
> > 
> > Do you have a high-speed interface to capture and store console output?
> > (As in something that can handle, say, 50MB in a reasonable period of
> > time.)  
> 
> The only option I could have is netconsole, in the hope it does not cause
> issues by itself!
> 
> Other than that I have a poor man's web-VNC kind of view on VGA-sized
> text console, which is slow and small (it's a virtual server at a hosting
> company).

Got a new stall "caught early" with some partial trace output. System
had been running for nearly 24 hours though did have some IO load (rsync
over SSH of data mountpoint) at the time of stall.

Attaching the screen-shotted output which might help pointing in some
direction.
This time there is a stack-trace with some possibly useful content
(I did tune console log level to include everything `dmesg -n 8`)

It seems to point to native_safe_halt+0x6/0x10 with some interrupt
interaction. Unfortunately one of the trace halves was never rendered on
the web-VNC console...

Partially transcribed trace:
  __do_softirq+0xe5/0x1f0
  irq_exit+0xbf/0xd0
  do_IRQ+0x4a/0xc0
  comon_interrupt+0x89/0x89
 RIP: 0010:native_safe_halt+0x6/0x10
 ... (register dump)
  
  default_idle+0x9/0x10
  arch_cup_idle+0xa/0x10
  default_idle_Call+0x1e/0x30
  do_idle+0x16d/0x190
  cpu_startup_entry+0x5f/0x70
  rest_init+0xab/0xb0
  start_kernel+0x3b7/0x3c4
  ? early_idt_handler_array+0x120/0x120
  x86_64_start_reservations+0x2/0x2c
  x86_64_start_kernel+0xe6/0xf3
  secondary_startup_64+0x9f/0x9f


Thanks,
Bruno

> > Thanx, Paul
> >   
> > > Thanks,
> > > Bruno
> > > 
> > > > Thanx, Paul
> > > > 
> > > > > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > > [swapper/0:0]
> > > > > [526468.020005]

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sun, 12 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:

> On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote:
> > On Sat, 11 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> 
> > wrote:  
> > > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:  
> > > > Hi,
> > > > 
> > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > > > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > > > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > > > reason.
> > > > 
> > > > All info I have is following console dump (from 4.13.11):
> > > > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > > > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > > > softirq=37393463/37393463 fqs=0
> > > > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > > > [526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
> > > > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > 
> > > The above line says that the rcu_sched kthread asked to sleep for three
> > > jiffies, but ended up sleeping for more than 745,854 jiffies.
> > > 
> > > If your system does not let the RCU's kernel threads run, RCU cannot
> > > help you much.
> > > 
> > > The ->state of 0x0 indicates that the kthread is in fact runnable, but
> > > did not get a chance to run.  Was the system heavily loaded to the
> > > point where you would expect a kthread to remain preempted for many
> > > minutes?
> > > 
> > > I am guessing that the answer is no, given that CPU 0 is actually idle
> > > (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> > > kthread to a specific CPU?  
> > 
> > The system should be lightly loaded (about 5-10% CPU usage on average), so
> > plenty of time for RCU to do its work.
> > 
> > I didn't bind processes (be it userspace process or kthread) to a specific
> > CPU, thus it's all auto-configured.
> > 
> > I guess the question then is what is the system busy with or waiting for
> > that prevents RCU to get its work done...
> > Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I might 
> > need
> > to check at which log level and make sure that loglevel reaches console.
> > Nothing did hit the disk though.  
> 
> Do you have a high-speed interface to capture and store console output?
> (As in something that can handle, say, 50MB in a reasonable period of
> time.)

The only option I could have is netconsole, in the hope it does not cause
issues by itself!

Other than that I have a poor man's web-VNC kind of view on VGA-sized
text console, which is slow and small (it's a virtual server at a hosting
company).

Thanks,
Bruno

>   Thanx, Paul
> 
> > Thanks,
> > Bruno
> >   
> > >   Thanx, Paul
> > >   
> > > > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526478.320009] INFO: rcu_sched self-detected stall on CPU
> > > > [526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
> > > > softirq=37393463/37393463 fqs=0
> > > > [526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
> > > > [526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
> > > > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > > [526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > ...
> > > > 
> > > > Attached is kernel config (4.13.11).
> > > > 
> > > > 
> > > > The output obtained with 4.11.3 was:
> > > > [  280.680010] INFO: rcu_sched self-detected stall on CPU
> > > > [  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 
> > > > softirq=6119/6119 fqs=0
> > > > [  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
> > > > [  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 
> > > > f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > > ...
> > > > 
> > > > 
> > > > As it's a remote VM for which I don't have access to the host I have 
> > > > little
> > > > options for further digging (can't trigger sysrq's).
> > > > 
> > > > 
> > > > Same kernel (4.13.11) seems to be running just fine on another KVM-base 
> > > > VM that
> > > > has two CPUs.
> > > > 
> > > > 
> > > > Does it ring a bell or is there some info that might be of any use,
> > > > assuming I can obtain it?
> > > > 
> > > > Bruno
> > > 
> > >   
> >   
> 

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sun, 12 November 2017 "Paul E. McKenney"  wrote:

> On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote:
> > On Sat, 11 November 2017 "Paul E. McKenney"  
> > wrote:  
> > > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:  
> > > > Hi,
> > > > 
> > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > > > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > > > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > > > reason.
> > > > 
> > > > All info I have is following console dump (from 4.13.11):
> > > > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > > > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > > > softirq=37393463/37393463 fqs=0
> > > > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > > > [526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
> > > > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > 
> > > The above line says that the rcu_sched kthread asked to sleep for three
> > > jiffies, but ended up sleeping for more than 745,854 jiffies.
> > > 
> > > If your system does not let the RCU's kernel threads run, RCU cannot
> > > help you much.
> > > 
> > > The ->state of 0x0 indicates that the kthread is in fact runnable, but
> > > did not get a chance to run.  Was the system heavily loaded to the
> > > point where you would expect a kthread to remain preempted for many
> > > minutes?
> > > 
> > > I am guessing that the answer is no, given that CPU 0 is actually idle
> > > (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> > > kthread to a specific CPU?  
> > 
> > The system should be lightly loaded (about 5-10% CPU usage on average), so
> > plenty of time for RCU to do its work.
> > 
> > I didn't bind processes (be it userspace process or kthread) to a specific
> > CPU, thus it's all auto-configured.
> > 
> > I guess the question then is what is the system busy with or waiting for
> > that prevents RCU to get its work done...
> > Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I might 
> > need
> > to check at which log level and make sure that loglevel reaches console.
> > Nothing did hit the disk though.  
> 
> Do you have a high-speed interface to capture and store console output?
> (As in something that can handle, say, 50MB in a reasonable period of
> time.)

The only option I could have is netconsole, in the hope it does not cause
issues by itself!

Other than that I have a poor man's web-VNC kind of view on VGA-sized
text console, which is slow and small (it's a virtual server at a hosting
company).

Thanks,
Bruno

>   Thanx, Paul
> 
> > Thanks,
> > Bruno
> >   
> > >   Thanx, Paul
> > >   
> > > > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526478.320009] INFO: rcu_sched self-detected stall on CPU
> > > > [526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
> > > > softirq=37393463/37393463 fqs=0
> > > > [526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
> > > > [526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
> > > > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > > [526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > [526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > > > [swapper/0:0]
> > > > ...
> > > > 
> > > > Attached is kernel config (4.13.11).
> > > > 
> > > > 
> > > > The output obtained with 4.11.3 was:
> > > > [  280.680010] INFO: rcu_sched self-detected stall on CPU
> > > > [  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 
> > > > softirq=6119/6119 fqs=0
> > > > [  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
> > > > [  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 
> > > > f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > > > ...
> > > > 
> > > > 
> > > > As it's a remote VM for which I don't have access to the host I have 
> > > > little
> > > > options for further digging (can't trigger sysrq's).
> > > > 
> > > > 
> > > > Same kernel (4.13.11) seems to be running just fine on another KVM-base 
> > > > VM that
> > > > has two CPUs.
> > > > 
> > > > 
> > > > Does it ring a bell or is there some info that might be of any use,
> > > > assuming I can obtain it?
> > > > 
> > > > Bruno
> > > 
> > >   
> >   
> 

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sat, 11 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:
> > Hi,
> > 
> > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > reason.
> > 
> > All info I have is following console dump (from 4.13.11):
> > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > softirq=37393463/37393463 fqs=0
> > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > [526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
> > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0  
> 
> The above line says that the rcu_sched kthread asked to sleep for three
> jiffies, but ended up sleeping for more than 745,854 jiffies.
> 
> If your system does not let the RCU's kernel threads run, RCU cannot
> help you much.
> 
> The ->state of 0x0 indicates that the kthread is in fact runnable, but
> did not get a chance to run.  Was the system heavily loaded to the
> point where you would expect a kthread to remain preempted for many
> minutes?
> 
> I am guessing that the answer is no, given that CPU 0 is actually idle
> (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> kthread to a specific CPU?

The system should be lightly loaded (about 5-10% CPU usage on average), so
plenty of time for RCU to do its work.

I didn't bind processes (be it userspace process or kthread) to a specific
CPU, thus it's all auto-configured.

I guess the question then is what is the system busy with or waiting for
that prevents RCU to get its work done...
Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I might need
to check at which log level and make sure that loglevel reaches console.
Nothing did hit the disk though.

Thanks,
Bruno

>   Thanx, Paul
> 
> > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526478.320009] INFO: rcu_sched self-detected stall on CPU
> > [526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
> > softirq=37393463/37393463 fqs=0
> > [526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
> > [526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
> > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > [526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > ...
> > 
> > Attached is kernel config (4.13.11).
> > 
> > 
> > The output obtained with 4.11.3 was:
> > [  280.680010] INFO: rcu_sched self-detected stall on CPU
> > [  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 softirq=6119/6119 
> > fqs=0
> > [  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
> > [  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 f0x0 
> > RCU_GP_WAIT_FQS(3) ->state=0x0
> > ...
> > 
> > 
> > As it's a remote VM for which I don't have access to the host I have little
> > options for further digging (can't trigger sysrq's).
> > 
> > 
> > Same kernel (4.13.11) seems to be running just fine on another KVM-base VM 
> > that
> > has two CPUs.
> > 
> > 
> > Does it ring a bell or is there some info that might be of any use,
> > assuming I can obtain it?
> > 
> > Bruno  
> 
> 

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

On Sat, 11 November 2017 "Paul E. McKenney"  wrote:
> On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:
> > Hi,
> > 
> > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
> > and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
> > 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
> > reason.
> > 
> > All info I have is following console dump (from 4.13.11):
> > [526415.290012] INFO: rcu_sched self-detected stall on CPU
> > [526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
> > softirq=37393463/37393463 fqs=0
> > [526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
> > [526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
> > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0  
> 
> The above line says that the rcu_sched kthread asked to sleep for three
> jiffies, but ended up sleeping for more than 745,854 jiffies.
> 
> If your system does not let the RCU's kernel threads run, RCU cannot
> help you much.
> 
> The ->state of 0x0 indicates that the kthread is in fact runnable, but
> did not get a chance to run.  Was the system heavily loaded to the
> point where you would expect a kthread to remain preempted for many
> minutes?
> 
> I am guessing that the answer is no, given that CPU 0 is actually idle
> (idle=ba2/2/0).  Seems unlikely, but I have to ask:  Did you bind the
> kthread to a specific CPU?

The system should be lightly loaded (about 5-10% CPU usage on average), so
plenty of time for RCU to do its work.

I didn't bind processes (be it userspace process or kthread) to a specific
CPU, thus it's all auto-configured.

I guess the question then is what is the system busy with or waiting for
that prevents RCU to get its work done...
Shouldn't the watchdog print a trace of where CPU#0 is stuck? If so I might need
to check at which log level and make sure that loglevel reaches console.
Nothing did hit the disk though.

Thanks,
Bruno

>   Thanx, Paul
> 
> > [526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526478.320009] INFO: rcu_sched self-detected stall on CPU
> > [526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
> > softirq=37393463/37393463 fqs=0
> > [526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
> > [526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
> > c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> > [526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > [526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> > [swapper/0:0]
> > ...
> > 
> > Attached is kernel config (4.13.11).
> > 
> > 
> > The output obtained with 4.11.3 was:
> > [  280.680010] INFO: rcu_sched self-detected stall on CPU
> > [  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 softirq=6119/6119 
> > fqs=0
> > [  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
> > [  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 f0x0 
> > RCU_GP_WAIT_FQS(3) ->state=0x0
> > ...
> > 
> > 
> > As it's a remote VM for which I don't have access to the host I have little
> > options for further digging (can't trigger sysrq's).
> > 
> > 
> > Same kernel (4.13.11) seems to be running just fine on another KVM-base VM 
> > that
> > has two CPUs.
> > 
> > 
> > Does it ring a bell or is there some info that might be of any use,
> > assuming I can obtain it?
> > 
> > Bruno  
> 
> 

RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

Hi,

On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
reason.

All info I have is following console dump (from 4.13.11):
[526415.290012] INFO: rcu_sched self-detected stall on CPU
[526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
softirq=37393463/37393463 fqs=0
[526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
[526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526478.320009] INFO: rcu_sched self-detected stall on CPU
[526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
softirq=37393463/37393463 fqs=0
[526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
[526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
...

Attached is kernel config (4.13.11).


The output obtained with 4.11.3 was:
[  280.680010] INFO: rcu_sched self-detected stall on CPU
[  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 softirq=6119/6119 
fqs=0
[  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
[  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 f0x0 
RCU_GP_WAIT_FQS(3) ->state=0x0
...


As it's a remote VM for which I don't have access to the host I have little
options for further digging (can't trigger sysrq's).


Same kernel (4.13.11) seems to be running just fine on another KVM-base VM that
has two CPUs.


Does it ring a bell or is there some info that might be of any use,
assuming I can obtain it?

Bruno

kvm-guest.config
Description: Binary data

RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

[Bruno Prémont]

Hi,

On a single-CPU KVM-based virtual machine I'm suffering from RCU stall
and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with
4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent
reason.

All info I have is following console dump (from 4.13.11):
[526415.290012] INFO: rcu_sched self-detected stall on CPU
[526415.290012] o0-...: (745847 ticks this GP) idle=ba2/2/0 
softirq=37393463/37393463 fqs=0
[526415.290012] o (t=745854 jiffies g=23779976 c=23779975 q=32)
[526415.290012] rcu_sched kthread starved for 745854 jiffies! g23779976 
c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[526440.020015] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526468.020005] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526478.320009] INFO: rcu_sched self-detected stall on CPU
[526478.320009] o0-...: (752143 ticks this GP) idle=ba2/2/0 
softirq=37393463/37393463 fqs=0
[526478.320009] o (t=752157 jiffies g=23779976 c=23779975 q=32)
[526478.320009] rcu_sched kthread starved for 752157 jiffies! g23779976 
c23779975 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[526504.020016] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
[526532.020007] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
...

Attached is kernel config (4.13.11).


The output obtained with 4.11.3 was:
[  280.680010] INFO: rcu_sched self-detected stall on CPU
[  280.680021] o0-...: (27312 ticks this GP) dile=b11/2/0 softirq=6119/6119 
fqs=0
[  280.680021] o (t=27312 jiffies g=441 c=440 q=0)
[  280.680021] rcu_sched_kthread starved for 27312 jiffies! g441 c440 f0x0 
RCU_GP_WAIT_FQS(3) ->state=0x0
...


As it's a remote VM for which I don't have access to the host I have little
options for further digging (can't trigger sysrq's).


Same kernel (4.13.11) seems to be running just fine on another KVM-base VM that
has two CPUs.


Does it ring a bell or is there some info that might be of any use,
assuming I can obtain it?

Bruno

kvm-guest.config
Description: Binary data

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset (was: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later)

[Bruno Prémont]

On Mon, 6 Nov 2017 18:57:15 -0500 (EST) Mikulas Patocka wrote:
> On Mon, 6 Nov 2017, Bruno Prémont wrote:
> > On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote:  
> > > On Thu, Nov 02 2017 at  4:39pm -0400, Bruno Prémont wrote:  
> > > > Hi,
> > > > 
> > > > Between 4.11 and 4.12 I stopped being able to boot my system with root
> > > > partition encrypted with dm-crypt (issue still present in 4.14-rc7).
> > > > The system was able to open the dm-crypt device and read-only mount the
> > > > XFS root partition on it.
> > > > Later read-write remounting though caused XFS to shutdown the filesystem
> > > > on IO error.
> > > > 
> > > > Some reports found online indicated a possible coincidence with stack
> > > > protection or the like as well as use of slub_debug, the latter causing
> > > > the IO errors to surface for me (I have slub_debug=ZP on my kernel
> > > > cmdline).
> > > > 
> > > > I finally got time to go and bisect in order to find the triggering
> > > > patch. Bisect log:
> > > > 
> > > > # good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
> > > > git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
> > > > # bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
> > > > git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
> > > > # bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 
> > > > 'gpio-v4.12-1' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
> > > > git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
> > > > # good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > > > git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> > > > # good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 
> > > > 'linux-4.12' of git://github.com/skeggsb/linux into drm-next
> > > > git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
> > > > # bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
> > > > 'backlight-next-4.12' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> > > > git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
> > > > # good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 
> > > > 'stable-4.12' of git://git.infradead.org/users/pcmoore/audit
> > > > git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
> > > > # good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge 
> > > > remote-tracking branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 
> > > > 'asoc/topic/zte-tdm' into asoc-next
> > > > git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
> > > > # bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
> > > > 'for-4.12/dm-post-merge-changes' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > > > git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
> > > > # good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
> > > > chunk_aligned_read() split bios more cleanly.
> > > > git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
> > > > # bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use 
> > > > hex2bin instead of open-coded variant
> > > > git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
> > > > # bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear 
> > > > the cache core's dirty_bitset when loading mappings
> > > > git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
> > > > # good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce 
> > > > new format of cipher with "capi:" prefix
> > > > git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
> > > > # bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts 
> > > > instead of sector_div
> > > > git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
> > > > # bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor 
> > > > out create_journal() from dm_integrity_ctr()
> > > > git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
> > > > # bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally 
> > > > support larger encryption sector size
> > > > git bisect bad 8f0

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset (was: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later)

[Bruno Prémont]

On Mon, 6 Nov 2017 18:57:15 -0500 (EST) Mikulas Patocka wrote:
> On Mon, 6 Nov 2017, Bruno Prémont wrote:
> > On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote:  
> > > On Thu, Nov 02 2017 at  4:39pm -0400, Bruno Prémont wrote:  
> > > > Hi,
> > > > 
> > > > Between 4.11 and 4.12 I stopped being able to boot my system with root
> > > > partition encrypted with dm-crypt (issue still present in 4.14-rc7).
> > > > The system was able to open the dm-crypt device and read-only mount the
> > > > XFS root partition on it.
> > > > Later read-write remounting though caused XFS to shutdown the filesystem
> > > > on IO error.
> > > > 
> > > > Some reports found online indicated a possible coincidence with stack
> > > > protection or the like as well as use of slub_debug, the latter causing
> > > > the IO errors to surface for me (I have slub_debug=ZP on my kernel
> > > > cmdline).
> > > > 
> > > > I finally got time to go and bisect in order to find the triggering
> > > > patch. Bisect log:
> > > > 
> > > > # good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
> > > > git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
> > > > # bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
> > > > git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
> > > > # bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 
> > > > 'gpio-v4.12-1' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
> > > > git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
> > > > # good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > > > git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> > > > # good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 
> > > > 'linux-4.12' of git://github.com/skeggsb/linux into drm-next
> > > > git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
> > > > # bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
> > > > 'backlight-next-4.12' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> > > > git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
> > > > # good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 
> > > > 'stable-4.12' of git://git.infradead.org/users/pcmoore/audit
> > > > git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
> > > > # good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge 
> > > > remote-tracking branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 
> > > > 'asoc/topic/zte-tdm' into asoc-next
> > > > git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
> > > > # bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
> > > > 'for-4.12/dm-post-merge-changes' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > > > git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
> > > > # good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
> > > > chunk_aligned_read() split bios more cleanly.
> > > > git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
> > > > # bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use 
> > > > hex2bin instead of open-coded variant
> > > > git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
> > > > # bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear 
> > > > the cache core's dirty_bitset when loading mappings
> > > > git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
> > > > # good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce 
> > > > new format of cipher with "capi:" prefix
> > > > git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
> > > > # bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts 
> > > > instead of sector_div
> > > > git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
> > > > # bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor 
> > > > out create_journal() from dm_integrity_ctr()
> > > > git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
> > > > # bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally 
> > > > support larger encryption sector size
> > > > git bisect bad 8f0

Re: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

[Bruno Prémont]

On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote:
> On Thu, Nov 02 2017 at  4:39pm -0400, Bruno Prémont wrote:
> > Hi,
> > 
> > Between 4.11 and 4.12 I stopped being able to boot my system with root
> > partition encrypted with dm-crypt (issue still present in 4.14-rc7).
> > The system was able to open the dm-crypt device and read-only mount the
> > XFS root partition on it.
> > Later read-write remounting though caused XFS to shutdown the filesystem
> > on IO error.
> > 
> > Some reports found online indicated a possible coincidence with stack
> > protection or the like as well as use of slub_debug, the latter causing
> > the IO errors to surface for me (I have slub_debug=ZP on my kernel
> > cmdline).
> > 
> > I finally got time to go and bisect in order to find the triggering
> > patch. Bisect log:
> > 
> > # good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
> > git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
> > # bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
> > git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
> > # bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 'gpio-v4.12-1' 
> > of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
> > git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
> > # good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> > # good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 
> > 'linux-4.12' of git://github.com/skeggsb/linux into drm-next
> > git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
> > # bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
> > 'backlight-next-4.12' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> > git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
> > # good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 
> > 'stable-4.12' of git://git.infradead.org/users/pcmoore/audit
> > git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
> > # good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge remote-tracking 
> > branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 'asoc/topic/zte-tdm' 
> > into asoc-next
> > git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
> > # bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
> > 'for-4.12/dm-post-merge-changes' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
> > # good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
> > chunk_aligned_read() split bios more cleanly.
> > git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
> > # bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use hex2bin 
> > instead of open-coded variant
> > git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
> > # bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear the 
> > cache core's dirty_bitset when loading mappings
> > git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
> > # good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce new 
> > format of cipher with "capi:" prefix
> > git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
> > # bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts 
> > instead of sector_div
> > git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
> > # bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor out 
> > create_journal() from dm_integrity_ctr()
> > git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
> > # bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally 
> > support larger encryption sector size
> > git bisect bad 8f0009a225171cc1b76a6b443de5137b26e1374b
> > # first bad commit: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: 
> > optionally support larger encryption sector size
> > 
> > In order to test on 4.12 I had to revert the following commits,
> > the first two having been applied on top of bad commit:
> >   583fe7474c05ee5523e14ef791ea59604cd846dc (dm crypt: fix large block 
> > integrity support)
> >   ff3af92b4461be773337111daea80bb91b2cd545 (dm crypt: use shifts instead of 
> > sector_div)
> >   8f0009a225171cc1b76a6b443de5137b26e1374b (dm crypt: optionally support 
> > larger encryption sector size)
> > 
> > From looking at 8f0009a225171cc1b76a6b443de5137b26e1374b I can't spot
> > direct cause though I assume there mi

Re: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

[Bruno Prémont]

On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote:
> On Thu, Nov 02 2017 at  4:39pm -0400, Bruno Prémont wrote:
> > Hi,
> > 
> > Between 4.11 and 4.12 I stopped being able to boot my system with root
> > partition encrypted with dm-crypt (issue still present in 4.14-rc7).
> > The system was able to open the dm-crypt device and read-only mount the
> > XFS root partition on it.
> > Later read-write remounting though caused XFS to shutdown the filesystem
> > on IO error.
> > 
> > Some reports found online indicated a possible coincidence with stack
> > protection or the like as well as use of slub_debug, the latter causing
> > the IO errors to surface for me (I have slub_debug=ZP on my kernel
> > cmdline).
> > 
> > I finally got time to go and bisect in order to find the triggering
> > patch. Bisect log:
> > 
> > # good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
> > git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
> > # bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
> > git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
> > # bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 'gpio-v4.12-1' 
> > of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
> > git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
> > # good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> > git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
> > # good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 
> > 'linux-4.12' of git://github.com/skeggsb/linux into drm-next
> > git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
> > # bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
> > 'backlight-next-4.12' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> > git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
> > # good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 
> > 'stable-4.12' of git://git.infradead.org/users/pcmoore/audit
> > git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
> > # good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge remote-tracking 
> > branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 'asoc/topic/zte-tdm' 
> > into asoc-next
> > git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
> > # bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
> > 'for-4.12/dm-post-merge-changes' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
> > # good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
> > chunk_aligned_read() split bios more cleanly.
> > git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
> > # bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use hex2bin 
> > instead of open-coded variant
> > git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
> > # bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear the 
> > cache core's dirty_bitset when loading mappings
> > git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
> > # good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce new 
> > format of cipher with "capi:" prefix
> > git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
> > # bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts 
> > instead of sector_div
> > git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
> > # bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor out 
> > create_journal() from dm_integrity_ctr()
> > git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
> > # bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally 
> > support larger encryption sector size
> > git bisect bad 8f0009a225171cc1b76a6b443de5137b26e1374b
> > # first bad commit: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: 
> > optionally support larger encryption sector size
> > 
> > In order to test on 4.12 I had to revert the following commits,
> > the first two having been applied on top of bad commit:
> >   583fe7474c05ee5523e14ef791ea59604cd846dc (dm crypt: fix large block 
> > integrity support)
> >   ff3af92b4461be773337111daea80bb91b2cd545 (dm crypt: use shifts instead of 
> > sector_div)
> >   8f0009a225171cc1b76a6b443de5137b26e1374b (dm crypt: optionally support 
> > larger encryption sector size)
> > 
> > From looking at 8f0009a225171cc1b76a6b443de5137b26e1374b I can't spot
> > direct cause though I assume there mi

[Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

[Bruno Prémont]

Hi,

Between 4.11 and 4.12 I stopped being able to boot my system with root
partition encrypted with dm-crypt (issue still present in 4.14-rc7).
The system was able to open the dm-crypt device and read-only mount the
XFS root partition on it.
Later read-write remounting though caused XFS to shutdown the filesystem
on IO error.

Some reports found online indicated a possible coincidence with stack
protection or the like as well as use of slub_debug, the latter causing
the IO errors to surface for me (I have slub_debug=ZP on my kernel
cmdline).

I finally got time to go and bisect in order to find the triggering
patch. Bisect log:

# good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
# bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
# bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 'gpio-v4.12-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
# good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
# good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 'linux-4.12' of 
git://github.com/skeggsb/linux into drm-next
git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
# bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
'backlight-next-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
# good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 'stable-4.12' 
of git://git.infradead.org/users/pcmoore/audit
git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
# good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge remote-tracking 
branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 'asoc/topic/zte-tdm' into 
asoc-next
git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
# bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
'for-4.12/dm-post-merge-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
# good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
chunk_aligned_read() split bios more cleanly.
git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
# bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use hex2bin 
instead of open-coded variant
git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
# bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear the cache 
core's dirty_bitset when loading mappings
git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
# good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce new 
format of cipher with "capi:" prefix
git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
# bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts instead 
of sector_div
git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
# bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor out 
create_journal() from dm_integrity_ctr()
git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
# bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally support 
larger encryption sector size
git bisect bad 8f0009a225171cc1b76a6b443de5137b26e1374b
# first bad commit: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: 
optionally support larger encryption sector size

In order to test on 4.12 I had to revert the following commits,
the first two having been applied on top of bad commit:
  583fe7474c05ee5523e14ef791ea59604cd846dc (dm crypt: fix large block integrity 
support)
  ff3af92b4461be773337111daea80bb91b2cd545 (dm crypt: use shifts instead of 
sector_div)
  8f0009a225171cc1b76a6b443de5137b26e1374b (dm crypt: optionally support larger 
encryption sector size)

From looking at 8f0009a225171cc1b76a6b443de5137b26e1374b I can't spot
direct cause though I assume there might be a mismatch in memory
allocation versus access sizes as a consequence of support for larger
encryption sector size (someplace 512 byte versus page size access
tripping on memory poison?).

Bruno

[Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

[Bruno Prémont]

Hi,

Between 4.11 and 4.12 I stopped being able to boot my system with root
partition encrypted with dm-crypt (issue still present in 4.14-rc7).
The system was able to open the dm-crypt device and read-only mount the
XFS root partition on it.
Later read-write remounting though caused XFS to shutdown the filesystem
on IO error.

Some reports found online indicated a possible coincidence with stack
protection or the like as well as use of slub_debug, the latter causing
the IO errors to surface for me (I have slub_debug=ZP on my kernel
cmdline).

I finally got time to go and bisect in order to find the triggering
patch. Bisect log:

# good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
# bad: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
git bisect bad 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
# bad: [2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 'gpio-v4.12-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect bad 2bd80401743568ced7d303b008ae5298ce77e695
# good: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
# good: [8b03d1ed2c43a2ba5ef3381322ee4515b97381bf] Merge branch 'linux-4.12' of 
git://github.com/skeggsb/linux into drm-next
git bisect good 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf
# bad: [e897f267c51812bfecec45771a2d835c1a2bdacf] Merge tag 
'backlight-next-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
git bisect bad e897f267c51812bfecec45771a2d835c1a2bdacf
# good: [46f0537b1ecf672052007c97f102a7e6bf0791e4] Merge branch 'stable-4.12' 
of git://git.infradead.org/users/pcmoore/audit
git bisect good 46f0537b1ecf672052007c97f102a7e6bf0791e4
# good: [20d5c84bef067b7e804a163e2abca16c47125bad] Merge remote-tracking 
branches 'asoc/topic/wm8960', 'asoc/topic/wm8978' and 'asoc/topic/zte-tdm' into 
asoc-next
git bisect good 20d5c84bef067b7e804a163e2abca16c47125bad
# bad: [7b66f13207e60e7c550af730986e77e38a0c69a3] Merge tag 
'for-4.12/dm-post-merge-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
git bisect bad 7b66f13207e60e7c550af730986e77e38a0c69a3
# good: [dd7a8f5dee81ffb1794df1103f07c63fd4f1d766] md/raid5: make 
chunk_aligned_read() split bios more cleanly.
git bisect good dd7a8f5dee81ffb1794df1103f07c63fd4f1d766
# bad: [6625d903253eb6f003849823e22d7b8de5bfb5b2] dm integrity: use hex2bin 
instead of open-coded variant
git bisect bad 6625d903253eb6f003849823e22d7b8de5bfb5b2
# bad: [449b668ce0b9069fcaafa6344c7f10fa2ba9632e] dm cache: set/clear the cache 
core's dirty_bitset when loading mappings
git bisect bad 449b668ce0b9069fcaafa6344c7f10fa2ba9632e
# good: [33d2f09fcb357fd1861c4959d1d3505492bf91f8] dm crypt: introduce new 
format of cipher with "capi:" prefix
git bisect good 33d2f09fcb357fd1861c4959d1d3505492bf91f8
# bad: [ff3af92b4461be773337111daea80bb91b2cd545] dm crypt: use shifts instead 
of sector_div
git bisect bad ff3af92b4461be773337111daea80bb91b2cd545
# bad: [1aa0efd4210df1c57764b77040a6615bc9b3ac0f] dm integrity: factor out 
create_journal() from dm_integrity_ctr()
git bisect bad 1aa0efd4210df1c57764b77040a6615bc9b3ac0f
# bad: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: optionally support 
larger encryption sector size
git bisect bad 8f0009a225171cc1b76a6b443de5137b26e1374b
# first bad commit: [8f0009a225171cc1b76a6b443de5137b26e1374b] dm crypt: 
optionally support larger encryption sector size

In order to test on 4.12 I had to revert the following commits,
the first two having been applied on top of bad commit:
  583fe7474c05ee5523e14ef791ea59604cd846dc (dm crypt: fix large block integrity 
support)
  ff3af92b4461be773337111daea80bb91b2cd545 (dm crypt: use shifts instead of 
sector_div)
  8f0009a225171cc1b76a6b443de5137b26e1374b (dm crypt: optionally support larger 
encryption sector size)

From looking at 8f0009a225171cc1b76a6b443de5137b26e1374b I can't spot
direct cause though I assume there might be a mismatch in memory
allocation versus access sizes as a consequence of support for larger
encryption sector size (someplace 512 byte versus page size access
tripping on memory poison?).

Bruno

Re: [PATCH 7/7] HID: picoLCD: Replace two seq_printf() calls by seq_puts() in picolcd_debug_reset_show()

[Bruno Prémont]

Acked-by: Bruno Prémont <bonb...@linux-vserver.org>

On Mon, 24 Apr 2017 22:23:02 +0200 SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 24 Apr 2017 21:27:42 +0200
> 
> Strings which did not contain data format specifications should be put
> into a sequence. Thus use the corresponding function "seq_puts".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/hid/hid-picolcd_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c 
> b/drivers/hid/hid-picolcd_debugfs.c
> index 3e0feb4bb538..975f36601d59 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -33,9 +33,9 @@
>  static int picolcd_debug_reset_show(struct seq_file *f, void *p)
>  {
>   if (picolcd_fbinfo((struct picolcd_data *)f->private))
> - seq_printf(f, "all fb\n");
> + seq_puts(f, "all fb\n");
>   else
> - seq_printf(f, "all\n");
> + seq_puts(f, "all\n");
>   return 0;
>  }
>  

Re: [PATCH 7/7] HID: picoLCD: Replace two seq_printf() calls by seq_puts() in picolcd_debug_reset_show()

[Bruno Prémont]

Acked-by: Bruno Prémont 

On Mon, 24 Apr 2017 22:23:02 +0200 SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 24 Apr 2017 21:27:42 +0200
> 
> Strings which did not contain data format specifications should be put
> into a sequence. Thus use the corresponding function "seq_puts".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/hid/hid-picolcd_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c 
> b/drivers/hid/hid-picolcd_debugfs.c
> index 3e0feb4bb538..975f36601d59 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -33,9 +33,9 @@
>  static int picolcd_debug_reset_show(struct seq_file *f, void *p)
>  {
>   if (picolcd_fbinfo((struct picolcd_data *)f->private))
> - seq_printf(f, "all fb\n");
> + seq_puts(f, "all fb\n");
>   else
> - seq_printf(f, "all\n");
> + seq_puts(f, "all\n");
>   return 0;
>  }
>  

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

[Bruno Prémont]

Hi Geert, Jiri,

Fine with me,
Acked-by: Bruno Prémont <bonb...@linux-vserver.org>

On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Bruno Prémont <bonb...@linux-vserver.org>
> Cc: linux-in...@vger.kernel.org
> ---
>  drivers/hid/hid-picolcd_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c 
> b/drivers/hid/hid-picolcd_debugfs.c
> index 3c13af6844108f97..3e0feb4bb5380978 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -736,7 +736,7 @@ void picolcd_debug_raw_event(struct picolcd_data *data,
>   }
>   break;
>   case REPORT_MEMORY:
> - /* Data buffer in response to REPORT_READ_MEMORY or 
> REPORT_WRTIE_MEMORY */
> + /* Data buffer in response to REPORT_READ_MEMORY or 
> REPORT_WRITE_MEMORY */
>   snprintf(buff, BUFF_SZ, "report %s (%d, size=%d)\n",
>   "REPORT_MEMORY", report->id, size-1);
>   hid_debug_event(hdev, buff);

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

[Bruno Prémont]

Hi Geert, Jiri,

Fine with me,
Acked-by: Bruno Prémont 

On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven
 wrote:
> Signed-off-by: Geert Uytterhoeven 
> Cc: Bruno Prémont 
> Cc: linux-in...@vger.kernel.org
> ---
>  drivers/hid/hid-picolcd_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c 
> b/drivers/hid/hid-picolcd_debugfs.c
> index 3c13af6844108f97..3e0feb4bb5380978 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -736,7 +736,7 @@ void picolcd_debug_raw_event(struct picolcd_data *data,
>   }
>   break;
>   case REPORT_MEMORY:
> - /* Data buffer in response to REPORT_READ_MEMORY or 
> REPORT_WRTIE_MEMORY */
> + /* Data buffer in response to REPORT_READ_MEMORY or 
> REPORT_WRITE_MEMORY */
>   snprintf(buff, BUFF_SZ, "report %s (%d, size=%d)\n",
>   "REPORT_MEMORY", report->id, size-1);
>   hid_debug_event(hdev, buff);

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

On Mon, 11 Jul 2016 09:30:30 +0200 Thorsten Leemhuis wrote:
> Bruno Prémont wrote on 11.07.2016 09:17:
> > On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote:  
> >> Bruno Prémont wrote on 30.06.2016 17:00:  
> >> > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
> >> > pointer dereference when rsp->msix is NULL:
> >> > […]
> >> > The affected code was introduced by commit 
> >> > cdb898c52d1dfad4b4800b83a58b3fe5d352edde
> >> > (qla2xxx: Add irq affinity notification).
> >> > 
> >> > Only dereference rsp->msix when it has been set so the machine can boot
> >> > fine. Possibly rsp->msix is unset because:
> >> > [3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA 
> >> > Driver: 8.07.00.33-k.
> >> > [3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 
> >> > iobase 0xc9038000.
> >> > [3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 
> >> > (0x2, 0x3).
> >> > [3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode 
> >> > -258.
> >> > [3.890145] scsi host0: qla2xxx
> >> > [3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - 
> >> > PCI-Express Single Channel 4Gb Fibre Channel HBA.
> >> > [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) 
> >> > @ :13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
> >> > [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps). 
> >> >
> >> 
> >> Bruno: Does that mean you actually tested that patch and it fixed the
> >> problem for you? It looks like it, but there is some confusion about it;
> >> that's one of the reasons why this patch didn't get any further yet
> >> afaics, so a quick clarification might help to finally get this fixed
> >> properly in mainline and stable.  
> > Yes, it does fix the Oops for me.  
> 
> Thx for the feedback. The patch hit mainline late last week (it's
> included in rc7) and should hopefully make it to the stable trees in a
> week or two.

I got the queued notification from James last week and kept an eye
at the state on patchwork before that.

> > I did not analyze the reason why rsp->msix is NULL (no idea if
> > it remains NULL forever on my hardware) - I just extracted messages
> > from qla driver shown during boot which seem to indicate a possible
> > reason why msix is NULL.
> > Further analysis should be done by someone with better knowledge of qla
> > driver than mine though I would be happy to perform tests.  
> 
> I have no idea about the details, but in case you missed it, this
> discussion might have some more relevant details:
> http://thread.gmane.org/gmane.linux.kernel/2247804/focus=2250727

I didn't see that thread, though it does have some insight.
Thanks for the reference!

Bruno

> Cheers, Thorsten

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

On Mon, 11 Jul 2016 09:30:30 +0200 Thorsten Leemhuis wrote:
> Bruno Prémont wrote on 11.07.2016 09:17:
> > On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote:  
> >> Bruno Prémont wrote on 30.06.2016 17:00:  
> >> > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
> >> > pointer dereference when rsp->msix is NULL:
> >> > […]
> >> > The affected code was introduced by commit 
> >> > cdb898c52d1dfad4b4800b83a58b3fe5d352edde
> >> > (qla2xxx: Add irq affinity notification).
> >> > 
> >> > Only dereference rsp->msix when it has been set so the machine can boot
> >> > fine. Possibly rsp->msix is unset because:
> >> > [3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA 
> >> > Driver: 8.07.00.33-k.
> >> > [3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 
> >> > iobase 0xc9038000.
> >> > [3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 
> >> > (0x2, 0x3).
> >> > [3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode 
> >> > -258.
> >> > [3.890145] scsi host0: qla2xxx
> >> > [3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - 
> >> > PCI-Express Single Channel 4Gb Fibre Channel HBA.
> >> > [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) 
> >> > @ :13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
> >> > [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps). 
> >> >
> >> 
> >> Bruno: Does that mean you actually tested that patch and it fixed the
> >> problem for you? It looks like it, but there is some confusion about it;
> >> that's one of the reasons why this patch didn't get any further yet
> >> afaics, so a quick clarification might help to finally get this fixed
> >> properly in mainline and stable.  
> > Yes, it does fix the Oops for me.  
> 
> Thx for the feedback. The patch hit mainline late last week (it's
> included in rc7) and should hopefully make it to the stable trees in a
> week or two.

I got the queued notification from James last week and kept an eye
at the state on patchwork before that.

> > I did not analyze the reason why rsp->msix is NULL (no idea if
> > it remains NULL forever on my hardware) - I just extracted messages
> > from qla driver shown during boot which seem to indicate a possible
> > reason why msix is NULL.
> > Further analysis should be done by someone with better knowledge of qla
> > driver than mine though I would be happy to perform tests.  
> 
> I have no idea about the details, but in case you missed it, this
> discussion might have some more relevant details:
> http://thread.gmane.org/gmane.linux.kernel/2247804/focus=2250727

I didn't see that thread, though it does have some insight.
Thanks for the reference!

Bruno

> Cheers, Thorsten

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote:
> Bruno Prémont wrote on 30.06.2016 17:00:
> > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
> > pointer dereference when rsp->msix is NULL:
> > […]
> > The affected code was introduced by commit 
> > cdb898c52d1dfad4b4800b83a58b3fe5d352edde
> > (qla2xxx: Add irq affinity notification).
> > 
> > Only dereference rsp->msix when it has been set so the machine can boot
> > fine. Possibly rsp->msix is unset because:
> > [3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA 
> > Driver: 8.07.00.33-k.
> > [3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 
> > iobase 0xc9038000.
> > [3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 
> > (0x2, 0x3).
> > [3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode -258.
> > [3.890145] scsi host0: qla2xxx
> > [3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express 
> > Single Channel 4Gb Fibre Channel HBA.
> > [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 
> > :13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
> > [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps).  
> 
> Bruno: Does that mean you actually tested that patch and it fixed the
> problem for you? It looks like it, but there is some confusion about it;
> that's one of the reasons why this patch didn't get any further yet
> afaics, so a quick clarification might help to finally get this fixed
> properly in mainline and stable.

Yes, it does fix the Oops for me.

I did not analyze the reason why rsp->msix is NULL (no idea if
it remains NULL forever on my hardware) - I just extracted messages
from qla driver shown during boot which seem to indicate a possible
reason why msix is NULL.
Further analysis should be done by someone with better knowledge of qla
driver than mine though I would be happy to perform tests.

Bruno


> Himanshu: While at it: Can you confirm this patch should get merged to
> mainline? Seems Quinn is on PTO and his out-of-office reply mentioned
> you as one point of contact.
> 
> Cheers, your regression tracker for Linux 4.7
>  Thorsten
> 
> > CC: <sta...@vger.kernel.org>
> > Signed-off-by: Bruno Prémont <bonb...@linux-vserver.org>
> > ---
> > diff --git a/drivers/scsi/qla2xxx/qla_isr.c
> > b/drivers/scsi/qla2xxx/qla_isr.c index 5649c20..a92a62d 100644
> > --- a/drivers/scsi/qla2xxx/qla_isr.c
> > +++ b/drivers/scsi/qla2xxx/qla_isr.c
> > @@ -2548,7 +2548,7 @@ void qla24xx_process_response_queue(struct
> > scsi_qla_host *vha, if (!vha->flags.online)
> > return;
> >  
> > -   if (rsp->msix->cpuid != smp_processor_id()) {
> > +   if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
> > /* if kernel does not notify qla of IRQ's CPU change,
> >  * then set it here.
> >  */
> > 
> > http://news.gmane.org/find-root.php?message_id=20160630170032.6dbaf496%40pluto.restena.lu
> >  
> > http://mid.gmane.org/20160630170032.6dbaf496%40pluto.restena.lu
> >   

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote:
> Bruno Prémont wrote on 30.06.2016 17:00:
> > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
> > pointer dereference when rsp->msix is NULL:
> > […]
> > The affected code was introduced by commit 
> > cdb898c52d1dfad4b4800b83a58b3fe5d352edde
> > (qla2xxx: Add irq affinity notification).
> > 
> > Only dereference rsp->msix when it has been set so the machine can boot
> > fine. Possibly rsp->msix is unset because:
> > [3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA 
> > Driver: 8.07.00.33-k.
> > [3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 
> > iobase 0xc9038000.
> > [3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 
> > (0x2, 0x3).
> > [3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode -258.
> > [3.890145] scsi host0: qla2xxx
> > [3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express 
> > Single Channel 4Gb Fibre Channel HBA.
> > [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 
> > :13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
> > [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps).  
> 
> Bruno: Does that mean you actually tested that patch and it fixed the
> problem for you? It looks like it, but there is some confusion about it;
> that's one of the reasons why this patch didn't get any further yet
> afaics, so a quick clarification might help to finally get this fixed
> properly in mainline and stable.

Yes, it does fix the Oops for me.

I did not analyze the reason why rsp->msix is NULL (no idea if
it remains NULL forever on my hardware) - I just extracted messages
from qla driver shown during boot which seem to indicate a possible
reason why msix is NULL.
Further analysis should be done by someone with better knowledge of qla
driver than mine though I would be happy to perform tests.

Bruno


> Himanshu: While at it: Can you confirm this patch should get merged to
> mainline? Seems Quinn is on PTO and his out-of-office reply mentioned
> you as one point of contact.
> 
> Cheers, your regression tracker for Linux 4.7
>  Thorsten
> 
> > CC: 
> > Signed-off-by: Bruno Prémont 
> > ---
> > diff --git a/drivers/scsi/qla2xxx/qla_isr.c
> > b/drivers/scsi/qla2xxx/qla_isr.c index 5649c20..a92a62d 100644
> > --- a/drivers/scsi/qla2xxx/qla_isr.c
> > +++ b/drivers/scsi/qla2xxx/qla_isr.c
> > @@ -2548,7 +2548,7 @@ void qla24xx_process_response_queue(struct
> > scsi_qla_host *vha, if (!vha->flags.online)
> > return;
> >  
> > -   if (rsp->msix->cpuid != smp_processor_id()) {
> > +   if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
> > /* if kernel does not notify qla of IRQ's CPU change,
> >  * then set it here.
> >  */
> > 
> > http://news.gmane.org/find-root.php?message_id=20160630170032.6dbaf496%40pluto.restena.lu
> >  
> > http://mid.gmane.org/20160630170032.6dbaf496%40pluto.restena.lu
> >   

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Bruno Prémont]

On Tue, 5 Jul 2016 11:25:10 +0200 Maxime Ripard wrote:
> On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote:
> > 
> > 
> > 05.07.2016, 13:26, "Michael Haas" :  
> > > Hi,
> > >
> > > nice work! Is this in any way related to Bruno Prémonts driver for the
> > > axp20x?
> > >
> > > I've got a reworked version of that lying around, but it's not quite
> > > ready for submission. Do you know what pieces are missing in your driver
> > > for axp20x support - as opposed to axp22x, which is already working?  
> > 
> > Therotically, it can run on axp20x. However, I have currently no
> > test device. (Still waiting for my C.H.I.P.)  So I can only promise
> > it to run on axp22x.  
> 
> Still, it looks like you just took Bruno's driver, stripped out the
> axp20x parts and added the one to deal with axp22x.
> 
> This makes the driver look weird, by being called axp20x, without
> actually supporting those PMICs, but having some axp22x variables
> right in the middle. And that's awfully inconsistent.
> 
> I'd rather have you add the AXP20x driver directly, and then add the
> needed stuff for the AXP22x.

>From a very quick look at the patch it looks like only basic
"monitoring" features have been retained, and yes, claiming the driver
to be for axp22x and having the functions named axp20x feels weird.

Missing parts are OCV, charge control (be it as interaction with
USB-power where charge current must be limited to not over-drain
USB power source or manual control when user knows more about the USB
power plug than the device).

Proper capacity measurement is a completely different story which I
did not implement (it exists in 3.4 sunxi kernel but is not
straight-forward and makes use of extra registers for data keeping).

Bruno

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Bruno Prémont]

On Tue, 5 Jul 2016 11:25:10 +0200 Maxime Ripard wrote:
> On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote:
> > 
> > 
> > 05.07.2016, 13:26, "Michael Haas" :  
> > > Hi,
> > >
> > > nice work! Is this in any way related to Bruno Prémonts driver for the
> > > axp20x?
> > >
> > > I've got a reworked version of that lying around, but it's not quite
> > > ready for submission. Do you know what pieces are missing in your driver
> > > for axp20x support - as opposed to axp22x, which is already working?  
> > 
> > Therotically, it can run on axp20x. However, I have currently no
> > test device. (Still waiting for my C.H.I.P.)  So I can only promise
> > it to run on axp22x.  
> 
> Still, it looks like you just took Bruno's driver, stripped out the
> axp20x parts and added the one to deal with axp22x.
> 
> This makes the driver look weird, by being called axp20x, without
> actually supporting those PMICs, but having some axp22x variables
> right in the middle. And that's awfully inconsistent.
> 
> I'd rather have you add the AXP20x driver directly, and then add the
> needed stuff for the AXP22x.

>From a very quick look at the patch it looks like only basic
"monitoring" features have been retained, and yes, claiming the driver
to be for axp22x and having the functions named axp20x feels weird.

Missing parts are OCV, charge control (be it as interaction with
USB-power where charge current must be limited to not over-drain
USB power source or manual control when user knows more about the USB
power plug than the device).

Proper capacity measurement is a completely different story which I
did not implement (it exists in 3.4 sunxi kernel but is not
straight-forward and makes use of extra registers for data keeping).

Bruno

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Bruno Prémont]

On Tue, 05 Jul 2016 16:47:38 +0800 Icenowy Zheng wrote:
> I read the datasheet of axp20x, and then found that this driver does
> not support backup RTC battery.
> (But maybe backup battery do not need a driver -- at least on IBM PC
> it has no driver)

A driver is needed to enable/disable the RTC battery charging (unless
uboot does it).
However all the driver can do according to datasheet is configure the
charge voltage/current or disable charging completely.
Monitoring RTC battery is not possible, neither is presence detection.

So driver should just apply configuration it finds in device-tree and
eventually share that information via power supply class.

> And I don't know whether the axp20x has default Li-ion/LiPo battery
> OCV parameter. (axp22x seems to be have a set of default OCV)

It seems to have default OCV parameters as well. With empty RTC
battery OCV values are present.

> You can test this driver on AXP20x. (I think I didn't access to
> AXP22x-specified registers in the power supply code)

Bruno

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Bruno Prémont]

On Tue, 05 Jul 2016 16:47:38 +0800 Icenowy Zheng wrote:
> I read the datasheet of axp20x, and then found that this driver does
> not support backup RTC battery.
> (But maybe backup battery do not need a driver -- at least on IBM PC
> it has no driver)

A driver is needed to enable/disable the RTC battery charging (unless
uboot does it).
However all the driver can do according to datasheet is configure the
charge voltage/current or disable charging completely.
Monitoring RTC battery is not possible, neither is presence detection.

So driver should just apply configuration it finds in device-tree and
eventually share that information via power supply class.

> And I don't know whether the axp20x has default Li-ion/LiPo battery
> OCV parameter. (axp22x seems to be have a set of default OCV)

It seems to have default OCV parameters as well. With empty RTC
battery OCV values are present.

> You can test this driver on AXP20x. (I think I didn't access to
> AXP22x-specified registers in the power supply code)

Bruno

[PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
pointer dereference when rsp->msix is NULL:

[5.622457] NULL pointer dereference at 0050
[5.622457] IP: [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457] PGD 0
[5.622457] Oops:  [#1] SMP
[5.622457] Modules linked in:
[5.622457] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.6.3-x86_64 #1
[5.622457] Hardware name: HP ProLiant DL360 G5, BIOS P58 05/02/2011
[5.622457] task: 8801a88f3740 ti: 8801a8954000 task.ti: 
8801a8954000
[5.622457] RIP: 0010:[]  [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457] RSP: :8801afb03de8  EFLAGS: 00010002
[5.622457] RAX:  RBX: 0032 RCX: 
[5.622457] RDX: 0002 RSI: 8801a79bf8c8 RDI: 8800c8f7e7c0
[5.622457] RBP: 8801afb03e68 R08:  R09: 
[5.622457] R10: 8c47 R11: 0002 R12: 8801a79bf8c8
[5.622457] R13: 8800c8f7e7c0 R14: 8800c8f6 R15: 00018013
[5.622457] FS:  () GS:8801afb0() 
knlGS:
[5.622457] CS:  0010 DS:  ES:  CR0: 80050033
[5.622457] CR2: 0050 CR3: 01e07000 CR4: 06e0
[5.622457] Stack:
[5.622457]  8801afb03e30 810c0f2d 0086 
0002
[5.622457]  8801afb03e28 816570e1 8800c8994628 
0002
[5.622457]  8801afb03e60 816772d4 b47c472ad6955e68 
0032
[5.622457] Call Trace:
[5.622457]  
[5.622457]  [] ? __wake_up_common+0x4d/0x80
[5.622457]  [] ? usb_hcd_resume_root_hub+0x51/0x60
[5.622457]  [] ? uhci_hub_status_data+0x64/0x240
[5.622457]  [] qla24xx_intr_handler+0xf0/0x2e0
[5.622457]  [] ? get_next_timer_interrupt+0xce/0x200
[5.622457]  [] handle_irq_event_percpu+0x64/0x100
[5.622457]  [] handle_irq_event+0x27/0x50
[5.622457]  [] handle_edge_irq+0x65/0x140
[5.622457]  [] handle_irq+0x18/0x30
[5.622457]  [] do_IRQ+0x46/0xd0
[5.622457]  [] common_interrupt+0x7f/0x7f
[5.622457]  
[5.622457]  [] ? mwait_idle+0x68/0x80
[5.622457]  [] arch_cpu_idle+0xa/0x10
[5.622457]  [] default_idle_call+0x27/0x30
[5.622457]  [] cpu_startup_entry+0x19b/0x230
[5.622457]  [] start_secondary+0x136/0x140
[5.622457] Code: 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 
47 58 a8 02 0f 84 c5 00 00 00 48 8b 46 50 49 89 f4 65 8b 15 34 bb aa 7e <39> 50 
50 74 11 89 50 50 48 8b 46 50 8b 40 50 41 89 86 60 8b 00
[5.622457] RIP  [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457]  RSP 
[5.622457] CR2: 0050
[5.622457] ---[ end trace fa2b19c25106d42b ]---
[5.622457] Kernel panic - not syncing: Fatal exception in interrupt


The affected code was introduced by commit 
cdb898c52d1dfad4b4800b83a58b3fe5d352edde
(qla2xxx: Add irq affinity notification).

Only dereference rsp->msix when it has been set so the machine can boot
fine. Possibly rsp->msix is unset because:
[3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
8.07.00.33-k.
[3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 iobase 
0xc9038000.
[3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 (0x2, 
0x3).
[3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode -258.
[3.890145] scsi host0: qla2xxx
[3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express 
Single Channel 4Gb Fibre Channel HBA.
[3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 
:13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
[5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps).


CC: <sta...@vger.kernel.org>
Signed-off-by: Bruno Prémont <bonb...@linux-vserver.org>
---
diff --git a/drivers/scsi/qla2xxx/qla_isr.c
b/drivers/scsi/qla2xxx/qla_isr.c index 5649c20..a92a62d 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2548,7 +2548,7 @@ void qla24xx_process_response_queue(struct
scsi_qla_host *vha, if (!vha->flags.online)
return;
 
-   if (rsp->msix->cpuid != smp_processor_id()) {
+   if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
/* if kernel does not notify qla of IRQ's CPU change,
 * then set it here.
 */

[PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

[Bruno Prémont]

In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
pointer dereference when rsp->msix is NULL:

[5.622457] NULL pointer dereference at 0050
[5.622457] IP: [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457] PGD 0
[5.622457] Oops:  [#1] SMP
[5.622457] Modules linked in:
[5.622457] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.6.3-x86_64 #1
[5.622457] Hardware name: HP ProLiant DL360 G5, BIOS P58 05/02/2011
[5.622457] task: 8801a88f3740 ti: 8801a8954000 task.ti: 
8801a8954000
[5.622457] RIP: 0010:[]  [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457] RSP: :8801afb03de8  EFLAGS: 00010002
[5.622457] RAX:  RBX: 0032 RCX: 
[5.622457] RDX: 0002 RSI: 8801a79bf8c8 RDI: 8800c8f7e7c0
[5.622457] RBP: 8801afb03e68 R08:  R09: 
[5.622457] R10: 8c47 R11: 0002 R12: 8801a79bf8c8
[5.622457] R13: 8800c8f7e7c0 R14: 8800c8f6 R15: 00018013
[5.622457] FS:  () GS:8801afb0() 
knlGS:
[5.622457] CS:  0010 DS:  ES:  CR0: 80050033
[5.622457] CR2: 0050 CR3: 01e07000 CR4: 06e0
[5.622457] Stack:
[5.622457]  8801afb03e30 810c0f2d 0086 
0002
[5.622457]  8801afb03e28 816570e1 8800c8994628 
0002
[5.622457]  8801afb03e60 816772d4 b47c472ad6955e68 
0032
[5.622457] Call Trace:
[5.622457]  
[5.622457]  [] ? __wake_up_common+0x4d/0x80
[5.622457]  [] ? usb_hcd_resume_root_hub+0x51/0x60
[5.622457]  [] ? uhci_hub_status_data+0x64/0x240
[5.622457]  [] qla24xx_intr_handler+0xf0/0x2e0
[5.622457]  [] ? get_next_timer_interrupt+0xce/0x200
[5.622457]  [] handle_irq_event_percpu+0x64/0x100
[5.622457]  [] handle_irq_event+0x27/0x50
[5.622457]  [] handle_edge_irq+0x65/0x140
[5.622457]  [] handle_irq+0x18/0x30
[5.622457]  [] do_IRQ+0x46/0xd0
[5.622457]  [] common_interrupt+0x7f/0x7f
[5.622457]  
[5.622457]  [] ? mwait_idle+0x68/0x80
[5.622457]  [] arch_cpu_idle+0xa/0x10
[5.622457]  [] default_idle_call+0x27/0x30
[5.622457]  [] cpu_startup_entry+0x19b/0x230
[5.622457]  [] start_secondary+0x136/0x140
[5.622457] Code: 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 
47 58 a8 02 0f 84 c5 00 00 00 48 8b 46 50 49 89 f4 65 8b 15 34 bb aa 7e <39> 50 
50 74 11 89 50 50 48 8b 46 50 8b 40 50 41 89 86 60 8b 00
[5.622457] RIP  [] 
qla24xx_process_response_queue+0x44/0x4b0
[5.622457]  RSP 
[5.622457] CR2: 0050
[5.622457] ---[ end trace fa2b19c25106d42b ]---
[5.622457] Kernel panic - not syncing: Fatal exception in interrupt


The affected code was introduced by commit 
cdb898c52d1dfad4b4800b83a58b3fe5d352edde
(qla2xxx: Add irq affinity notification).

Only dereference rsp->msix when it has been set so the machine can boot
fine. Possibly rsp->msix is unset because:
[3.479679] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
8.07.00.33-k.
[3.481839] qla2xxx [:13:00.0]-001d: : Found an ISP2432 irq 17 iobase 
0xc9038000.
[3.484081] qla2xxx [:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 (0x2, 
0x3).
[3.485804] qla2xxx [:13:00.0]-0037:0: Falling back-to MSI mode -258.
[3.890145] scsi host0: qla2xxx
[3.891956] qla2xxx [:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express 
Single Channel 4Gb Fibre Channel HBA.
[3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 
:13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
[5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps).


CC: 
Signed-off-by: Bruno Prémont 
---
diff --git a/drivers/scsi/qla2xxx/qla_isr.c
b/drivers/scsi/qla2xxx/qla_isr.c index 5649c20..a92a62d 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2548,7 +2548,7 @@ void qla24xx_process_response_queue(struct
scsi_qla_host *vha, if (!vha->flags.online)
return;
 
-   if (rsp->msix->cpuid != smp_processor_id()) {
+   if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
/* if kernel does not notify qla of IRQ's CPU change,
 * then set it here.
 */

Re: [PATCH] HID-PICOLCD: Dummy hid-picolcd functions should return error code

[Bruno Prémont]

Hi Arvind,

I can only NACK this patch as it would cause the driver to refuse
probe()ing if any of the features are disabled in kernel configuration.

Have a look at the callers in hid-picolcd_code.c, if any of those
functions does return an error the probe function aborts with an error.


Your commit message talks about allowing compilation if features
are disabled, so which compilation errors do you get that changing
those return codes "fix"?
If you don't have such errors, I don't get your motivations for the
change out of your commit message.

Regards,
Bruno


On Wed, 22 Jun 2016 00:08:40 +0530 Arvind Yadav wrote:
> - inline picolcd_fb_reset and picolcd_init_framebuffer stub simply
>   allows compilation on systems with CONFIG_HID_PICOLCD_FB disabled.
> - inline picolcd_init_backlight and picolcd_resume_backlight stub
>   simply allows compilation on systems with CONFIG_HID_PICOLCD_BACKLIGHT
>   disabled.
> - inline picolcd_init_lcd and picolcd_resume_lcd stub simply allows
>   compilation on systems with CONFIG_HID_PICOLCD_LCD disabled.
> - inline picolcd_init_leds stub simply allows compilation on systems
>   with CONFIG_HID_PICOLCD_LEDS disabled.
> - inline picolcd_init_cir stub simply allows compilation on systems
>   with CONFIG_HID_PICOLCD_CIR disabled.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/hid/hid-picolcd.h | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-picolcd.h b/drivers/hid/hid-picolcd.h
> index e56d847..7e6c10a 100644
> --- a/drivers/hid/hid-picolcd.h
> +++ b/drivers/hid/hid-picolcd.h
> @@ -17,6 +17,8 @@
>   *   along with this software. If not see .  *
>   ***/
>  
> +#include 
> +
>  #define PICOLCD_NAME "PicoLCD (graphic)"
>  
>  /* Report numbers */
> @@ -192,11 +194,11 @@ void picolcd_fb_refresh(struct picolcd_data *data);
>  #else
>  static inline int picolcd_fb_reset(struct picolcd_data *data, int clear)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline int picolcd_init_framebuffer(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENOMEM;
>  }
>  static inline void picolcd_exit_framebuffer(struct picolcd_data *data)
>  {
> @@ -221,14 +223,14 @@ void picolcd_suspend_backlight(struct picolcd_data 
> *data);
>  static inline int picolcd_init_backlight(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_backlight(struct picolcd_data *data)
>  {
>  }
>  static inline int picolcd_resume_backlight(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_suspend_backlight(struct picolcd_data *data)
>  {
> @@ -248,14 +250,14 @@ int picolcd_resume_lcd(struct picolcd_data *data);
>  static inline int picolcd_init_lcd(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_lcd(struct picolcd_data *data)
>  {
>  }
>  static inline int picolcd_resume_lcd(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  #endif /* CONFIG_HID_PICOLCD_LCD */
>  
> @@ -271,7 +273,7 @@ void picolcd_leds_set(struct picolcd_data *data);
>  static inline int picolcd_init_leds(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_leds(struct picolcd_data *data)
>  {
> @@ -297,7 +299,7 @@ static inline int picolcd_raw_cir(struct picolcd_data 
> *data,
>  }
>  static inline int picolcd_init_cir(struct picolcd_data *data, struct 
> hid_report *report)
>  {
> - return 0;
> + return -ENOMEM;
>  }
>  static inline void picolcd_exit_cir(struct picolcd_data *data)
>  {

Re: [PATCH] HID-PICOLCD: Dummy hid-picolcd functions should return error code

[Bruno Prémont]

Hi Arvind,

I can only NACK this patch as it would cause the driver to refuse
probe()ing if any of the features are disabled in kernel configuration.

Have a look at the callers in hid-picolcd_code.c, if any of those
functions does return an error the probe function aborts with an error.


Your commit message talks about allowing compilation if features
are disabled, so which compilation errors do you get that changing
those return codes "fix"?
If you don't have such errors, I don't get your motivations for the
change out of your commit message.

Regards,
Bruno


On Wed, 22 Jun 2016 00:08:40 +0530 Arvind Yadav wrote:
> - inline picolcd_fb_reset and picolcd_init_framebuffer stub simply
>   allows compilation on systems with CONFIG_HID_PICOLCD_FB disabled.
> - inline picolcd_init_backlight and picolcd_resume_backlight stub
>   simply allows compilation on systems with CONFIG_HID_PICOLCD_BACKLIGHT
>   disabled.
> - inline picolcd_init_lcd and picolcd_resume_lcd stub simply allows
>   compilation on systems with CONFIG_HID_PICOLCD_LCD disabled.
> - inline picolcd_init_leds stub simply allows compilation on systems
>   with CONFIG_HID_PICOLCD_LEDS disabled.
> - inline picolcd_init_cir stub simply allows compilation on systems
>   with CONFIG_HID_PICOLCD_CIR disabled.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/hid/hid-picolcd.h | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-picolcd.h b/drivers/hid/hid-picolcd.h
> index e56d847..7e6c10a 100644
> --- a/drivers/hid/hid-picolcd.h
> +++ b/drivers/hid/hid-picolcd.h
> @@ -17,6 +17,8 @@
>   *   along with this software. If not see .  *
>   ***/
>  
> +#include 
> +
>  #define PICOLCD_NAME "PicoLCD (graphic)"
>  
>  /* Report numbers */
> @@ -192,11 +194,11 @@ void picolcd_fb_refresh(struct picolcd_data *data);
>  #else
>  static inline int picolcd_fb_reset(struct picolcd_data *data, int clear)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline int picolcd_init_framebuffer(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENOMEM;
>  }
>  static inline void picolcd_exit_framebuffer(struct picolcd_data *data)
>  {
> @@ -221,14 +223,14 @@ void picolcd_suspend_backlight(struct picolcd_data 
> *data);
>  static inline int picolcd_init_backlight(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_backlight(struct picolcd_data *data)
>  {
>  }
>  static inline int picolcd_resume_backlight(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_suspend_backlight(struct picolcd_data *data)
>  {
> @@ -248,14 +250,14 @@ int picolcd_resume_lcd(struct picolcd_data *data);
>  static inline int picolcd_init_lcd(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_lcd(struct picolcd_data *data)
>  {
>  }
>  static inline int picolcd_resume_lcd(struct picolcd_data *data)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  #endif /* CONFIG_HID_PICOLCD_LCD */
>  
> @@ -271,7 +273,7 @@ void picolcd_leds_set(struct picolcd_data *data);
>  static inline int picolcd_init_leds(struct picolcd_data *data,
>   struct hid_report *report)
>  {
> - return 0;
> + return -ENODEV;
>  }
>  static inline void picolcd_exit_leds(struct picolcd_data *data)
>  {
> @@ -297,7 +299,7 @@ static inline int picolcd_raw_cir(struct picolcd_data 
> *data,
>  }
>  static inline int picolcd_init_cir(struct picolcd_data *data, struct 
> hid_report *report)
>  {
> - return 0;
> + return -ENOMEM;
>  }
>  static inline void picolcd_exit_cir(struct picolcd_data *data)
>  {

Re: piping core dump to a program escapes container

[Bruno Prémont]

On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote:
> Dongsheng Yang  writes:
> 
> > On 12/09/2015 10:26 AM, Dongsheng Yang wrote:  
> >> On 10/25/2015 05:54 AM, Shayan Pooya wrote:  
> >>> I noticed the following core_pattern behavior in my linux box while
> >>> running docker containers. I am not sure if it is bug, but it is
> >>> inconsistent and not documented.
> >>>
> >>> If the core_pattern is set on the host, the containers will observe
> >>> and use the pattern for dumping cores (there is no per cgroup
> >>> core_pattern). According to core(5) for setting core_pattern one can:
> >>>
> >>> 1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern
> >>> 2. echo "|/bin/custom_core /tmp/cores/ %e %p " >
> >>> /proc/sys/kernel/core_pattern
> >>>
> >>> The former pattern evaluates the /tmp/cores path in the container's
> >>> filesystem namespace. Which means, the host does not see a core file
> >>> in /tmp/cores.
> >>>
> >>> However, the latter evaluates the /bin/custom_core path in the global
> >>> filesystem namespace. Moreover, if /bin/core decides to write the core
> >>> to a path (/tmp/cores in this case as shown by the arg to
> >>> custom_core), the path will be evaluated in the global filesystem
> >>> namespace as well.
> >>>
> >>> The latter behaviour is counter-intuitive and error-prone as the
> >>> container can fill up the core-file directory which it does not have
> >>> direct access to (which means the core is also not accessible for
> >>> debugging if someone only has access to the container).  
> 
> From a container perspective it is perhaps counter intuitive from
> the perspective of the operator of the machine nothing works specially
> about core_pattern and it works as designed with no unusual danages.
> 
> >> Hi Shayan,
> >>  We found the same problem with what you described here.
> >> Is there any document for this behaviour? I want to know is
> >> that intentional or as you said a 'bug'. Maybe that's intentional
> >> to provide a way for admin to collect core dumps from all containers as
> >> Richard said. I am interested in it too.
> >>
> >> Anyone can help here?  
> >
> > In addition, is that a good idea to make core_pattern to be seperated
> > in different namespace?  
> 
> The behavior was the best we could do at the time last time this issue
> was examined.There is enough information available to be able to
> write a core dumping program that can reliably place your core dumps
> in your container.
> 
> There has not yet been an obvious namespace in which to stick
> core_pattern, and even worse exactly how to appropriate launch a process
> in a container has not been figured out.
> 
> If those tricky problems can be solved we can have a core_pattern in a
> container.  What we have now is the best we have been able to figure out
> so far.

Isn't the second option dangerous if its run in global namespace and
settable from some other namespace/container?

If a process inside a container can set /proc/sys/kernel/core_pattern
then it could e.g. set it to
  echo "|/bin/rm -rf / /tmp/cores/ %e %p " > /proc/sys/kernel/core_pattern
and kill the host (eventually itself included).
Other command lines could do different bad things.


Something that would sound reasonable is to have the core dumping
helper process run under the namespaces the process which wrote to
/proc/sys/kernel/core_pattern had.
When some of those namespaces are gone, falling back to the namespaces
of the process for which core is to be dumped might seem reasonable
(or just not dumping core at all as is done when core_pipe_limit is
exceeded).

The value of core_pattern (and other core_* sysctls)  should probably belong
to the mount namespace the proc filesystem used for setting its value
was in - or the matching namespace of calling process when set via syscall.

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: piping core dump to a program escapes container

[Bruno Prémont]

On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote:
> Dongsheng Yang  writes:
> 
> > On 12/09/2015 10:26 AM, Dongsheng Yang wrote:  
> >> On 10/25/2015 05:54 AM, Shayan Pooya wrote:  
> >>> I noticed the following core_pattern behavior in my linux box while
> >>> running docker containers. I am not sure if it is bug, but it is
> >>> inconsistent and not documented.
> >>>
> >>> If the core_pattern is set on the host, the containers will observe
> >>> and use the pattern for dumping cores (there is no per cgroup
> >>> core_pattern). According to core(5) for setting core_pattern one can:
> >>>
> >>> 1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern
> >>> 2. echo "|/bin/custom_core /tmp/cores/ %e %p " >
> >>> /proc/sys/kernel/core_pattern
> >>>
> >>> The former pattern evaluates the /tmp/cores path in the container's
> >>> filesystem namespace. Which means, the host does not see a core file
> >>> in /tmp/cores.
> >>>
> >>> However, the latter evaluates the /bin/custom_core path in the global
> >>> filesystem namespace. Moreover, if /bin/core decides to write the core
> >>> to a path (/tmp/cores in this case as shown by the arg to
> >>> custom_core), the path will be evaluated in the global filesystem
> >>> namespace as well.
> >>>
> >>> The latter behaviour is counter-intuitive and error-prone as the
> >>> container can fill up the core-file directory which it does not have
> >>> direct access to (which means the core is also not accessible for
> >>> debugging if someone only has access to the container).  
> 
> From a container perspective it is perhaps counter intuitive from
> the perspective of the operator of the machine nothing works specially
> about core_pattern and it works as designed with no unusual danages.
> 
> >> Hi Shayan,
> >>  We found the same problem with what you described here.
> >> Is there any document for this behaviour? I want to know is
> >> that intentional or as you said a 'bug'. Maybe that's intentional
> >> to provide a way for admin to collect core dumps from all containers as
> >> Richard said. I am interested in it too.
> >>
> >> Anyone can help here?  
> >
> > In addition, is that a good idea to make core_pattern to be seperated
> > in different namespace?  
> 
> The behavior was the best we could do at the time last time this issue
> was examined.There is enough information available to be able to
> write a core dumping program that can reliably place your core dumps
> in your container.
> 
> There has not yet been an obvious namespace in which to stick
> core_pattern, and even worse exactly how to appropriate launch a process
> in a container has not been figured out.
> 
> If those tricky problems can be solved we can have a core_pattern in a
> container.  What we have now is the best we have been able to figure out
> so far.

Isn't the second option dangerous if its run in global namespace and
settable from some other namespace/container?

If a process inside a container can set /proc/sys/kernel/core_pattern
then it could e.g. set it to
  echo "|/bin/rm -rf / /tmp/cores/ %e %p " > /proc/sys/kernel/core_pattern
and kill the host (eventually itself included).
Other command lines could do different bad things.


Something that would sound reasonable is to have the core dumping
helper process run under the namespaces the process which wrote to
/proc/sys/kernel/core_pattern had.
When some of those namespaces are gone, falling back to the namespaces
of the process for which core is to be dumped might seem reasonable
(or just not dumping core at all as is done when core_pipe_limit is
exceeded).

The value of core_pattern (and other core_* sysctls)  should probably belong
to the mount namespace the proc filesystem used for setting its value
was in - or the matching namespace of calling process when set via syscall.

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

[Bruno Prémont]

Hi Darren,

Looks like the Apple issue with backlight working on hidden Intel IGP
(doing IO on VGA addresses) while graphics are running on visible
discrete GPU (Radeon this time instead of usual nvidia).


I should have offered a solution quite some time ago but it seem time
was running very fast.
The best solution I can think of is denying any vga_arb on Apple EFI
systems (and not trying to choose the right one which is not possible
when one of both GPUs is hidden).


The lines of interest in dmesg are:
[0.210225] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.210227] vgaarb: loaded
[0.210228] vgaarb: setting as boot device: PCI::01:00.0
[0.210229] vgaarb: bridge control possible :01:00.0
[0.385583] fb0: EFI VGA frame buffer device
[7.738507] apple_gmux: Found gmux version 4.0.20 [indexed]
[7.738514] apple_gmux: locked IO for PCI::01:00.0
[7.792805] fb: switching to radeondrmfb from EFI VGA

Not loading apple_gmux might or might not affect ability to control
backlight depending on what backlight devices go registered
(radeon backlight device probably does not affect screen, at best an
ACPI backlight device might work)

Interesting part to check is how things work when both GPU are visible
to OS.

Thanks,
Bruno

On Thu, 22 Oct 2015 11:36:52 Darren Hart wrote:
> Bruno, can you please have a look at the following regression attributed to:
> 
> 4eebd5a apple-gmux: lock iGP IO to protect from vgaarb changes
>  2015-03-18 (7 months ago), Bruno Prémont 
> 
> 
> On Thu, Oct 15, 2015 at 04:47:13AM +, bugzilla-dae...@bugzilla.kernel.org 
> wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=105051
> > 
> > Felipe Ortiz  changed:
> > 
> >What|Removed |Added
> > 
> >  CC||fort...@gmail.com
> > 
> > --- Comment #14 from Felipe Ortiz  ---
> > I can confirm the problem with 4eebd5a4e72697aac25a8a57d3f888a9d5f80370. I 
> > have
> > a MPB 11,5 with AMD/Intel graphics. I recompile the module (a previous 
> > version
> > of 4eebd5a4e72697aac25a8a57d3f888a9d5f80370) and brightness adjusts is 
> > working
> > again.
> > 
> > I see two problems: 
> > 
> > 1) If someone uses gpu-switch (https://github.com/0xbb/gpu-switch) with this
> > bug screen seem not work, after severals reboots (with different kernels) I 
> > can
> > access a terminal and execute gpu-switch -d and then screen seems work 
> > again.
> > 
> > 2) If you use a Intel card (swiched with gpu-switch) the OSD (activated with
> > functions keys) is so slow and chromium have the same problem (temporary 
> > fix is
> > deactivate chromium hw acceleration) is this a intel driver bug?
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> > 
> 
> Thanks,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

[Bruno Prémont]

Hi Darren,

Looks like the Apple issue with backlight working on hidden Intel IGP
(doing IO on VGA addresses) while graphics are running on visible
discrete GPU (Radeon this time instead of usual nvidia).


I should have offered a solution quite some time ago but it seem time
was running very fast.
The best solution I can think of is denying any vga_arb on Apple EFI
systems (and not trying to choose the right one which is not possible
when one of both GPUs is hidden).


The lines of interest in dmesg are:
[0.210225] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.210227] vgaarb: loaded
[0.210228] vgaarb: setting as boot device: PCI::01:00.0
[0.210229] vgaarb: bridge control possible :01:00.0
[0.385583] fb0: EFI VGA frame buffer device
[7.738507] apple_gmux: Found gmux version 4.0.20 [indexed]
[7.738514] apple_gmux: locked IO for PCI::01:00.0
[7.792805] fb: switching to radeondrmfb from EFI VGA

Not loading apple_gmux might or might not affect ability to control
backlight depending on what backlight devices go registered
(radeon backlight device probably does not affect screen, at best an
ACPI backlight device might work)

Interesting part to check is how things work when both GPU are visible
to OS.

Thanks,
Bruno

On Thu, 22 Oct 2015 11:36:52 Darren Hart wrote:
> Bruno, can you please have a look at the following regression attributed to:
> 
> 4eebd5a apple-gmux: lock iGP IO to protect from vgaarb changes
>  2015-03-18 (7 months ago), Bruno Prémont <bonb...@linux-vserver.org>
> 
> 
> On Thu, Oct 15, 2015 at 04:47:13AM +, bugzilla-dae...@bugzilla.kernel.org 
> wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=105051
> > 
> > Felipe Ortiz <fort...@gmail.com> changed:
> > 
> >What|Removed |Added
> > 
> >  CC||fort...@gmail.com
> > 
> > --- Comment #14 from Felipe Ortiz <fort...@gmail.com> ---
> > I can confirm the problem with 4eebd5a4e72697aac25a8a57d3f888a9d5f80370. I 
> > have
> > a MPB 11,5 with AMD/Intel graphics. I recompile the module (a previous 
> > version
> > of 4eebd5a4e72697aac25a8a57d3f888a9d5f80370) and brightness adjusts is 
> > working
> > again.
> > 
> > I see two problems: 
> > 
> > 1) If someone uses gpu-switch (https://github.com/0xbb/gpu-switch) with this
> > bug screen seem not work, after severals reboots (with different kernels) I 
> > can
> > access a terminal and execute gpu-switch -d and then screen seems work 
> > again.
> > 
> > 2) If you use a Intel card (swiched with gpu-switch) the OSD (activated with
> > functions keys) is so slow and chromium have the same problem (temporary 
> > fix is
> > deactivate chromium hw acceleration) is this a intel driver bug?
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> > 
> 
> Thanks,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] HID-picoLCD: Deletion of unnecessary checks before three function calls

[Bruno Prémont]

On Sun, 28 Jun 2015 13:54:56 +0200 SF Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Wed, 19 Nov 2014 18:30:22 +0100
> > 
> > The functions backlight_device_unregister(), lcd_device_unregister() and
> > rc_unregister_device() test whether their argument is NULL and then
> > return immediately. Thus the test around the call is not needed.
> > 
> > This issue was detected by using the Coccinelle software.
> > 
> > Signed-off-by: Markus Elfring 
> > ---
> >  drivers/hid/hid-picolcd_backlight.c | 3 +--
> >  drivers/hid/hid-picolcd_cir.c   | 3 +--
> >  drivers/hid/hid-picolcd_lcd.c   | 3 +--
> >  3 files changed, 3 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-picolcd_backlight.c 
> > b/drivers/hid/hid-picolcd_backlight.c
> > index a32c5f8..808807a 100644
> > --- a/drivers/hid/hid-picolcd_backlight.c
> > +++ b/drivers/hid/hid-picolcd_backlight.c
> > @@ -94,8 +94,7 @@ void picolcd_exit_backlight(struct picolcd_data *data)
> > struct backlight_device *bdev = data->backlight;
> >  
> > data->backlight = NULL;
> > -   if (bdev)
> > -   backlight_device_unregister(bdev);
> > +   backlight_device_unregister(bdev);
> >  }
> >  
> >  int picolcd_resume_backlight(struct picolcd_data *data)
> > diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
> > index 045f8eb..9628651 100644
> > --- a/drivers/hid/hid-picolcd_cir.c
> > +++ b/drivers/hid/hid-picolcd_cir.c
> > @@ -145,7 +145,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
> > struct rc_dev *rdev = data->rc_dev;
> >  
> > data->rc_dev = NULL;
> > -   if (rdev)
> > -   rc_unregister_device(rdev);
> > +   rc_unregister_device(rdev);
> >  }
> >  
> > diff --git a/drivers/hid/hid-picolcd_lcd.c b/drivers/hid/hid-picolcd_lcd.c
> > index 89821c2..22dcbe1 100644
> > --- a/drivers/hid/hid-picolcd_lcd.c
> > +++ b/drivers/hid/hid-picolcd_lcd.c
> > @@ -92,8 +92,7 @@ void picolcd_exit_lcd(struct picolcd_data *data)
> > struct lcd_device *ldev = data->lcd;
> >  
> > data->lcd = NULL;
> > -   if (ldev)
> > -   lcd_device_unregister(ldev);
> > +   lcd_device_unregister(ldev);
> >  }
> >  
> >  int picolcd_resume_lcd(struct picolcd_data *data)
> > 
> 
> Would you like to integrate this update suggestion
> into another source code repository?

Sorry for forgetting about this patch.

Looks good to me:
  Reviewed-by: Bruno Prémont 

Jiri, can you take it?

Best regards,
Bruno

> Regards,
> Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] HID-picoLCD: Deletion of unnecessary checks before three function calls

[Bruno Prémont]

On Sun, 28 Jun 2015 13:54:56 +0200 SF Markus Elfring wrote:
  From: Markus Elfring elfr...@users.sourceforge.net
  Date: Wed, 19 Nov 2014 18:30:22 +0100
  
  The functions backlight_device_unregister(), lcd_device_unregister() and
  rc_unregister_device() test whether their argument is NULL and then
  return immediately. Thus the test around the call is not needed.
  
  This issue was detected by using the Coccinelle software.
  
  Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
  ---
   drivers/hid/hid-picolcd_backlight.c | 3 +--
   drivers/hid/hid-picolcd_cir.c   | 3 +--
   drivers/hid/hid-picolcd_lcd.c   | 3 +--
   3 files changed, 3 insertions(+), 6 deletions(-)
  
  diff --git a/drivers/hid/hid-picolcd_backlight.c 
  b/drivers/hid/hid-picolcd_backlight.c
  index a32c5f8..808807a 100644
  --- a/drivers/hid/hid-picolcd_backlight.c
  +++ b/drivers/hid/hid-picolcd_backlight.c
  @@ -94,8 +94,7 @@ void picolcd_exit_backlight(struct picolcd_data *data)
  struct backlight_device *bdev = data-backlight;
   
  data-backlight = NULL;
  -   if (bdev)
  -   backlight_device_unregister(bdev);
  +   backlight_device_unregister(bdev);
   }
   
   int picolcd_resume_backlight(struct picolcd_data *data)
  diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
  index 045f8eb..9628651 100644
  --- a/drivers/hid/hid-picolcd_cir.c
  +++ b/drivers/hid/hid-picolcd_cir.c
  @@ -145,7 +145,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
  struct rc_dev *rdev = data-rc_dev;
   
  data-rc_dev = NULL;
  -   if (rdev)
  -   rc_unregister_device(rdev);
  +   rc_unregister_device(rdev);
   }
   
  diff --git a/drivers/hid/hid-picolcd_lcd.c b/drivers/hid/hid-picolcd_lcd.c
  index 89821c2..22dcbe1 100644
  --- a/drivers/hid/hid-picolcd_lcd.c
  +++ b/drivers/hid/hid-picolcd_lcd.c
  @@ -92,8 +92,7 @@ void picolcd_exit_lcd(struct picolcd_data *data)
  struct lcd_device *ldev = data-lcd;
   
  data-lcd = NULL;
  -   if (ldev)
  -   lcd_device_unregister(ldev);
  +   lcd_device_unregister(ldev);
   }
   
   int picolcd_resume_lcd(struct picolcd_data *data)
  
 
 Would you like to integrate this update suggestion
 into another source code repository?

Sorry for forgetting about this patch.

Looks good to me:
  Reviewed-by: Bruno Prémont bonb...@linux-vserver.org

Jiri, can you take it?

Best regards,
Bruno

 Regards,
 Markus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Fri, 29 May 2015 18:36:50 +0200 Darren Hart wrote:
> > Making sure to lock only the intel GPU when present and especially 
> > protecting
> > against nvidia driver will be hard if legacy-IO is being processed by a 
> > hidden
> > device!
> 
> Ugh indeed. Worst case we can special case via dmi strings. Is this Apple 
> device
> significantly different from others? Bruno, what are you testing on?

I only own a pretty old MacBook Air with just NVIDIA IGP and had to
rely on BUG reports and testing from affected users.

Not doing anything on apple-gmux when only a single GPU is visible
should be easy, but denying any vgaarb operation when Intel IGP is
hidden and just discrete GPU present is much harder (if one does not
want to risk opening the next can of worms).

DMI based special-casing would work but will it uncover the next issue
with the same device configured differently?

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Fri, 29 May 2015 18:36:50 +0200 Darren Hart wrote:
  Making sure to lock only the intel GPU when present and especially 
  protecting
  against nvidia driver will be hard if legacy-IO is being processed by a 
  hidden
  device!
 
 Ugh indeed. Worst case we can special case via dmi strings. Is this Apple 
 device
 significantly different from others? Bruno, what are you testing on?

I only own a pretty old MacBook Air with just NVIDIA IGP and had to
rely on BUG reports and testing from affected users.

Not doing anything on apple-gmux when only a single GPU is visible
should be easy, but denying any vgaarb operation when Intel IGP is
hidden and just discrete GPU present is much harder (if one does not
want to risk opening the next can of worms).

DMI based special-casing would work but will it uncover the next issue
with the same device configured differently?

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Tue, 26 May 2015 22:35:46 -0700 Michael Marineau wrote:
> On Tue, May 26, 2015 at 9:47 PM, Darren Hart  wrote:
> > On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
> >> FYI, this actually broke backlight controls on my MBP11,3 because the
> >> assumption the patch makes that gmux is always loaded before graphics
> >> drivers didn't hold true. At least for me dracut included the nouveau
> >> module in the initrd but not gmux, ensuring the ordering was wrong. No
> >> errors were reporting, and gmux still offered the backlight device, it
> >> just became inoperable. I worked around this for my kernel by building
> >> gmux into vmlinuz instead of as a module but that isn't going to in
> >> more general configs because there is an apple backlight driver which
> >> cannot be built at all in that configuration.
> >>
> >
> > Thank you for reporting this Michael,
> >
> > That is tough as nouveau doesn't have an explicit dependency on gmux, so we
> > could do something like a passive request_module(), but if it isn't in the
> > initrd image, it would still fail as you describe.
> >
> >> Is there a way to make the ordering between nouveau and gmux more
> >> explicit/reliable? Can gmux complain loudly if the ordering is ever
> >> wrong?
> >
> > It should print an error if the probe fails due to the IO already being in 
> > use
> > or if it can't be allocated. The disabled IO case is only info level though,
> > perhaps that should be higher priority. Printing something when failing to 
> > probe
> > seems like a reasonable thing to do.
> >
> > Michael, which message do you get if you boot with "debug" or "loglevel=6" 
> > when
> > apple-gmux is not built-in?
> 
> No error, gmux claims it worked:
> [   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
> [   13.693400] vgaarb: device changed decodes:
> PCI::01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
> [   13.693404] apple_gmux: locked IO for PCI::01:00.0
> 
> Full dmesg: https://gist.github.com/marineam/0e5a23548e8b3b2e1d50

What GPUs are there in your MBP11,3? From your dmesg it looks like all
you have is NVIDIA GPU :01:00.0 (lspci?).

Is there a somehow hidden intel GPU around doing the backlight?
If so my locking does the wrong thing for your system as:

[0.393298] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.393299] vgaarb: loaded
[0.393300] vgaarb: setting as boot device: PCI::01:00.0
[0.393301] vgaarb: bridge control possible :01:00.0
...
[   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
[   13.693400] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
[   13.693404] apple_gmux: locked IO for PCI::01:00.0

Here it triggers "olddecodes=none -> io+mem".

Making sure to lock only the intel GPU when present and especially protecting
against nvidia driver will be hard if legacy-IO is being processed by a hidden
device!

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

Hi Michael,

On Tue, 26 May 2015 21:47:49 -0700 Darren Hart wrote:
> On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
> > FYI, this actually broke backlight controls on my MBP11,3 because the
> > assumption the patch makes that gmux is always loaded before graphics
> > drivers didn't hold true. At least for me dracut included the nouveau
> > module in the initrd but not gmux, ensuring the ordering was wrong. No
> > errors were reporting, and gmux still offered the backlight device, it
> > just became inoperable. I worked around this for my kernel by building
> > gmux into vmlinuz instead of as a module but that isn't going to in
> > more general configs because there is an apple backlight driver which
> > cannot be built at all in that configuration.
> 
> Thank you for reporting this Michael,
> 
> That is tough as nouveau doesn't have an explicit dependency on gmux, so we
> could do something like a passive request_module(), but if it isn't in the
> initrd image, it would still fail as you describe.
> 
> > Is there a way to make the ordering between nouveau and gmux more
> > explicit/reliable? Can gmux complain loudly if the ordering is ever
> > wrong?
> 
> It should print an error if the probe fails due to the IO already being in use
> or if it can't be allocated. The disabled IO case is only info level though,
> perhaps that should be higher priority. Printing something when failing to 
> probe
> seems like a reasonable thing to do.
> 
> Michael, which message do you get if you boot with "debug" or "loglevel=6" 
> when
> apple-gmux is not built-in?

A full kernel log up to including post-initrd loading of gmux would be
useful.

As far as I have seen nouveau should not be doing unneeded vgaarb
operations by itself (though userspace might be) as opposed to closed
nvidia driver.

If your systems allows, try booting to init=/bin/bash, then check for
backlight, load nouveau, check for backlight and finally load gmux and
check backlight (putting i915 in the mix where initrd/userspace puts
it would be nice).

Thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

Hi Michael,

On Tue, 26 May 2015 21:47:49 -0700 Darren Hart wrote:
 On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
  FYI, this actually broke backlight controls on my MBP11,3 because the
  assumption the patch makes that gmux is always loaded before graphics
  drivers didn't hold true. At least for me dracut included the nouveau
  module in the initrd but not gmux, ensuring the ordering was wrong. No
  errors were reporting, and gmux still offered the backlight device, it
  just became inoperable. I worked around this for my kernel by building
  gmux into vmlinuz instead of as a module but that isn't going to in
  more general configs because there is an apple backlight driver which
  cannot be built at all in that configuration.
 
 Thank you for reporting this Michael,
 
 That is tough as nouveau doesn't have an explicit dependency on gmux, so we
 could do something like a passive request_module(), but if it isn't in the
 initrd image, it would still fail as you describe.
 
  Is there a way to make the ordering between nouveau and gmux more
  explicit/reliable? Can gmux complain loudly if the ordering is ever
  wrong?
 
 It should print an error if the probe fails due to the IO already being in use
 or if it can't be allocated. The disabled IO case is only info level though,
 perhaps that should be higher priority. Printing something when failing to 
 probe
 seems like a reasonable thing to do.
 
 Michael, which message do you get if you boot with debug or loglevel=6 
 when
 apple-gmux is not built-in?

A full kernel log up to including post-initrd loading of gmux would be
useful.

As far as I have seen nouveau should not be doing unneeded vgaarb
operations by itself (though userspace might be) as opposed to closed
nvidia driver.

If your systems allows, try booting to init=/bin/bash, then check for
backlight, load nouveau, check for backlight and finally load gmux and
check backlight (putting i915 in the mix where initrd/userspace puts
it would be nice).

Thanks,
Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Tue, 26 May 2015 22:35:46 -0700 Michael Marineau wrote:
 On Tue, May 26, 2015 at 9:47 PM, Darren Hart dvh...@infradead.org wrote:
  On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
  FYI, this actually broke backlight controls on my MBP11,3 because the
  assumption the patch makes that gmux is always loaded before graphics
  drivers didn't hold true. At least for me dracut included the nouveau
  module in the initrd but not gmux, ensuring the ordering was wrong. No
  errors were reporting, and gmux still offered the backlight device, it
  just became inoperable. I worked around this for my kernel by building
  gmux into vmlinuz instead of as a module but that isn't going to in
  more general configs because there is an apple backlight driver which
  cannot be built at all in that configuration.
 
 
  Thank you for reporting this Michael,
 
  That is tough as nouveau doesn't have an explicit dependency on gmux, so we
  could do something like a passive request_module(), but if it isn't in the
  initrd image, it would still fail as you describe.
 
  Is there a way to make the ordering between nouveau and gmux more
  explicit/reliable? Can gmux complain loudly if the ordering is ever
  wrong?
 
  It should print an error if the probe fails due to the IO already being in 
  use
  or if it can't be allocated. The disabled IO case is only info level though,
  perhaps that should be higher priority. Printing something when failing to 
  probe
  seems like a reasonable thing to do.
 
  Michael, which message do you get if you boot with debug or loglevel=6 
  when
  apple-gmux is not built-in?
 
 No error, gmux claims it worked:
 [   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
 [   13.693400] vgaarb: device changed decodes:
 PCI::01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
 [   13.693404] apple_gmux: locked IO for PCI::01:00.0
 
 Full dmesg: https://gist.github.com/marineam/0e5a23548e8b3b2e1d50

What GPUs are there in your MBP11,3? From your dmesg it looks like all
you have is NVIDIA GPU :01:00.0 (lspci?).

Is there a somehow hidden intel GPU around doing the backlight?
If so my locking does the wrong thing for your system as:

[0.393298] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.393299] vgaarb: loaded
[0.393300] vgaarb: setting as boot device: PCI::01:00.0
[0.393301] vgaarb: bridge control possible :01:00.0
...
[   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
[   13.693400] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
[   13.693404] apple_gmux: locked IO for PCI::01:00.0

Here it triggers olddecodes=none - io+mem.

Making sure to lock only the intel GPU when present and especially protecting
against nvidia driver will be hard if legacy-IO is being processed by a hidden
device!

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju 
Tested-by: Petri Hodju 
Cc: Bjorn Helgaas 
Cc: Matthew Garrett 
Signed-off-by: Bruno Prémont 
---
Resending v2 in the hope Darren won't hit quoted-printable.
Also adding linux-pci on CC by Bjorn's request in bugzilla.

Changes since v2:
- Renamed gmux_find_pdev to gmux_get_io_pdev
- Whitespace fix
- vga_put() on error path

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..e743b03 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,23 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_get_io_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (!(cmd & PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +444,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +495,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version >> 16) & 0xff;
ver_release = (version >> 8) & 0xff;
} else {
-   pr_info("gmux device not present\n");
+   pr_info("gmux device not present or IO disabled\n");
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +503,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
ver_release, (gmux_data->indexed ? "indexed" : "classic"));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_get_io_pdev();
+   if (pdev && vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err("IO+MEM vgaarb-locking for PCI:%s failed\n",
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info("locked IO for PCI:%s\n", pci_name(pdev));
+   gmux_data->pdev = pdev;
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +611,10 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   if (gmux_data->pdev)
+   vga_put(gmux_data->pdev,
+   VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM);
+   pci_dev

[Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju petriho...@yahoo.com
Tested-by: Petri Hodju petriho...@yahoo.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matthew Garrett matthew.garr...@nebula.com
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Resending v2 in the hope Darren won't hit quoted-printable.
Also adding linux-pci on CC by Bjorn's request in bugzilla.

Changes since v2:
- Renamed gmux_find_pdev to gmux_get_io_pdev
- Whitespace fix
- vga_put() on error path

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..e743b03 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include linux/delay.h
 #include linux/pci.h
 #include linux/vga_switcheroo.h
+#include linux/vgaarb.h
 #include acpi/video.h
 #include asm/io.h
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,23 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_get_io_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, cmd);
+   if (!(cmd  PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +444,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +495,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version  16)  0xff;
ver_release = (version  8)  0xff;
} else {
-   pr_info(gmux device not present\n);
+   pr_info(gmux device not present or IO disabled\n);
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +503,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info(Found gmux version %d.%d.%d [%s]\n, ver_major, ver_minor,
ver_release, (gmux_data-indexed ? indexed : classic));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_get_io_pdev();
+   if (pdev  vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err(IO+MEM vgaarb-locking for PCI:%s failed\n,
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info(locked IO for PCI:%s\n, pci_name(pdev));
+   gmux_data-pdev = pdev;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +611,10 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   if (gmux_data-pdev)
+   vga_put(gmux_data-pdev

Re: [Patch v2 resend] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju 
Tested-by: Petri Hodju 
Cc: Bjorn Helgaas 
Cc: Matthew Garrett 
Signed-off-by: Bruno Prémont 
---
Resending v2 in the hope Darren won't hit quoted-printable.
Also adding linux-pci on CC by Bjorn's request in bugzilla.

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (!(cmd & PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version >> 16) & 0xff;
ver_release = (version >> 8) & 0xff;
} else {
-   pr_info("gmux device not present\n");
+   pr_info("gmux device not present or IO disabled\n");
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
ver_release, (gmux_data->indexed ? "indexed" : "classic"));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev && vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err("IO+MEM vgaarb-locking for PCI:%s failed\n",
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info("locked IO for PCI:%s\n", pci_name(pdev));
+   gmux_data->pdev = pdev;
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data->iostart, gmux_data->iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
   _notify_handler);
  

Re: [Patch v2 resend] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju petriho...@yahoo.com
Tested-by: Petri Hodju petriho...@yahoo.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matthew Garrett matthew.garr...@nebula.com
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Resending v2 in the hope Darren won't hit quoted-printable.
Also adding linux-pci on CC by Bjorn's request in bugzilla.

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include linux/delay.h
 #include linux/pci.h
 #include linux/vga_switcheroo.h
+#include linux/vgaarb.h
 #include acpi/video.h
 #include asm/io.h
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, cmd);
+   if (!(cmd  PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version  16)  0xff;
ver_release = (version  8)  0xff;
} else {
-   pr_info(gmux device not present\n);
+   pr_info(gmux device not present or IO disabled\n);
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info(Found gmux version %d.%d.%d [%s]\n, ver_major, ver_minor,
ver_release, (gmux_data-indexed ? indexed : classic));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev  vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err(IO+MEM vgaarb-locking for PCI:%s failed\n,
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info(locked IO for PCI:%s\n, pci_name(pdev));
+   gmux_data-pdev = pdev;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data-iostart, gmux_data-iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp

Re: [Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Fri, 06 March 2015 Darren Hart  wrote:
> On Thu, Mar 05, 2015 at 11:20:38PM +0100, Bruno Prémont wrote:
> > As GMUX depends on IO for iGP to be enabled and active, lock the IO at
> > vgaarb level. This should prevent GPU driver for dGPU to disable IO for
> > iGP while it tries to own legacy VGA IO.
> > 
> > This fixes usage of backlight control combined with closed nvidia
> > driver on some Apple dual-GPU (intel/nvidia) systems.
> > 
> > On those systems loading nvidia driver disables intel IO decoding,
> > disabling the gmux backlight controls as a side effect.
> > Prior to commits moving boot_vga from (optional) efifb to less optional
> > vgaarb this mis-behavior could be avoided by using right kernel config
> > (efifb enabled but vgaarb disabled).
> > 
> > This patch explicitly does not try to trigger vgaarb changes in order
> > to avoid confusing already running graphics drivers. If IO has been
> > mis-configured by vgaarb gmux will thus fail to probe.
> > It is expected to load/probe gmux prior to graphics drivers.
> > 
> > Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
> > Reported-by: Petri Hodju 
> > Tested-by: Petri Hodju 
> > Cc: Bjorn Helgaas 
> > Cc: Matthew Garrett 
> > Signed-off-by: Bruno Prémont 
> > ---
> > Respinning, fixing Darren's nit.
> > 
> > Changes since v1:
> > - Dropped repeat of gmux in pr_info/pr_err calls
> > - Mention PCI device we tried to lock IO for in case of error

Hi Darren,

> Hi Bruno,
> 
> I don't know if this is on your end or mine (I've not seen this before). 
> Saving
> off your patch (through mutt like I do everything else) to a file and applying
> works, build works, and git show and visual inspection look correct.
> 
> However, checkpatch sees a lot of =3D instead of just =, and complains 
> bitterly.
> 
> Can you check this patch (from the list) and let me know what you find?

That smells like `Content-Transfer-Encoding: quoted-printable` not being
understood by check-patch when operating on a raw mail.
No idea if mutt can recode the mail to plain 8-bit/UTF-8 when saving...
patch from patch-utils might have the same issues with it while git-am is
fine (as it handles mail-patches including charset and other headers).

I'm sending the mail via claws-mail which might encode it more
conservatively than e.g. git-send-email. I can see if there's an option
to prefer 8-bit over quoted-printable though.

Bruno


> ERROR: patch seems to be corrupt (line wrapped?)
> #93: FILE: drivers/platform/x86/apple-gmux.c:27:
> =20
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #108: FILE: drivers/platform/x86/apple-gmux.c:421:
> + struct pci_dev *pdev =3D NULL;
>^
> 
> WARNING: Missing a blank line after declarations
> #109: FILE: drivers/platform/x86/apple-gmux.c:422:
> + struct pci_dev *pdev =3D NULL;
> + while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #109: FILE: drivers/platform/x86/apple-gmux.c:422:
> + while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
>^
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #130: FILE: drivers/platform/x86/apple-gmux.c:447:
> + struct pci_dev *pdev =3D NULL;
>^
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #155: FILE: drivers/platform/x86/apple-gmux.c:510:
> + pdev =3D gmux_find_pdev();
>^
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #160: FILE: drivers/platform/x86/apple-gmux.c:515:
> + ret =3D -EBUSY;
>   ^
> 
> ERROR: need consistent spacing around '-' (ctx:WxV)
> #160: FILE: drivers/platform/x86/apple-gmux.c:515:
> + ret =3D -EBUSY;
>   ^
> 
> ERROR: spaces required around that '=' (ctx:WxV)
> #164: FILE: drivers/platform/x86/apple-gmux.c:519:
> + gmux_data->pdev =3D pdev;
>   ^
> 
> total: 8 errors, 1 warnings, 96 lines checked
> 
> /home/dvhart/apple.patch has style problems, please review.
> 
> If any of these errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

On Fri, 06 March 2015 Darren Hart dvh...@infradead.org wrote:
 On Thu, Mar 05, 2015 at 11:20:38PM +0100, Bruno Prémont wrote:
  As GMUX depends on IO for iGP to be enabled and active, lock the IO at
  vgaarb level. This should prevent GPU driver for dGPU to disable IO for
  iGP while it tries to own legacy VGA IO.
  
  This fixes usage of backlight control combined with closed nvidia
  driver on some Apple dual-GPU (intel/nvidia) systems.
  
  On those systems loading nvidia driver disables intel IO decoding,
  disabling the gmux backlight controls as a side effect.
  Prior to commits moving boot_vga from (optional) efifb to less optional
  vgaarb this mis-behavior could be avoided by using right kernel config
  (efifb enabled but vgaarb disabled).
  
  This patch explicitly does not try to trigger vgaarb changes in order
  to avoid confusing already running graphics drivers. If IO has been
  mis-configured by vgaarb gmux will thus fail to probe.
  It is expected to load/probe gmux prior to graphics drivers.
  
  Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
  Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
  Reported-by: Petri Hodju petriho...@yahoo.com
  Tested-by: Petri Hodju petriho...@yahoo.com
  Cc: Bjorn Helgaas bhelg...@google.com
  Cc: Matthew Garrett matthew.garr...@nebula.com
  Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
  ---
  Respinning, fixing Darren's nit.
  
  Changes since v1:
  - Dropped repeat of gmux in pr_info/pr_err calls
  - Mention PCI device we tried to lock IO for in case of error

Hi Darren,

 Hi Bruno,
 
 I don't know if this is on your end or mine (I've not seen this before). 
 Saving
 off your patch (through mutt like I do everything else) to a file and applying
 works, build works, and git show and visual inspection look correct.
 
 However, checkpatch sees a lot of =3D instead of just =, and complains 
 bitterly.
 
 Can you check this patch (from the list) and let me know what you find?

That smells like `Content-Transfer-Encoding: quoted-printable` not being
understood by check-patch when operating on a raw mail.
No idea if mutt can recode the mail to plain 8-bit/UTF-8 when saving...
patch from patch-utils might have the same issues with it while git-am is
fine (as it handles mail-patches including charset and other headers).

I'm sending the mail via claws-mail which might encode it more
conservatively than e.g. git-send-email. I can see if there's an option
to prefer 8-bit over quoted-printable though.

Bruno


 ERROR: patch seems to be corrupt (line wrapped?)
 #93: FILE: drivers/platform/x86/apple-gmux.c:27:
 =20
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #108: FILE: drivers/platform/x86/apple-gmux.c:421:
 + struct pci_dev *pdev =3D NULL;
^
 
 WARNING: Missing a blank line after declarations
 #109: FILE: drivers/platform/x86/apple-gmux.c:422:
 + struct pci_dev *pdev =3D NULL;
 + while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #109: FILE: drivers/platform/x86/apple-gmux.c:422:
 + while ((pdev =3D pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
^
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #130: FILE: drivers/platform/x86/apple-gmux.c:447:
 + struct pci_dev *pdev =3D NULL;
^
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #155: FILE: drivers/platform/x86/apple-gmux.c:510:
 + pdev =3D gmux_find_pdev();
^
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #160: FILE: drivers/platform/x86/apple-gmux.c:515:
 + ret =3D -EBUSY;
   ^
 
 ERROR: need consistent spacing around '-' (ctx:WxV)
 #160: FILE: drivers/platform/x86/apple-gmux.c:515:
 + ret =3D -EBUSY;
   ^
 
 ERROR: spaces required around that '=' (ctx:WxV)
 #164: FILE: drivers/platform/x86/apple-gmux.c:519:
 + gmux_data-pdev =3D pdev;
   ^
 
 total: 8 errors, 1 warnings, 96 lines checked
 
 /home/dvhart/apple.patch has style problems, please review.
 
 If any of these errors are false positives, please report
 them to the maintainer, see CHECKPATCH in MAINTAINERS.
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju 
Tested-by: Petri Hodju 
Cc: Bjorn Helgaas 
Cc: Matthew Garrett 
Signed-off-by: Bruno Prémont 
---
Respinning, fixing Darren's nit.

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (!(cmd & PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version >> 16) & 0xff;
ver_release = (version >> 8) & 0xff;
} else {
-   pr_info("gmux device not present\n");
+   pr_info("gmux device not present or IO disabled\n");
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
ver_release, (gmux_data->indexed ? "indexed" : "classic"));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev && vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err("IO+MEM vgaarb-locking for PCI:%s failed\n",
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info("locked IO for PCI:%s\n", pci_name(pdev));
+   gmux_data->pdev = pdev;
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data->iostart, gmux_data->iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
   _notify_handler);
}
 
+   if (gmux_data->pdev) {
+   vga_put(gmux

[Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju petriho...@yahoo.com
Tested-by: Petri Hodju petriho...@yahoo.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matthew Garrett matthew.garr...@nebula.com
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Respinning, fixing Darren's nit.

Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error


 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include linux/delay.h
 #include linux/pci.h
 #include linux/vga_switcheroo.h
+#include linux/vgaarb.h
 #include acpi/video.h
 #include asm/io.h
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, cmd);
+   if (!(cmd  PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version  16)  0xff;
ver_release = (version  8)  0xff;
} else {
-   pr_info(gmux device not present\n);
+   pr_info(gmux device not present or IO disabled\n);
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info(Found gmux version %d.%d.%d [%s]\n, ver_major, ver_minor,
ver_release, (gmux_data-indexed ? indexed : classic));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev  vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err(IO+MEM vgaarb-locking for PCI:%s failed\n,
+   pci_name(pdev));
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info(locked IO for PCI:%s\n, pci_name(pdev));
+   gmux_data-pdev = pdev;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data-iostart, gmux_data-iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
   gmux_notify_handler);
}
 
+   if (gmux_data-pdev

[Patch] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju 
Tested-by: Petri Hodju 
Cc: Bjorn Helgaas 
Cc: Matthew Garrett 
Signed-off-by: Bruno Prémont 
---
 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (!(cmd & PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version >> 16) & 0xff;
ver_release = (version >> 8) & 0xff;
} else {
-   pr_info("gmux device not present\n");
+   pr_info("gmux device not present or IO disabled\n");
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,22 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
ver_release, (gmux_data->indexed ? "indexed" : "classic"));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev && vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err("gmux boot_vga IO+MEM vgaarb-locking failed\n");
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info("gmux: locked IO for PCI:%s\n", pci_name(pdev));
+   gmux_data->pdev = pdev;
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data->iostart, gmux_data->iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
   _notify_handler);
}
 
+   if (gmux_data->pdev) {
+   vga_put(gmux_data->pdev,
+   VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM);
+   pci_dev_put(gmux_data->pdev);
+   }
backlight_device_unregister(gmux_data->bdev);
 
release_

[Patch] apple-gmux: lock iGP IO to protect from vgaarb changes

[Bruno Prémont]

As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.

This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.

On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).

This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.

Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju petriho...@yahoo.com
Tested-by: Petri Hodju petriho...@yahoo.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matthew Garrett matthew.garr...@nebula.com
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
 drivers/platform/x86/apple-gmux.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
 #include linux/delay.h
 #include linux/pci.h
 #include linux/vga_switcheroo.h
+#include linux/vgaarb.h
 #include acpi/video.h
 #include asm/io.h
 
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
 
+   struct pci_dev *pdev;
struct backlight_device *bdev;
 
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
 }
 
+static struct pci_dev *gmux_find_pdev(void)
+{
+   struct pci_dev *pdev = NULL;
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev))) {
+   u16 cmd;
+
+   pci_read_config_word(pdev, PCI_COMMAND, cmd);
+   if (!(cmd  PCI_COMMAND_IO))
+   continue;
+
+   return pdev;
+   }
+
+   return NULL;
+}
+
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
 {
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+   struct pci_dev *pdev = NULL;
 
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
ver_minor = (version  16)  0xff;
ver_release = (version  8)  0xff;
} else {
-   pr_info(gmux device not present\n);
+   pr_info(gmux device not present or IO disabled\n);
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,22 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
pr_info(Found gmux version %d.%d.%d [%s]\n, ver_major, ver_minor,
ver_release, (gmux_data-indexed ? indexed : classic));
 
+   /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+   pdev = gmux_find_pdev();
+   if (pdev  vga_tryget(pdev,
+  VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+   pr_err(gmux boot_vga IO+MEM vgaarb-locking failed\n);
+   ret = -EBUSY;
+   goto err_release;
+   } else if (pdev)
+   pr_info(gmux: locked IO for PCI:%s\n, pci_name(pdev));
+   gmux_data-pdev = pdev;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
 err_notify:
backlight_device_unregister(bdev);
 err_release:
+   pci_dev_put(pdev);
release_region(gmux_data-iostart, gmux_data-iolen);
 err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
   gmux_notify_handler);
}
 
+   if (gmux_data-pdev) {
+   vga_put(gmux_data-pdev,
+   VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM);
+   pci_dev_put(gmux_data-pdev);
+   }
backlight_device_unregister

Re: Logitech G-series drivers

[Bruno Prémont]

On Sat, 21 February 2015 Ciprian Ciubotariu  wrote:
> Hi. Only now I realized you wrote some instructions. Below are my (quite 
> lengthy) responses.
> 
> On Thursday 19 February 2015 10:48:27 Bruno Prémont wrote:
> > Hi Ciprian,
> > 
> > Adding linux-input and Jiri (HID maintainer) to CC.
> 
> Should I register myself on the linux-input mailing list as well?

That's up to you, though it would help catching possibly relevant threads
affecting input devices or (later) Logitech devices you care about.

> > On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote:
> > Did you check for older work on Logitech keyboards that has been
> > proposed on linux-input list some time ago and what is currently
> > present in Linus' tree?
> 
> Yes, I have checked the tree. The mailing list archives recorded some related 
> activity in 2010, but no patches were applied to the kernel tree.

Reviewing the work that happened back then and at least considering the
comments made at that time will help you get the code into a better shape.

That's about the time when I wrote picolcd driver, using the proposed
Logitech driver as a starting point.

> > An overview of the features covered by the drivers would help
> > understand what the new drivers add (and the differences between all
> > the covered keyboard variants).
> 
> I. From the user perspective, all G-series keyboards have
> 
> (1) A set of "macro" keys and a set of support keys (macro set selection, 
> menu navigation and such). 
> 
> (2) Some devices present an LCD, which is either monochrome or color. 
> 
> (3) All have LEDs that allow changing the (3a) keyboard illumination 
> intensity and color, (3b) the backlight of the macro set selection keys, as 
> well (3c) as the backlight of the LCD. 
> 
> II. Hardware
> 
> The hardware presents these extra keys on a separate USB device. G110 and G19 
> use a separate endpoint for some of the keys, while other models use just HID 
> reports. All seem to use a custom bit-flag format to report the key status, 
> but 
> I am not a HID expert - maybe it is standard. However, all these keys are 
> dead 
> without these drivers.
>
> The LEDs are controlled via hid reports, but the calculus of the fields 
> differs 
> on some models (G110 needs some weird maths).
> 
> The LCD framebuffer can be written to via USB interrupt/bulk endpoints 
> depending on the model. hid-gfb.c implements the LCD matrix via the kernel's 
> FB API. The LCD backlight can only be controlled independently on G19, and is 
> mapped to LED devices by hid-g19.

This is rather important information for explaining your choice of splitting
up the code.
You may want to extend this, eventually putting it into a file under
Documentation/

Giving a clear overview of how the various features are presented on USB/HID
side for each driver definitely helps.

This should also help you decide if unification is reasonable or just requires
too much glue-code to translate different HW implementations.

> III. Driver code
> 
> 
> 
> > If you would like to get the drivers merged please create patches
> > against upstream tree, eventually starting with support for the
> > keyboard you own, adding support for the other keyboards in separate
> > patches.
> > You could also split your patch based on feature support.
> 
> While I am typing on the G19 right now, I have only tested G110, G13, G15v2 
> and they seem stable. I lack the G15 model, and G510 is not yet working.
> 
> To summarize, this submission is about devices g110, g13, g15v2 and g19, all 
> tested by me and working.
> 
> I have prepared a patch for the kernel tree, rebased into a single commit. I 
> can split it per-device, but I don't know how to split the changes to 
> Kconfig, 
> hid-ids.h and hid-core.c so that each patch can be applied independently 
> (because the changes would overlap).

Splitting per-device is one way. More interesting for review would be splitting
by feature:
- base input driver handling the "dead" keys
- adding LEDs
- adding LCD fb/backlight
- adding other goodies

Proposing the patches in a series where later patches depend on previous ones
is the normal way of operating.

> The Kconfig made me wonder if I should (a) activate the dependent code in the 
> kernel (for instance the FB or LEDS_CLASS etc), or (b) deactivate the feature 
> from the driver and advise users in the help text.

For those wanting to trip down their kernels in size having the option to
reduce feature set via Kconfig options is welcome.
If you select dependencies (you can only properly do so when selecting
config options that have no dependencies) or have your options show up/default
on them is up to you.

Re: Logitech G-series drivers

[Bruno Prémont]

On Sat, 21 February 2015 Ciprian Ciubotariu cheepe...@gmx.net wrote:
 Hi. Only now I realized you wrote some instructions. Below are my (quite 
 lengthy) responses.
 
 On Thursday 19 February 2015 10:48:27 Bruno Prémont wrote:
  Hi Ciprian,
  
  Adding linux-input and Jiri (HID maintainer) to CC.
 
 Should I register myself on the linux-input mailing list as well?

That's up to you, though it would help catching possibly relevant threads
affecting input devices or (later) Logitech devices you care about.

  On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote:
  Did you check for older work on Logitech keyboards that has been
  proposed on linux-input list some time ago and what is currently
  present in Linus' tree?
 
 Yes, I have checked the tree. The mailing list archives recorded some related 
 activity in 2010, but no patches were applied to the kernel tree.

Reviewing the work that happened back then and at least considering the
comments made at that time will help you get the code into a better shape.

That's about the time when I wrote picolcd driver, using the proposed
Logitech driver as a starting point.

  An overview of the features covered by the drivers would help
  understand what the new drivers add (and the differences between all
  the covered keyboard variants).
 
 I. From the user perspective, all G-series keyboards have
 
 (1) A set of macro keys and a set of support keys (macro set selection, 
 menu navigation and such). 
 
 (2) Some devices present an LCD, which is either monochrome or color. 
 
 (3) All have LEDs that allow changing the (3a) keyboard illumination 
 intensity and color, (3b) the backlight of the macro set selection keys, as 
 well (3c) as the backlight of the LCD. 
 
 II. Hardware
 
 The hardware presents these extra keys on a separate USB device. G110 and G19 
 use a separate endpoint for some of the keys, while other models use just HID 
 reports. All seem to use a custom bit-flag format to report the key status, 
 but 
 I am not a HID expert - maybe it is standard. However, all these keys are 
 dead 
 without these drivers.

 The LEDs are controlled via hid reports, but the calculus of the fields 
 differs 
 on some models (G110 needs some weird maths).
 
 The LCD framebuffer can be written to via USB interrupt/bulk endpoints 
 depending on the model. hid-gfb.c implements the LCD matrix via the kernel's 
 FB API. The LCD backlight can only be controlled independently on G19, and is 
 mapped to LED devices by hid-g19.

This is rather important information for explaining your choice of splitting
up the code.
You may want to extend this, eventually putting it into a file under
Documentation/

Giving a clear overview of how the various features are presented on USB/HID
side for each driver definitely helps.

This should also help you decide if unification is reasonable or just requires
too much glue-code to translate different HW implementations.

 III. Driver code
 
 snip
 
  If you would like to get the drivers merged please create patches
  against upstream tree, eventually starting with support for the
  keyboard you own, adding support for the other keyboards in separate
  patches.
  You could also split your patch based on feature support.
 
 While I am typing on the G19 right now, I have only tested G110, G13, G15v2 
 and they seem stable. I lack the G15 model, and G510 is not yet working.
 
 To summarize, this submission is about devices g110, g13, g15v2 and g19, all 
 tested by me and working.
 
 I have prepared a patch for the kernel tree, rebased into a single commit. I 
 can split it per-device, but I don't know how to split the changes to 
 Kconfig, 
 hid-ids.h and hid-core.c so that each patch can be applied independently 
 (because the changes would overlap).

Splitting per-device is one way. More interesting for review would be splitting
by feature:
- base input driver handling the dead keys
- adding LEDs
- adding LCD fb/backlight
- adding other goodies

Proposing the patches in a series where later patches depend on previous ones
is the normal way of operating.

 The Kconfig made me wonder if I should (a) activate the dependent code in the 
 kernel (for instance the FB or LEDS_CLASS etc), or (b) deactivate the feature 
 from the driver and advise users in the help text.

For those wanting to trip down their kernels in size having the option to
reduce feature set via Kconfig options is welcome.
If you select dependencies (you can only properly do so when selecting
config options that have no dependencies) or have your options show up/default
on them is up to you.

  It might be worth exploring the option to organize the driver(s) as a
  MFD (multi-function-device) device.
 
 I have looked at the list of MFD devices with make menuconfig, but I have not 
 seen any input devices there. Perhaps a radio, and mostly PMICs of various 
 sorts.
 
 These are rather HID input devices with some extra custom goodies (extra 
 keys, 
 LEDs

Re: Logitech G-series drivers

[Bruno Prémont]

Hi Ciprian,

Adding linux-input and Jiri (HID maintainer) to CC.

On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote:
> I would like to submit to your attention for inclusion in the mainline kernel 
> a series of drivers for a set of Logitech keybord devices. I forked the 
> sources under a GPL/GPLv2 license and performed maintenance and stabilization 
> work on them.
> 
> The repository I am working on is at 
> 
> https://github.com/CMoH/lg4l
> 
> Short description of the modules and files:
> 
> - hid-g110 - Logitech G110 (tested)
> - hid-g13 - Logitech G13 (tested)
> - hid-g15v2 - Logitech G15, version 2 (tested)
> - hid-g19 - Logitech G19 (tested)
> 
> - hid-g15 - Logitech G15 (not tested)
> - hid-g510 - Logitech G510 - not ready
> 
> - hid-gcore - common functions for other modules
> - hid-gfb - framebuffer implementation for on-device displays
> - hid-ids.h - product IDs 
> 
> I would like the opinion of a kernel developer on the possibility of 
> including 
> these drivers in the kernel. If the answer is favorable, I will prepare a 
> series of patches against the kernel's master branch and work towards them 
> being accepted.

>From a quick look at your github tree the drivers are prepared for
building out-of-tree.

Did you check for older work on Logitech keyboards that has been
proposed on linux-input list some time ago and what is currently
present in Linus' tree?

An overview of the features covered by the drivers would help
understand what the new drivers add (and the differences between all
the covered keyboard variants).
There seem to be individual drivers for each keyboard type.
Are the features so different that distinct drivers are needed or can
the drivers be unified?


If you would like to get the drivers merged please create patches
against upstream tree, eventually starting with support for the
keyboard you own, adding support for the other keyboards in separate
patches.
You could also split your patch based on feature support.

It might be worth exploring the option to organize the driver(s) as a
MFD (multi-function-device) device.

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Logitech G-series drivers

[Bruno Prémont]

Hi Ciprian,

Adding linux-input and Jiri (HID maintainer) to CC.

On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote:
 I would like to submit to your attention for inclusion in the mainline kernel 
 a series of drivers for a set of Logitech keybord devices. I forked the 
 sources under a GPL/GPLv2 license and performed maintenance and stabilization 
 work on them.
 
 The repository I am working on is at 
 
 https://github.com/CMoH/lg4l
 
 Short description of the modules and files:
 
 - hid-g110 - Logitech G110 (tested)
 - hid-g13 - Logitech G13 (tested)
 - hid-g15v2 - Logitech G15, version 2 (tested)
 - hid-g19 - Logitech G19 (tested)
 
 - hid-g15 - Logitech G15 (not tested)
 - hid-g510 - Logitech G510 - not ready
 
 - hid-gcore - common functions for other modules
 - hid-gfb - framebuffer implementation for on-device displays
 - hid-ids.h - product IDs 
 
 I would like the opinion of a kernel developer on the possibility of 
 including 
 these drivers in the kernel. If the answer is favorable, I will prepare a 
 series of patches against the kernel's master branch and work towards them 
 being accepted.

From a quick look at your github tree the drivers are prepared for
building out-of-tree.

Did you check for older work on Logitech keyboards that has been
proposed on linux-input list some time ago and what is currently
present in Linus' tree?

An overview of the features covered by the drivers would help
understand what the new drivers add (and the differences between all
the covered keyboard variants).
There seem to be individual drivers for each keyboard type.
Are the features so different that distinct drivers are needed or can
the drivers be unified?


If you would like to get the drivers merged please create patches
against upstream tree, eventually starting with support for the
keyboard you own, adding support for the other keyboards in separate
patches.
You could also split your patch based on feature support.

It might be worth exploring the option to organize the driver(s) as a
MFD (multi-function-device) device.

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ethernet: how to disable gigabit support

[Bruno Prémont]

On Fri, 06 February 2015 Pavel Machek wrote:
> On Thu 2015-02-05 14:44:55, Florian Fainelli wrote:
> > On 05/02/15 12:25, Pavel Machek wrote:
> > > This happened on more than one project: there's gigabit-capable chip,
> > > but the connector is not designed for gigabit speed.
> > > 
> > > I'd like to have speed autonegotiation, but not offer gigabit (as it
> > > will not work).
> > > 
> > > Is there way to do that without hacking the kernel? Should mii-tool do
> > > that?
> > 
> > Since you use the PHY library, you should be able to do something like
> > this in your PHY driver prior to starting the PHY state machine:
> > 
> > phydev->supported &= PHY_BASIC_FEATURES (effectively masking Gigabit
> > capability)
> 
> Thanks, that did the trick.
>   Pavel
> (But still it would be nice to have a generic way of doing this,
> using something like mii-tool.)

You can use ethtool to do so:

  ethtool -s ethX advertise 0x0f

c.f. man ethtool:
  advertise N
Sets the speed and duplex advertised by autonegotiation. The argument is
a hexadecimal value using one or a combination of the following values:

  0x001 10 Half
  0x002 10 Full
  0x004 100 Half
  0x008 100 Full
  0x010 1000 Half(not supported by IEEE standards)
  0x020 1000 Full
  0x80002500 Full(not supported by IEEE standards)
  0x10001 Full
  0x2   2MLD2 Full   (not supported by IEEE standards)
  0x4   2KR2 Full(not supported by IEEE standards)

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ethernet: how to disable gigabit support

[Bruno Prémont]

On Fri, 06 February 2015 Pavel Machek wrote:
 On Thu 2015-02-05 14:44:55, Florian Fainelli wrote:
  On 05/02/15 12:25, Pavel Machek wrote:
   This happened on more than one project: there's gigabit-capable chip,
   but the connector is not designed for gigabit speed.
   
   I'd like to have speed autonegotiation, but not offer gigabit (as it
   will not work).
   
   Is there way to do that without hacking the kernel? Should mii-tool do
   that?
  
  Since you use the PHY library, you should be able to do something like
  this in your PHY driver prior to starting the PHY state machine:
  
  phydev-supported = PHY_BASIC_FEATURES (effectively masking Gigabit
  capability)
 
 Thanks, that did the trick.
   Pavel
 (But still it would be nice to have a generic way of doing this,
 using something like mii-tool.)

You can use ethtool to do so:

  ethtool -s ethX advertise 0x0f

c.f. man ethtool:
  advertise N
Sets the speed and duplex advertised by autonegotiation. The argument is
a hexadecimal value using one or a combination of the following values:

  0x001 10 Half
  0x002 10 Full
  0x004 100 Half
  0x008 100 Full
  0x010 1000 Half(not supported by IEEE standards)
  0x020 1000 Full
  0x80002500 Full(not supported by IEEE standards)
  0x10001 Full
  0x2   2MLD2 Full   (not supported by IEEE standards)
  0x4   2KR2 Full(not supported by IEEE standards)

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Thu, 29 January 2015 Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
> >
> > The WARN() was already changed to a WARN_ONCE().
> 
> Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
> always happening.
> 
> So I think the right fix is to:
> 
>  - warn once like we do
> 
>  - but *not* do that __set_current_state() which was always total crap anyway
> 
> Why do I say "total crap"? Because of two independent issues:
> 
>  (a) it actually changes behavior for a debug vs non-debug kernel,
> which is a really bad idea to begin with
> 
>  (b) it's really wrong. The whole "nested sleep" case was never a
> major bug to begin with, just a possible inefficiency where constant
> nested sleeps would possibly make the outer sleep not sleep. But that
> "could possibly make" case was the unlikely case, and the debug patch
> made it happen *all* the time by explicitly setting things running.
> 
> So I think the proper patch is the attached.
> 
> The comment is also crap. The comment says
> 
> "Blocking primitives will set (and therefore destroy) current->state 
> [...]"
> 
> but the reality is that they *may* set it, and only in the unlikely
> slow-path where they actually block.
> 
> So doing this in "__may_sleep()" is just bogus and horrible horrible
> crap. It turns the "harmless ugliness" into a real *harmful* bug. The
> key word of "__may_sleep()" is that "MAY" part. It's a debug thing to
> make relatively rare cases show up.
> 
> PeterZ, please don't make "debugging" patches like this. Ever again.
> Because this was just stupid, and it took me too long to realize that
> despite the warning being shut up, the debug patch was still actively
> doing bad bad things.
> 
> Ingo, maybe you'd want to apply this through the scheduler tree, the
> way you already did the WARN_ONCE() thing.
> 
> Bruno, does this finally actually fix your pccard thing?

Tested the variant that was applied by running rc7 and it fixes the
endless loop.
The loop is now replaced by a single WARN() trace - I guess expected:

[3.083647] [ cut here ]
[3.087477] WARNING: CPU: 0 PID: 67 at 
/usr/src/linux-git/kernel/sched/core.c:7300 __might_sleep+0x79/0x90()
[3.091357] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] pccardd+0xa0/0x3e0
[3.095232] Modules linked in:
[3.099020] CPU: 0 PID: 67 Comm: pccardd Not tainted 
3.19.0-rc7-3-g67288c4 #17
[3.102760] Hardware name: Acer TravelMate 660/TravelMate 660, BIOS 3A19 
01/14/2004
[3.106504]  c212def4 c212def4 c212deb4 c16caf23 c212dee4 c10416fd c1907334 
c212df10
[3.110315]  0043 c1907380 1c84 c105a099 c105a099 c1442040 0001 
f5f54bc0
[3.114143]  c212defc c104176e 0009 c212def4 c1907334 c212df10 c212df30 
c105a099
[3.117960] Call Trace:
[3.121703]  [] dump_stack+0x16/0x18
[3.125447]  [] warn_slowpath_common+0x7d/0xc0
[3.129172]  [] ? __might_sleep+0x79/0x90
[3.132868]  [] ? __might_sleep+0x79/0x90
[3.136500]  [] ? pccardd+0xa0/0x3e0
[3.140092]  [] warn_slowpath_fmt+0x2e/0x30
[3.143657]  [] __might_sleep+0x79/0x90
[3.147209]  [] ? pccardd+0xa0/0x3e0
[3.150747]  [] ? pccardd+0xa0/0x3e0
[3.154256]  [] mutex_lock+0x17/0x2a
[3.157734]  [] pccardd+0xe9/0x3e0
[3.161207]  [] ? pcmcia_socket_uevent+0x30/0x30
[3.164660]  [] kthread+0xa0/0xc0
[3.168059]  [] ret_from_kernel_thread+0x20/0x30
[3.171436]  [] ? kthread_worker_fn+0x140/0x140
[3.174796] ---[ end trace c3f708b642e3d8f0 ]---

>From my reading of the thread fixing pccardd/sched TASK_RUNNING usage/check
is another issue left for the future.

Thanks,
Bruno

>   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Thu, 29 January 2015 Linus Torvalds wrote:
 On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
 
  The WARN() was already changed to a WARN_ONCE().
 
 Oh, but I notice that the __set_current_state(TASK_RUNNING) ends up
 always happening.
 
 So I think the right fix is to:
 
  - warn once like we do
 
  - but *not* do that __set_current_state() which was always total crap anyway
 
 Why do I say total crap? Because of two independent issues:
 
  (a) it actually changes behavior for a debug vs non-debug kernel,
 which is a really bad idea to begin with
 
  (b) it's really wrong. The whole nested sleep case was never a
 major bug to begin with, just a possible inefficiency where constant
 nested sleeps would possibly make the outer sleep not sleep. But that
 could possibly make case was the unlikely case, and the debug patch
 made it happen *all* the time by explicitly setting things running.
 
 So I think the proper patch is the attached.
 
 The comment is also crap. The comment says
 
 Blocking primitives will set (and therefore destroy) current-state 
 [...]
 
 but the reality is that they *may* set it, and only in the unlikely
 slow-path where they actually block.
 
 So doing this in __may_sleep() is just bogus and horrible horrible
 crap. It turns the harmless ugliness into a real *harmful* bug. The
 key word of __may_sleep() is that MAY part. It's a debug thing to
 make relatively rare cases show up.
 
 PeterZ, please don't make debugging patches like this. Ever again.
 Because this was just stupid, and it took me too long to realize that
 despite the warning being shut up, the debug patch was still actively
 doing bad bad things.
 
 Ingo, maybe you'd want to apply this through the scheduler tree, the
 way you already did the WARN_ONCE() thing.
 
 Bruno, does this finally actually fix your pccard thing?

Tested the variant that was applied by running rc7 and it fixes the
endless loop.
The loop is now replaced by a single WARN() trace - I guess expected:

[3.083647] [ cut here ]
[3.087477] WARNING: CPU: 0 PID: 67 at 
/usr/src/linux-git/kernel/sched/core.c:7300 __might_sleep+0x79/0x90()
[3.091357] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[c1442040] pccardd+0xa0/0x3e0
[3.095232] Modules linked in:
[3.099020] CPU: 0 PID: 67 Comm: pccardd Not tainted 
3.19.0-rc7-3-g67288c4 #17
[3.102760] Hardware name: Acer TravelMate 660/TravelMate 660, BIOS 3A19 
01/14/2004
[3.106504]  c212def4 c212def4 c212deb4 c16caf23 c212dee4 c10416fd c1907334 
c212df10
[3.110315]  0043 c1907380 1c84 c105a099 c105a099 c1442040 0001 
f5f54bc0
[3.114143]  c212defc c104176e 0009 c212def4 c1907334 c212df10 c212df30 
c105a099
[3.117960] Call Trace:
[3.121703]  [c16caf23] dump_stack+0x16/0x18
[3.125447]  [c10416fd] warn_slowpath_common+0x7d/0xc0
[3.129172]  [c105a099] ? __might_sleep+0x79/0x90
[3.132868]  [c105a099] ? __might_sleep+0x79/0x90
[3.136500]  [c1442040] ? pccardd+0xa0/0x3e0
[3.140092]  [c104176e] warn_slowpath_fmt+0x2e/0x30
[3.143657]  [c105a099] __might_sleep+0x79/0x90
[3.147209]  [c1442040] ? pccardd+0xa0/0x3e0
[3.150747]  [c1442040] ? pccardd+0xa0/0x3e0
[3.154256]  [c16cf447] mutex_lock+0x17/0x2a
[3.157734]  [c1442089] pccardd+0xe9/0x3e0
[3.161207]  [c1441fa0] ? pcmcia_socket_uevent+0x30/0x30
[3.164660]  [c1056990] kthread+0xa0/0xc0
[3.168059]  [c16d1040] ret_from_kernel_thread+0x20/0x30
[3.171436]  [c10568f0] ? kthread_worker_fn+0x140/0x140
[3.174796] ---[ end trace c3f708b642e3d8f0 ]---

From my reading of the thread fixing pccardd/sched TASK_RUNNING usage/check
is another issue left for the future.

Thanks,
Bruno

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote:
> On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote:
> > On Fri, 30 January 2015 Trond Myklebust wrote:
> > > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> > > > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
> > > > > On a system running home-brown container (mntns, utsns,
> > > > > pidns, netns) with NFS mount-point bind-mounted into the
> > > > > container I hit the following trace if nfs filesystem is
> > > > > first umount()ed in init ns and then later umounted from
> > > > > container when the container exists.
> > > > >
> > > > > 
> > > >
> > > > We should rather change rpcb_create() to pass the nodename from
> > > > the parent. The point is that the rpc_clnt->cl_nodename is used
> > > > in various different contexts (for instance in the AUTH_SYS
> > > > credential) where it isn't always appropriate to have it set to
> > > > an empty string.
> > >
> > > I was rather hoping that Bruno would fix up his patch and resend,
> > > but since other reports of the same bug are now surfacing...
> > > Please could you all check if something like the following patch
> > > fixes it.
> >
> > This patch works for me, so
> >   Tested-by: Bruno Prémont 
> >
> > Now I get just the following complaint in dmesg on shutdown:
> >   [ 1940.173201] lockd: cannot unmonitor nfs.home
> >    name of NFS
> > server
> >
> > This complaint did not happen with my "empty string" name
> > patch.
> 
> Are there any clues from rpc.statd in your syslog that might help to
> explain the error?

I would say there is no more running rpc.statd at that time.

My shutdown process looks about as follows (it's not necessarily the
optimal ordering):

- umount nfs mountpoints from root mntns
- stop nfsclient
- stop rpc.statd
- stop rpcbind
- stop containers (with bind-mounted nfs mountpoints from root mntns
that get implicitly umounted on mntns release)

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Fri, 30 January 2015 Trond Myklebust wrote:
> On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
> > > On a system running home-brown container (mntns, utsns, pidns, netns)
> > > with NFS mount-point bind-mounted into the container I hit the following
> > > trace if nfs filesystem is first umount()ed in init ns and then later
> > > umounted from container when the container exists.
> > >
> > > [51397.767310] BUG: unable to handle kernel NULL pointer dereference at 
> > > 0008
> > > [51397.770671] IP: [] rpc_new_client+0x193/0x2b0
> > > [51397.773967] PGD 0
> > > [51397.777218] Oops:  [#1] SMP
> > > [51397.780490] Modules linked in:
> > > [51397.783751] CPU: 0 PID: 1711 Comm: image-starter Not tainted 
> > > 3.19.0-rc2-kvm+ #7
> > > [51397.787123] Hardware name: Gigabyte Technology Co., Ltd. 
> > > GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
> > > [51397.790606] task: 8800c9fcbac0 ti: 8801fe754000 task.ti: 
> > > 8801fe754000
> > > [51397.794149] RIP: 0010:[]  [] 
> > > rpc_new_client+0x193/0x2b0
> > > [51397.797798] RSP: 0018:8801fe757908  EFLAGS: 00010246
> > > [51397.801444] RAX:  RBX: 88009dafb240 RCX: 
> > > 0180
> > > [51397.805174] RDX: bae0 RSI: 1770 RDI: 
> > > 88009dafb308
> > > [51397.808913] RBP: 8801fe757948 R08: 88009daf92d8 R09: 
> > > 88009dafb458
> > > [51397.812673] R10: 88009dafb458 R11: 88020ec15bc0 R12: 
> > > 8801fe757a40
> > > [51397.816456] R13: 81b9d800 R14: 8800c6e31030 R15: 
> > > 
> > > [51397.820270] FS:  7f335a3a1700() GS:88020ec0() 
> > > knlGS:f7287700
> > > [51397.824168] CS:  0010 DS:  ES:  CR0: 8005003b
> > > [51397.828066] CR2: 0008 CR3: 0001fc54d000 CR4: 
> > > 07f0
> > > [51397.832017] Stack:
> > > [51397.835924]  000a 81b9d770 81826450 
> > > 8801fe757a40
> > > [51397.840023]  8801fe757a40 8800cf08d500 81826450 
> > > 820f4728
> > > [51397.844130]  8801fe757978 81828815 8801fe757978 
> > > 8182aad8
> > > [51397.848224] Call Trace:
> > > [51397.852221]  [] ? call_start+0x20/0x20
> > > [51397.856273]  [] ? call_start+0x20/0x20
> > > [51397.860295]  [] rpc_create_xprt+0x15/0xb0
> > > [51397.864324]  [] ? xprt_create_transport+0x108/0x1b0
> > > [51397.868428]  [] rpc_create+0xc1/0x190
> > > [51397.872574]  [] ? internal_add_timer+0x66/0x80
> > > [51397.876733]  [] ? mod_timer+0x109/0x1e0
> > > [51397.880877]  [] rpcb_create+0x6e/0x90
> > > [51397.884999]  [] rpcb_getport_async+0x15a/0x330
> > > [51397.889118]  [] ? rpc_malloc+0x3a/0x70
> > > [51397.893240]  [] ? __kmalloc+0xc2/0x170
> > > [51397.897354]  [] ? call_reserveresult+0x110/0x110
> > > [51397.901490]  [] ? call_start+0x20/0x20
> > > [51397.905606]  [] ? call_start+0x20/0x20
> > > [51397.909662]  [] call_bind+0x3e/0x40
> > > [51397.913709]  [] __rpc_execute+0x79/0x330
> > > [51397.917778]  [] rpc_execute+0x5d/0xa0
> > > [51397.921871]  [] rpc_run_task+0x6b/0x90
> > > [51397.925989]  [] rpc_call_sync+0x3e/0xa0
> > > [51397.930108]  [] nsm_mon_unmon+0xb9/0xd0
> > > [51397.934191]  [] ? call_rcu_bh+0x20/0x20
> > > [51397.938235]  [] nsm_unmonitor+0x8c/0x140
> > > [51397.942309]  [] nlm_destroy_host_locked+0x63/0xa0
> > > [51397.946442]  [] nlmclnt_release_host+0x7c/0x130
> > > [51397.950591]  [] nlmclnt_done+0x15/0x30
> > > [51397.954773]  [] nfs_destroy_server+0x12/0x20
> > > [51397.958934]  [] nfs_free_server+0x22/0xa0
> > > [51397.963053]  [] nfs_kill_super+0x1d/0x30
> > > [51397.967158]  [] deactivate_locked_super+0x4c/0x70
> > > [51397.971286]  [] deactivate_super+0x49/0x70
> > > [51397.975398]  [] cleanup_mnt+0x3e/0x90
> > > [51397.979499]  [] __cleanup_mnt+0xd/0x10
> > > [51397.983598]  [] task_work_run+0xbc/0xe0
> > > [51397.987697]  [] do_exit+0x295/0xaf0
> > > [51397.991812]  [] ? fput+0x9/0x10
> > > [51397.995937]  [] ? task_work_run+0xa4/0xe0
> > > [51398.70]  [] do_group_exit+0x3a/0xa0
> > > [51398.004201]  [] SyS_exit_group+0xf/0x10
> > > [51398.008315]  [] system_call_fastpath+0x12/0x17
> > >

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Fri, 30 January 2015 Trond Myklebust wrote:
 On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
  On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
   On a system running home-brown container (mntns, utsns, pidns, netns)
   with NFS mount-point bind-mounted into the container I hit the following
   trace if nfs filesystem is first umount()ed in init ns and then later
   umounted from container when the container exists.
  
   [51397.767310] BUG: unable to handle kernel NULL pointer dereference at 
   0008
   [51397.770671] IP: [81828173] rpc_new_client+0x193/0x2b0
   [51397.773967] PGD 0
   [51397.777218] Oops:  [#1] SMP
   [51397.780490] Modules linked in:
   [51397.783751] CPU: 0 PID: 1711 Comm: image-starter Not tainted 
   3.19.0-rc2-kvm+ #7
   [51397.787123] Hardware name: Gigabyte Technology Co., Ltd. 
   GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
   [51397.790606] task: 8800c9fcbac0 ti: 8801fe754000 task.ti: 
   8801fe754000
   [51397.794149] RIP: 0010:[81828173]  [81828173] 
   rpc_new_client+0x193/0x2b0
   [51397.797798] RSP: 0018:8801fe757908  EFLAGS: 00010246
   [51397.801444] RAX:  RBX: 88009dafb240 RCX: 
   0180
   [51397.805174] RDX: bae0 RSI: 1770 RDI: 
   88009dafb308
   [51397.808913] RBP: 8801fe757948 R08: 88009daf92d8 R09: 
   88009dafb458
   [51397.812673] R10: 88009dafb458 R11: 88020ec15bc0 R12: 
   8801fe757a40
   [51397.816456] R13: 81b9d800 R14: 8800c6e31030 R15: 
   
   [51397.820270] FS:  7f335a3a1700() GS:88020ec0() 
   knlGS:f7287700
   [51397.824168] CS:  0010 DS:  ES:  CR0: 8005003b
   [51397.828066] CR2: 0008 CR3: 0001fc54d000 CR4: 
   07f0
   [51397.832017] Stack:
   [51397.835924]  000a 81b9d770 81826450 
   8801fe757a40
   [51397.840023]  8801fe757a40 8800cf08d500 81826450 
   820f4728
   [51397.844130]  8801fe757978 81828815 8801fe757978 
   8182aad8
   [51397.848224] Call Trace:
   [51397.852221]  [81826450] ? call_start+0x20/0x20
   [51397.856273]  [81826450] ? call_start+0x20/0x20
   [51397.860295]  [81828815] rpc_create_xprt+0x15/0xb0
   [51397.864324]  [8182aad8] ? xprt_create_transport+0x108/0x1b0
   [51397.868428]  [81828971] rpc_create+0xc1/0x190
   [51397.872574]  [8c86] ? internal_add_timer+0x66/0x80
   [51397.876733]  [81113a99] ? mod_timer+0x109/0x1e0
   [51397.880877]  [8183a19e] rpcb_create+0x6e/0x90
   [51397.884999]  [8183a71a] rpcb_getport_async+0x15a/0x330
   [51397.889118]  [8182f1da] ? rpc_malloc+0x3a/0x70
   [51397.893240]  [811af8d2] ? __kmalloc+0xc2/0x170
   [51397.897354]  [81826830] ? call_reserveresult+0x110/0x110
   [51397.901490]  [81826450] ? call_start+0x20/0x20
   [51397.905606]  [81826450] ? call_start+0x20/0x20
   [51397.909662]  [8182648e] call_bind+0x3e/0x40
   [51397.913709]  [8182fa99] __rpc_execute+0x79/0x330
   [51397.917778]  [818327bd] rpc_execute+0x5d/0xa0
   [51397.921871]  [818286cb] rpc_run_task+0x6b/0x90
   [51397.925989]  [8182872e] rpc_call_sync+0x3e/0xa0
   [51397.930108]  [8127fe29] nsm_mon_unmon+0xb9/0xd0
   [51397.934191]  [8110e2a0] ? call_rcu_bh+0x20/0x20
   [51397.938235]  [8128018c] nsm_unmonitor+0x8c/0x140
   [51397.942309]  [8127bc43] nlm_destroy_host_locked+0x63/0xa0
   [51397.946442]  [8127c03c] nlmclnt_release_host+0x7c/0x130
   [51397.950591]  [81279645] nlmclnt_done+0x15/0x30
   [51397.954773]  [81241862] nfs_destroy_server+0x12/0x20
   [51397.958934]  [81242372] nfs_free_server+0x22/0xa0
   [51397.963053]  [8124cadd] nfs_kill_super+0x1d/0x30
   [51397.967158]  [811c2e2c] deactivate_locked_super+0x4c/0x70
   [51397.971286]  [811c33f9] deactivate_super+0x49/0x70
   [51397.975398]  [811ddafe] cleanup_mnt+0x3e/0x90
   [51397.979499]  [811ddb9d] __cleanup_mnt+0xd/0x10
   [51397.983598]  [810e04cc] task_work_run+0xbc/0xe0
   [51397.987697]  [810c8f95] do_exit+0x295/0xaf0
   [51397.991812]  [811c2239] ? fput+0x9/0x10
   [51397.995937]  [810e04b4] ? task_work_run+0xa4/0xe0
   [51398.70]  [810c986a] do_group_exit+0x3a/0xa0
   [51398.004201]  [810c98df] SyS_exit_group+0xf/0x10
   [51398.008315]  [8185e8d2] system_call_fastpath+0x12/0x17
   [51398.012438] Code: 43 78 48 8d bb c8 00 00 00 48 89 7b 70 48 8b 30 e8 
   63 2d 01 00 c7 03 01 00 00 00 65 48 8b 04 25 00 aa 00 00 48 8b 80 c0 09 
   00 00 4c 8b 68 08 49 83 c5 45 4
   [51398.022378] RIP  [81828173] rpc_new_client+0x193/0x2b0
   [51398.026732]  RSP 8801fe757908
   [51398.031025] CR2: 0008

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote:
 On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote:
  On Fri, 30 January 2015 Trond Myklebust wrote:
   On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
 On a system running home-brown container (mntns, utsns,
 pidns, netns) with NFS mount-point bind-mounted into the
 container I hit the following trace if nfs filesystem is
 first umount()ed in init ns and then later umounted from
 container when the container exists.

 snip trace
   
We should rather change rpcb_create() to pass the nodename from
the parent. The point is that the rpc_clnt-cl_nodename is used
in various different contexts (for instance in the AUTH_SYS
credential) where it isn't always appropriate to have it set to
an empty string.
  
   I was rather hoping that Bruno would fix up his patch and resend,
   but since other reports of the same bug are now surfacing...
   Please could you all check if something like the following patch
   fixes it.
 
  This patch works for me, so
Tested-by: Bruno Prémont bonb...@linux-vserver.org
 
  Now I get just the following complaint in dmesg on shutdown:
[ 1940.173201] lockd: cannot unmonitor nfs.home
     name of NFS
  server
 
  This complaint did not happen with my empty string name
  patch.
 
 Are there any clues from rpc.statd in your syslog that might help to
 explain the error?

I would say there is no more running rpc.statd at that time.

My shutdown process looks about as follows (it's not necessarily the
optimal ordering):

- umount nfs mountpoints from root mntns
- stop nfsclient
- stop rpc.statd
- stop rpcbind
- stop containers (with bind-mounted nfs mountpoints from root mntns
that get implicitly umounted on mntns release)

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Thu, 29 Jan 2015 17:25:07 Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
> >
> > The WARN() was already changed to a WARN_ONCE().
> 
> Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
> always happening.
> 
> So I think the right fix is to:
> 
>  - warn once like we do
> 
>  - but *not* do that __set_current_state() which was always total
> crap anyway
> 
> Why do I say "total crap"? Because of two independent issues:
> 
>  (a) it actually changes behavior for a debug vs non-debug kernel,
> which is a really bad idea to begin with
> 
>  (b) it's really wrong. The whole "nested sleep" case was never a
> major bug to begin with, just a possible inefficiency where constant
> nested sleeps would possibly make the outer sleep not sleep. But that
> "could possibly make" case was the unlikely case, and the debug patch
> made it happen *all* the time by explicitly setting things running.
> 
> So I think the proper patch is the attached.
> 
> The comment is also crap. The comment says
> 
> "Blocking primitives will set (and therefore destroy)
> current->state [...]"
> 
> but the reality is that they *may* set it, and only in the unlikely
> slow-path where they actually block.
> 
> So doing this in "__may_sleep()" is just bogus and horrible horrible
> crap. It turns the "harmless ugliness" into a real *harmful* bug. The
> key word of "__may_sleep()" is that "MAY" part. It's a debug thing to
> make relatively rare cases show up.
> 
> PeterZ, please don't make "debugging" patches like this. Ever again.
> Because this was just stupid, and it took me too long to realize that
> despite the warning being shut up, the debug patch was still actively
> doing bad bad things.
> 
> Ingo, maybe you'd want to apply this through the scheduler tree, the
> way you already did the WARN_ONCE() thing.
> 
> Bruno, does this finally actually fix your pccard thing?

I will report back on Wednesday when I'm back home from FOSDEM. I don't
have the affected machine at hand at the moment.

Thanks for looking into it!
Bruno

>   Linus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Fri, 30 Jan 2015 18:49:21 Trond Myklebust  
wrote:
> On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
> >  wrote:
> > > On a system running home-brown container (mntns, utsns, pidns,
> > > netns) with NFS mount-point bind-mounted into the container I hit
> > > the following trace if nfs filesystem is first umount()ed in init
> > > ns and then later umounted from container when the container
> > > exists.
> > >
> >
> > We should rather change rpcb_create() to pass the nodename from the
> > parent. The point is that the rpc_clnt->cl_nodename is used in
> > various different contexts (for instance in the AUTH_SYS
> > credential) where it isn't always appropriate to have it set to an
> > empty string.
> 
> I was rather hoping that Bruno would fix up his patch and resend, but
> since other reports of the same bug are now surfacing... Please could
> you all check if something like the following patch fixes it.

With FOSDEM this weekend I've had no time to look into it.

Will test when home on Wednesday.

Thanks,
Bruno


> Thanks
>   Trond
> 
> 8<-
> From 87557df0ca2241da0edac558286650fdb081152c Mon Sep 17 00:00:00 2001
> From: Trond Myklebust 
> Date: Fri, 30 Jan 2015 18:12:28 -0500
> Subject: [PATCH] SUNRPC: NULL utsname dereference on NFS umount during
>  namespace cleanup
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Fix an Oopsable condition when nsm_mon_unmon is called as part of the
> namespace cleanup, which now apparently happens after the utsname
> has been freed.
> 
> Link: http://lkml.kernel.org/r/20150125220604.09012...@neptune.home
> Reported-by: Bruno Prémont 
> Cc: sta...@vger.kernel.org # 3.18
> Signed-off-by: Trond Myklebust 
> ---
>  fs/lockd/mon.c  | 13 +
>  include/linux/sunrpc/clnt.h |  3 ++-
>  net/sunrpc/clnt.c   | 12 +++-
>  net/sunrpc/rpcb_clnt.c  |  8 ++--
>  4 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/lockd/mon.c b/fs/lockd/mon.c
> index 1cc6ec51e6b1..47a32b6d9b90 100644
> --- a/fs/lockd/mon.c
> +++ b/fs/lockd/mon.c
> @@ -65,7 +65,7 @@ static inline struct sockaddr *nsm_addr(const
> struct nsm_handle *nsm) return (struct sockaddr *)>sm_addr;
>  }
>  
> -static struct rpc_clnt *nsm_create(struct net *net)
> +static struct rpc_clnt *nsm_create(struct net *net, const char
> *nodename) {
>   struct sockaddr_in sin = {
>   .sin_family = AF_INET,
> @@ -77,6 +77,7 @@ static struct rpc_clnt *nsm_create(struct net *net)
>   .address= (struct sockaddr *),
>   .addrsize   = sizeof(sin),
>   .servername = "rpc.statd",
> + .nodename   = nodename,
>   .program= _program,
>   .version= NSM_VERSION,
>   .authflavor = RPC_AUTH_NULL,
> @@ -102,7 +103,7 @@ out:
>   return clnt;
>  }
>  
> -static struct rpc_clnt *nsm_client_get(struct net *net)
> +static struct rpc_clnt *nsm_client_get(struct net *net, const char
> *nodename) {
>   struct rpc_clnt *clnt, *new;
>   struct lockd_net *ln = net_generic(net, lockd_net_id);
> @@ -111,7 +112,7 @@ static struct rpc_clnt *nsm_client_get(struct net
> *net) if (clnt != NULL)
>   goto out;
>  
> - clnt = new = nsm_create(net);
> + clnt = new = nsm_create(net, nodename);
>   if (IS_ERR(clnt))
>   goto out;
>  
> @@ -190,19 +191,23 @@ int nsm_monitor(const struct nlm_host *host)
>   struct nsm_res  res;
>   int status;
>   struct rpc_clnt *clnt;
> + const char *nodename = NULL;
>  
>   dprintk("lockd: nsm_monitor(%s)\n", nsm->sm_name);
>  
>   if (nsm->sm_monitored)
>   return 0;
>  
> + if (host->h_rpcclnt)
> + nodename = host->h_rpcclnt->cl_nodename;
> +
>   /*
>* Choose whether to record the caller_name or IP address of
>* this peer in the local rpc.statd's database.
>*/
>   nsm->sm_mon_name = nsm_use_hostnames ? nsm->sm_name :
> nsm->sm_addrbuf; 
> - clnt = nsm_client_get(host->net);
> + clnt = nsm_client_get(host->net, nodename);
>   if (IS_ERR(clnt)) {
>   status = PTR_ERR(clnt);
>   dprintk("lockd: failed to create NSM upcall
> transport, " diff --git a/include/linu

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On Fri, 30 Jan 2015 18:49:21 Trond Myklebust trond.mykleb...@primarydata.com 
wrote:
 On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
  On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
  bonb...@linux-vserver.org wrote:
   On a system running home-brown container (mntns, utsns, pidns,
   netns) with NFS mount-point bind-mounted into the container I hit
   the following trace if nfs filesystem is first umount()ed in init
   ns and then later umounted from container when the container
   exists.
  
 
  We should rather change rpcb_create() to pass the nodename from the
  parent. The point is that the rpc_clnt-cl_nodename is used in
  various different contexts (for instance in the AUTH_SYS
  credential) where it isn't always appropriate to have it set to an
  empty string.
 
 I was rather hoping that Bruno would fix up his patch and resend, but
 since other reports of the same bug are now surfacing... Please could
 you all check if something like the following patch fixes it.

With FOSDEM this weekend I've had no time to look into it.

Will test when home on Wednesday.

Thanks,
Bruno


 Thanks
   Trond
 
 8-
 From 87557df0ca2241da0edac558286650fdb081152c Mon Sep 17 00:00:00 2001
 From: Trond Myklebust trond.mykleb...@primarydata.com
 Date: Fri, 30 Jan 2015 18:12:28 -0500
 Subject: [PATCH] SUNRPC: NULL utsname dereference on NFS umount during
  namespace cleanup
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 Fix an Oopsable condition when nsm_mon_unmon is called as part of the
 namespace cleanup, which now apparently happens after the utsname
 has been freed.
 
 Link: http://lkml.kernel.org/r/20150125220604.09012...@neptune.home
 Reported-by: Bruno Prémont bonb...@linux-vserver.org
 Cc: sta...@vger.kernel.org # 3.18
 Signed-off-by: Trond Myklebust trond.mykleb...@primarydata.com
 ---
  fs/lockd/mon.c  | 13 +
  include/linux/sunrpc/clnt.h |  3 ++-
  net/sunrpc/clnt.c   | 12 +++-
  net/sunrpc/rpcb_clnt.c  |  8 ++--
  4 files changed, 24 insertions(+), 12 deletions(-)
 
 diff --git a/fs/lockd/mon.c b/fs/lockd/mon.c
 index 1cc6ec51e6b1..47a32b6d9b90 100644
 --- a/fs/lockd/mon.c
 +++ b/fs/lockd/mon.c
 @@ -65,7 +65,7 @@ static inline struct sockaddr *nsm_addr(const
 struct nsm_handle *nsm) return (struct sockaddr *)nsm-sm_addr;
  }
  
 -static struct rpc_clnt *nsm_create(struct net *net)
 +static struct rpc_clnt *nsm_create(struct net *net, const char
 *nodename) {
   struct sockaddr_in sin = {
   .sin_family = AF_INET,
 @@ -77,6 +77,7 @@ static struct rpc_clnt *nsm_create(struct net *net)
   .address= (struct sockaddr *)sin,
   .addrsize   = sizeof(sin),
   .servername = rpc.statd,
 + .nodename   = nodename,
   .program= nsm_program,
   .version= NSM_VERSION,
   .authflavor = RPC_AUTH_NULL,
 @@ -102,7 +103,7 @@ out:
   return clnt;
  }
  
 -static struct rpc_clnt *nsm_client_get(struct net *net)
 +static struct rpc_clnt *nsm_client_get(struct net *net, const char
 *nodename) {
   struct rpc_clnt *clnt, *new;
   struct lockd_net *ln = net_generic(net, lockd_net_id);
 @@ -111,7 +112,7 @@ static struct rpc_clnt *nsm_client_get(struct net
 *net) if (clnt != NULL)
   goto out;
  
 - clnt = new = nsm_create(net);
 + clnt = new = nsm_create(net, nodename);
   if (IS_ERR(clnt))
   goto out;
  
 @@ -190,19 +191,23 @@ int nsm_monitor(const struct nlm_host *host)
   struct nsm_res  res;
   int status;
   struct rpc_clnt *clnt;
 + const char *nodename = NULL;
  
   dprintk(lockd: nsm_monitor(%s)\n, nsm-sm_name);
  
   if (nsm-sm_monitored)
   return 0;
  
 + if (host-h_rpcclnt)
 + nodename = host-h_rpcclnt-cl_nodename;
 +
   /*
* Choose whether to record the caller_name or IP address of
* this peer in the local rpc.statd's database.
*/
   nsm-sm_mon_name = nsm_use_hostnames ? nsm-sm_name :
 nsm-sm_addrbuf; 
 - clnt = nsm_client_get(host-net);
 + clnt = nsm_client_get(host-net, nodename);
   if (IS_ERR(clnt)) {
   status = PTR_ERR(clnt);
   dprintk(lockd: failed to create NSM upcall
 transport,  diff --git a/include/linux/sunrpc/clnt.h
 b/include/linux/sunrpc/clnt.h index d86acc63b25f..598ba80ec30c 100644
 --- a/include/linux/sunrpc/clnt.h
 +++ b/include/linux/sunrpc/clnt.h
 @@ -57,7 +57,7 @@ struct rpc_clnt {
   const struct rpc_timeout *cl_timeout;   /* Timeout
 strategy */ 
   int cl_nodelen; /* nodename
 length */
 - charcl_nodename[UNX_MAXNODENAME];
 + charcl_nodename[UNX_MAXNODENAME+1

Re: Linux 3.19-rc5

[Bruno Prémont]

On Thu, 29 Jan 2015 17:25:07 Linus Torvalds wrote:
 On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
 
  The WARN() was already changed to a WARN_ONCE().
 
 Oh, but I notice that the __set_current_state(TASK_RUNNING) ends up
 always happening.
 
 So I think the right fix is to:
 
  - warn once like we do
 
  - but *not* do that __set_current_state() which was always total
 crap anyway
 
 Why do I say total crap? Because of two independent issues:
 
  (a) it actually changes behavior for a debug vs non-debug kernel,
 which is a really bad idea to begin with
 
  (b) it's really wrong. The whole nested sleep case was never a
 major bug to begin with, just a possible inefficiency where constant
 nested sleeps would possibly make the outer sleep not sleep. But that
 could possibly make case was the unlikely case, and the debug patch
 made it happen *all* the time by explicitly setting things running.
 
 So I think the proper patch is the attached.
 
 The comment is also crap. The comment says
 
 Blocking primitives will set (and therefore destroy)
 current-state [...]
 
 but the reality is that they *may* set it, and only in the unlikely
 slow-path where they actually block.
 
 So doing this in __may_sleep() is just bogus and horrible horrible
 crap. It turns the harmless ugliness into a real *harmful* bug. The
 key word of __may_sleep() is that MAY part. It's a debug thing to
 make relatively rare cases show up.
 
 PeterZ, please don't make debugging patches like this. Ever again.
 Because this was just stupid, and it took me too long to realize that
 despite the warning being shut up, the debug patch was still actively
 doing bad bad things.
 
 Ingo, maybe you'd want to apply this through the scheduler tree, the
 way you already did the WARN_ONCE() thing.
 
 Bruno, does this finally actually fix your pccard thing?

I will report back on Wednesday when I'm back home from FOSDEM. I don't
have the affected machine at hand at the moment.

Thanks for looking into it!
Bruno

   Linus

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On a system running home-brown container (mntns, utsns, pidns, netns)
with NFS mount-point bind-mounted into the container I hit the following
trace if nfs filesystem is first umount()ed in init ns and then later
umounted from container when the container exists.

[51397.767310] BUG: unable to handle kernel NULL pointer dereference at 
0008
[51397.770671] IP: [] rpc_new_client+0x193/0x2b0
[51397.773967] PGD 0 
[51397.777218] Oops:  [#1] SMP 
[51397.780490] Modules linked in:
[51397.783751] CPU: 0 PID: 1711 Comm: image-starter Not tainted 3.19.0-rc2-kvm+ 
#7
[51397.787123] Hardware name: Gigabyte Technology Co., Ltd. 
GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
[51397.790606] task: 8800c9fcbac0 ti: 8801fe754000 task.ti: 
8801fe754000
[51397.794149] RIP: 0010:[]  [] 
rpc_new_client+0x193/0x2b0
[51397.797798] RSP: 0018:8801fe757908  EFLAGS: 00010246
[51397.801444] RAX:  RBX: 88009dafb240 RCX: 0180
[51397.805174] RDX: bae0 RSI: 1770 RDI: 88009dafb308
[51397.808913] RBP: 8801fe757948 R08: 88009daf92d8 R09: 88009dafb458
[51397.812673] R10: 88009dafb458 R11: 88020ec15bc0 R12: 8801fe757a40
[51397.816456] R13: 81b9d800 R14: 8800c6e31030 R15: 
[51397.820270] FS:  7f335a3a1700() GS:88020ec0() 
knlGS:f7287700
[51397.824168] CS:  0010 DS:  ES:  CR0: 8005003b
[51397.828066] CR2: 0008 CR3: 0001fc54d000 CR4: 07f0
[51397.832017] Stack:
[51397.835924]  000a 81b9d770 81826450 
8801fe757a40
[51397.840023]  8801fe757a40 8800cf08d500 81826450 
820f4728
[51397.844130]  8801fe757978 81828815 8801fe757978 
8182aad8
[51397.848224] Call Trace:
[51397.852221]  [] ? call_start+0x20/0x20
[51397.856273]  [] ? call_start+0x20/0x20
[51397.860295]  [] rpc_create_xprt+0x15/0xb0
[51397.864324]  [] ? xprt_create_transport+0x108/0x1b0
[51397.868428]  [] rpc_create+0xc1/0x190
[51397.872574]  [] ? internal_add_timer+0x66/0x80
[51397.876733]  [] ? mod_timer+0x109/0x1e0
[51397.880877]  [] rpcb_create+0x6e/0x90
[51397.884999]  [] rpcb_getport_async+0x15a/0x330
[51397.889118]  [] ? rpc_malloc+0x3a/0x70
[51397.893240]  [] ? __kmalloc+0xc2/0x170
[51397.897354]  [] ? call_reserveresult+0x110/0x110
[51397.901490]  [] ? call_start+0x20/0x20
[51397.905606]  [] ? call_start+0x20/0x20
[51397.909662]  [] call_bind+0x3e/0x40
[51397.913709]  [] __rpc_execute+0x79/0x330
[51397.917778]  [] rpc_execute+0x5d/0xa0
[51397.921871]  [] rpc_run_task+0x6b/0x90
[51397.925989]  [] rpc_call_sync+0x3e/0xa0
[51397.930108]  [] nsm_mon_unmon+0xb9/0xd0
[51397.934191]  [] ? call_rcu_bh+0x20/0x20
[51397.938235]  [] nsm_unmonitor+0x8c/0x140
[51397.942309]  [] nlm_destroy_host_locked+0x63/0xa0
[51397.946442]  [] nlmclnt_release_host+0x7c/0x130
[51397.950591]  [] nlmclnt_done+0x15/0x30
[51397.954773]  [] nfs_destroy_server+0x12/0x20
[51397.958934]  [] nfs_free_server+0x22/0xa0
[51397.963053]  [] nfs_kill_super+0x1d/0x30
[51397.967158]  [] deactivate_locked_super+0x4c/0x70
[51397.971286]  [] deactivate_super+0x49/0x70
[51397.975398]  [] cleanup_mnt+0x3e/0x90
[51397.979499]  [] __cleanup_mnt+0xd/0x10
[51397.983598]  [] task_work_run+0xbc/0xe0
[51397.987697]  [] do_exit+0x295/0xaf0
[51397.991812]  [] ? fput+0x9/0x10
[51397.995937]  [] ? task_work_run+0xa4/0xe0
[51398.70]  [] do_group_exit+0x3a/0xa0
[51398.004201]  [] SyS_exit_group+0xf/0x10
[51398.008315]  [] system_call_fastpath+0x12/0x17
[51398.012438] Code: 43 78 48 8d bb c8 00 00 00 48 89 7b 70 48 8b 30 e8 63 2d 
01 00 c7 03 01 00 00 00 65 48 8b 04 25 00 aa 00 00 48 8b 80 c0 09 00 00 <4c> 8b 
68 08 49 83 c5 45 4
[51398.022378] RIP  [] rpc_new_client+0x193/0x2b0
[51398.026732]  RSP 
[51398.031025] CR2: 0008
[51398.035326] ---[ end trace b701b037bc457620 ]---
[51398.058223] Fixing recursive fault but reboot is needed!


The code executed in rpc_new_client() tries to dereference the
struct new_utsname * returned by utsname() which has already been
released at this time.

Cc:  # 3.18
Signed-off-by: Bruno Prémont 
---
I've seen this trace on 3.18.x as well as 3.19-rc.


This patch fixes the NULL dereference but I'm not sure this is the
right fix.
Should init uts_ns be referred to or what is the impact of using a random
string to satisfy rpc_clnt_set_nodename()?

Thanks,
Bruno
---
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 05da12a..0246e94 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -365,6 +365,7 @@ static struct rpc_clnt * rpc_new_client(const struct 
rpc_create_args *args,
const struct rpc_version *version;
struct rpc_clnt *clnt = NULL;
const struct rpc_timeout *timeout;
+   const struct new_utsname *uts_name;
int err;
 
/* sanity check the name before trying to print it */
@@ -421,7 +422,8 @@ static struct rpc_clnt * rpc_new_client(const 

[Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Bruno Prémont]

On a system running home-brown container (mntns, utsns, pidns, netns)
with NFS mount-point bind-mounted into the container I hit the following
trace if nfs filesystem is first umount()ed in init ns and then later
umounted from container when the container exists.

[51397.767310] BUG: unable to handle kernel NULL pointer dereference at 
0008
[51397.770671] IP: [81828173] rpc_new_client+0x193/0x2b0
[51397.773967] PGD 0 
[51397.777218] Oops:  [#1] SMP 
[51397.780490] Modules linked in:
[51397.783751] CPU: 0 PID: 1711 Comm: image-starter Not tainted 3.19.0-rc2-kvm+ 
#7
[51397.787123] Hardware name: Gigabyte Technology Co., Ltd. 
GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
[51397.790606] task: 8800c9fcbac0 ti: 8801fe754000 task.ti: 
8801fe754000
[51397.794149] RIP: 0010:[81828173]  [81828173] 
rpc_new_client+0x193/0x2b0
[51397.797798] RSP: 0018:8801fe757908  EFLAGS: 00010246
[51397.801444] RAX:  RBX: 88009dafb240 RCX: 0180
[51397.805174] RDX: bae0 RSI: 1770 RDI: 88009dafb308
[51397.808913] RBP: 8801fe757948 R08: 88009daf92d8 R09: 88009dafb458
[51397.812673] R10: 88009dafb458 R11: 88020ec15bc0 R12: 8801fe757a40
[51397.816456] R13: 81b9d800 R14: 8800c6e31030 R15: 
[51397.820270] FS:  7f335a3a1700() GS:88020ec0() 
knlGS:f7287700
[51397.824168] CS:  0010 DS:  ES:  CR0: 8005003b
[51397.828066] CR2: 0008 CR3: 0001fc54d000 CR4: 07f0
[51397.832017] Stack:
[51397.835924]  000a 81b9d770 81826450 
8801fe757a40
[51397.840023]  8801fe757a40 8800cf08d500 81826450 
820f4728
[51397.844130]  8801fe757978 81828815 8801fe757978 
8182aad8
[51397.848224] Call Trace:
[51397.852221]  [81826450] ? call_start+0x20/0x20
[51397.856273]  [81826450] ? call_start+0x20/0x20
[51397.860295]  [81828815] rpc_create_xprt+0x15/0xb0
[51397.864324]  [8182aad8] ? xprt_create_transport+0x108/0x1b0
[51397.868428]  [81828971] rpc_create+0xc1/0x190
[51397.872574]  [8c86] ? internal_add_timer+0x66/0x80
[51397.876733]  [81113a99] ? mod_timer+0x109/0x1e0
[51397.880877]  [8183a19e] rpcb_create+0x6e/0x90
[51397.884999]  [8183a71a] rpcb_getport_async+0x15a/0x330
[51397.889118]  [8182f1da] ? rpc_malloc+0x3a/0x70
[51397.893240]  [811af8d2] ? __kmalloc+0xc2/0x170
[51397.897354]  [81826830] ? call_reserveresult+0x110/0x110
[51397.901490]  [81826450] ? call_start+0x20/0x20
[51397.905606]  [81826450] ? call_start+0x20/0x20
[51397.909662]  [8182648e] call_bind+0x3e/0x40
[51397.913709]  [8182fa99] __rpc_execute+0x79/0x330
[51397.917778]  [818327bd] rpc_execute+0x5d/0xa0
[51397.921871]  [818286cb] rpc_run_task+0x6b/0x90
[51397.925989]  [8182872e] rpc_call_sync+0x3e/0xa0
[51397.930108]  [8127fe29] nsm_mon_unmon+0xb9/0xd0
[51397.934191]  [8110e2a0] ? call_rcu_bh+0x20/0x20
[51397.938235]  [8128018c] nsm_unmonitor+0x8c/0x140
[51397.942309]  [8127bc43] nlm_destroy_host_locked+0x63/0xa0
[51397.946442]  [8127c03c] nlmclnt_release_host+0x7c/0x130
[51397.950591]  [81279645] nlmclnt_done+0x15/0x30
[51397.954773]  [81241862] nfs_destroy_server+0x12/0x20
[51397.958934]  [81242372] nfs_free_server+0x22/0xa0
[51397.963053]  [8124cadd] nfs_kill_super+0x1d/0x30
[51397.967158]  [811c2e2c] deactivate_locked_super+0x4c/0x70
[51397.971286]  [811c33f9] deactivate_super+0x49/0x70
[51397.975398]  [811ddafe] cleanup_mnt+0x3e/0x90
[51397.979499]  [811ddb9d] __cleanup_mnt+0xd/0x10
[51397.983598]  [810e04cc] task_work_run+0xbc/0xe0
[51397.987697]  [810c8f95] do_exit+0x295/0xaf0
[51397.991812]  [811c2239] ? fput+0x9/0x10
[51397.995937]  [810e04b4] ? task_work_run+0xa4/0xe0
[51398.70]  [810c986a] do_group_exit+0x3a/0xa0
[51398.004201]  [810c98df] SyS_exit_group+0xf/0x10
[51398.008315]  [8185e8d2] system_call_fastpath+0x12/0x17
[51398.012438] Code: 43 78 48 8d bb c8 00 00 00 48 89 7b 70 48 8b 30 e8 63 2d 
01 00 c7 03 01 00 00 00 65 48 8b 04 25 00 aa 00 00 48 8b 80 c0 09 00 00 4c 8b 
68 08 49 83 c5 45 4
[51398.022378] RIP  [81828173] rpc_new_client+0x193/0x2b0
[51398.026732]  RSP 8801fe757908
[51398.031025] CR2: 0008
[51398.035326] ---[ end trace b701b037bc457620 ]---
[51398.058223] Fixing recursive fault but reboot is needed!


The code executed in rpc_new_client() tries to dereference the
struct new_utsname * returned by utsname() which has already been
released at this time.

Cc: sta...@vger.kernel.org # 3.18
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
I've seen this trace on 3.18.x as well as 3.19-rc.


This patch fixes

Re: Linux 3.19-rc5

[Bruno Prémont]

On Wed, 21 January 2015 Bruno Prémont wrote:
> On Tue, 20 January 2015 Linus Torvalds wrote:
> > On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
> > >
> > > No idea yet which rc is the offender (nor exact patch), but on my not
> > > so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
> > > converting my laptop into a heater.
> > >
> > > lspci for affected nodes:
> > > 02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
> > > Controller [1217:7113] (rev 20)
> > > 02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
> > > Controller [1217:7113] (rev 20)
> > >
> > > Very basics I have, before I attempt any bisection:
> > 
> > Hmm. I'm not seeing anything recent changing anything in this area, so
> > I suspect that unless somebody else steps up and says "Ahh, that
> > sounds like xyz", your bisection is the best option.

Bisecting to the end did point me at (the warning traces produced in great
quantities might not be the very same issue as the abusive CPU usage, but
certainly look very related):
  [CCing people on CC for the patch]

commit 8eb23b9f35aae413140d3fda766a98092c21e9b0
Author: Peter Zijlstra 
Date:   Wed Sep 24 10:18:55 2014 +0200

sched: Debug nested sleeps

Validate we call might_sleep() with TASK_RUNNING, which catches places
where we nest blocking primitives, eg. mutex usage in a wait loop.

Since all blocking is arranged through task_struct::state, nesting
this will cause the inner primitive to set TASK_RUNNING and the outer
will thus not block.

Another observed problem is calling a blocking function from
schedule()->sched_submit_work()->blk_schedule_flush_plug() which will
then destroy the task state for the actual __schedule() call that
comes after it.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: t...@linutronix.de
Cc: ilya.dryo...@inktank.com
Cc: umgwanakikb...@gmail.com
Cc: o...@redhat.com
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20140924082242.591637...@infradead.org
Signed-off-by: Ingo Molnar 

Which does produce the following trace (hand-copied most important parts of it):
  Warning: CPU 0 PID: 68 at kernel/sched/core.c:7311 __might_sleep+0x143/0x170
  do not call blocking ops when !TASK_RUNNING; state=1 set at [] 
pccardd+0xa0/0x3e0
  ...
  Call trace:
...
__might_sleep+0x143/0x170
? pccardd+0xa0/0x3e0
? pccardd+0xa0/0x3e0
mutex_lock+0x17/0x2a
pccardd+0xe9/0x3e0
? pcmcia_socket_uevent+0x30/0x30

pccardd() is located in drivers/pcmcia/cs.c and seems to be of the structure
Peter's patch wants to warn about.


Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Tue, 20 January 2015 Linus Torvalds wrote:
> On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
> >
> > No idea yet which rc is the offender (nor exact patch), but on my not
> > so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
> > converting my laptop into a heater.
> >
> > lspci for affected nodes:
> > 02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
> > Controller [1217:7113] (rev 20)
> > 02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
> > Controller [1217:7113] (rev 20)
> >
> > Very basics I have, before I attempt any bisection:
> 
> Hmm. I'm not seeing anything recent changing anything in this area, so
> I suspect that unless somebody else steps up and says "Ahh, that
> sounds like xyz", your bisection is the best option.

I've done most of the bisection and ended up in the scheduler changes.
CCing Peter.

A few iterations from the end kernel is warning about (might?)sleeping during
locking or so (scrolling too fast to read end making access to console
hard).

My current bisection log is:
git bisect start
# bad: [117af36e3bceb4fceb1c63489d6f3d94ed259a4c] Apple-GMUX: inhibit VGA 
arbitration changes
git bisect bad 117af36e3bceb4fceb1c63489d6f3d94ed259a4c
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
# bad: [c0222ac086669a631814bbf857f8c8023452a4d7] Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad c0222ac086669a631814bbf857f8c8023452a4d7
# bad: [2183a58803c2bbd87c2d0057eed6779ec4718d4d] Merge tag 'media/v3.19-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 2183a58803c2bbd87c2d0057eed6779ec4718d4d
# good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 6da314122ddc11936c6f054753bbb956a499d020
# bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612
# bad: [9e66645d72d3c395da92b0f8855c787f4b5f0e89] Merge branch 
'irq-irqdomain-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 9e66645d72d3c395da92b0f8855c787f4b5f0e89
# good: [5706ffd045c3810912c4982357d7daa721af3464] Merge branch 
'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 5706ffd045c3810912c4982357d7daa721af3464
# bad: [a157508c9790ccd1c8b5c6a828d6ba85bbe95aaa] Merge branch 
'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad a157508c9790ccd1c8b5c6a828d6ba85bbe95aaa
# bad: [acb32132ec0433c03bed750f3e9508dc29db0328] sched/deadline: Add deadline 
rq status print
git bisect bad acb32132ec0433c03bed750f3e9508dc29db0328
# good: [1029a2b52c09e479fd7b07275812ad97868c0fb0] sched, exit: Deal with 
nested sleeps
git bisect good 1029a2b52c09e479fd7b07275812ad97868c0fb0


That means, the remaining commits would be:
 commit acb32132ec0433c03bed750f3e9508dc29db0328
 Author: Wanpeng Li 
 Date:   Fri Oct 31 06:39:33 2014 +0800

 sched/deadline: Add deadline rq status print

 ...

 commit e23738a7300a7591a57a22f47b813fd1b53ec404
 Author: Peter Zijlstra 
 Date:   Wed Sep 24 10:18:50 2014 +0200

 sched, inotify: Deal with nested sleeps


It looks like pccardd might be doing the wrong thing for
locking/sleeping/waiting.


Trying to complete bisection.

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Wed, 21 January 2015 Bruno Prémont wrote:
 On Tue, 20 January 2015 Linus Torvalds wrote:
  On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
  
   No idea yet which rc is the offender (nor exact patch), but on my not
   so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
   converting my laptop into a heater.
  
   lspci for affected nodes:
   02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
   Controller [1217:7113] (rev 20)
   02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
   Controller [1217:7113] (rev 20)
  
   Very basics I have, before I attempt any bisection:
  
  Hmm. I'm not seeing anything recent changing anything in this area, so
  I suspect that unless somebody else steps up and says Ahh, that
  sounds like xyz, your bisection is the best option.

Bisecting to the end did point me at (the warning traces produced in great
quantities might not be the very same issue as the abusive CPU usage, but
certainly look very related):
  [CCing people on CC for the patch]

commit 8eb23b9f35aae413140d3fda766a98092c21e9b0
Author: Peter Zijlstra pet...@infradead.org
Date:   Wed Sep 24 10:18:55 2014 +0200

sched: Debug nested sleeps

Validate we call might_sleep() with TASK_RUNNING, which catches places
where we nest blocking primitives, eg. mutex usage in a wait loop.

Since all blocking is arranged through task_struct::state, nesting
this will cause the inner primitive to set TASK_RUNNING and the outer
will thus not block.

Another observed problem is calling a blocking function from
schedule()-sched_submit_work()-blk_schedule_flush_plug() which will
then destroy the task state for the actual __schedule() call that
comes after it.

Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Cc: t...@linutronix.de
Cc: ilya.dryo...@inktank.com
Cc: umgwanakikb...@gmail.com
Cc: o...@redhat.com
Cc: Linus Torvalds torva...@linux-foundation.org
Link: http://lkml.kernel.org/r/20140924082242.591637...@infradead.org
Signed-off-by: Ingo Molnar mi...@kernel.org

Which does produce the following trace (hand-copied most important parts of it):
  Warning: CPU 0 PID: 68 at kernel/sched/core.c:7311 __might_sleep+0x143/0x170
  do not call blocking ops when !TASK_RUNNING; state=1 set at [c1436390] 
pccardd+0xa0/0x3e0
  ...
  Call trace:
...
__might_sleep+0x143/0x170
? pccardd+0xa0/0x3e0
? pccardd+0xa0/0x3e0
mutex_lock+0x17/0x2a
pccardd+0xe9/0x3e0
? pcmcia_socket_uevent+0x30/0x30

pccardd() is located in drivers/pcmcia/cs.c and seems to be of the structure
Peter's patch wants to warn about.


Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Tue, 20 January 2015 Linus Torvalds wrote:
 On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
 
  No idea yet which rc is the offender (nor exact patch), but on my not
  so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
  converting my laptop into a heater.
 
  lspci for affected nodes:
  02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
  Controller [1217:7113] (rev 20)
  02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus 
  Controller [1217:7113] (rev 20)
 
  Very basics I have, before I attempt any bisection:
 
 Hmm. I'm not seeing anything recent changing anything in this area, so
 I suspect that unless somebody else steps up and says Ahh, that
 sounds like xyz, your bisection is the best option.

I've done most of the bisection and ended up in the scheduler changes.
CCing Peter.

A few iterations from the end kernel is warning about (might?)sleeping during
locking or so (scrolling too fast to read end making access to console
hard).

My current bisection log is:
git bisect start
# bad: [117af36e3bceb4fceb1c63489d6f3d94ed259a4c] Apple-GMUX: inhibit VGA 
arbitration changes
git bisect bad 117af36e3bceb4fceb1c63489d6f3d94ed259a4c
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
# bad: [c0222ac086669a631814bbf857f8c8023452a4d7] Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad c0222ac086669a631814bbf857f8c8023452a4d7
# bad: [2183a58803c2bbd87c2d0057eed6779ec4718d4d] Merge tag 'media/v3.19-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 2183a58803c2bbd87c2d0057eed6779ec4718d4d
# good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 6da314122ddc11936c6f054753bbb956a499d020
# bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612
# bad: [9e66645d72d3c395da92b0f8855c787f4b5f0e89] Merge branch 
'irq-irqdomain-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 9e66645d72d3c395da92b0f8855c787f4b5f0e89
# good: [5706ffd045c3810912c4982357d7daa721af3464] Merge branch 
'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 5706ffd045c3810912c4982357d7daa721af3464
# bad: [a157508c9790ccd1c8b5c6a828d6ba85bbe95aaa] Merge branch 
'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad a157508c9790ccd1c8b5c6a828d6ba85bbe95aaa
# bad: [acb32132ec0433c03bed750f3e9508dc29db0328] sched/deadline: Add deadline 
rq status print
git bisect bad acb32132ec0433c03bed750f3e9508dc29db0328
# good: [1029a2b52c09e479fd7b07275812ad97868c0fb0] sched, exit: Deal with 
nested sleeps
git bisect good 1029a2b52c09e479fd7b07275812ad97868c0fb0


That means, the remaining commits would be:
 commit acb32132ec0433c03bed750f3e9508dc29db0328
 Author: Wanpeng Li wanpeng...@linux.intel.com
 Date:   Fri Oct 31 06:39:33 2014 +0800

 sched/deadline: Add deadline rq status print

 ...

 commit e23738a7300a7591a57a22f47b813fd1b53ec404
 Author: Peter Zijlstra pet...@infradead.org
 Date:   Wed Sep 24 10:18:50 2014 +0200

 sched, inotify: Deal with nested sleeps


It looks like pccardd might be doing the wrong thing for
locking/sleeping/waiting.


Trying to complete bisection.

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Bruno Prémont]

On Sun, 18 January 2015 Linus Torvalds  wrote:
> Another week, another -rc.
> 
> Fairly normal release, although I'd wish that by rc5 we'd have calmed
> down even further.  But no, with some of the driver tree merges in
> particular, this is actually larger than rc4 was.
> 
> That said, it's not like there is anything particularly scary in here.
> 
> The arm64 vm bug that I mentioned as pending in the rc4 notes got
> fixed within a day of that previous rc release, and the rest looks
> pretty standard. Mostly drivers (networking, usb, scsi target, block
> layer, mmc,  tty etc), but also arch updates (arm, x86, s390 and some
> tiny powerpc fixes), some filesystem updates (fuse and nfs), tracing
> fixes, and some perf tooling fixes.
> 
> Shortlog with the details appended.
> 
> Go forth and test.

No idea yet which rc is the offender (nor exact patch), but on my not
so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
converting my laptop into a heater.

lspci for affected nodes:
02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller 
[1217:7113] (rev 20)
02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller 
[1217:7113] (rev 20)


Very basics I have, before I attempt any bisection:

cat /proc/$(pidof pccardd)/stack
[] pccardd+0x1a5/0x3e0
[] kthread+0xa0/0xc0
[] ret_from_kernel_thread+0x20/0x30
[] 0x


Doing objdump on drivers/pcmcia/cs.o in which pccardd() is defined
it seems pccardd is stuck in try_to_freeze_unsafe().

Does this kind of behavior ring a bell?

I can unbind the two yenta_cardbus devices from yenta_cardbus to stop
the CPU usage.


Possibly important config option:
# CONFIG_SMP is not set




Objdump below:

static int pccardd(void *__skt)
{
 ca0:   55  push   %ebp
 ca1:   89 e5   mov%esp,%ebp
 ca3:   57  push   %edi
 ca4:   56  push   %esi
 ca5:   53  push   %ebx
 ca6:   89 c3   mov%eax,%ebx
 ca8:   83 ec 24sub$0x24,%esp

DECLARE_PER_CPU(struct task_struct *, current_task);

static __always_inline struct task_struct *get_current(void)
{
return this_cpu_read_stable(current_task);
 cab:   a1 00 00 00 00  mov0x0,%eax
struct pcmcia_socket *skt = __skt;
int ret;

skt->thread = current;
 cb0:   89 83 e4 00 00 00   mov%eax,0xe4(%ebx)
skt->socket = dead_socket;
 cb6:   a1 00 00 00 00  mov0x0,%eax
skt->ops->init(skt);
 cbb:   8b 93 cc 00 00 00   mov0xcc(%ebx),%edx
{
struct pcmcia_socket *skt = __skt;
int ret;

skt->thread = current;
skt->socket = dead_socket;
 cc1:   89 43 04mov%eax,0x4(%ebx)
 cc4:   a1 04 00 00 00  mov0x4,%eax
 cc9:   89 43 08mov%eax,0x8(%ebx)
 ccc:   a1 08 00 00 00  mov0x8,%eax
 cd1:   89 43 0cmov%eax,0xc(%ebx)
skt->ops->init(skt);
 cd4:   89 d8   mov%ebx,%eax
 cd6:   ff 12   call   *(%edx)
skt->ops->set_socket(skt, >socket);
 cd8:   8b 8b cc 00 00 00   mov0xcc(%ebx),%ecx
 cde:   8d 53 04lea0x4(%ebx),%edx
 ce1:   89 d8   mov%ebx,%eax
 ce3:   ff 51 0ccall   *0xc(%ecx)

/* register with the device core */
ret = device_register(>dev);
 ce6:   8d 83 2c 01 00 00   lea0x12c(%ebx),%eax
 cec:   89 45 e0mov%eax,-0x20(%ebp)
 cef:   e8 fc ff ff ff  call   cf0 
if (ret) {
 cf4:   85 c0   test   %eax,%eax
 cf6:   0f 85 d4 02 00 00   jnefd0 
   "PCMCIA: unable to register socket\n");
skt->thread = NULL;
complete(>thread_done);
return 0;
}
ret = pccard_sysfs_add_socket(>dev);
 cfc:   8b 45 e0mov-0x20(%ebp),%eax
 cff:   e8 fc ff ff ff  call   d00 
if (ret)
 d04:   85 c0   test   %eax,%eax
   "PCMCIA: unable to register socket\n");
skt->thread = NULL;
complete(>thread_done);
return 0;
}
ret = pccard_sysfs_add_socket(>dev);
 d06:   89 45 e4mov%eax,-0x1c(%ebp)
if (ret)
 d09:   0f 85 01 03 00 00   jne1010 
dev_warn(>dev, "err %d adding socket attributes\n", ret);

complete(>thread_done);
 d0f:   8d 83 e8 00 00 00   lea0xe8(%ebx),%eax
 d15:   e8 fc ff ff ff  call   d16 

/* wait for userspace to catch up */

Re: Linux 3.19-rc5

[Bruno Prémont]

On Sun, 18 January 2015 Linus Torvalds torva...@linux-foundation.org wrote:
 Another week, another -rc.
 
 Fairly normal release, although I'd wish that by rc5 we'd have calmed
 down even further.  But no, with some of the driver tree merges in
 particular, this is actually larger than rc4 was.
 
 That said, it's not like there is anything particularly scary in here.
 
 The arm64 vm bug that I mentioned as pending in the rc4 notes got
 fixed within a day of that previous rc release, and the rest looks
 pretty standard. Mostly drivers (networking, usb, scsi target, block
 layer, mmc,  tty etc), but also arch updates (arm, x86, s390 and some
 tiny powerpc fixes), some filesystem updates (fuse and nfs), tracing
 fixes, and some perf tooling fixes.
 
 Shortlog with the details appended.
 
 Go forth and test.

No idea yet which rc is the offender (nor exact patch), but on my not
so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
converting my laptop into a heater.

lspci for affected nodes:
02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller 
[1217:7113] (rev 20)
02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller 
[1217:7113] (rev 20)


Very basics I have, before I attempt any bisection:

cat /proc/$(pidof pccardd)/stack
[c143ec95] pccardd+0x1a5/0x3e0
[c10543a0] kthread+0xa0/0xc0
[c16cd840] ret_from_kernel_thread+0x20/0x30
[] 0x


Doing objdump on drivers/pcmcia/cs.o in which pccardd() is defined
it seems pccardd is stuck in try_to_freeze_unsafe().

Does this kind of behavior ring a bell?

I can unbind the two yenta_cardbus devices from yenta_cardbus to stop
the CPU usage.


Possibly important config option:
# CONFIG_SMP is not set




Objdump below:

static int pccardd(void *__skt)
{
 ca0:   55  push   %ebp
 ca1:   89 e5   mov%esp,%ebp
 ca3:   57  push   %edi
 ca4:   56  push   %esi
 ca5:   53  push   %ebx
 ca6:   89 c3   mov%eax,%ebx
 ca8:   83 ec 24sub$0x24,%esp

DECLARE_PER_CPU(struct task_struct *, current_task);

static __always_inline struct task_struct *get_current(void)
{
return this_cpu_read_stable(current_task);
 cab:   a1 00 00 00 00  mov0x0,%eax
struct pcmcia_socket *skt = __skt;
int ret;

skt-thread = current;
 cb0:   89 83 e4 00 00 00   mov%eax,0xe4(%ebx)
skt-socket = dead_socket;
 cb6:   a1 00 00 00 00  mov0x0,%eax
skt-ops-init(skt);
 cbb:   8b 93 cc 00 00 00   mov0xcc(%ebx),%edx
{
struct pcmcia_socket *skt = __skt;
int ret;

skt-thread = current;
skt-socket = dead_socket;
 cc1:   89 43 04mov%eax,0x4(%ebx)
 cc4:   a1 04 00 00 00  mov0x4,%eax
 cc9:   89 43 08mov%eax,0x8(%ebx)
 ccc:   a1 08 00 00 00  mov0x8,%eax
 cd1:   89 43 0cmov%eax,0xc(%ebx)
skt-ops-init(skt);
 cd4:   89 d8   mov%ebx,%eax
 cd6:   ff 12   call   *(%edx)
skt-ops-set_socket(skt, skt-socket);
 cd8:   8b 8b cc 00 00 00   mov0xcc(%ebx),%ecx
 cde:   8d 53 04lea0x4(%ebx),%edx
 ce1:   89 d8   mov%ebx,%eax
 ce3:   ff 51 0ccall   *0xc(%ecx)

/* register with the device core */
ret = device_register(skt-dev);
 ce6:   8d 83 2c 01 00 00   lea0x12c(%ebx),%eax
 cec:   89 45 e0mov%eax,-0x20(%ebp)
 cef:   e8 fc ff ff ff  call   cf0 pccardd+0x50
if (ret) {
 cf4:   85 c0   test   %eax,%eax
 cf6:   0f 85 d4 02 00 00   jnefd0 pccardd+0x330
   PCMCIA: unable to register socket\n);
skt-thread = NULL;
complete(skt-thread_done);
return 0;
}
ret = pccard_sysfs_add_socket(skt-dev);
 cfc:   8b 45 e0mov-0x20(%ebp),%eax
 cff:   e8 fc ff ff ff  call   d00 pccardd+0x60
if (ret)
 d04:   85 c0   test   %eax,%eax
   PCMCIA: unable to register socket\n);
skt-thread = NULL;
complete(skt-thread_done);
return 0;
}
ret = pccard_sysfs_add_socket(skt-dev);
 d06:   89 45 e4mov%eax,-0x1c(%ebp)
if (ret)
 d09:   0f 85 01 03 00 00   jne1010 pccardd+0x370
dev_warn(skt-dev, err %d adding socket attributes\n, ret);

complete(skt-thread_done);
 d0f:   8d 83 e8 00 00 00   lea0xe8(%ebx),%eax
 d15:   

Re: [PATCH] input: Add soft kill switch for input devices

[Bruno Prémont]

On Sat, 03 January 2015 Tristan Lelong  wrote:
> This adds a sysfs attribute named 'mute' to all input devices.
> It allows to disable them by software in a generic way.
> 
> It can be set to 0 or 1:
> echo 1 > /sys/class/input/inputX/mute: will set all the input_events() call 
> to return immediately.
> echo 0 > /sys/class/input/inputX/mute: will reset to default behavior.
> 
> mute is set to 0 by default when calling alloc_input_device().
> 
> Signed-off-by: Tristan Lelong 
> ---
> Hi,
> 
> I created this patch to answer a need on my machine: I want to be able to 
> disable momentarily the touchscreen
> in order to wipe out a dust or clean the display without creating a mess on 
> my desktop and opened docs.
> It seemed consistent to have that kill switch at a central point, and 
> moreover,
> it doesn't depend on any tool linked to a specifc X server, graphical 
> toolkit, desktop environment...
> 
> This patch uses the 0/1 values to enable or disable the mute, but I could 
> update it to use
> enable/disable instead if it is preferred.
> Also, the permissions are write for group or ownoer only.
> I thought about setting it world writable in order to allow easy shortcut 
> creation, but it might also be a security flaw.
> 
> Let me know what you think about all this, at least it is really useful in my 
> case, linked to a keyboard shortcut.
> 
> Best regards
> ---
>  drivers/input/input.c | 30 +-
>  include/linux/input.h |  1 +
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index a1e609a..2f80fee 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -425,7 +425,7 @@ void input_event(struct input_dev *dev,
>  {
>   unsigned long flags;
>  
> - if (is_event_supported(type, dev->evbit, EV_MAX)) {
> + if (!dev->mute && is_event_supported(type, dev->evbit, EV_MAX)) {
>  
>   spin_lock_irqsave(>event_lock, flags);
>   input_handle_event(dev, type, code, value);
> @@ -1384,10 +1384,38 @@ static ssize_t input_dev_show_properties(struct 
> device *dev,
> 

One big issue I see here is that you start dropping all events at a random
point in time.
You may end up within a gesture or just while a button is down and remain
so until that same button gets pressed again on unmute.

On your touchscreen, how do things behave if you trigger the muting while
you are dragging or doing some gesture (and unmute when noone touches
the touchscreen)?

If applied to a keyboard, what happens when you mute while keys are pressed
and unmute when they have long been released?


If you could send a "reset" event to input listeners when muting you could
work around most issues as any application making use of events would know
that after this "reset" event things should not depend on any past state.


Possibly a better way to achieve your aim is to just unbind and re-bind
the device from device driver, causing software hotplug.
That way you are sure no application will perform incorrect guesses while
device is "muted".

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: Add soft kill switch for input devices

[Bruno Prémont]

On Sat, 03 January 2015 Tristan Lelong tris...@lelong.xyz wrote:
 This adds a sysfs attribute named 'mute' to all input devices.
 It allows to disable them by software in a generic way.
 
 It can be set to 0 or 1:
 echo 1  /sys/class/input/inputX/mute: will set all the input_events() call 
 to return immediately.
 echo 0  /sys/class/input/inputX/mute: will reset to default behavior.
 
 mute is set to 0 by default when calling alloc_input_device().
 
 Signed-off-by: Tristan Lelong tris...@lelong.xyz
 ---
 Hi,
 
 I created this patch to answer a need on my machine: I want to be able to 
 disable momentarily the touchscreen
 in order to wipe out a dust or clean the display without creating a mess on 
 my desktop and opened docs.
 It seemed consistent to have that kill switch at a central point, and 
 moreover,
 it doesn't depend on any tool linked to a specifc X server, graphical 
 toolkit, desktop environment...
 
 This patch uses the 0/1 values to enable or disable the mute, but I could 
 update it to use
 enable/disable instead if it is preferred.
 Also, the permissions are write for group or ownoer only.
 I thought about setting it world writable in order to allow easy shortcut 
 creation, but it might also be a security flaw.
 
 Let me know what you think about all this, at least it is really useful in my 
 case, linked to a keyboard shortcut.
 
 Best regards
 ---
  drivers/input/input.c | 30 +-
  include/linux/input.h |  1 +
  2 files changed, 30 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/input/input.c b/drivers/input/input.c
 index a1e609a..2f80fee 100644
 --- a/drivers/input/input.c
 +++ b/drivers/input/input.c
 @@ -425,7 +425,7 @@ void input_event(struct input_dev *dev,
  {
   unsigned long flags;
  
 - if (is_event_supported(type, dev-evbit, EV_MAX)) {
 + if (!dev-mute  is_event_supported(type, dev-evbit, EV_MAX)) {
  
   spin_lock_irqsave(dev-event_lock, flags);
   input_handle_event(dev, type, code, value);
 @@ -1384,10 +1384,38 @@ static ssize_t input_dev_show_properties(struct 
 device *dev,
 snip

One big issue I see here is that you start dropping all events at a random
point in time.
You may end up within a gesture or just while a button is down and remain
so until that same button gets pressed again on unmute.

On your touchscreen, how do things behave if you trigger the muting while
you are dragging or doing some gesture (and unmute when noone touches
the touchscreen)?

If applied to a keyboard, what happens when you mute while keys are pressed
and unmute when they have long been released?


If you could send a reset event to input listeners when muting you could
work around most issues as any application making use of events would know
that after this reset event things should not depend on any past state.


Possibly a better way to achieve your aim is to just unbind and re-bind
the device from device driver, causing software hotplug.
That way you are sure no application will perform incorrect guesses while
device is muted.

Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] netconsole: New console flag to dump full log buffer

[Bruno Prémont]

Be default only log messages not yet seen by userspace are output when
enabling netconsole via module parameter (none when enabling dynamic
targets).

When using netconsole to centrally log kernel messages it's of interest
to have the whole kernel log sent over the same medium, even if netconsole
setup happens rather late during system boot. The big advantage of netconsole
over syslog for this task is that it usually allow catching much more
messages when system crashes/panics.

This causes dynamic netconsoles to request full kernel log when first
enabled.

Signed-off-by: Bruno Prémont 
---
Note, with this kernel is too quick at sending packets for some receiving
machines to catch all of them. Either packets get dropped by the receiving
NIC if can't buffer enough until OS has time to empty the buffers or they
get lost between kernel and userspace socket if backlog is too small.

My test environment was 4core AMD APU with Gbit NIC to Marvell Kirkwood
SheevaPlug with Gbit NIC. About first 100 lines get through, then lines
start getting lost.

 drivers/net/netconsole.c |  3 ++-
 include/linux/console.h  |  1 +
 kernel/printk/printk.c   | 12 +---
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index a96cd8e..241c70f 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -661,7 +661,8 @@ static struct config_item *make_netconsole_target(struct 
config_group *group,
mutex_init(>mutex);
memset(nt->np.remote_mac, 0xff, ETH_ALEN);
snprintf(nt->console.name, sizeof(nt->console.name), "netcon-%s", name);
-   nt->console.flags = CON_ENABLED;
+   /* Dump existing printks when we register */
+   nt->console.flags = CON_ENABLED | CON_PRINTBUFFER | CON_PRINTALL;
nt->console.write = write_msg;
nt->console.loglevel = 0;
 
diff --git a/include/linux/console.h b/include/linux/console.h
index f3a8996..6f53a54 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -116,6 +116,7 @@ static inline int con_debug_leave(void)
 #define CON_ANYTIME(16) /* Safe to call when cpu is offline */
 #define CON_BRL(32) /* Used for a braille device */
 #define CON_LOGLEVEL   (64) /* Per-console log-level filtering */
+#define CON_PRINTALL   (128) /* Extends CON_PRINTBUFFER */
 
 struct console {
charname[16];
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f09f30..193665d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2554,9 +2554,15 @@ void register_console(struct console *newcon)
 * for us.
 */
raw_spin_lock_irqsave(_lock, flags);
-   console_seq = syslog_seq;
-   console_idx = syslog_idx;
-   console_prev = syslog_prev;
+   if (newcon->flags & CON_PRINTALL) {
+   console_seq = log_first_seq;
+   console_idx = log_first_idx;
+   console_prev = LOG_NEWLINE;
+   } else {
+   console_seq = syslog_seq;
+   console_idx = syslog_idx;
+   console_prev = syslog_prev;
+   }
raw_spin_unlock_irqrestore(_lock, flags);
/*
 * We're about to replay the log buffer.  Only do this to the
-- 
2.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] netconsole: make loglevel configurable per target

[Bruno Prémont]

Switch to registering a new console for each target so that loglevel
based message filtering can be set individually for each target.

This adds a new loglevel= option to netconsole module parameter and also
add a configfs file to configure the loglevel.

The loglevel conf be adjusted at any time for synamic netconsole
consoles.

Signed-off-by: Bruno Prémont 
---
Note: only configuration via configfs has been runtime-tested.

 Documentation/networking/netconsole.txt |  11 ++-
 drivers/net/netconsole.c| 114 +++-
 2 files changed, 94 insertions(+), 31 deletions(-)

diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index a5d574a..c1df516 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -24,7 +24,7 @@ Sender and receiver configuration:
 It takes a string configuration parameter "netconsole" in the
 following format:
 
- netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr]
+ 
netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr][,loglevel=level]
 
where
 src-port  source for UDP packets (defaults to 6665)
@@ -33,6 +33,9 @@ following format:
 tgt-port  port for logging agent ()
 tgt-ipIP address for logging agent
 tgt-macaddr   ethernet MAC address for logging agent (broadcast)
+level limit messages printed to those whose loglevel is
+  smaller that value, range is 1 to 8
+  If missing, loglevel limit as set via syslog(1) applies
 
 Examples:
 
@@ -114,11 +117,16 @@ The interface exposes these parameters of a netconsole 
target to userspace:
remote_ip   Remote agent's IP address   (read-write)
local_mac   Local interface's MAC address   (read-only)
remote_mac  Remote agent's MAC address  (read-write)
+   loglevelConsole loglevel filter (read-write)
 
 The "enabled" attribute is also used to control whether the parameters of
 a target can be updated or not -- you can modify the parameters of only
 disabled targets (i.e. if "enabled" is 0).
 
+The "loglevel" parameter can be set at any time. When set to "0" it will
+read back as empty string and global loglevel filter applies. Otherwise
+specified loglevel filter applies.
+
 To update a target's parameters:
 
  cat enabled   # check if enabled is 1
@@ -164,6 +172,7 @@ priority messages to the console. You can change this at 
runtime using:
 
  dmesg -n 8
 
+or by specifying netconsole loglevel parameter
 or by specifying "debug" on the kernel command line at boot, to send
 all kernel messages to the console. A specific value for this parameter
 can also be set using the "loglevel" kernel boot option. See the
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index ba2f5e7..a96cd8e 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -103,10 +103,12 @@ struct netconsole_target {
 #ifdef CONFIG_NETCONSOLE_DYNAMIC
struct config_item  item;
 #endif
+   struct console  console;
int enabled;
struct mutexmutex;
struct netpoll  np;
 };
+static void write_msg(struct console *con, const char *msg, unsigned int len);
 
 #ifdef CONFIG_NETCONSOLE_DYNAMIC
 
@@ -171,6 +173,7 @@ static struct netconsole_target *alloc_param_target(char 
*target_config)
 {
int err = -ENOMEM;
struct netconsole_target *nt;
+   char *loglevel;
 
/*
 * Allocate and initialize with defaults.
@@ -186,8 +189,26 @@ static struct netconsole_target *alloc_param_target(char 
*target_config)
nt->np.remote_port = ;
mutex_init(>mutex);
memset(nt->np.remote_mac, 0xff, ETH_ALEN);
+   snprintf(nt->console.name, sizeof(nt->console.name), "netcon");
+   /* Dump existing printks when we register */
+   nt->console.flags = CON_ENABLED | CON_PRINTBUFFER;
+   nt->console.write = write_msg;
 
/* Parse parameters and setup netpoll */
+   loglevel = strstr(target_config, ",loglevel=");
+   if (loglevel) {
+   int level;
+   err = kstrtoint(loglevel+10, 10, );
+   if (err < 0)
+   goto fail;
+   if (level < 1 || level > 8) {
+   err = -EINVAL;
+   goto fail;
+   }
+   nt->console.loglevel = level;
+   nt->console.flags |= CON_LOGLEVEL;
+   *loglevel = '\0';
+   }
err = netpoll_parse_options(>np, target_config);
if (err)
goto fail;
@@ -228,6 +249,7 @@ static void free_param_target(

[PATCH 1/3] printk: Use a flag to indicate console-private loglevel

[Bruno Prémont]

In order to set loglevel for a given console that is not affected by
global loglevel as adjusted via syslog(2), add a flag to the console and
choose the level to match against msg level depending on this flag.

Signed-off-by: Bruno Prémont 
---
This depends on Daniel's patch "printk: add per console loglevel"
and modifies the way its filtering is applied.


 include/linux/console.h |  1 +
 kernel/printk/printk.c  | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/console.h b/include/linux/console.h
index 99020d5..f3a8996 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -115,6 +115,7 @@ static inline int con_debug_leave(void)
 #define CON_BOOT   (8)
 #define CON_ANYTIME(16) /* Safe to call when cpu is offline */
 #define CON_BRL(32) /* Used for a braille device */
+#define CON_LOGLEVEL   (64) /* Per-console log-level filtering */
 
 struct console {
charname[16];
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 218d94d..8f09f30 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1399,12 +1399,12 @@ static void call_console_drivers(int level, const char 
*text, size_t len)
 
trace_console(text, len);
 
-   if (level >= console_loglevel && !ignore_loglevel)
-   return;
if (!console_drivers)
return;
 
for_each_console(con) {
+   if (!ignore_loglevel && level >= (con->flags & CON_LOGLEVEL ? 
con->loglevel : console_loglevel))
+   continue;
if (exclusive_console && con != exclusive_console)
continue;
if (!(con->flags & CON_ENABLED))
@@ -1414,9 +1414,6 @@ static void call_console_drivers(int level, const char 
*text, size_t len)
if (!cpu_online(smp_processor_id()) &&
!(con->flags & CON_ANYTIME))
continue;
-   if (con->loglevel && !ignore_loglevel &&
-   level >= con->loglevel)
-   continue;
con->write(con, text, len);
}
 }
@@ -2512,7 +2509,10 @@ void register_console(struct console *newcon)
newcon->setup(newcon, console_cmdline[i].options) != 0)
break;
 
-   newcon->loglevel = c->loglevel;
+   if (c->loglevel) {
+   newcon->loglevel = c->loglevel;
+   newcon->flags |= CON_LOGLEVEL;
+   }
newcon->flags |= CON_ENABLED;
newcon->index = c->index;
if (i == selected_console) {
-- 
2.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] printk: add per console loglevel

[Bruno Prémont]

On Tue, 23 December 2014 dwal...@fifo99.com wrote:
> On Sun, Dec 21, 2014 at 07:47:53PM +0100, Bruno Prémont wrote:
> > On Sat, 20 December 2014 dwal...@fifo99.com wrote:
> > > This adds to to the console= command line options allowing the
> > > addition of a per console log level setting.
> > > 
> > > examples,
> > > 
> > >   console=ttyS0,ll4
> > >   console=tty0,ll6
> > > 
> > > This can be used on systems which have multiple serial consoles, but
> > > it's desired for logging to be light on one and heavy on another.
> > 
> > Looks useful to me.
> > What would be the best way to make these per-console loglevels
> > configurable at runtime? `dmesg -n $LEVEL` only affects the global
> > limit.
> > 
> > One drawback to letting global loglevel have precedence is that
> > all consoles that should not get detailed log messages need to have
> > their loglevel explicitly lowered and it's not possible to have
> > one console forced to show more than the global loglevel.
> 
> Right, reason for the patch.
>  
> > 
> > An approach I would prefer is to have all consoles follow global
> > loglevel except when something different had been explicitly requested
> > for them.
> 
> This patch is mostly like this. It breaks down when you set the "llX"
> parameter to something above KERN_NOTICE, and the global one is also
> set above that.

In your patch global filter applies first, then what passes global filter
gets filtered with the per-console filter.

So I can't have `dmesg -n 3` and "console=ttyS0,ll8 console=tty0"
to get my debugging output over serial console.

> > This way a single console can be added later on (e.g. netconsole)
> > and set to pass through debug messages without affecting anyone else.

Netconsole console can be added at any time when system is running
either through loading of its module or using dynamic configuration
via configfs.

See also my patches.

Thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] printk: add per console loglevel

[Bruno Prémont]

On Tue, 23 December 2014 dwal...@fifo99.com wrote:
 On Sun, Dec 21, 2014 at 07:47:53PM +0100, Bruno Prémont wrote:
  On Sat, 20 December 2014 dwal...@fifo99.com wrote:
   This adds to to the console= command line options allowing the
   addition of a per console log level setting.
   
   examples,
   
 console=ttyS0,ll4
 console=tty0,ll6
   
   This can be used on systems which have multiple serial consoles, but
   it's desired for logging to be light on one and heavy on another.
  
  Looks useful to me.
  What would be the best way to make these per-console loglevels
  configurable at runtime? `dmesg -n $LEVEL` only affects the global
  limit.
  
  One drawback to letting global loglevel have precedence is that
  all consoles that should not get detailed log messages need to have
  their loglevel explicitly lowered and it's not possible to have
  one console forced to show more than the global loglevel.
 
 Right, reason for the patch.
  
  
  An approach I would prefer is to have all consoles follow global
  loglevel except when something different had been explicitly requested
  for them.
 
 This patch is mostly like this. It breaks down when you set the llX
 parameter to something above KERN_NOTICE, and the global one is also
 set above that.

In your patch global filter applies first, then what passes global filter
gets filtered with the per-console filter.

So I can't have `dmesg -n 3` and console=ttyS0,ll8 console=tty0
to get my debugging output over serial console.

  This way a single console can be added later on (e.g. netconsole)
  and set to pass through debug messages without affecting anyone else.

Netconsole console can be added at any time when system is running
either through loading of its module or using dynamic configuration
via configfs.

See also my patches.

Thanks,
Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] printk: Use a flag to indicate console-private loglevel

[Bruno Prémont]

In order to set loglevel for a given console that is not affected by
global loglevel as adjusted via syslog(2), add a flag to the console and
choose the level to match against msg level depending on this flag.

Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
This depends on Daniel's patch printk: add per console loglevel
and modifies the way its filtering is applied.


 include/linux/console.h |  1 +
 kernel/printk/printk.c  | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/console.h b/include/linux/console.h
index 99020d5..f3a8996 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -115,6 +115,7 @@ static inline int con_debug_leave(void)
 #define CON_BOOT   (8)
 #define CON_ANYTIME(16) /* Safe to call when cpu is offline */
 #define CON_BRL(32) /* Used for a braille device */
+#define CON_LOGLEVEL   (64) /* Per-console log-level filtering */
 
 struct console {
charname[16];
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 218d94d..8f09f30 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1399,12 +1399,12 @@ static void call_console_drivers(int level, const char 
*text, size_t len)
 
trace_console(text, len);
 
-   if (level = console_loglevel  !ignore_loglevel)
-   return;
if (!console_drivers)
return;
 
for_each_console(con) {
+   if (!ignore_loglevel  level = (con-flags  CON_LOGLEVEL ? 
con-loglevel : console_loglevel))
+   continue;
if (exclusive_console  con != exclusive_console)
continue;
if (!(con-flags  CON_ENABLED))
@@ -1414,9 +1414,6 @@ static void call_console_drivers(int level, const char 
*text, size_t len)
if (!cpu_online(smp_processor_id()) 
!(con-flags  CON_ANYTIME))
continue;
-   if (con-loglevel  !ignore_loglevel 
-   level = con-loglevel)
-   continue;
con-write(con, text, len);
}
 }
@@ -2512,7 +2509,10 @@ void register_console(struct console *newcon)
newcon-setup(newcon, console_cmdline[i].options) != 0)
break;
 
-   newcon-loglevel = c-loglevel;
+   if (c-loglevel) {
+   newcon-loglevel = c-loglevel;
+   newcon-flags |= CON_LOGLEVEL;
+   }
newcon-flags |= CON_ENABLED;
newcon-index = c-index;
if (i == selected_console) {
-- 
2.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] netconsole: make loglevel configurable per target

[Bruno Prémont]

Switch to registering a new console for each target so that loglevel
based message filtering can be set individually for each target.

This adds a new loglevel= option to netconsole module parameter and also
add a configfs file to configure the loglevel.

The loglevel conf be adjusted at any time for synamic netconsole
consoles.

Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Note: only configuration via configfs has been runtime-tested.

 Documentation/networking/netconsole.txt |  11 ++-
 drivers/net/netconsole.c| 114 +++-
 2 files changed, 94 insertions(+), 31 deletions(-)

diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index a5d574a..c1df516 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -24,7 +24,7 @@ Sender and receiver configuration:
 It takes a string configuration parameter netconsole in the
 following format:
 
- netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@tgt-ip/[tgt-macaddr]
+ 
netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@tgt-ip/[tgt-macaddr][,loglevel=level]
 
where
 src-port  source for UDP packets (defaults to 6665)
@@ -33,6 +33,9 @@ following format:
 tgt-port  port for logging agent ()
 tgt-ipIP address for logging agent
 tgt-macaddr   ethernet MAC address for logging agent (broadcast)
+level limit messages printed to those whose loglevel is
+  smaller that value, range is 1 to 8
+  If missing, loglevel limit as set via syslog(1) applies
 
 Examples:
 
@@ -114,11 +117,16 @@ The interface exposes these parameters of a netconsole 
target to userspace:
remote_ip   Remote agent's IP address   (read-write)
local_mac   Local interface's MAC address   (read-only)
remote_mac  Remote agent's MAC address  (read-write)
+   loglevelConsole loglevel filter (read-write)
 
 The enabled attribute is also used to control whether the parameters of
 a target can be updated or not -- you can modify the parameters of only
 disabled targets (i.e. if enabled is 0).
 
+The loglevel parameter can be set at any time. When set to 0 it will
+read back as empty string and global loglevel filter applies. Otherwise
+specified loglevel filter applies.
+
 To update a target's parameters:
 
  cat enabled   # check if enabled is 1
@@ -164,6 +172,7 @@ priority messages to the console. You can change this at 
runtime using:
 
  dmesg -n 8
 
+or by specifying netconsole loglevel parameter
 or by specifying debug on the kernel command line at boot, to send
 all kernel messages to the console. A specific value for this parameter
 can also be set using the loglevel kernel boot option. See the
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index ba2f5e7..a96cd8e 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -103,10 +103,12 @@ struct netconsole_target {
 #ifdef CONFIG_NETCONSOLE_DYNAMIC
struct config_item  item;
 #endif
+   struct console  console;
int enabled;
struct mutexmutex;
struct netpoll  np;
 };
+static void write_msg(struct console *con, const char *msg, unsigned int len);
 
 #ifdef CONFIG_NETCONSOLE_DYNAMIC
 
@@ -171,6 +173,7 @@ static struct netconsole_target *alloc_param_target(char 
*target_config)
 {
int err = -ENOMEM;
struct netconsole_target *nt;
+   char *loglevel;
 
/*
 * Allocate and initialize with defaults.
@@ -186,8 +189,26 @@ static struct netconsole_target *alloc_param_target(char 
*target_config)
nt-np.remote_port = ;
mutex_init(nt-mutex);
memset(nt-np.remote_mac, 0xff, ETH_ALEN);
+   snprintf(nt-console.name, sizeof(nt-console.name), netcon);
+   /* Dump existing printks when we register */
+   nt-console.flags = CON_ENABLED | CON_PRINTBUFFER;
+   nt-console.write = write_msg;
 
/* Parse parameters and setup netpoll */
+   loglevel = strstr(target_config, ,loglevel=);
+   if (loglevel) {
+   int level;
+   err = kstrtoint(loglevel+10, 10, level);
+   if (err  0)
+   goto fail;
+   if (level  1 || level  8) {
+   err = -EINVAL;
+   goto fail;
+   }
+   nt-console.loglevel = level;
+   nt-console.flags |= CON_LOGLEVEL;
+   *loglevel = '\0';
+   }
err = netpoll_parse_options(nt-np, target_config);
if (err)
goto fail;
@@ -228,6 +249,7 @@ static void free_param_target(struct netconsole_target *nt)
  * |   remote_ip
  * |   local_mac

[PATCH 3/3] netconsole: New console flag to dump full log buffer

[Bruno Prémont]

Be default only log messages not yet seen by userspace are output when
enabling netconsole via module parameter (none when enabling dynamic
targets).

When using netconsole to centrally log kernel messages it's of interest
to have the whole kernel log sent over the same medium, even if netconsole
setup happens rather late during system boot. The big advantage of netconsole
over syslog for this task is that it usually allow catching much more
messages when system crashes/panics.

This causes dynamic netconsoles to request full kernel log when first
enabled.

Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Note, with this kernel is too quick at sending packets for some receiving
machines to catch all of them. Either packets get dropped by the receiving
NIC if can't buffer enough until OS has time to empty the buffers or they
get lost between kernel and userspace socket if backlog is too small.

My test environment was 4core AMD APU with Gbit NIC to Marvell Kirkwood
SheevaPlug with Gbit NIC. About first 100 lines get through, then lines
start getting lost.

 drivers/net/netconsole.c |  3 ++-
 include/linux/console.h  |  1 +
 kernel/printk/printk.c   | 12 +---
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index a96cd8e..241c70f 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -661,7 +661,8 @@ static struct config_item *make_netconsole_target(struct 
config_group *group,
mutex_init(nt-mutex);
memset(nt-np.remote_mac, 0xff, ETH_ALEN);
snprintf(nt-console.name, sizeof(nt-console.name), netcon-%s, name);
-   nt-console.flags = CON_ENABLED;
+   /* Dump existing printks when we register */
+   nt-console.flags = CON_ENABLED | CON_PRINTBUFFER | CON_PRINTALL;
nt-console.write = write_msg;
nt-console.loglevel = 0;
 
diff --git a/include/linux/console.h b/include/linux/console.h
index f3a8996..6f53a54 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -116,6 +116,7 @@ static inline int con_debug_leave(void)
 #define CON_ANYTIME(16) /* Safe to call when cpu is offline */
 #define CON_BRL(32) /* Used for a braille device */
 #define CON_LOGLEVEL   (64) /* Per-console log-level filtering */
+#define CON_PRINTALL   (128) /* Extends CON_PRINTBUFFER */
 
 struct console {
charname[16];
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f09f30..193665d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2554,9 +2554,15 @@ void register_console(struct console *newcon)
 * for us.
 */
raw_spin_lock_irqsave(logbuf_lock, flags);
-   console_seq = syslog_seq;
-   console_idx = syslog_idx;
-   console_prev = syslog_prev;
+   if (newcon-flags  CON_PRINTALL) {
+   console_seq = log_first_seq;
+   console_idx = log_first_idx;
+   console_prev = LOG_NEWLINE;
+   } else {
+   console_seq = syslog_seq;
+   console_idx = syslog_idx;
+   console_prev = syslog_prev;
+   }
raw_spin_unlock_irqrestore(logbuf_lock, flags);
/*
 * We're about to replay the log buffer.  Only do this to the
-- 
2.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] printk: add per console loglevel

[Bruno Prémont]

On Sat, 20 December 2014 dwal...@fifo99.com wrote:
> This adds to to the console= command line options allowing the
> addition of a per console log level setting.
> 
> examples,
> 
>   console=ttyS0,ll4
>   console=tty0,ll6
> 
> This can be used on systems which have multiple serial consoles, but
> it's desired for logging to be light on one and heavy on another.

Looks useful to me.
What would be the best way to make these per-console loglevels
configurable at runtime? `dmesg -n $LEVEL` only affects the global
limit.

One drawback to letting global loglevel have precedence is that
all consoles that should not get detailed log messages need to have
their loglevel explicitly lowered and it's not possible to have
one console forced to show more than the global loglevel.


An approach I would prefer is to have all consoles follow global
loglevel except when something different had been explicitly requested
for them.
This way a single console can be added later on (e.g. netconsole)
and set to pass through debug messages without affecting anyone else.

Bruno

> Signed-off-by: Daniel Walker 
> ---
>  Documentation/kernel-parameters.txt | 24 ++--
>  include/linux/console.h |  1 +
>  kernel/printk/console_cmdline.h |  9 +
>  kernel/printk/printk.c  | 37 
> -
>  4 files changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 4df73da..7e65d5b 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -696,30 +696,42 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>  
>   console=[KNL] Output console device and options.
>  
> - tty  Use the virtual console device .
> + tty[,llX]Use the virtual console device .
>  
> - ttyS[,options]
> - ttyUSB0[,options]
> + ttyS[,options][,llX]
> + ttyUSB0[,options][,llX]
>   Use the specified serial port.  The options are of
>   the form "pnf", where "" is the baud rate,
>   "p" is parity ("n", "o", or "e"), "n" is number of
>   bits, and "f" is flow control ("r" for RTS or
>   omit it).  Default is "9600n8".
>  
> + "llX" explained below,
> +
>   See Documentation/serial-console.txt for more
>   information.  See
>   Documentation/networking/netconsole.txt for an
>   alternative.
>  
> - uart[8250],io,[,options]
> - uart[8250],mmio,[,options]
> + uart[8250],io,[,options][,llX]
> + uart[8250],mmio,[,options][,llX]
>   Start an early, polled-mode console on the 8250/16550
>   UART at the specified I/O port or MMIO address,
>   switching to the matching ttyS device later.  The
>   options are the same as for ttyS, above.
> - hvc  Use the hypervisor console device . This is for
> +
> + "llX" explained below,
> +
> + hvc[,llX]
> + Use the hypervisor console device . This is for
>   both Xen and PowerPC hypervisors.
>  
> + "llX" is used to define the loglevel per console. The 
> "X"
> + defines the loglevel number for this console. The usage
> + is similar to the "loglevel=" option, and the effect is
> + the same only per console. The "loglevel=" option takes
> + precedence of this option.
> +
>  If the device connected to the port is not a TTY but a 
> braille
>  device, prepend "brl," before the device type, for instance
>   console=brl,ttyS0
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 7571a16..99020d5 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -118,6 +118,7 @@ static inline int con_debug_leave(void)
>  
>  struct console {
>   charname[16];
> + int loglevel;
>   void(*write)(struct console *, const char *, unsigned);
>   int (*read)(struct console *, char *, unsigned);
>   struct tty_driver *(*device)(struct console *, int *);
> diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
> index cbd69d8..6f6f98f 100644
> --- a/kernel/printk/console_cmdline.h
> +++ b/kernel/printk/console_cmdline.h
> @@ -3,11 +3,12 @@
>  
>  struct console_cmdline
>  {
> - charname[8];/* Name of the driver   */
> - int index;  /* Minor dev. to use*/
> - char*options;   /* Options 

Re: [PATCH] printk: add per console loglevel

[Bruno Prémont]

On Sat, 20 December 2014 dwal...@fifo99.com wrote:
 This adds to to the console= command line options allowing the
 addition of a per console log level setting.
 
 examples,
 
   console=ttyS0,ll4
   console=tty0,ll6
 
 This can be used on systems which have multiple serial consoles, but
 it's desired for logging to be light on one and heavy on another.

Looks useful to me.
What would be the best way to make these per-console loglevels
configurable at runtime? `dmesg -n $LEVEL` only affects the global
limit.

One drawback to letting global loglevel have precedence is that
all consoles that should not get detailed log messages need to have
their loglevel explicitly lowered and it's not possible to have
one console forced to show more than the global loglevel.


An approach I would prefer is to have all consoles follow global
loglevel except when something different had been explicitly requested
for them.
This way a single console can be added later on (e.g. netconsole)
and set to pass through debug messages without affecting anyone else.

Bruno

 Signed-off-by: Daniel Walker dwal...@fifo99.com
 ---
  Documentation/kernel-parameters.txt | 24 ++--
  include/linux/console.h |  1 +
  kernel/printk/console_cmdline.h |  9 +
  kernel/printk/printk.c  | 37 
 -
  4 files changed, 60 insertions(+), 11 deletions(-)
 
 diff --git a/Documentation/kernel-parameters.txt 
 b/Documentation/kernel-parameters.txt
 index 4df73da..7e65d5b 100644
 --- a/Documentation/kernel-parameters.txt
 +++ b/Documentation/kernel-parameters.txt
 @@ -696,30 +696,42 @@ bytes respectively. Such letter suffixes can also be 
 entirely omitted.
  
   console=[KNL] Output console device and options.
  
 - ttyn  Use the virtual console device n.
 + ttyn[,llX]Use the virtual console device n.
  
 - ttySn[,options]
 - ttyUSB0[,options]
 + ttySn[,options][,llX]
 + ttyUSB0[,options][,llX]
   Use the specified serial port.  The options are of
   the form pnf, where  is the baud rate,
   p is parity (n, o, or e), n is number of
   bits, and f is flow control (r for RTS or
   omit it).  Default is 9600n8.
  
 + llX explained below,
 +
   See Documentation/serial-console.txt for more
   information.  See
   Documentation/networking/netconsole.txt for an
   alternative.
  
 - uart[8250],io,addr[,options]
 - uart[8250],mmio,addr[,options]
 + uart[8250],io,addr[,options][,llX]
 + uart[8250],mmio,addr[,options][,llX]
   Start an early, polled-mode console on the 8250/16550
   UART at the specified I/O port or MMIO address,
   switching to the matching ttyS device later.  The
   options are the same as for ttyS, above.
 - hvcn  Use the hypervisor console device n. This is for
 +
 + llX explained below,
 +
 + hvcn[,llX]
 + Use the hypervisor console device n. This is for
   both Xen and PowerPC hypervisors.
  
 + llX is used to define the loglevel per console. The 
 X
 + defines the loglevel number for this console. The usage
 + is similar to the loglevel= option, and the effect is
 + the same only per console. The loglevel= option takes
 + precedence of this option.
 +
  If the device connected to the port is not a TTY but a 
 braille
  device, prepend brl, before the device type, for instance
   console=brl,ttyS0
 diff --git a/include/linux/console.h b/include/linux/console.h
 index 7571a16..99020d5 100644
 --- a/include/linux/console.h
 +++ b/include/linux/console.h
 @@ -118,6 +118,7 @@ static inline int con_debug_leave(void)
  
  struct console {
   charname[16];
 + int loglevel;
   void(*write)(struct console *, const char *, unsigned);
   int (*read)(struct console *, char *, unsigned);
   struct tty_driver *(*device)(struct console *, int *);
 diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
 index cbd69d8..6f6f98f 100644
 --- a/kernel/printk/console_cmdline.h
 +++ b/kernel/printk/console_cmdline.h
 @@ -3,11 +3,12 @@
  
  struct console_cmdline
  {
 - charname[8];/* Name of the driver   */
 - int index;  /* Minor dev. to use*/
 - char*options;   /* Options for the driver   */
 + charname[8];/* Name of the driver  

Re: need help to clear kernel (2.6.16.17) cached memory

[Bruno Prémont]

Hi,

On Sat, 13 December 2014 Manish Yadav  wrote:
> on my system (based on 2.6.16.17), i am trying to clear the cached
> memory but it is not being cleared.
> 
> mars# free -m
>  total   used   free sharedbuffers cached
> Mem:   925459465  0  0231
> -/+ buffers/cache:228697
> Swap:0  0  0
> mars# sync && echo 3 > /proc/sys/vm/drop_caches
> M1450-mrakesh# free -m
>  total   used   free sharedbuffers cached
> Mem:   925459466  0  0231
> -/+ buffers/cache:227697
> Swap:0  0  0
> mars#
> 
> could you please let me know what i am missing here? as per my
> investigation writing 3 to drop_caches should clear the cached memory.

Any tmpfs around that would be filled with the remaining cached data?

> thanks,
> manish

Cheers,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: need help to clear kernel (2.6.16.17) cached memory

[Bruno Prémont]

Hi,

On Sat, 13 December 2014 Manish Yadav kmanish@gmail.com wrote:
 on my system (based on 2.6.16.17), i am trying to clear the cached
 memory but it is not being cleared.
 
 mars# free -m
  total   used   free sharedbuffers cached
 Mem:   925459465  0  0231
 -/+ buffers/cache:228697
 Swap:0  0  0
 mars# sync  echo 3  /proc/sys/vm/drop_caches
 M1450-mrakesh# free -m
  total   used   free sharedbuffers cached
 Mem:   925459466  0  0231
 -/+ buffers/cache:227697
 Swap:0  0  0
 mars#
 
 could you please let me know what i am missing here? as per my
 investigation writing 3 to drop_caches should clear the cached memory.

Any tmpfs around that would be filled with the remaining cached data?

 thanks,
 manish

Cheers,
Bruno
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

[Bruno Prémont]

Hi Hendrick,

On Fri, 14 November 2014 Henrik Rydberg  wrote:
> > So it would need to at least be select VGA_ARB if (PCI && !S390)
> > in order to not have broken kernel configuration (in more or less
> > exotic cases) while depends on VGA_ARB would be the only correct option
> > if the rule 'select only allowed for leafs' is enforced.
> 
> Here is a tested patch that does just that, thanks for the suggestion.

Sure it will cover your case but with a few issues.

As you might have noted, VGA_ARB can only be disabled if you select
EXPERT. In that case you kind of give up warranty.

In addition, prior to the patches that landed in 3.17, just selecting
X86_SYSFB would runtime-disable EFI_FB disabling boot_vga tagging
based on screen_info as well.

Stating in the commit message that EFI_FB depends on VGA_ARB is pretty
wrong. A more correct phrasing would be that before the commit EFI_FB
included boot_vga detection which has been moved around, but that
feature is not inherent to EFI_FB. Doing the select only keeps
`make oldconfig` provide the same feature set.




As boot_vga is a PCI thing maybe the whole detection should effectively
be fully dissociated from runtime GPU switching and be adjusted to
really only flag the boot GPU (even when there is no VGA around).

Unfortunately this attribute is not explicitly documented so drawing the
line one way or another may trip on some user's feet.

We have some more or less conflicting information in commit messages though:

217f45de3d2 by Dave Airlie introducing boot_vgain 2009:
PCI: expose boot VGA device via sysfs.

X really would like to know which VGA device was considered the boot
device by the system. The x86 PCI fixups have support for discovering
this but we provide no way to expose it to userspace.

This adds a sysfs file per VGA class device which has the value 0 for
non the boot device or unknown, and 1 if the VGA device is the boot
device.

1a39b310e92 by Matthew Garrett making it variable in 2012:
vgaarb: Add support for setting the default video device (v2)

The default VGA device is a somewhat fluid concept on platforms with
multiple GPUs. Add support for setting it so switching code can update
things appropriately, and make sure that the sysfs code returns the right
device if it's changed.

So should boot_vga now represent the main GPU of the system or should
it represent the one(s) that were used for booting? (I've not heard
of systems with more than one active firmware GPU... but why not!

Matthew covered the case where multiple GPUs are in a set where only one
of them can be active as in driving displays. Maybe this would need some
alternative sysfs attribute kind of "preferred_gpu".

Bruno


> From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
> From: Henrik Rydberg 
> Date: Fri, 14 Nov 2014 20:01:21 +0100
> Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
> depends on the VGA arbitration layer. However, the configuration does
> not reflect this, which leads to a hard-to-find bug when FB_EFI is
> configured without VGA_ARB. Add a select clause to remedy this.
> 
> Cc: Bruno Prémont 
> Signed-off-by: Henrik Rydberg 
> ---
>  drivers/video/fbdev/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c7bf606..1615a1b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -761,6 +761,7 @@ config FB_EFI
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
> + select VGA_ARB if (PCI && !S390)
>   help
> This is the EFI frame buffer device driver. If the firmware on
> your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

[Bruno Prémont]

On Fri, 14 Nov 2014 13:53:30 +0100 Henrik Rydberg wrote:
> Since commit 20cde694027e ("x86, ia64: Move EFI_FB
> vga_default_device() initialization to pci_vga_fixup()") in the 3.17
> merge window, the EFI framebuffer depends on the VGA arbitration
> layer. However, the configuration does not reflect this, which leads
> to a hard-to-find bug when FB_EFI is configured without VGA_ARB. Add a
> select clause to remedy this.

Could you be more verbose in why it depends on/needs VGA_ARB?

With EFI starting to show up on ARM this is not necessarily true
(no PCI -> no VGA_ARB arbitration).


So it would need to at least be select VGA_ARB if (PCI && !S390)
in order to not have broken kernel configuration (in more or less
exotic cases) while depends on VGA_ARB would be the only correct option
if the rule 'select only allowed for leafs' is enforced.

Bruno

> Cc: Bruno Prémont 
> Signed-off-by: Henrik Rydberg 
> ---
> Hi Peter,
> 
> I stumbled upon this bug from the 3.17 merge window when updating to
> Linus's 3.18 git head yesterday. The patch has been tested on two
> different EFI machines; one that needs the patch and one that does not.
> 
> Thanks,
> Henrik
> 
>  drivers/video/fbdev/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c7bf606..81b21bc 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -761,6 +761,7 @@ config FB_EFI
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
> + select VGA_ARB
>   help
> This is the EFI frame buffer device driver. If the firmware on
> your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

[Bruno Prémont]

On Fri, 14 Nov 2014 13:53:30 +0100 Henrik Rydberg wrote:
 Since commit 20cde694027e (x86, ia64: Move EFI_FB
 vga_default_device() initialization to pci_vga_fixup()) in the 3.17
 merge window, the EFI framebuffer depends on the VGA arbitration
 layer. However, the configuration does not reflect this, which leads
 to a hard-to-find bug when FB_EFI is configured without VGA_ARB. Add a
 select clause to remedy this.

Could you be more verbose in why it depends on/needs VGA_ARB?

With EFI starting to show up on ARM this is not necessarily true
(no PCI - no VGA_ARB arbitration).


So it would need to at least be select VGA_ARB if (PCI  !S390)
in order to not have broken kernel configuration (in more or less
exotic cases) while depends on VGA_ARB would be the only correct option
if the rule 'select only allowed for leafs' is enforced.

Bruno

 Cc: Bruno Prémont bonb...@linux-vserver.org
 Signed-off-by: Henrik Rydberg rydb...@euromail.se
 ---
 Hi Peter,
 
 I stumbled upon this bug from the 3.17 merge window when updating to
 Linus's 3.18 git head yesterday. The patch has been tested on two
 different EFI machines; one that needs the patch and one that does not.
 
 Thanks,
 Henrik
 
  drivers/video/fbdev/Kconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
 index c7bf606..81b21bc 100644
 --- a/drivers/video/fbdev/Kconfig
 +++ b/drivers/video/fbdev/Kconfig
 @@ -761,6 +761,7 @@ config FB_EFI
   select FB_CFB_FILLRECT
   select FB_CFB_COPYAREA
   select FB_CFB_IMAGEBLIT
 + select VGA_ARB
   help
 This is the EFI frame buffer device driver. If the firmware on
 your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

[Bruno Prémont]

Hi Hendrick,

On Fri, 14 November 2014 Henrik Rydberg rydb...@euromail.se wrote:
  So it would need to at least be select VGA_ARB if (PCI  !S390)
  in order to not have broken kernel configuration (in more or less
  exotic cases) while depends on VGA_ARB would be the only correct option
  if the rule 'select only allowed for leafs' is enforced.
 
 Here is a tested patch that does just that, thanks for the suggestion.

Sure it will cover your case but with a few issues.

As you might have noted, VGA_ARB can only be disabled if you select
EXPERT. In that case you kind of give up warranty.

In addition, prior to the patches that landed in 3.17, just selecting
X86_SYSFB would runtime-disable EFI_FB disabling boot_vga tagging
based on screen_info as well.

Stating in the commit message that EFI_FB depends on VGA_ARB is pretty
wrong. A more correct phrasing would be that before the commit EFI_FB
included boot_vga detection which has been moved around, but that
feature is not inherent to EFI_FB. Doing the select only keeps
`make oldconfig` provide the same feature set.




As boot_vga is a PCI thing maybe the whole detection should effectively
be fully dissociated from runtime GPU switching and be adjusted to
really only flag the boot GPU (even when there is no VGA around).

Unfortunately this attribute is not explicitly documented so drawing the
line one way or another may trip on some user's feet.

We have some more or less conflicting information in commit messages though:

217f45de3d2 by Dave Airlie introducing boot_vgain 2009:
PCI: expose boot VGA device via sysfs.

X really would like to know which VGA device was considered the boot
device by the system. The x86 PCI fixups have support for discovering
this but we provide no way to expose it to userspace.

This adds a sysfs file per VGA class device which has the value 0 for
non the boot device or unknown, and 1 if the VGA device is the boot
device.

1a39b310e92 by Matthew Garrett making it variable in 2012:
vgaarb: Add support for setting the default video device (v2)

The default VGA device is a somewhat fluid concept on platforms with
multiple GPUs. Add support for setting it so switching code can update
things appropriately, and make sure that the sysfs code returns the right
device if it's changed.

So should boot_vga now represent the main GPU of the system or should
it represent the one(s) that were used for booting? (I've not heard
of systems with more than one active firmware GPU... but why not!

Matthew covered the case where multiple GPUs are in a set where only one
of them can be active as in driving displays. Maybe this would need some
alternative sysfs attribute kind of preferred_gpu.

Bruno


 From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
 From: Henrik Rydberg rydb...@euromail.se
 Date: Fri, 14 Nov 2014 20:01:21 +0100
 Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
 depends on the VGA arbitration layer. However, the configuration does
 not reflect this, which leads to a hard-to-find bug when FB_EFI is
 configured without VGA_ARB. Add a select clause to remedy this.
 
 Cc: Bruno Prémont bonb...@linux-vserver.org
 Signed-off-by: Henrik Rydberg rydb...@euromail.se
 ---
  drivers/video/fbdev/Kconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
 index c7bf606..1615a1b 100644
 --- a/drivers/video/fbdev/Kconfig
 +++ b/drivers/video/fbdev/Kconfig
 @@ -761,6 +761,7 @@ config FB_EFI
   select FB_CFB_FILLRECT
   select FB_CFB_COPYAREA
   select FB_CFB_IMAGEBLIT
 + select VGA_ARB if (PCI  !S390)
   help
 This is the EFI frame buffer device driver. If the firmware on
 your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/