Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
On Sun, May 27, 2018 at 07:48:47AM +0200, Marcus Folkesson wrote: > On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote: > > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > > > Signed-off-by: Marcus Folkesson > > > > I can't take patches without any changelog text. And why would you > > submit a patch over 1000 lines without any? > > I'm sorry, obviously not much went well for me yesterday. > The changlelog was "fixup:ed" away and now I noticed that my > patch version history did not follow for v2. > > Is it better to send a v3 with updated version history or wait for more > comments? Nah, that's fine, but I'll let Felipe decide as he is the one that has to review this, not me. thanks, greg k-h
Re: [PATCH] cpufreq: reinitialize new policy min/max when writing scaling_(max|min)_freq
Hi Kevin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kevin-Wangtao/cpufreq-reinitialize-new-policy-min-max-when-writing-scaling_-max-min-_freq/20180527-132510
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: i386-randconfig-x079-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/cpufreq/cpufreq.c: In function 'store_scaling_min_freq':
>> drivers/cpufreq/cpufreq.c:700:12: error: invalid type argument of '->' (have
>> 'struct cpufreq_policy')
new_policy->min = policy->user_policy.min; \
^
drivers/cpufreq/cpufreq.c:715:1: note: in expansion of macro 'store_one'
store_one(scaling_min_freq, min);
^
drivers/cpufreq/cpufreq.c:701:12: error: invalid type argument of '->' (have
'struct cpufreq_policy')
new_policy->max = policy->user_policy.max; \
^
drivers/cpufreq/cpufreq.c:715:1: note: in expansion of macro 'store_one'
store_one(scaling_min_freq, min);
^
drivers/cpufreq/cpufreq.c: In function 'store_scaling_max_freq':
>> drivers/cpufreq/cpufreq.c:700:12: error: invalid type argument of '->' (have
>> 'struct cpufreq_policy')
new_policy->min = policy->user_policy.min; \
^
drivers/cpufreq/cpufreq.c:716:1: note: in expansion of macro 'store_one'
store_one(scaling_max_freq, max);
^
drivers/cpufreq/cpufreq.c:701:12: error: invalid type argument of '->' (have
'struct cpufreq_policy')
new_policy->max = policy->user_policy.max; \
^
drivers/cpufreq/cpufreq.c:716:1: note: in expansion of macro 'store_one'
store_one(scaling_max_freq, max);
^
vim +700 drivers/cpufreq/cpufreq.c
685
686 static int cpufreq_set_policy(struct cpufreq_policy *policy,
687 struct cpufreq_policy *new_policy);
688
689 /**
690 * cpufreq_per_cpu_attr_write() / store_##file_name() - sysfs write
access
691 */
692 #define store_one(file_name, object)\
693 static ssize_t store_##file_name
\
694 (struct cpufreq_policy *policy, const char *buf, size_t count)
\
695 {
\
696 int ret, temp;
\
697 struct cpufreq_policy new_policy;
\
698
\
699 memcpy(&new_policy, policy, sizeof(*policy));
\
> 700 new_policy->min = policy->user_policy.min;
> \
701 new_policy->max = policy->user_policy.max;
\
702
\
703 ret = sscanf(buf, "%u", &new_policy.object);
\
704 if (ret != 1)
\
705 return -EINVAL;
\
706
\
707 temp = new_policy.object;
\
708 ret = cpufreq_set_policy(policy, &new_policy); \
709 if (!ret)
\
710 policy->user_policy.object = temp;
\
711
\
712 return ret ? ret : count;
\
713 }
714
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Sun, 27 May 2018, Michael Schmitz wrote: > That should have fixed the warning already ... It's still not fixed (hence my "acked-by" for Geunter's patch). --
Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote: > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > > Signed-off-by: Marcus Folkesson > > I can't take patches without any changelog text. And why would you > submit a patch over 1000 lines without any? I'm sorry, obviously not much went well for me yesterday. The changlelog was "fixup:ed" away and now I noticed that my patch version history did not follow for v2. Is it better to send a v3 with updated version history or wait for more comments? I'll start review my patches better before sending them. Thank you for your time and comments. > > Please fix. > > thanks, > > greg k-h
Re: net-next boot error: KASAN: use-after-free Write in call_usermodehelper_exec_work
On Sun, May 27, 2018 at 7:34 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:5b79c2af667c Merge git://git.kernel.org/pub/scm/linux/kern.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=16087fa780 > kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c > dashboard link: https://syzkaller.appspot.com/bug?extid=9269ae80345087b898d0 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+9269ae80345087b89...@syzkaller.appspotmail.com This first happened just now on net-next, so +net maintainers. This happened during boot, so no separate reproducer. > FS-Cache: Loaded > CacheFiles: Loaded > pnp: PnP ACPI init > pnp: PnP ACPI: found 7 devices > == > BUG: KASAN: use-after-free in call_usermodehelper_exec_work+0x2d3/0x310 > kernel/umh.c:195 > Write of size 4 at addr 8801d63bd370 by task kworker/u4:0/6 > > CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.17.0-rc6+ #65 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: events_unbound call_usermodehelper_exec_work > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > print_address_description+0x6c/0x20b mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 > __asan_report_store4_noabort+0x17/0x20 mm/kasan/report.c:437 > call_usermodehelper_exec_work+0x2d3/0x310 kernel/umh.c:195 > process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145 > worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279 > kthread+0x345/0x410 kernel/kthread.c:240 > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 > > Allocated by task 1: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 > kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620 > kmalloc include/linux/slab.h:512 [inline] > kzalloc include/linux/slab.h:701 [inline] > call_usermodehelper_setup+0xe8/0x400 kernel/umh.c:382 > clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: > 2085701024 ns > kobject_uevent_env+0xb21/0x1110 lib/kobject_uevent.c:608 > kobject_uevent+0x1f/0x30 lib/kobject_uevent.c:636 > device_add+0xb01/0x16d0 drivers/base/core.c:1843 > device_create_groups_vargs+0x1ff/0x270 drivers/base/core.c:2439 > device_create_vargs drivers/base/core.c:2479 [inline] > device_create+0xd3/0x100 drivers/base/core.c:2515 > chr_dev_init+0x120/0x158 drivers/char/mem.c:938 > do_one_initcall+0x127/0x913 init/main.c:884 > do_initcall_level init/main.c:952 [inline] > do_initcalls init/main.c:960 [inline] > do_basic_setup init/main.c:978 [inline] > kernel_init_freeable+0x49b/0x58e init/main.c:1135 > kernel_init+0x11/0x1b3 init/main.c:1061 > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 > > Freed by task 1296: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > NET: Registered protocol family 2 > set_track mm/kasan/kasan.c:460 [inline] > __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 > kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 > __cache_free mm/slab.c:3498 [inline] > kfree+0xd9/0x260 mm/slab.c:3813 > call_usermodehelper_freeinfo kernel/umh.c:45 [inline] > umh_complete+0x7b/0x90 kernel/umh.c:59 > call_usermodehelper_exec_async+0x6e8/0x9e0 kernel/umh.c:116 > tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes) > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 > > The buggy address belongs to the object at 8801d63bd300 > which belongs to the cache kmalloc-192 of size 192 > The buggy address is located 112 bytes inside of > 192-byte region [8801d63bd300, 8801d63bd3c0) > The buggy address belongs to the page: > TCP established hash table entries: 65536 (order: 7, 524288 bytes) > page:ea000758ef40 count:1 mapcount:0 mapping:8801d63bd000 index:0x0 > flags: 0x2fffc000100(slab) > raw: 02fffc000100 8801d63bd000 00010010 > TCP bind hash table entries: 65536 (order: 10, 4194304 bytes) > raw: ea000759c2e0 ea0007521be0 8801da800040 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8801d63bd200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8801d63bd280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >> >> 8801d63bd300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > > TCP: Hash tables configured (established 65536 bind 65536) > ^ > 8801d63bd380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc > 8801d63bd400: fb fb fb fb fb fb fb fb fb fb fb fb
net-next boot error: KASAN: use-after-free Write in call_usermodehelper_exec_work
Hello, syzbot found the following crash on: HEAD commit:5b79c2af667c Merge git://git.kernel.org/pub/scm/linux/kern.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=16087fa780 kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c dashboard link: https://syzkaller.appspot.com/bug?extid=9269ae80345087b898d0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+9269ae80345087b89...@syzkaller.appspotmail.com FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init pnp: PnP ACPI: found 7 devices == BUG: KASAN: use-after-free in call_usermodehelper_exec_work+0x2d3/0x310 kernel/umh.c:195 Write of size 4 at addr 8801d63bd370 by task kworker/u4:0/6 CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.17.0-rc6+ #65 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events_unbound call_usermodehelper_exec_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_store4_noabort+0x17/0x20 mm/kasan/report.c:437 call_usermodehelper_exec_work+0x2d3/0x310 kernel/umh.c:195 process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145 worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279 kthread+0x345/0x410 kernel/kthread.c:240 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Allocated by task 1: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620 kmalloc include/linux/slab.h:512 [inline] kzalloc include/linux/slab.h:701 [inline] call_usermodehelper_setup+0xe8/0x400 kernel/umh.c:382 clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 2085701024 ns kobject_uevent_env+0xb21/0x1110 lib/kobject_uevent.c:608 kobject_uevent+0x1f/0x30 lib/kobject_uevent.c:636 device_add+0xb01/0x16d0 drivers/base/core.c:1843 device_create_groups_vargs+0x1ff/0x270 drivers/base/core.c:2439 device_create_vargs drivers/base/core.c:2479 [inline] device_create+0xd3/0x100 drivers/base/core.c:2515 chr_dev_init+0x120/0x158 drivers/char/mem.c:938 do_one_initcall+0x127/0x913 init/main.c:884 do_initcall_level init/main.c:952 [inline] do_initcalls init/main.c:960 [inline] do_basic_setup init/main.c:978 [inline] kernel_init_freeable+0x49b/0x58e init/main.c:1135 kernel_init+0x11/0x1b3 init/main.c:1061 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Freed by task 1296: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 NET: Registered protocol family 2 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 call_usermodehelper_freeinfo kernel/umh.c:45 [inline] umh_complete+0x7b/0x90 kernel/umh.c:59 call_usermodehelper_exec_async+0x6e8/0x9e0 kernel/umh.c:116 tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes) ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 The buggy address belongs to the object at 8801d63bd300 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 112 bytes inside of 192-byte region [8801d63bd300, 8801d63bd3c0) The buggy address belongs to the page: TCP established hash table entries: 65536 (order: 7, 524288 bytes) page:ea000758ef40 count:1 mapcount:0 mapping:8801d63bd000 index:0x0 flags: 0x2fffc000100(slab) raw: 02fffc000100 8801d63bd000 00010010 TCP bind hash table entries: 65536 (order: 10, 4194304 bytes) raw: ea000759c2e0 ea0007521be0 8801da800040 page dumped because: kasan: bad access detected Memory state around the buggy address: 8801d63bd200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8801d63bd280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc 8801d63bd300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb TCP: Hash tables configured (established 65536 bind 65536) ^ 8801d63bd380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc 8801d63bd400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == UDP hash table entries: 4096 (order: 7, 655360 bytes) UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes) --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal
RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services
> > Assume some user requested to execute some non-blocking variant of > > efi_rts and the kernel hasn't called efi_call_virt() yet, but was > > scheduled out. IOW, even though user requests for non-blocking efi call, we > might still block. Am I right? > > > > No, that is the whole point. These functions may be called from atomic > context, > which is why they trylock() and give up rather than block on the semaphore if > a rt > services call is already in progress. E.g., > > /* > * efivar_entry_set_nonblocking - call set_variable_nonblocking() > * > * This function is guaranteed to not block and is suitable for calling > * from crash/panic handlers. > * > * Crucially, this function will not block if it cannot acquire > * efivars_lock. Instead, it returns -EBUSY. > */ > One more question again, if we are sure that non-blocking variants will _always_ be called in atomic context, then, we got it covered. Because, in set_variable() and query_variable_info() (both blocking and non-blocking) we check for in_atomic() and if so, we don't use efi_rts_wq (please refer to patch 3). If you think, there might be a probability of calling non-blocking efi_rts out of atomic context, then, sure! Let's make them never use efi_rts_wq. Regards, Sai
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi Finn,
was your patch to implement this in arch_setup_pdev_archdata() rejected?
That should have fixed the warning already ...
Am 27.05.2018 um 15:01 schrieb Finn Thain:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
>> following warning on driver initialization on Macintosh q800 systems.
>>
>> SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
>> [ cut here ]
>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
>> macsonic_init+0x6a/0x15a
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1
>> Stack from 0781fdd8:
>> 0781fdd8 003615b3 000181ba 05c4 07a24cbc
>> 20e8
>> 07a24800 002c196c 0001824e 00334c06 0204 001f782a 0009
>> 003358d9 001f782a 00334c06 0204 0003 07a24800
>> 002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 0003
>> 07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00
>> 07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 0007 0054d040 07845c0a
>> Call Trace: [<000181ba>] __warn+0xc0/0xc2
>> [<20e8>] do_one_initcall+0x0/0x140
>> [<0001824e>] warn_slowpath_null+0x26/0x2c
>> [<001f782a>] macsonic_init+0x6a/0x15a
>> [<001f782a>] macsonic_init+0x6a/0x15a
>> [<002b5cb6>] memcmp+0x0/0x2a
>> [<000372ec>] printk+0x0/0x18
>> [<001f8b1a>] mac_sonic_platform_probe+0x380/0x404
>>
>> As per the warning the coherent_dma_mask is not set on this device.
>> There is nothing special about the DMA memory coherency on this hardware
>> so we can just set the mask to 32bits in the platform data for the FEC
>> ethernet devices.
>>
>> Signed-off-by: Guenter Roeck
>
> Acked-by: Finn Thain
>
> Geert, assuming that Guenter's patch is acceptable, would you also accept
> a similar patch for the "macmace" platform device?
>
>> ---
>> Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform
>> FEC ethernets").
>>
>> RFC: Is "nothing special about the DMA memory coherency" correect ?
>>
>
> As I understand it, "cache-coherence" is meaningless unless you have
> multiple CPU cores and caches. If there's only one CPU core, its cache
> can't be said to be "coherent" or "non-coherent". Moreover, DMA (direct
> memory access) concerns an IO device and a memory, not a cache, so the
> term "coherent dma" is bogus IMHO.
DMA does concern the CPU cache insofar as (without explicit cache
maintenance) the CPU cache may hold stale data after a DMA write, or
data to be used in a DMA read may not have been written back from cache
to memory. As far as I understand it, the generic DMA API does handle
these cache maintenance aspects without a need for action at the driver
level. But you're correct that the question of coherent memory does not
arise on uniprocessor systems, so the whole warning could have been
avoided.
Unless 'coherent memory' in this context means no explicit cache
maintenance is required (CPU does bus snooping - which of our platforms
fully support that)?
Cheers,
Michael
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi,
On Sun, May 27, 2018 at 01:01:11PM +1000, Finn Thain wrote:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> > following warning on driver initialization on Macintosh q800 systems.
> >
> > SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
> > macsonic_init+0x6a/0x15a
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1
> > Stack from 0781fdd8:
> > 0781fdd8 003615b3 000181ba 05c4 07a24cbc
> > 20e8
> > 07a24800 002c196c 0001824e 00334c06 0204 001f782a 0009
> > 003358d9 001f782a 00334c06 0204 0003 07a24800
> > 002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 0003
> > 07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00
> > 07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 0007 0054d040 07845c0a
> > Call Trace: [<000181ba>] __warn+0xc0/0xc2
> > [<20e8>] do_one_initcall+0x0/0x140
> > [<0001824e>] warn_slowpath_null+0x26/0x2c
> > [<001f782a>] macsonic_init+0x6a/0x15a
> > [<001f782a>] macsonic_init+0x6a/0x15a
> > [<002b5cb6>] memcmp+0x0/0x2a
> > [<000372ec>] printk+0x0/0x18
> > [<001f8b1a>] mac_sonic_platform_probe+0x380/0x404
> >
> > As per the warning the coherent_dma_mask is not set on this device.
> > There is nothing special about the DMA memory coherency on this hardware
> > so we can just set the mask to 32bits in the platform data for the FEC
> > ethernet devices.
> >
> > Signed-off-by: Guenter Roeck
>
> Acked-by: Finn Thain
>
> Geert, assuming that Guenter's patch is acceptable, would you also accept
> a similar patch for the "macmace" platform device?
>
> > ---
> > Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform
> > FEC ethernets").
> >
> > RFC: Is "nothing special about the DMA memory coherency" correect ?
> >
>
> As I understand it, "cache-coherence" is meaningless unless you have
> multiple CPU cores and caches. If there's only one CPU core, its cache
Good point. Maybe it would be better to limit the warning to SMP systems
instead of (unnecessarily) fixing drivers all over the place ?
Guenter
---
>From 9eea0e1b609b69094682757285fd7f89d3930a8e Mon Sep 17 00:00:00 2001
From: Guenter Roeck
Date: Sat, 26 May 2018 21:08:39 -0700
Subject: [PATCH] dma-mapping: Warn about coherent_dma_mask only for SMP
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") is unconditional, even if the affected system
is a single-CPU system where coherence is irrelevant. Limit the
warning to SMP configurations to reduce the noise.
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Signed-off-by: Guenter Roeck
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0f589e..ffbb39d84797 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -513,7 +513,7 @@ static inline void *dma_alloc_attrs(struct device *dev,
size_t size,
void *cpu_addr;
BUG_ON(!ops);
- WARN_ON_ONCE(dev && !dev->coherent_dma_mask);
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_SMP) && dev && !dev->coherent_dma_mask);
if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr))
return cpu_addr;
--
2.7.4
Re: [PATCH] powerpc/64s: Clear PCR on boot
Hi Michael, On Sun, May 27, 2018 at 12:22:23PM +1000, Michael Ellerman wrote: > > > On 25 May 2018 11:33:08 pm AEST, Guenter Roeck wrote: > >On Fri, May 18, 2018 at 11:37:42AM +1000, Michael Neuling wrote: > >> Clear the PCR (Processor Compatibility Register) on boot to ensure we > >> are not running in a compatibility mode. > >> > >> We've seen this cause problems when a crash (and kdump) occurs while > >> running compat mode guests. The kdump kernel then runs with the PCR > >> set and causes problems. The symptom in the kdump kernel (also seen > >in > >> petitboot after fast-reboot) is early userspace programs taking > >> sigills on newer instructions (seen in libc). > >> > > > >Hi folks, > > > >this patch causes qemu to bail out with > > > >Trying to write privileged spr 338 (0x152) at c0033454 > > > >when running it with "-M powernv -cpu POWER8" and powernv_defconfig. > > > >Can you confirm that this is a bug in qemu ? > > Hi Guenter, > > Thanks for the report. As far as I'm concerned this is a qemu bug, that > register should exist on a bare metal Power8. > > Will try and get you a qemu patch to fix it. > I already have a patch, or at least one that does the trick for me. Getting qemu patched was not the problem. I just want to be sure that the problem is indeed a qemu problem. Thanks, Guenter --- >From 1617bac264b4c49d817b6947611affa9b73318f6 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 25 May 2018 06:38:40 -0700 Subject: [PATCH] PowerPC: Permit privileged access to SPR_PCR for POWER7+ Without this access, Linux mainline bails out. Signed-off-by: Guenter Roeck --- target/ppc/translate_init.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c index 391b94b..3b09c49 100644 --- a/target/ppc/translate_init.c +++ b/target/ppc/translate_init.c @@ -7953,11 +7953,12 @@ static void gen_spr_power6_common(CPUPPCState *env) #endif /* * Register PCR to report POWERPC_EXCP_PRIV_REG instead of - * POWERPC_EXCP_INVAL_SPR. + * POWERPC_EXCP_INVAL_SPR in userspace. Permit privileged + * access. */ spr_register(env, SPR_PCR, "PCR", SPR_NOACCESS, SPR_NOACCESS, - SPR_NOACCESS, SPR_NOACCESS, + &spr_read_generic, &spr_write_generic, 0x); } -- 2.7.4
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Sat, 26 May 2018, Guenter Roeck wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> following warning on driver initialization on Macintosh q800 systems.
>
> SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
> macsonic_init+0x6a/0x15a
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1
> Stack from 0781fdd8:
> 0781fdd8 003615b3 000181ba 05c4 07a24cbc
> 20e8
> 07a24800 002c196c 0001824e 00334c06 0204 001f782a 0009
> 003358d9 001f782a 00334c06 0204 0003 07a24800
> 002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 0003
> 07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00
> 07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 0007 0054d040 07845c0a
> Call Trace: [<000181ba>] __warn+0xc0/0xc2
> [<20e8>] do_one_initcall+0x0/0x140
> [<0001824e>] warn_slowpath_null+0x26/0x2c
> [<001f782a>] macsonic_init+0x6a/0x15a
> [<001f782a>] macsonic_init+0x6a/0x15a
> [<002b5cb6>] memcmp+0x0/0x2a
> [<000372ec>] printk+0x0/0x18
> [<001f8b1a>] mac_sonic_platform_probe+0x380/0x404
>
> As per the warning the coherent_dma_mask is not set on this device.
> There is nothing special about the DMA memory coherency on this hardware
> so we can just set the mask to 32bits in the platform data for the FEC
> ethernet devices.
>
> Signed-off-by: Guenter Roeck
Acked-by: Finn Thain
Geert, assuming that Guenter's patch is acceptable, would you also accept
a similar patch for the "macmace" platform device?
> ---
> Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform
> FEC ethernets").
>
> RFC: Is "nothing special about the DMA memory coherency" correect ?
>
As I understand it, "cache-coherence" is meaningless unless you have
multiple CPU cores and caches. If there's only one CPU core, its cache
can't be said to be "coherent" or "non-coherent". Moreover, DMA (direct
memory access) concerns an IO device and a memory, not a cache, so the
term "coherent dma" is bogus IMHO.
--
> arch/m68k/mac/config.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
> index 0c3275aa0197..8e0476daddb8 100644
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> /* keyb */
> #include
> #include
> @@ -971,6 +972,15 @@ static const struct resource mac_scsi_ccl_rsrc[]
> __initconst = {
> },
> };
>
> +static struct platform_device macsonic_dev = {
> + .name = "macsonic",
> + .id = -1,
> + .dev= {
> + .dma_mask = &macsonic_dev.dev.coherent_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + },
> +};
> +
> int __init mac_platform_init(void)
> {
> u8 *swim_base;
> @@ -1088,7 +1098,7 @@ int __init mac_platform_init(void)
>
> if (macintosh_config->ether_type == MAC_ETHER_SONIC ||
> macintosh_config->expansion_type == MAC_EXP_PDS_COMM)
> - platform_device_register_simple("macsonic", -1, NULL, 0);
> + platform_device_register(&macsonic_dev);
>
> if (macintosh_config->expansion_type == MAC_EXP_PDS ||
> macintosh_config->expansion_type == MAC_EXP_PDS_COMM)
> --
> 2.7.4
>
Re: [PATCH] bdi: Fix another oops in wb_workfn()
On Sun, May 27, 2018 at 11:21:25AM +0900, Tetsuo Handa wrote: > From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Sun, 27 May 2018 11:08:20 +0900 > Subject: [PATCH] bdi: Fix another oops in wb_workfn() > > syzbot is still hitting NULL pointer dereference at wb_workfn() [1]. > This might be because we overlooked that delayed_work_timer_fn() does not > check WB_registered before calling __queue_work() while mod_delayed_work() > does not wait for already started delayed_work_timer_fn() because it uses > del_timer() rather than del_timer_sync(). It shouldn't be that as dwork timer is an irq safe timer. Even if that's the case, the right thing to do would be fixing workqueue rather than reaching into workqueue internals from backing-dev code. Thanks. -- tejun
[RFC PATCH] regulator: bd71837: buck_7_volts[] can be static
Fixes: 9ebaeaf21446 ("regulator: bd71837: Build BD71837 regulator driver")
Signed-off-by: kbuild test robot
---
bd71837-regulator.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/bd71837-regulator.c
b/drivers/regulator/bd71837-regulator.c
index e6c3fa7..d48b71c 100644
--- a/drivers/regulator/bd71837-regulator.c
+++ b/drivers/regulator/bd71837-regulator.c
@@ -207,7 +207,7 @@ static const struct regulator_linear_range
bd71837_buck6_voltage_ranges[] = {
* 110 = 1.95V
* 111 = 1.995V
*/
-const unsigned int buck_7_volts[] = {
+static const unsigned int buck_7_volts[] = {
1605000, 1695000, 1755000, 180, 1845000, 1905000, 195, 1995000
};
@@ -232,7 +232,7 @@ static const struct regulator_linear_range
bd71837_ldo1_voltage_ranges[] = {
* LDO2
* 0.8 or 0.9V
*/
-const unsigned int ldo_2_volts[] = {
+static const unsigned int ldo_2_volts[] = {
90, 80
};
Re: [PATCH 9/9] regulator: bd71837: Build BD71837 regulator driver
Hi Matti, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ljones-mfd/for-mfd-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Matti-Vaittinen/mfd-regulator-clk-bd71837-ROHM-BD71837-PMIC-driver/20180526-192351 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] bdi: Fix another oops in wb_workfn()
>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sun, 27 May 2018 11:08:20 +0900 Subject: [PATCH] bdi: Fix another oops in wb_workfn() syzbot is still hitting NULL pointer dereference at wb_workfn() [1]. This might be because we overlooked that delayed_work_timer_fn() does not check WB_registered before calling __queue_work() while mod_delayed_work() does not wait for already started delayed_work_timer_fn() because it uses del_timer() rather than del_timer_sync(). Make wb_shutdown() be careful about wb_wakeup_delayed() path. [1] https://syzkaller.appspot.com/bug?id=e0818ccb7e46190b3f1038b0c794299208ed4206 Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Tejun Heo Cc: Dave Chinner Cc: Jan Kara Cc: Jens Axboe --- mm/backing-dev.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/mm/backing-dev.c b/mm/backing-dev.c index 7441bd9..31e1d7e 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -372,11 +372,24 @@ static void wb_shutdown(struct bdi_writeback *wb) cgwb_remove_from_bdi_list(wb); /* +* mod_delayed_work() is not appropriate here, for +* delayed_work_timer_fn() from wb_wakeup_delayed() does not check +* WB_registered before calling __queue_work(). +*/ + del_timer_sync(&wb->dwork.timer); + /* +* Clear WORK_STRUCT_PENDING_BIT in order to make sure that next +* queue_delayed_work() actually enqueues this work to the tail, for +* wb_wakeup_delayed() already set WORK_STRUCT_PENDING_BIT before +* scheduling delayed_work_timer_fn(). +*/ + cancel_delayed_work_sync(&wb->dwork); + /* * Drain work list and shutdown the delayed_work. !WB_registered * tells wb_workfn() that @wb is dying and its work_list needs to * be drained no matter what. */ - mod_delayed_work(bdi_wq, &wb->dwork, 0); + queue_delayed_work(bdi_wq, &wb->dwork, 0); flush_delayed_work(&wb->dwork); WARN_ON(!list_empty(&wb->work_list)); /* -- 1.8.3.1
Re: [PATCH] powerpc/64s: Clear PCR on boot
On 25 May 2018 11:33:08 pm AEST, Guenter Roeck wrote: >On Fri, May 18, 2018 at 11:37:42AM +1000, Michael Neuling wrote: >> Clear the PCR (Processor Compatibility Register) on boot to ensure we >> are not running in a compatibility mode. >> >> We've seen this cause problems when a crash (and kdump) occurs while >> running compat mode guests. The kdump kernel then runs with the PCR >> set and causes problems. The symptom in the kdump kernel (also seen >in >> petitboot after fast-reboot) is early userspace programs taking >> sigills on newer instructions (seen in libc). >> > >Hi folks, > >this patch causes qemu to bail out with > >Trying to write privileged spr 338 (0x152) at c0033454 > >when running it with "-M powernv -cpu POWER8" and powernv_defconfig. > >Can you confirm that this is a bug in qemu ? Hi Guenter, Thanks for the report. As far as I'm concerned this is a qemu bug, that register should exist on a bare metal Power8. Will try and get you a qemu patch to fix it. cheers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
On Sat, May 26, 2018 at 5:32 PM Kees Cook wrote: > I went through some old threads from 2012 when e268337dfe26 was > introduced, and later when things got looked at during DirtyCOW. There > was discussion about removing FOLL_FORCE (in order to block writes on > a read-only memory region). Side note, we did that for /dev/mem, and things broke. Thus commit f511c0b17b08 "Yes, people use FOLL_FORCE ;)" Side note, that very sam ecommit f511c0b17b08 is also the explanation for why the patch under discussion now seems broken. People really do use "write to /proc/self/mem" as a way to keep the mappings read-only, but have a way to change them when required. Linus
Re: [PATCH, net-next] qcom-emag: hide ACPI specific functions
On 5/25/18 7:22 PM, Timur Tabi wrote: -phy->open = emac_sgmii_open; -phy->close = emac_sgmii_close; -phy->link_up = emac_sgmii_link_up; -phy->link_down = emac_sgmii_link_down; I'll take it look at it next week when I'm back in the office. I posted a patch that fixes this problem and also retains device-tree support. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 1/2] x86/numa_emulation: Fix emulated-to-physical node mapping
Without this change the distance table calculation for emulated nodes
may use the wrong numa node and report an incorrect distance.
Cc: Wei Yang
Cc: David Rientjes
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc:
Signed-off-by: Dan Williams
---
arch/x86/mm/numa_emulation.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index 34a2a3bfde9c..22cbad56acab 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -61,7 +61,7 @@ static int __init emu_setup_memblk(struct numa_meminfo *ei,
eb->nid = nid;
if (emu_nid_to_phys[nid] == NUMA_NO_NODE)
- emu_nid_to_phys[nid] = nid;
+ emu_nid_to_phys[nid] = pb->nid;
pb->start += size;
if (pb->start >= pb->end) {
[PATCH 0/2] x86/numa_emulation: Introduce uniform split capability
The current numa emulation capabilities for splitting System RAM by a fixed size or by a set number of nodes may result in some nodes being larger than others. The implementation prioritizes establishing a minimum usable memory size over satisfying the requested number of numa nodes. Introduce a uniform split capability that evenly partitions each physical numa node into N emulated nodes. For example numa=fake=3U creates 6 emulated nodes total on a system that has 2 physical nodes. This capability is useful for debugging and evaluating platform memory-side-cache capabilities as described by the ACPI HMAT (see 5.2.27.5 Memory Side Cache Information Structure in ACPI 6.2a) See more details in patch2. --- Dan Williams (2): x86/numa_emulation: Fix emulated-to-physical node mapping x86/numa_emulation: Introduce uniform split capability Documentation/x86/x86_64/boot-options.txt |4 + arch/x86/mm/numa_emulation.c | 98 +++-- 2 files changed, 82 insertions(+), 20 deletions(-)
[PATCH 2/2] x86/numa_emulation: Introduce uniform split capability
The current numa emulation capabilities for splitting System RAM by a
fixed size or by a set number of nodes may result in some nodes being
larger than others. The implementation prioritizes establishing a
minimum usable memory size over satisfying the requested number of numa
nodes.
Introduce a uniform split capability that evenly partitions each
physical numa node into N emulated nodes. For example numa=fake=3U
creates 6 emulated nodes total on a system that has 2 physical nodes.
This capability is useful for debugging and evaluating platform
memory-side-cache capabilities as described by the ACPI HMAT (see
5.2.27.5 Memory Side Cache Information Structure in ACPI 6.2a)
Compare numa=fake=6 that results in only 5 nodes being created against
numa=fake=3U which takes the 2 physical nodes and evenly divides them.
numa=fake=6
available: 5 nodes (0-4)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
node 0 size: 2648 MB
node 0 free: 2443 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 1 size: 2672 MB
node 1 free: 2442 MB
node 2 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
node 2 size: 5291 MB
node 2 free: 5278 MB
node 3 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 3 size: 2677 MB
node 3 free: 2665 MB
node 4 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 4 size: 2676 MB
node 4 free: 2663 MB
node distances:
node 0 1 2 3 4
0: 10 20 10 20 20
1: 20 10 20 10 10
2: 10 20 10 20 20
3: 20 10 20 10 10
4: 20 10 20 10 10
numa=fake=3U
# numactl --hardware
available: 6 nodes (0-5)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
node 0 size: 2900 MB
node 0 free: 2637 MB
node 1 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
node 1 size: 3023 MB
node 1 free: 3012 MB
node 2 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
node 2 size: 2015 MB
node 2 free: 2004 MB
node 3 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 3 size: 2704 MB
node 3 free: 2522 MB
node 4 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 4 size: 2709 MB
node 4 free: 2698 MB
node 5 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
node 5 size: 2612 MB
node 5 free: 2601 MB
node distances:
node 0 1 2 3 4 5
0: 10 10 10 20 20 20
1: 10 10 10 20 20 20
2: 10 10 10 20 20 20
3: 20 20 20 10 10 10
4: 20 20 20 10 10 10
5: 20 20 20 10 10 10
Cc: Wei Yang
Cc: David Rientjes
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc:
Signed-off-by: Dan Williams
---
Documentation/x86/x86_64/boot-options.txt |4 +
arch/x86/mm/numa_emulation.c | 96 +++--
2 files changed, 81 insertions(+), 19 deletions(-)
diff --git a/Documentation/x86/x86_64/boot-options.txt
b/Documentation/x86/x86_64/boot-options.txt
index b297c48389b9..d1332609a17e 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -156,6 +156,10 @@ NUMA
If given as an integer, fills all system RAM with N fake nodes
interleaved over physical nodes.
+ numa=fake=U
+ If given as an integer followed by 'U', it will divide each
+ physical node into N emulated nodes.
+
ACPI
acpi=off Don't enable ACPI
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index 22cbad56acab..039db00541b7 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -204,34 +204,58 @@ static u64 __init find_end_of_node(u64 start, u64
max_addr, u64 size)
*
* Returns zero on success or negative on error.
*/
-static int __init split_nodes_size_interleave(struct numa_meminfo *ei,
+static int __init split_nodes_size_interleave_uniform(struct numa_meminfo *ei,
struct numa_meminfo *pi,
- u64 addr, u64 max_addr, u64 size)
+ u64 addr, u64 max_addr, u64 size,
+ int nr_nodes, struct numa_memblk
*pblk,
+ int nid)
{
nodemask_t physnode_mask = numa_nodes_parsed;
+ int i, ret, uniform = 0;
u64 min_size;
- int nid = 0;
- int i, ret;
- if (!size)
+ if ((!size && !nr_nodes) || (nr_nodes && !pblk))
return -1;
+
/*
-* The limit on emulated nodes is MAX_NUMNODES, so the size per node is
-* increased accordingly if the requested size is too small. This
-* creates a uniform distribution of node sizes across the entire
-* machine (but not necessarily over physical nodes).
+* In the 'uniform' case split the passed in physical node by
+* nr_nodes, in the non-uniform case, ignore the passed in
+* physical blo
Re: WARNING: bad usercopy in __kvm_write_guest_page
On Sat, May 26, 2018 at 10:42 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:73fcb1a370c7 Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b3a82780
> kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
> dashboard link: https://syzkaller.appspot.com/bug?extid=083f3b88782aa3a46bdb
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1027dbcf80
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=159eff9780
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+083f3b88782aa3a46...@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> [ cut here ]
> Bad or missing usercopy whitelist? Kernel memory exposure attempt detected
> from SLAB object 'kvm_vcpu' (offset 23192, size 8)!
Looks like something else besides the "arch" field is being copied
in/out of struct kvm_vcpu? (Also, whoa, 22K struct?) Oh, in looking, I
assume it's something in struct vcpu_vmx ?
(i.e. this is not fixed by 46515736f8687 ("kvm: whitelist struct
kvm_vcpu_arch").)
Looks like this is:
if (kvm_write_guest_virt_system(&vcpu->arch.emulate_ctxt, vmcs_gva,
(void *)&to_vmx(vcpu)->nested.current_vmptr,
sizeof(u64), &e)) {
... this is a fixed size, but it looks like it gets down to the
copy_*_user() as a variable so automatically whitelisting is
happening. :(
-Kees
> WARNING: CPU: 0 PID: 4554 at mm/usercopy.c:81 usercopy_warn+0xf5/0x120
> mm/usercopy.c:76
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 4554 Comm: syz-executor726 Not tainted 4.17.0-rc5+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> panic+0x22f/0x4de kernel/panic.c:184
> __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:usercopy_warn+0xf5/0x120 mm/usercopy.c:76
> RSP: 0018:8801ad54f0b0 EFLAGS: 00010286
> RAX: 007e RBX: 889d52f0 RCX: 8160aa5d
> RDX: RSI: 8160f711 RDI: 8801ad54ec10
> RBP: 8801ad54f110 R08: 8801d96c8680 R09: 0006
> R10: 8801d96c8680 R11: R12: 87d2fa60
> R13: 87c19ec0 R14: R15: 0008
> __check_heap_object+0x89/0xb5 mm/slab.c:4440
> check_heap_object mm/usercopy.c:236 [inline]
> __check_object_size+0x4c7/0x5d9 mm/usercopy.c:259
> check_object_size include/linux/thread_info.h:108 [inline]
> __copy_to_user include/linux/uaccess.h:104 [inline]
> __kvm_write_guest_page+0x90/0x140
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:1828
> kvm_vcpu_write_guest_page arch/x86/kvm/../../../virt/kvm/kvm_main.c:1849
> [inline]
> kvm_vcpu_write_guest+0x65/0xe0
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:1883
> kvm_write_guest_virt_system+0x8a/0x190 arch/x86/kvm/x86.c:4843
> handle_vmptrst+0x1d2/0x260 arch/x86/kvm/vmx.c:8196
> vmx_handle_exit+0x2c0/0x17b0 arch/x86/kvm/vmx.c:9234
> vcpu_enter_guest+0x13af/0x6060 arch/x86/kvm/x86.c:7503
> vcpu_run arch/x86/kvm/x86.c:7565 [inline]
> kvm_arch_vcpu_ioctl_run+0x33e/0x1690 arch/x86/kvm/x86.c:7742
> kvm_vcpu_ioctl+0x79d/0x12e0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2560
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:500 [inline]
> do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
> __do_sys_ioctl fs/ioctl.c:708 [inline]
> __se_sys_ioctl fs/ioctl.c:706 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x443039
> RSP: 002b:7ffc272242b8 EFLAGS: 0286 ORIG_RAX: 0010
> RAX: ffda RBX: 004002c8 RCX: 00443039
> RDX: RSI: ae80 RDI: 0005
> RBP: 006cd018 R08: 2580 R09: 2580
> R10: R11: 0286 R12: 00404080
> R13: 00404110 R14: R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot enginee
Re: general protection fault in wb_workfn (2)
Forwarding
http://lkml.kernel.org/r/201805251915.fgh64517.hvfjoolffmq...@i-love.sakura.ne.jp
.
Jan Kara wrote:
> > void delayed_work_timer_fn(struct timer_list *t)
> > {
> > struct delayed_work *dwork = from_timer(dwork, t, timer);
> >
> > /* should have been called from irqsafe timer with irq already off */
> > __queue_work(dwork->cpu, dwork->wq, &dwork->work);
> > }
> >
> > Then, wb_workfn() is after all scheduled even if we check for
> > WB_registered bit, isn't it?
>
> It can be queued after WB_registered bit is cleared but it cannot be queued
> after mod_delayed_work(bdi_wq, &wb->dwork, 0) has finished. That function
> deletes the pending timer (the timer cannot be armed again because
> WB_registered is cleared) and queues what should be the last round of
> wb_workfn().
mod_delayed_work() deletes the pending timer but does not wait for already
invoked timer handler to complete because it is using del_timer() rather than
del_timer_sync(). Then, what happens if __queue_work() is almost concurrently
executed from two CPUs, one from mod_delayed_work(bdi_wq, &wb->dwork, 0) from
wb_shutdown() path (which is called without spin_lock_bh(&wb->work_lock)) and
the other from delayed_work_timer_fn() path (which is called without checking
WB_registered bit under spin_lock_bh(&wb->work_lock)) ?
wb_wakeup_delayed() {
spin_lock_bh(&wb->work_lock);
if (test_bit(WB_registered, &wb->state)) // succeeds
queue_delayed_work(bdi_wq, &wb->d_work, timeout) {
queue_delayed_work_on(WORK_CPU_UNBOUND, bdi_wq, &wb->d_work, timeout) {
if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT,
work_data_bits(&wb->d_work.work))) { // succeeds
__queue_delayed_work(WORK_CPU_UNBOUND, bdi_wq, &wb->d_work, timeout)
{
add_timer(timer); // schedules for delayed_work_timer_fn()
}
}
}
}
spin_unlock_bh(&wb->work_lock);
}
delayed_work_timer_fn() {
// del_timer() already returns false at this point because this timer
// is already inside handler. But something took long here enough to
// wait for __queue_work() from wb_shutdown() path to finish?
__queue_work(WORK_CPU_UNBOUND, bdi_wq, &wb->d_work.work) {
insert_work(pwq, work, worklist, work_flags);
}
}
wb_shutdown() {
mod_delayed_work(bdi_wq, &wb->dwork, 0) {
mod_delayed_work_on(WORK_CPU_UNBOUND, bdi_wq, &wb->dwork, 0) {
ret = try_to_grab_pending(&wb->dwork.work, true, &flags) {
if (likely(del_timer(&wb->dwork.timer))) // fails because already in
delayed_work_timer_fn()
return 1;
if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT,
work_data_bits(&wb->dwork.work))) // fails because already set by
queue_delayed_work()
return 0;
// Returns 1 or -ENOENT after doing something?
}
if (ret >= 0)
__queue_delayed_work(WORK_CPU_UNBOUND, bdi_wq, &wb->dwork, 0) {
__queue_work(WORK_CPU_UNBOUND, bdi_wq, &wb->dwork.work) {
insert_work(pwq, work, worklist, work_flags);
}
}
}
}
}
[PATCH v3] gpu: drm: gma500: Change return type to vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_{pfn,mixed} returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_{pfn,mixed} will replace this inefficiency by
returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
v2: updated the change log
v3: Fixed kbuild error
drivers/gpu/drm/gma500/framebuffer.c | 14 +-
drivers/gpu/drm/gma500/gem.c | 27 ++-
drivers/gpu/drm/gma500/psb_drv.h | 3 ++-
3 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae..632aadb 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -111,7 +111,7 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct
fb_info *info)
return 0;
}
-static int psbfb_vm_fault(struct vm_fault *vmf)
+static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct psb_framebuffer *psbfb = vma->vm_private_data;
@@ -120,7 +120,7 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
int page_num;
int i;
unsigned long address;
- int ret;
+ vm_fault_t ret = VM_FAULT_SIGBUS;
unsigned long pfn;
unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
psbfb->gtt->offset;
@@ -133,18 +133,14 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
for (i = 0; i < page_num; i++) {
pfn = (phys_addr >> PAGE_SHIFT);
- ret = vm_insert_mixed(vma, address,
+ ret = vmf_insert_mixed(vma, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
- if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+ if (unlikely(ret & VM_FAULT_ERROR))
break;
- else if (unlikely(ret != 0)) {
- ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
- return ret;
- }
address += PAGE_SIZE;
phys_addr += PAGE_SIZE;
}
- return VM_FAULT_NOPAGE;
+ return ret;
}
static void psbfb_vm_open(struct vm_area_struct *vma)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 1312397..e7be5c9 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -134,12 +134,13 @@ int psb_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
* vma->vm_private_data points to the GEM object that is backing this
* mapping.
*/
-int psb_gem_fault(struct vm_fault *vmf)
+vm_fault_t psb_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj;
struct gtt_range *r;
- int ret;
+ int err;
+ vm_fault_t ret;
unsigned long pfn;
pgoff_t page_offset;
struct drm_device *dev;
@@ -158,9 +159,10 @@ int psb_gem_fault(struct vm_fault *vmf)
/* For now the mmap pins the object and it stays pinned. As things
stand that will do us no harm */
if (r->mmapping == 0) {
- ret = psb_gtt_pin(r);
- if (ret < 0) {
- dev_err(dev->dev, "gma500: pin failed: %d\n", ret);
+ err = psb_gtt_pin(r);
+ if (err < 0) {
+ dev_err(dev->dev, "gma500: pin failed: %d\n", err);
+ ret = vmf_error(err);
goto fail;
}
r->mmapping = 1;
@@ -175,18 +177,9 @@ int psb_gem_fault(struct vm_fault *vmf)
pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
else
pfn = page_to_pfn(r->pages[page_offset]);
- ret = vm_insert_pfn(vma, vmf->address, pfn);
-
+ ret = vmf_insert_pfn(vma, vmf->address, pfn);
fail:
mutex_unlock(&dev_priv->mmap_mutex);
- switch (ret) {
- case 0:
- case -ERESTARTSYS:
- case -EINTR:
- return VM_FAULT_NOPAGE;
- case -ENOMEM:
- return VM_FAULT_OOM;
- default:
- return VM_FAULT_SIGBUS;
- }
+
+ return ret;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e8300f5..93d2f40 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -21,6 +21,7 @@
#define _PSB_DRV_H_
#include
+#include
#include
#include
@@ -749,7 +750,7 @@ extern int psb_gem_get_aperture(struct drm_device *dev,
void
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
On Sat, May 26, 2018 at 7:50 AM, Salvatore Mesoraca
wrote:
> Prevent a task from opening, in "write" mode, any /proc/*/mem
> file that operates on the task's mm.
> /proc/*/mem is mainly a debugging means and, as such, it shouldn't
> be used by the inspected process itself.
> Current implementation always allow a task to access its own
> /proc/*/mem file.
> A process can use it to overwrite read-only memory, making
> pointless the use of security_file_mprotect() or other ways to
> enforce RO memory.
I went through some old threads from 2012 when e268337dfe26 was
introduced, and later when things got looked at during DirtyCOW. There
was discussion about removing FOLL_FORCE (in order to block writes on
a read-only memory region). But that was much more general, touched
ptrace, etc. I think this patch would be okay, since it's specific to
the proc "self" mem interface, not remote processes (via ptrace). This
patch would also have blocked the /proc/self/mem path to DirtyCOW
(though not ptrace), so that would be nice if we have similar issues
in the future. So, as long as this doesn't break anything, I'm for it
in general. I've CCed Linus and Jann too, since they've stared at this
a lot too. :P
Note that you're re-checking the mm-check-for-self in mm_access().
That's used in /proc and for process_vm_write(). Ptrace (and
mm_access()) uses ptrace_may_access() for stuff (which has a similar
check to bypass LSMs), so I'd be curious what would happen if this
logic was plumbed into mm_access() instead of into proc_mem_open().
(Does anything open /proc/$pid files for writing? Does anything using
process_vm_write() on itself?)
-Kees
>
> Signed-off-by: Salvatore Mesoraca
> ---
> fs/proc/base.c | 25 ++---
> fs/proc/internal.h | 3 ++-
> fs/proc/task_mmu.c | 4 ++--
> fs/proc/task_nommu.c | 2 +-
> 4 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 1a76d75..01ecfec 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -762,8 +762,9 @@ static int proc_single_open(struct inode *inode, struct
> file *filp)
> .release= single_release,
> };
>
> -
> -struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode)
> +struct mm_struct *proc_mem_open(struct inode *inode,
> + unsigned int mode,
> + fmode_t f_mode)
> {
> struct task_struct *task = get_proc_task(inode);
> struct mm_struct *mm = ERR_PTR(-ESRCH);
> @@ -773,10 +774,20 @@ struct mm_struct *proc_mem_open(struct inode *inode,
> unsigned int mode)
> put_task_struct(task);
>
> if (!IS_ERR_OR_NULL(mm)) {
> - /* ensure this mm_struct can't be freed */
> - mmgrab(mm);
> - /* but do not pin its memory */
> - mmput(mm);
> + /*
> +* Prevent this interface from being used as a mean
> +* to bypass memory restrictions, including those
> +* imposed by LSMs.
> +*/
> + if (mm == current->mm &&
> + f_mode & FMODE_WRITE)
> + mm = ERR_PTR(-EACCES);
> + else {
> + /* ensure this mm_struct can't be freed */
> + mmgrab(mm);
> + /* but do not pin its memory */
> + mmput(mm);
> + }
> }
> }
>
> @@ -785,7 +796,7 @@ struct mm_struct *proc_mem_open(struct inode *inode,
> unsigned int mode)
>
> static int __mem_open(struct inode *inode, struct file *file, unsigned int
> mode)
> {
> - struct mm_struct *mm = proc_mem_open(inode, mode);
> + struct mm_struct *mm = proc_mem_open(inode, mode, file->f_mode);
>
> if (IS_ERR(mm))
> return PTR_ERR(mm);
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index 0f1692e..8d38cc7 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -275,7 +275,8 @@ struct proc_maps_private {
> #endif
> } __randomize_layout;
>
> -struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
> +struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode,
> + fmode_t f_mode);
>
> extern const struct file_operations proc_pid_maps_operations;
> extern const struct file_operations proc_tid_maps_operations;
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index c486ad4..efb6535 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -227,7 +227,7 @@ static int proc_maps_open(struct inode *inode, struct
> file *file,
> return -ENOMEM;
>
> priv->inode = inode;
> - priv->mm = proc_mem_open(inode, PTRACE_MODE_READ);
> + priv->mm
[RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
following warning on driver initialization on Macintosh q800 systems.
SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
[ cut here ]
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
macsonic_init+0x6a/0x15a
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1
Stack from 0781fdd8:
0781fdd8 003615b3 000181ba 05c4 07a24cbc 20e8
07a24800 002c196c 0001824e 00334c06 0204 001f782a 0009
003358d9 001f782a 00334c06 0204 0003 07a24800
002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 0003
07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00
07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 0007 0054d040 07845c0a
Call Trace: [<000181ba>] __warn+0xc0/0xc2
[<20e8>] do_one_initcall+0x0/0x140
[<0001824e>] warn_slowpath_null+0x26/0x2c
[<001f782a>] macsonic_init+0x6a/0x15a
[<001f782a>] macsonic_init+0x6a/0x15a
[<002b5cb6>] memcmp+0x0/0x2a
[<000372ec>] printk+0x0/0x18
[<001f8b1a>] mac_sonic_platform_probe+0x380/0x404
As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.
Signed-off-by: Guenter Roeck
---
Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform
FEC ethernets").
RFC: Is "nothing special about the DMA memory coherency" correect ?
arch/m68k/mac/config.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 0c3275aa0197..8e0476daddb8 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
/* keyb */
#include
#include
@@ -971,6 +972,15 @@ static const struct resource mac_scsi_ccl_rsrc[]
__initconst = {
},
};
+static struct platform_device macsonic_dev = {
+ .name = "macsonic",
+ .id = -1,
+ .dev= {
+ .dma_mask = &macsonic_dev.dev.coherent_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
int __init mac_platform_init(void)
{
u8 *swim_base;
@@ -1088,7 +1098,7 @@ int __init mac_platform_init(void)
if (macintosh_config->ether_type == MAC_ETHER_SONIC ||
macintosh_config->expansion_type == MAC_EXP_PDS_COMM)
- platform_device_register_simple("macsonic", -1, NULL, 0);
+ platform_device_register(&macsonic_dev);
if (macintosh_config->expansion_type == MAC_EXP_PDS ||
macintosh_config->expansion_type == MAC_EXP_PDS_COMM)
--
2.7.4
Re: [PATCH v2] mm: fix race between kmem_cache destroy, create and deactivate
On Sat, May 26, 2018 at 11:58 AM, Vladimir Davydov wrote: > On Tue, May 22, 2018 at 01:13:36PM -0700, Shakeel Butt wrote: >> The memcg kmem cache creation and deactivation (SLUB only) is >> asynchronous. If a root kmem cache is destroyed whose memcg cache is in >> the process of creation or deactivation, the kernel may crash. >> >> Example of one such crash: >> general protection fault: [#1] SMP PTI >> CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp >> ... >> Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn >> RIP: 0010:has_cpu_slab >> ... >> Call Trace: >> ? on_each_cpu_cond >> __kmem_cache_shrink >> kmemcg_cache_deact_after_rcu >> kmemcg_deactivate_workfn >> process_one_work >> worker_thread >> kthread >> ret_from_fork+0x35/0x40 >> >> This issue is due to the lack of real reference counting for the root >> kmem_caches. Currently kmem_cache does have a field named refcount which >> has been used for multiple purposes i.e. shared count, reference count >> and noshare flag. Due to its conflated nature, it can not be used for >> reference counting by other subsystems. >> >> This patch decoupled the reference counting from shared count and >> noshare flag. The new field 'shared_count' represents the shared count >> and noshare flag while 'refcount' is converted into a real reference >> counter. >> >> The reference counting is only implemented for root kmem_caches for >> simplicity. The reference of a root kmem_cache is elevated on sharing or >> while its memcg kmem_cache creation or deactivation request is in the >> fly and thus it is made sure that the root kmem_cache is not destroyed >> in the middle. As the reference of kmem_cache is elevated on sharing, >> the 'shared_count' does not need any locking protection as at worst it >> can be out-dated for a small window which is tolerable. > > I wonder if we could fix this problem without introducing reference > counting for kmem caches (which seems a bit of an overkill to me TBO), > e.g. by flushing memcg_kmem_cache_wq before root cache destruction? Thanks I will look into workqueue flushing.
Re: [PATCH] memcg: force charge kmem counter too
On Sat, May 26, 2018 at 11:51 AM, Vladimir Davydov wrote: > On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote: >> Based on several conditions the kernel can decide to force charge an >> allocation for a memcg i.e. overcharge memcg->memory and memcg->memsw >> counters. Do the same for memcg->kmem counter too. In cgroup-v1, this >> bug can cause a __GFP_NOFAIL kmem allocation fail if an explicit limit >> on kmem counter is set and reached. > > memory.kmem.limit is broken and unlikely to ever be fixed as this knob > was deprecated in cgroup-v2. The fact that hitting the limit doesn't > trigger reclaim can result in unexpected behavior from user's pov, like > getting ENOMEM while listing a directory. Bypassing the limit for NOFAIL > allocations isn't going to fix those problem. I understand that fixing NOFAIL will not fix all other issues but it still is better than current situation. IMHO we should keep fixing kmem bit by bit. One crazy idea is to just break it completely by force charging all the time.
Re: [PATCH] ALSA: seq: fix spelling mistake "Unamed" -> "Unnamed"
On Sat, 26 May 2018 17:11:00 +0200, Colin King wrote: > > From: Colin Ian King > > Trivial fix to spelling mistake in string > > Signed-off-by: Colin Ian King Applied, thanks. Takashi
Re: [PATCH] ASoC: AMD: make channel 1 dma as circular
On Fri, May 25, 2018 at 3:23 AM Akshu Agrawal wrote:
> channel 1: SYSMEM<->ACP
> channel 2: ACP<->I2S
> Instead of waiting on period interrupt of ch 2 and then starting
> dma on ch1, we make ch1 dma as circular.
> This removes dependency of period granularity on hw pointer.
> Signed-off-by: Akshu Agrawal
Reviewed-by: Daniel Kurtz
Tested-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-pcm-dma.c | 72
+++--
> 1 file changed, 10 insertions(+), 62 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index ac32dea..f1d8678 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -337,8 +337,7 @@ static void config_acp_dma(void __iomem *acp_mmio,
> }
> /* Start a given DMA channel transfer */
> -static void acp_dma_start(void __iomem *acp_mmio,
> - u16 ch_num, bool is_circular)
> +static void acp_dma_start(void __iomem *acp_mmio, u16 ch_num)
> {
> u32 dma_ctrl;
> @@ -369,11 +368,8 @@ static void acp_dma_start(void __iomem *acp_mmio,
> break;
> }
> - /* enable for ACP SRAM to/from I2S DMA channel */
> - if (is_circular == true)
> - dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
> - else
> - dma_ctrl &= ~ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
> + /* circular for both DMA channel */
> + dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
> acp_reg_write(dma_ctrl, acp_mmio, mmACP_DMA_CNTL_0 + ch_num);
> }
> @@ -617,7 +613,6 @@ static int acp_deinit(void __iomem *acp_mmio)
> /* ACP DMA irq handler routine for playback, capture usecases */
> static irqreturn_t dma_irq_handler(int irq, void *arg)
> {
> - u16 dscr_idx;
> u32 intr_flag, ext_intr_status;
> struct audio_drv_data *irq_data;
> void __iomem *acp_mmio;
> @@ -634,33 +629,13 @@ static irqreturn_t dma_irq_handler(int irq, void
*arg)
> if ((intr_flag & BIT(ACP_TO_I2S_DMA_CH_NUM)) != 0) {
> valid_irq = true;
> - if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_13) ==
> - PLAYBACK_START_DMA_DESCR_CH13)
> - dscr_idx = PLAYBACK_END_DMA_DESCR_CH12;
> - else
> - dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
> - config_acp_dma_channel(acp_mmio, SYSRAM_TO_ACP_CH_NUM,
dscr_idx,
> - 1, 0);
> - acp_dma_start(acp_mmio, SYSRAM_TO_ACP_CH_NUM, false);
> -
> snd_pcm_period_elapsed(irq_data->play_i2ssp_stream);
> -
> acp_reg_write((intr_flag & BIT(ACP_TO_I2S_DMA_CH_NUM)) <<
16,
>acp_mmio, mmACP_EXTERNAL_INTR_STAT);
> }
> if ((intr_flag & BIT(ACP_TO_I2S_DMA_BT_INSTANCE_CH_NUM)) != 0) {
> valid_irq = true;
> - if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_9) ==
> - PLAYBACK_START_DMA_DESCR_CH9)
> - dscr_idx = PLAYBACK_END_DMA_DESCR_CH8;
> - else
> - dscr_idx = PLAYBACK_START_DMA_DESCR_CH8;
> - config_acp_dma_channel(acp_mmio,
> - SYSRAM_TO_ACP_BT_INSTANCE_CH_NUM,
> - dscr_idx, 1, 0);
> - acp_dma_start(acp_mmio, SYSRAM_TO_ACP_BT_INSTANCE_CH_NUM,
> - false);
> snd_pcm_period_elapsed(irq_data->play_i2sbt_stream);
> acp_reg_write((intr_flag &
>BIT(ACP_TO_I2S_DMA_BT_INSTANCE_CH_NUM)) <<
16,
> @@ -669,38 +644,20 @@ static irqreturn_t dma_irq_handler(int irq, void
*arg)
> if ((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) != 0) {
> valid_irq = true;
> - if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_15) ==
> - CAPTURE_START_DMA_DESCR_CH15)
> - dscr_idx = CAPTURE_END_DMA_DESCR_CH14;
> - else
> - dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
> - config_acp_dma_channel(acp_mmio, ACP_TO_SYSRAM_CH_NUM,
dscr_idx,
> - 1, 0);
> - acp_dma_start(acp_mmio, ACP_TO_SYSRAM_CH_NUM, false);
> -
> + snd_pcm_period_elapsed(irq_data->capture_i2ssp_stream);
> acp_reg_write((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) <<
16,
>acp_mmio, mmACP_EXTERNAL_INTR_STAT);
> }
> if ((intr_flag & BIT(ACP_TO_SYSRAM_CH_NUM)) != 0) {
> valid_irq = true;
> - snd_pcm_period_elapsed(irq_data->capture_i2ssp_stream);
> acp_reg_write((intr_flag & BIT(ACP_TO_SYSRAM_CH_NUM)) <<
16,
>acp_mmio, mmACP_EXTERNAL_INTR_STAT);
> }
> if (
[PATCH v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
Chip Card Interface Device (CCID) protocol is a USB protocol that
allows a smartcard device to be connected to a computer via a card
reader using a standard USB interface, without the need for each manufacturer
of smartcards to provide its own reader or protocol.
This gadget driver makes Linux show up as a CCID device to the host and let a
userspace daemon act as the smartcard.
This is useful when the Linux gadget itself should act as a cryptographic
device or forward APDUs to an embedded smartcard device.
Signed-off-by: Marcus Folkesson
---
drivers/usb/gadget/Kconfig | 17 +
drivers/usb/gadget/function/Makefile | 1 +
drivers/usb/gadget/function/f_ccid.c | 988 +++
drivers/usb/gadget/function/f_ccid.h | 91
include/uapi/linux/usb/ccid.h| 93
5 files changed, 1190 insertions(+)
create mode 100644 drivers/usb/gadget/function/f_ccid.c
create mode 100644 drivers/usb/gadget/function/f_ccid.h
create mode 100644 include/uapi/linux/usb/ccid.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 31cce7805eb2..bdebdf1ffa2b 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -149,6 +149,9 @@ config USB_LIBCOMPOSITE
config USB_F_ACM
tristate
+config USB_F_CCID
+ tristate
+
config USB_F_SS_LB
tristate
@@ -248,6 +251,20 @@ config USB_CONFIGFS_ACM
ACM serial link. This function can be used to interoperate with
MS-Windows hosts or with the Linux-USB "cdc-acm" driver.
+config USB_CONFIGFS_CCID
+ bool "Chip Card Interface Device (CCID)"
+ depends on USB_CONFIGFS
+ select USB_F_CCID
+ help
+ The CCID function driver provides generic emulation of a
+ Chip Card Interface Device (CCID).
+
+ You will need a user space server talking to /dev/ccidg*,
+ since the kernel itself does not implement CCID/TPDU/APDU
+ protocol.
+
+ For more information, see Documentation/usb/gadget_ccid.rst.
+
config USB_CONFIGFS_OBEX
bool "Object Exchange Model (CDC OBEX)"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/function/Makefile
b/drivers/usb/gadget/function/Makefile
index 5d3a6cf02218..629851009e1a 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -9,6 +9,7 @@ ccflags-y +=
-I$(srctree)/drivers/usb/gadget/udc/
# USB Functions
usb_f_acm-y:= f_acm.o
obj-$(CONFIG_USB_F_ACM)+= usb_f_acm.o
+obj-$(CONFIG_USB_F_CCID) += f_ccid.o
usb_f_ss_lb-y := f_loopback.o f_sourcesink.o
obj-$(CONFIG_USB_F_SS_LB) += usb_f_ss_lb.o
obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/gadget/function/f_ccid.c
b/drivers/usb/gadget/function/f_ccid.c
new file mode 100644
index ..9ff8615ca303
--- /dev/null
+++ b/drivers/usb/gadget/function/f_ccid.c
@@ -0,0 +1,988 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * f_ccid.c -- Chip Card Interface Device (CCID) function Driver
+ *
+ * Copyright (C) 2018 Marcus Folkesson
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "f_ccid.h"
+#include "u_f.h"
+
+/* Number of tx requests to allocate */
+#define N_TX_REQS 4
+
+/* Maximum number of devices */
+#define CCID_MINORS 4
+
+struct ccidg_bulk_dev {
+ atomic_t is_open;
+ atomic_t rx_req_busy;
+ wait_queue_head_t read_wq;
+ wait_queue_head_t write_wq;
+ struct usb_request *rx_req;
+ atomic_t rx_done;
+ struct list_head tx_idle;
+};
+
+struct f_ccidg {
+ struct usb_function_instancefunc_inst;
+ struct usb_function function;
+ spinlock_t lock;
+ atomic_t online;
+
+ /* Character device */
+ struct cdev cdev;
+ int minor;
+
+ /* Dynamic attributes */
+ u32 features;
+ u32 protocols;
+ u8 pinsupport;
+ u8 nslots;
+ u8 lcdlayout;
+
+ /* Endpoints */
+ struct usb_ep *in;
+ struct usb_ep *out;
+ struct ccidg_bulk_dev bulk_dev;
+};
+
+/* Interface Descriptor: */
+static struct usb_interface_descriptor ccid_interface_desc = {
+ .bLength = USB_DT_INTERFACE_SIZE,
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints =2,
+ .bInterfaceClass = USB_CLASS_CSCID,
+ .bInterfaceSubClass = 0,
+ .bInterfaceProtocol = 0,
+};
+
+/* CCID Class Descriptor */
+static struct ccid_class_descriptor ccid_class_desc = {
+ .bLength = sizeof(ccid_class_desc),
+ .bDescriptorType = CCID_DECRIPTOR_TYPE,
+ .bcdCCID = CCID1_10,
+ /* .bMaxSlotIndex = DYNAMIC */
+ .bVoltageSupport = CCID_VOLTS_3_0,
+ /* .dwProtocols = DYNAMIC */
+ .dwDefaultClock = 3580,
+ .dwMaximumClock = 3580,
+ .bNum
[PATCH v2 2/3] Documentation: usb: add documentation for USB CCID Gadget Device
Add documentation to give a brief description on how to use the CCID Gadget Device. This includes a description for all attributes followed by an example on how to setup the device with ConfigFS. Signed-off-by: Marcus Folkesson --- Documentation/usb/gadget_ccid.rst | 267 ++ 1 file changed, 267 insertions(+) create mode 100644 Documentation/usb/gadget_ccid.rst diff --git a/Documentation/usb/gadget_ccid.rst b/Documentation/usb/gadget_ccid.rst new file mode 100644 index ..5ac806b14604 --- /dev/null +++ b/Documentation/usb/gadget_ccid.rst @@ -0,0 +1,267 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +CCID Gadget + + +:Author: Marcus Folkesson + +Introduction + + +The CCID Gadget will present itself as a CCID device to the host system. +The device supports two endpoints for now; BULK IN and BULK OUT. +These endpoints is exposed to userspace via /dev/ccidg*. + +All CCID commands are sent on the BULK-OUT endpoint. Each command sent to the CCID +has an associated ending response. Some commands can also have intermediate +responses. The response is sent on the BULK-IN endpoint. +See Figure 3-3 in the CCID Specification [1]_ for more details. + +The CCID commands must be handled in userspace since the driver is only working +as a transport layer for the TPDUs. + + +CCID Commands +-- + +All CCID commands begins with a 10 bytes header followed by an optional +data field depending on message type. + +++--+---+--+ +| Offset | Field| Size | Description | +++==+===+==+ +| 0 | bMessageType | 1 | Type of message | +++--+---+--+ +| 1 | dwLength | 4 | Message specific data length | +|| | | | +++--+---+--+ +| 5 | bSlot| 1 | Identifies the slot number | +|| | | for this command | +++--+---+--+ +| 6 | bSeq | 1 | Sequence number for command | +++--+---+--+ +| 7 | ... | 3 | Fields depends on message type | +++--+---+--+ +| 10 | abData | array | Message specific data (OPTIONAL) | +++--+---+--+ + + +Multiple CCID gadgets +-- + +It is possible to create multiple instances of the CCID gadget, however, +a much more flexible way is to create one gadget and set the `nslots` attribute +to the number of desired CCID devices. + +All CCID commands specifies which slot that is the receiver in the `bSlot` field +of the CCID header. + +Usage += + +Access from userspace +-- +All communication is by read(2) and write(2) to the corresponding /dev/ccidg* device. +Only one filedescriptor is allowed to be open to the device at a time. + +The buffer size provided to read(2) **must be at least** 522 (10 bytes header + 512 bytes payload) +bytes as we are working with whole commands. + +The buffer size provided to write(2) **may not exceed** 522 (10 bytes header + 512 bytes payload) +bytes as we are working with whole commands. + + +Configuration with configfs + + +ConfigFS is used to create and configure the CCID gadget. +In order to get a device to work as intended, a few attributes must +be considered. + +The attributes is described below followed by an example. + +features +~ + +The `feature` attribute writes to the dwFeatures field in the class descriptor. +See Table 5.1-1 Smart Card Device Descriptors in the CCID Specification [1]_. + +The value indicates what intelligent features the CCID has. +These values are available to user application as defines in ccid.h [2]_. +The default value is 0x. + +The value is a bitwise OR operation performed on the following values: + ++++ +| Value | Description| ++++ +| 0x | No special characteristics | ++++ +| 0x0002 | Automatic parameter configuration based on ATR data| ++++ +| 0x0004 | Automatic activation of ICC on inserting | +++---
[PATCH v2 3/3] MAINTAINERS: add USB CCID Gadget Device
Add MAINTAINERS entry for USB CCID Gadget Device Signed-off-by: Marcus Folkesson --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 078fd80f664f..e77c3d2bec89 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14541,6 +14541,14 @@ L: linux-s...@vger.kernel.org S: Maintained F: drivers/usb/storage/uas.c +USB CCID GADGET +M: Marcus Folkesson +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/usb/gadget/function/f_ccid.* +F: include/uapi/linux/usb/ccid.h +F: Documentation/usb/gadget_ccid.rst + USB CDC ETHERNET DRIVER M: Oliver Neukum L: linux-...@vger.kernel.org -- 2.16.2
[GIT PULL] ARM: SoC fixes
Hi Linus, Please merge. Thanks! -Olof The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11: Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to e5dd61546a777d19d4fe35e2d0a2b664ca49f6b2: Merge tag 'hisi-fixes-for-4.17v2' of git://github.com/hisilicon/linux-hisi into fixes (2018-05-26 12:12:44 -0700) ARM: SoC fixes for 4.17-rc A few more fixes for v4.17: - A fix for a crash in scm_call_atomic on qcom platforms - Display fix for Allwinner A10 - A fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al) - A fix for eMMC corruption on hikey - i2c-gpio descriptor tables for ixp4xx + a small typo fix Chen-Yu Tsai (1): ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One Colin Ian King (1): ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled" John Stultz (1): arm64: dts: hikey: Fix eMMC corruption regression Linus Walleij (1): ARM: Fix i2c-gpio GPIO descriptor tables Niklas Cassel (1): firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1() Olof Johansson (3): Merge tag 'sunxi-fixes-for-4.17' of https://git.kernel.org/.../sunxi/linux into fixes Merge tag 'qcom-fixes-for-4.17-rc7' of git://git.kernel.org/.../agross/linux into fixes Merge tag 'hisi-fixes-for-4.17v2' of git://github.com/hisilicon/linux-hisi into fixes Pascal Roeleven (1): ARM: dts: sun4i: Fix incorrect clocks for displays arch/arm/boot/dts/sun4i-a10.dtsi | 6 +++--- arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 1 + arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 2 +- arch/arm/mach-ep93xx/core.c| 2 +- arch/arm/mach-ixp4xx/avila-setup.c | 2 +- arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +- arch/arm/mach-ixp4xx/fsg-setup.c | 2 +- arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 +- arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +- arch/arm/mach-ixp4xx/nslu2-setup.c | 2 +- arch/arm/mach-pxa/palmz72.c| 2 +- arch/arm/mach-pxa/viper.c | 4 ++-- arch/arm/mach-sa1100/simpad.c | 2 +- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 - drivers/firmware/qcom_scm-32.c | 8 15 files changed, 20 insertions(+), 20 deletions(-)
Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > Signed-off-by: Marcus Folkesson I can't take patches without any changelog text. And why would you submit a patch over 1000 lines without any? Please fix. thanks, greg k-h
Re: [GIT PULL] ARM: at91: DT for 4.18
On Sat, May 26, 2018 at 12:50:33AM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > I'm a bit late for this very small PR, as I had to extend the expiration > date for my GPG signature key. > > Two small DT changes that have no functional impact. > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.18-dt > > for you to fetch changes up to a642693882ce417683012a211ca9d6e65bae1dc4: > > ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier (2018-05-14 > 15:29:52 +0200) > > > AT91 DT for 4.18: > > - small DT improvements without functional changes > > > Dmitry Torokhov (1): > ARM: dts: at91: sama5d4ek: use canonical compatible for touchscreen > > Hernán Gonzalez (1): > ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier Merged, thanks. -Olof
Re: [PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver
On Sat, May 26, 2018 at 11:15:35AM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, May 25, 2018 3:31 AM
> > To: Vadim Pasternak
> > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> > j...@resnulli.us;
> > Michael Shych ; ivec...@redhat.com
> > Subject: Re: [PATCH v2 6/7] platform/mellanox: Introduce support for
> > Mellanox
> > register access driver
> >
> > On Mon, May 07, 2018 at 06:48:54AM +, Vadim Pasternak wrote:
> > > Introduce new Mellanox platform driver to allow access to Mellanox
> > > programmable device register space trough sysfs interface.
> > > The driver purpose is to provide sysfs interface for user space for
> > > the registers essential for system control and monitoring.
> > > The sets of registers for sysfs access are supposed to be defined per
> > > system type bases and include the registers related to system resets
> > > operation, system reset causes monitoring and some kinds of mux selection.
> > >
> > > Signed-off-by: Vadim Pasternak
> > > ---
> >
> > One question on the attr init which I'm not familiar with... Andy, Greg -
> > can you
> > offer your opinion below...
> >
...
> > > + priv->mlxreg_io_dev_attr[i].dev_attr.attr.mode =
> > > + priv->pdata->data[i].mode;
> > > + switch (priv->pdata->data[i].mode) {
> >
> > This seemed a bit odd to me. Do we need to do this conditional assignment
> > within the kernel, or can these just be assigned, and the mode will guard
> > against
> > the user being able to call store on a read only attr?
> >
> > > + case 0200:
> > > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > > + mlxreg_io_attr_store;
> > > + break;
> > > +
> > > + case 0444:
> > > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > > + mlxreg_io_attr_show;
> > > + break;
> > > +
> > > + case 0644:
> > > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > > + mlxreg_io_attr_show;
> > > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > > + mlxreg_io_attr_store;
> > > + break;
> >
> > If this is necessary, we can simplify this by checking for the read mask
> > and the
> > write mask and setting each once - rather than duplicating this for r, w,
> > and rw.
> > As it is a 0400 would not assign the show function, even though it is
> > readable by
> > somebody.
>
> Maybe I really can add something like
> static struct device_attribute mlxreg_io_devattr_rw = {
> .show = mlxreg_io_attr_show,
> .store = mlxreg_io_attr_store,
> };
>
> And replace this whole switch statement just with:
> memcpy(&priv->mlxreg_io_dev_attr[i].dev_attr,
> &mlxreg_io_devattr_rw, sizeof(struct device_attribute));
This is certainly preferable if it doesn't present any functional problems.
Seems to me it must be doable because the OS has to deny write for Group and
Other and allow for User with 644, similarly for read is other perm conditions.
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='
On Thu, May 24, 2018 at 6:45 AM, Masahiro Yamada
wrote:
> 2018-05-21 20:06 GMT+09:00 Ulf Magnusson :
>
>>>
>>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>>> {
>>> const char *in, *prev_in, *p;
>>> char *new, *out;
>>> size_t outlen;
>>>
>>> out = xmalloc(1);
>>> *out = 0;
>>>
>>> p = in = *str;
>>>
>>> while (1) {
>>> if (*p == '$') {
>>> prev_in = in;
>>> in = p + 1;
>>> new = expand_dollar(&in);
>>> outlen = strlen(out) + (p - prev_in) + strlen(new)
>>> + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, prev_in, p - prev_in);
>>> strcat(out, new);
>>> free(new);
>>> p = in;
>>> continue;
>>> }
>>>
>>> if (is_end(p))
>>> break;
>>>
>>> p++;
>>> }
>>>
>>> outlen = strlen(out) + (p - in) + 1;
>>> out = xrealloc(out, outlen);
>>> strncat(out, in, p - in);
>>>
>>> *str = p;
>>>
>>> return out;
>>> }
>>>
>>> static bool is_end_of_str(const char *s)
>>> {
>>> return !*s;
>>> }
>>>
>>> char *expand_string(const char *in)
>>> {
>>> return __expand_string(&in, is_end_of_str);
>>> }
>>>
>>> static bool is_end_of_token(const char *s)
>>> {
>>> return !(isalnum(*s) || *s == '_' || *s == '-' || *s == '.' ||
>>> *s == '/');
>>> }
>>>
>>> char *expand_one_token(const char **str)
>>> {
>>> return __expand_string(str, is_end_of_token);
>>> }
>>
>> Yep, something like that would be nicer I think.
>>
>> This variant might work too (untested):
>>
>> dollar_i = p;
>> p++;
>> expansion = expand_dollar(&p);
>>
>> out = xrealloc(out, strlen(out) + (dollar_i - in)
>> + strlen(expansion) + 1);
>> strncat(out, in, dollar_i - in);
>> strcat(out, expansion);
>> free(expansion);
>>
>> in = p;
>>
>> continue;
>>
>> The p++ would disappear if expand_dollar() took a pointer to the '$'.
>>
>
>
> I took the variable name "expansion" because
> it is more descriptive than "new".
>
>
> I rewrote like follows:
>
>
> static char *__expand_string(const char **str, bool (*is_end)(const char *))
> {
> const char *in, *p;
> char *expansion, *out;
> size_t in_len, out_len;
>
> out = xmalloc(1);
> *out = 0;
> out_len = 1;
>
> p = in = *str;
>
> while (1) {
> if (*p == '$') {
> in_len = p - in;
> p++;
> expansion = expand_dollar(&p);
> out_len += in_len + strlen(expansion);
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
> strcat(out, expansion);
> free(expansion);
> in = p;
> continue;
> }
>
> if (is_end(p))
> break;
>
> p++;
> }
>
> in_len = p - in;
> out_len += in_len;
> out = xrealloc(out, out_len);
> strncat(out, in, in_len);
>
> /* Advance 'str' to the end character */
> *str = p;
>
> return out;
> }
>
>
>
> I used "out_len" to remember the length of "out"
> instead of calculating strlen(out) every time.
>
> I do not need dollar_p.
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
Looks good to me.
Could keep some 'out' pointer to avoid the str(n)cat()s too, but
pretty sure it's overkilling it. Should have some general string
buffer helpers at that point I think. :)
Cheers,
Ulf
[PATCH 2/3] Documentation: usb: add documentation for USB CCID Gadget Device
Signed-off-by: Marcus Folkesson --- Documentation/usb/gadget_ccid.rst | 267 ++ 1 file changed, 267 insertions(+) create mode 100644 Documentation/usb/gadget_ccid.rst diff --git a/Documentation/usb/gadget_ccid.rst b/Documentation/usb/gadget_ccid.rst new file mode 100644 index ..5ac806b14604 --- /dev/null +++ b/Documentation/usb/gadget_ccid.rst @@ -0,0 +1,267 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +CCID Gadget + + +:Author: Marcus Folkesson + +Introduction + + +The CCID Gadget will present itself as a CCID device to the host system. +The device supports two endpoints for now; BULK IN and BULK OUT. +These endpoints is exposed to userspace via /dev/ccidg*. + +All CCID commands are sent on the BULK-OUT endpoint. Each command sent to the CCID +has an associated ending response. Some commands can also have intermediate +responses. The response is sent on the BULK-IN endpoint. +See Figure 3-3 in the CCID Specification [1]_ for more details. + +The CCID commands must be handled in userspace since the driver is only working +as a transport layer for the TPDUs. + + +CCID Commands +-- + +All CCID commands begins with a 10 bytes header followed by an optional +data field depending on message type. + +++--+---+--+ +| Offset | Field| Size | Description | +++==+===+==+ +| 0 | bMessageType | 1 | Type of message | +++--+---+--+ +| 1 | dwLength | 4 | Message specific data length | +|| | | | +++--+---+--+ +| 5 | bSlot| 1 | Identifies the slot number | +|| | | for this command | +++--+---+--+ +| 6 | bSeq | 1 | Sequence number for command | +++--+---+--+ +| 7 | ... | 3 | Fields depends on message type | +++--+---+--+ +| 10 | abData | array | Message specific data (OPTIONAL) | +++--+---+--+ + + +Multiple CCID gadgets +-- + +It is possible to create multiple instances of the CCID gadget, however, +a much more flexible way is to create one gadget and set the `nslots` attribute +to the number of desired CCID devices. + +All CCID commands specifies which slot that is the receiver in the `bSlot` field +of the CCID header. + +Usage += + +Access from userspace +-- +All communication is by read(2) and write(2) to the corresponding /dev/ccidg* device. +Only one filedescriptor is allowed to be open to the device at a time. + +The buffer size provided to read(2) **must be at least** 522 (10 bytes header + 512 bytes payload) +bytes as we are working with whole commands. + +The buffer size provided to write(2) **may not exceed** 522 (10 bytes header + 512 bytes payload) +bytes as we are working with whole commands. + + +Configuration with configfs + + +ConfigFS is used to create and configure the CCID gadget. +In order to get a device to work as intended, a few attributes must +be considered. + +The attributes is described below followed by an example. + +features +~ + +The `feature` attribute writes to the dwFeatures field in the class descriptor. +See Table 5.1-1 Smart Card Device Descriptors in the CCID Specification [1]_. + +The value indicates what intelligent features the CCID has. +These values are available to user application as defines in ccid.h [2]_. +The default value is 0x. + +The value is a bitwise OR operation performed on the following values: + ++++ +| Value | Description| ++++ +| 0x | No special characteristics | ++++ +| 0x0002 | Automatic parameter configuration based on ATR data| ++++ +| 0x0004 | Automatic activation of ICC on inserting | ++++ +| 0x0008 | Automatic ICC voltage selection| ++++ +| 0x0010 | Automati
[PATCH 3/3] MAINTAINERS: add USB CCID Gadget Device
Add MAINTAINERS entry for USB CCID Gadget Device Signed-off-by: Marcus Folkesson --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 078fd80f664f..e77c3d2bec89 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14541,6 +14541,14 @@ L: linux-s...@vger.kernel.org S: Maintained F: drivers/usb/storage/uas.c +USB CCID GADGET +M: Marcus Folkesson +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/usb/gadget/function/f_ccid.* +F: include/uapi/linux/usb/ccid.h +F: Documentation/usb/gadget_ccid.rst + USB CDC ETHERNET DRIVER M: Oliver Neukum L: linux-...@vger.kernel.org -- 2.16.2
[PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
Signed-off-by: Marcus Folkesson
---
drivers/usb/gadget/Kconfig | 17 +
drivers/usb/gadget/function/Makefile | 1 +
drivers/usb/gadget/function/f_ccid.c | 988 +++
drivers/usb/gadget/function/f_ccid.h | 91
include/uapi/linux/usb/ccid.h| 93
5 files changed, 1190 insertions(+)
create mode 100644 drivers/usb/gadget/function/f_ccid.c
create mode 100644 drivers/usb/gadget/function/f_ccid.h
create mode 100644 include/uapi/linux/usb/ccid.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 31cce7805eb2..bdebdf1ffa2b 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -149,6 +149,9 @@ config USB_LIBCOMPOSITE
config USB_F_ACM
tristate
+config USB_F_CCID
+ tristate
+
config USB_F_SS_LB
tristate
@@ -248,6 +251,20 @@ config USB_CONFIGFS_ACM
ACM serial link. This function can be used to interoperate with
MS-Windows hosts or with the Linux-USB "cdc-acm" driver.
+config USB_CONFIGFS_CCID
+ bool "Chip Card Interface Device (CCID)"
+ depends on USB_CONFIGFS
+ select USB_F_CCID
+ help
+ The CCID function driver provides generic emulation of a
+ Chip Card Interface Device (CCID).
+
+ You will need a user space server talking to /dev/ccidg*,
+ since the kernel itself does not implement CCID/TPDU/APDU
+ protocol.
+
+ For more information, see Documentation/usb/gadget_ccid.rst.
+
config USB_CONFIGFS_OBEX
bool "Object Exchange Model (CDC OBEX)"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/function/Makefile
b/drivers/usb/gadget/function/Makefile
index 5d3a6cf02218..629851009e1a 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -9,6 +9,7 @@ ccflags-y +=
-I$(srctree)/drivers/usb/gadget/udc/
# USB Functions
usb_f_acm-y:= f_acm.o
obj-$(CONFIG_USB_F_ACM)+= usb_f_acm.o
+obj-$(CONFIG_USB_F_CCID) += f_ccid.o
usb_f_ss_lb-y := f_loopback.o f_sourcesink.o
obj-$(CONFIG_USB_F_SS_LB) += usb_f_ss_lb.o
obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/gadget/function/f_ccid.c
b/drivers/usb/gadget/function/f_ccid.c
new file mode 100644
index ..9ff8615ca303
--- /dev/null
+++ b/drivers/usb/gadget/function/f_ccid.c
@@ -0,0 +1,988 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * f_ccid.c -- Chip Card Interface Device (CCID) function Driver
+ *
+ * Copyright (C) 2018 Marcus Folkesson
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "f_ccid.h"
+#include "u_f.h"
+
+/* Number of tx requests to allocate */
+#define N_TX_REQS 4
+
+/* Maximum number of devices */
+#define CCID_MINORS 4
+
+struct ccidg_bulk_dev {
+ atomic_t is_open;
+ atomic_t rx_req_busy;
+ wait_queue_head_t read_wq;
+ wait_queue_head_t write_wq;
+ struct usb_request *rx_req;
+ atomic_t rx_done;
+ struct list_head tx_idle;
+};
+
+struct f_ccidg {
+ struct usb_function_instancefunc_inst;
+ struct usb_function function;
+ spinlock_t lock;
+ atomic_t online;
+
+ /* Character device */
+ struct cdev cdev;
+ int minor;
+
+ /* Dynamic attributes */
+ u32 features;
+ u32 protocols;
+ u8 pinsupport;
+ u8 nslots;
+ u8 lcdlayout;
+
+ /* Endpoints */
+ struct usb_ep *in;
+ struct usb_ep *out;
+ struct ccidg_bulk_dev bulk_dev;
+};
+
+/* Interface Descriptor: */
+static struct usb_interface_descriptor ccid_interface_desc = {
+ .bLength = USB_DT_INTERFACE_SIZE,
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints =2,
+ .bInterfaceClass = USB_CLASS_CSCID,
+ .bInterfaceSubClass = 0,
+ .bInterfaceProtocol = 0,
+};
+
+/* CCID Class Descriptor */
+static struct ccid_class_descriptor ccid_class_desc = {
+ .bLength = sizeof(ccid_class_desc),
+ .bDescriptorType = CCID_DECRIPTOR_TYPE,
+ .bcdCCID = CCID1_10,
+ /* .bMaxSlotIndex = DYNAMIC */
+ .bVoltageSupport = CCID_VOLTS_3_0,
+ /* .dwProtocols = DYNAMIC */
+ .dwDefaultClock = 3580,
+ .dwMaximumClock = 3580,
+ .bNumClockSupported = 0,
+ .dwDataRate = 9600,
+ .dwMaxDataRate =9600,
+ .bNumDataRatesSupported = 0,
+ .dwMaxIFSD =0,
+ .dwSynchProtocols = 0,
+ .dwMechanical = 0,
+ /* .dwFeatures =DYNAMIC */
+
+ /* extended APDU level Message Length */
+ .dwMaxCCIDMessageLength = 0x200,
+ .bClassGetResponse =0x0,
+ .bClassEnvelope = 0x0,
+ /* .wLcdLayout =DYNAMIC */
+ /* .bPINSupport
Re: Bugs involving maliciously crafted file system
On Sat, May 26, 2018 at 07:12:49PM +0200, Dmitry Vyukov wrote: > > I don't see that "some kind of machine learning or expert system > evaluation" is feasible. At least not in short/mid-term. There are > innocently-looking bugs that actually turn out to be very bad, and > there are badly looking at first glance bugs that actually not that > bad for some complex reasons. Full security assessment is a complex > task and I think stays "human expert area" for now. One can get some > coarse estimation by searching for "use-after-free" and > "out-of-bounds" on the dashboard. If the kernel intentionally triggers a BUG_ON or a panic (as in file systems configured with 'tune2fs -e panic') it's pretty obvious that those errors can't be weaponized to execute code chosen by the attacker. Would you agree with that? The same should be true for "blocked for more than 120 seconds"; again, I claim that those sorts of errors are by definition less serious than buffer overruns. So there is at least some kind of automated evaluation that can be done, even if the general case problem is really hard. > > Or maybe it would be useful if there was a way where maintainers could > > be able to annotate bugs with priority and severity levels, and maybe > > make comments that can be viewed from the Syzbot dashboard UI. > > This looks more realistic. +Tetsuo proposed something similar: > https://github.com/google/syzkaller/issues/608 > > I think to make it useful we need to settle on some small set of > well-defined tags for bugs that we can show on the dashboard. > Arbitrary detailed free-form comments can be left on the mailing list > threads that are always referenced from the dashboard. > > What tags would you use today for existing bugs? One would be > "security-critical", right? For me, it's not about tags. Things missing from the https://syzkaller.appspot.com/ front page are: * Whether or not a repro is available * Which subsystems the bug has been tentatively assigned * A maintainer assigned priority and severity level I generally don't use the syzkaller.apptspot.com front page because it's too hard to find the sorts of thing that I'm looking for --- namely the most important syzkaller bug that I as an ext4 expert can work on. If someone else sends me a well-formed bug report on bugzilla.kernel.org, with free-standing image file, and a simple .c reproducer, I can make forward progress much more quickly. So if I'm time bound, guess which bug I'm going to pay attention to first? Especially when Syzkaller makes it hard for me to find the bug again once it ages out of my inbox? > Well, we have KASAN, almost have KMSAN and will have KTSAN in future. > They can detect detect significant portion of bugs that go unnoticed > otherwise. At least this prevents "bad guys" from also using tooling > to cheaply harvest exploits. Systematic use of these tools on browsers > raised exploit costs to $1M+ for a reason. I'll note that browsers also use processes and capsicum to provide security boundaries. This is why David and I have been suggesting solutions like FUSE or running the mount in a guest VM, which can act as an isolation layer. Even if there is a bug in the guest kernel, the blast radius of the bug can be isolated, hopefully to the point where it can be completely contained. It's not an either-or, but a both-and. But the much more important thing is that mangement has to be willing to **fund** bug remediation. That was true for Chrome; it doesn't seem to be as true for the Linux Kernel, for whatever reason. People trying to fix Syzkaller and other fuzzer-found bugs on 20% time, or on the weekends, or as a background activity during low-bandwidth meetings, or as an unfunded mandate that doesn't show up on anyone's quarterly objectives upon which they are graded, is just not going to scale. And if that's the reality, it may very well be that if you want Syzkaller to make more a difference, anything you can do to reduce the human toil needed to investigate a bug is going to be hugely important. And if bug remediation is only going to be funded to a very limited extent, then it's important that the bugs we work on are the highest priority ones, since the lower priority ones *will* have to let slide. Regards, - Ted
[GIT pull] x86/pti updates for 4.17
Linus,
please pull the latest x86-pti-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus
Two fixes for the SSBD mitigation code:
- Expose SSBD properly to guests. This got broken when the CPU feature
flags got reshuffled.
- Simplify the CPU detection logic to avoid duplicate entries in the
tables.
Thanks,
tglx
-->
Dominik Brodowski (1):
x86/speculation: Simplify the CPU bug detection logic
Konrad Rzeszutek Wilk (1):
KVM/VMX: Expose SSBD properly to guests
arch/x86/kernel/cpu/common.c | 22 +++---
arch/x86/kvm/cpuid.c | 4 ++--
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 78decc3e3067..38276f58d3bf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -942,12 +942,8 @@ static const __initconst struct x86_cpu_id
cpu_no_meltdown[] = {
{}
};
+/* Only list CPUs which speculate but are non susceptible to SSB */
static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW},
- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT},
- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL },
- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW },
- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT1 },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_AIRMONT },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT2 },
@@ -955,14 +951,10 @@ static const __initconst struct x86_cpu_id
cpu_no_spec_store_bypass[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_CORE_YONAH },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_XEON_PHI_KNL },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_XEON_PHI_KNM },
- { X86_VENDOR_CENTAUR, 5, },
- { X86_VENDOR_INTEL, 5, },
- { X86_VENDOR_NSC, 5, },
{ X86_VENDOR_AMD, 0x12, },
{ X86_VENDOR_AMD, 0x11, },
{ X86_VENDOR_AMD, 0x10, },
{ X86_VENDOR_AMD, 0xf,},
- { X86_VENDOR_ANY, 4, },
{}
};
@@ -970,6 +962,12 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
{
u64 ia32_cap = 0;
+ if (x86_match_cpu(cpu_no_speculation))
+ return;
+
+ setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
+ setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
+
if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
@@ -977,12 +975,6 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
!(ia32_cap & ARCH_CAP_SSB_NO))
setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
- if (x86_match_cpu(cpu_no_speculation))
- return;
-
- setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
- setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
-
if (x86_match_cpu(cpu_no_meltdown))
return;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index ced851169730..598461e24be3 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -407,8 +407,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
- F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | F(SSBD) |
- F(ARCH_CAPABILITIES);
+ F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
+ F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES);
/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
[GIT pull] scheduler fixes for 4.17
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
Three fixes for scheduler and kthread code:
- Allow calling kthread_park() on an already parked thread
- Restore the sched_pi_setprio() tracepoint behaviour
- Clarify the unclear string for the scheduling domain debug output
Thanks,
tglx
-->
Juri Lelli (1):
sched/topology: Clarify root domain(s) debug string
Peter Zijlstra (1):
kthread: Allow kthread_park() on a parked kthread
Sebastian Andrzej Siewior (1):
sched, tracing: Fix trace_sched_pi_setprio() for deboosting
include/trace/events/sched.h | 4 +++-
kernel/kthread.c | 6 ++
kernel/sched/topology.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index bc01e06bc716..0be866c91f62 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -435,7 +435,9 @@ TRACE_EVENT(sched_pi_setprio,
memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
__entry->pid= tsk->pid;
__entry->oldprio= tsk->prio;
- __entry->newprio= pi_task ? pi_task->prio : tsk->prio;
+ __entry->newprio= pi_task ?
+ min(tsk->normal_prio, pi_task->prio) :
+ tsk->normal_prio;
/* XXX SCHED_DEADLINE bits missing */
),
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 2017a39ab490..481951bf091d 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -193,7 +193,7 @@ EXPORT_SYMBOL_GPL(kthread_parkme);
void kthread_park_complete(struct task_struct *k)
{
- complete(&to_kthread(k)->parked);
+ complete_all(&to_kthread(k)->parked);
}
static int kthread(void *_create)
@@ -459,6 +459,7 @@ void kthread_unpark(struct task_struct *k)
if (test_bit(KTHREAD_IS_PER_CPU, &kthread->flags))
__kthread_bind(k, kthread->cpu, TASK_PARKED);
+ reinit_completion(&kthread->parked);
clear_bit(KTHREAD_SHOULD_PARK, &kthread->flags);
wake_up_state(k, TASK_PARKED);
}
@@ -483,9 +484,6 @@ int kthread_park(struct task_struct *k)
if (WARN_ON(k->flags & PF_EXITING))
return -ENOSYS;
- if (WARN_ON_ONCE(test_bit(KTHREAD_SHOULD_PARK, &kthread->flags)))
- return -EBUSY;
-
set_bit(KTHREAD_SHOULD_PARK, &kthread->flags);
if (k != current) {
wake_up_process(k);
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 64cc564f5255..61a1125c1ae4 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1708,7 +1708,7 @@ build_sched_domains(const struct cpumask *cpu_map, struct
sched_domain_attr *att
rcu_read_unlock();
if (rq && sched_debug_enabled) {
- pr_info("span: %*pbl (max cpu_capacity = %lu)\n",
+ pr_info("root domain span: %*pbl (max cpu_capacity = %lu)\n",
cpumask_pr_args(cpu_map), rq->rd->max_cpu_capacity);
}
[PATCH] parport: Add support for the WCH384 4S multi-IO card
This Multi-IO card has one serial 16550-like serial connectors. Here's
the lspci output, after this commit is applied:
01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05
[16850])
Subsystem: Device [1c00:3470]
Flags: fast devsel, IRQ 16
I/O ports at e000 [size=256]
Memory at f010 (32-bit, prefetchable) [size=32K]
I/O ports at e100 [size=4]
Expansion ROM at f7d0 [disabled] [size=32K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [80] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: parport_serial
This card was already added to the blacklist of 8250_pci.c in commit
72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").
Cc: Sergej Pupykin
Signed-off-by: Matt Turner
---
It looks like CH355_4S is similarly missing, but I don't have hardware
to test.
This commit makes me wonder if I'm missing something -- how could
anything have worked after commit 72a3c0e4e662 without support in
parport_serial?
drivers/parport/parport_serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
index e15b4845f7c6..2c166d5a0d91 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -65,6 +65,7 @@ enum parport_pc_pci_cards {
wch_ch353_1s1p,
wch_ch353_2s1p,
wch_ch382_2s1p,
+ wch_ch384_4,
sunix_2s1p,
};
@@ -153,6 +154,7 @@ static struct parport_pc_pci cards[] = {
/* wch_ch353_1s1p*/ { 1, { { 1, -1}, } },
/* wch_ch353_2s1p*/ { 1, { { 2, -1}, } },
/* wch_ch382_2s1p*/ { 1, { { 2, -1}, } },
+ /* wch_ch384_4 */ { 1, { { 4, -1}, } },
/* sunix_2s1p */{ 1, { { 3, -1 }, } },
};
@@ -260,6 +262,7 @@ static struct pci_device_id parport_serial_pci_tbl[] = {
{ 0x4348, 0x5053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch353_1s1p},
{ 0x4348, 0x7053, 0x4348, 0x3253, 0, 0, wch_ch353_2s1p},
{ 0x1c00, 0x3250, 0x1c00, 0x3250, 0, 0, wch_ch382_2s1p},
+ { 0x1c00, 0x3470, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch384_4},
/*
* More SUNIX variations. At least one of these has part number
@@ -504,6 +507,13 @@ static struct pciserial_board pci_parport_serial_boards[]
= {
.uart_offset= 8,
.first_offset = 0xC0,
},
+ [wch_ch384_4] = {
+ .flags = FL_BASE0,
+ .num_ports = 4,
+ .base_baud = 115200,
+ .uart_offset= 8,
+ .first_offset = 0xC0,
+ },
[sunix_2s1p] = {
.flags = FL_BASE0|FL_BASE_BARS,
.num_ports = 2,
--
2.16.1
Re: [PATCH 4/7] x86: remove a stray reference to pci-nommu.c
On Fri, 25 May 2018, Christoph Hellwig wrote: Subject should be: Documentation/x86: Remove . please > This is just the minimal workaround. The file file is mostly either stale file file? > and/or duplicative of Documentation/admin-guide/kernel-parameters.txt, > but that is much more work than I'm willing to do right now. Yeah, this thing is on the todo list ... > Signed-off-by: Christoph Hellwig Other than the above nits: Reviewed-by: Thomas Gleixner > --- > Documentation/x86/x86_64/boot-options.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/x86/x86_64/boot-options.txt > b/Documentation/x86/x86_64/boot-options.txt > index b297c48389b9..153b3a57fba2 100644 > --- a/Documentation/x86/x86_64/boot-options.txt > +++ b/Documentation/x86/x86_64/boot-options.txt > @@ -187,9 +187,9 @@ PCI > > IOMMU (input/output memory management unit) > > - Currently four x86-64 PCI-DMA mapping implementations exist: > + Multiple x86-64 PCI-DMA mapping implementations exist, for example: > > - 1. : use no hardware/software IOMMU at all > + 1. : use no hardware/software IOMMU at all >(e.g. because you have < 3 GB memory). >Kernel boot message: "PCI-DMA: Disabling IOMMU" > > -- > 2.17.0 > >
Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand
On Sat, May 26, 2018 at 06:35:34AM +0200, Paul Menzel wrote: > Building the configuration created with `make tinyconfig` on the Power 8 > system IBM S822LC with Ubuntu 18.04 fails with the error below. > AS arch/powerpc/kernel/head_32.o > arch/powerpc/kernel/head_32.S: Assembler messages: > arch/powerpc/kernel/head_32.S:1106: Error: missing operand You are building a 32-bit kernel for a 64-bit machine. This is not supported, and as you found out, does not work. Segher
Re: [PATCH v2] mm: fix race between kmem_cache destroy, create and deactivate
On Tue, May 22, 2018 at 01:13:36PM -0700, Shakeel Butt wrote: > The memcg kmem cache creation and deactivation (SLUB only) is > asynchronous. If a root kmem cache is destroyed whose memcg cache is in > the process of creation or deactivation, the kernel may crash. > > Example of one such crash: > general protection fault: [#1] SMP PTI > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > ... > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > RIP: 0010:has_cpu_slab > ... > Call Trace: > ? on_each_cpu_cond > __kmem_cache_shrink > kmemcg_cache_deact_after_rcu > kmemcg_deactivate_workfn > process_one_work > worker_thread > kthread > ret_from_fork+0x35/0x40 > > This issue is due to the lack of real reference counting for the root > kmem_caches. Currently kmem_cache does have a field named refcount which > has been used for multiple purposes i.e. shared count, reference count > and noshare flag. Due to its conflated nature, it can not be used for > reference counting by other subsystems. > > This patch decoupled the reference counting from shared count and > noshare flag. The new field 'shared_count' represents the shared count > and noshare flag while 'refcount' is converted into a real reference > counter. > > The reference counting is only implemented for root kmem_caches for > simplicity. The reference of a root kmem_cache is elevated on sharing or > while its memcg kmem_cache creation or deactivation request is in the > fly and thus it is made sure that the root kmem_cache is not destroyed > in the middle. As the reference of kmem_cache is elevated on sharing, > the 'shared_count' does not need any locking protection as at worst it > can be out-dated for a small window which is tolerable. I wonder if we could fix this problem without introducing reference counting for kmem caches (which seems a bit of an overkill to me TBO), e.g. by flushing memcg_kmem_cache_wq before root cache destruction?
Re: [PATCH] memcg: force charge kmem counter too
On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote:
> Based on several conditions the kernel can decide to force charge an
> allocation for a memcg i.e. overcharge memcg->memory and memcg->memsw
> counters. Do the same for memcg->kmem counter too. In cgroup-v1, this
> bug can cause a __GFP_NOFAIL kmem allocation fail if an explicit limit
> on kmem counter is set and reached.
memory.kmem.limit is broken and unlikely to ever be fixed as this knob
was deprecated in cgroup-v2. The fact that hitting the limit doesn't
trigger reclaim can result in unexpected behavior from user's pov, like
getting ENOMEM while listing a directory. Bypassing the limit for NOFAIL
allocations isn't going to fix those problem. So I'd suggest to avoid
setting memory.kmem.limit instead of trying to fix it or, even better,
switch to cgroup-v2.
>
> Signed-off-by: Shakeel Butt
> ---
> mm/memcontrol.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ab5673dbfc4e..0a88f824c550 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1893,6 +1893,18 @@ void mem_cgroup_handle_over_high(void)
> current->memcg_nr_pages_over_high = 0;
> }
>
> +/*
> + * Based on try_charge() force charge conditions.
> + */
> +static inline bool should_force_charge(gfp_t gfp_mask)
> +{
> + return (unlikely(tsk_is_oom_victim(current) ||
> + fatal_signal_pending(current) ||
> + current->flags & PF_EXITING ||
> + current->flags & PF_MEMALLOC ||
> + gfp_mask & __GFP_NOFAIL));
> +}
> +
> static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> unsigned int nr_pages)
> {
> @@ -2008,6 +2020,8 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
> gfp_mask,
>* The allocation either can't fail or will lead to more memory
>* being freed very soon. Allow memory usage go over the limit
>* temporarily by force charging it.
> + *
> + * NOTE: Please keep the should_force_charge() conditions in sync.
>*/
> page_counter_charge(&memcg->memory, nr_pages);
> if (do_memsw_account())
> @@ -2331,8 +2345,11 @@ int memcg_kmem_charge_memcg(struct page *page, gfp_t
> gfp, int order,
>
> if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) &&
> !page_counter_try_charge(&memcg->kmem, nr_pages, &counter)) {
> - cancel_charge(memcg, nr_pages);
> - return -ENOMEM;
> + if (!should_force_charge(gfp)) {
> + cancel_charge(memcg, nr_pages);
> + return -ENOMEM;
> + }
> + page_counter_charge(&memcg->kmem, nr_pages);
> }
>
> page->mem_cgroup = memcg;
Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand
Dear Christophe, Am 26.05.2018 um 18:02 schrieb christophe leroy: Le 26/05/2018 à 06:35, Paul Menzel a écrit : Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'akpm' (patches from Andrew) $ make tinyconfig $ make -j120 […] AS arch/powerpc/kernel/head_32.o arch/powerpc/kernel/head_32.S: Assembler messages: arch/powerpc/kernel/head_32.S:1106: Error: missing operand There was a similar problem in 2015, see http://linux-kernel.2935.n7.nabble.com/Missing-operand-for-tlbie-instruction-on-Power7-td1206917.html Which version of binutils do you use ? 2.30-15ubuntu1 is installed. Kind regards, Paul
Re: [PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs
Hi Viresh,
On 2018/5/26 19:00, Wei Xu wrote:
> Hi Viresh,
>
> On 2018/5/25 6:40, Viresh Kumar wrote:
>> The cooling device properties, like "#cooling-cells" and
>> "dynamic-power-coefficient", should either be present for all the CPUs
>> of a cluster or none. If these are present only for a subset of CPUs of
>> a cluster then things will start falling apart as soon as the CPUs are
>> brought online in a different order. For example, this will happen
>> because the operating system looks for such properties in the CPU node
>> it is trying to bring up, so that it can register a cooling device.
>>
>> Add such missing properties.
>>
>> Do minor rearrangement as well to keep ordering consistent.
>>
>> Signed-off-by: Viresh Kumar
>
> Thanks!
> Applied to the hisilicon fix tree.
Sorry for the noise!
It seems this patch is still under discussion.
I will drop it firstly.
Best Regards,
Wei
>
> Best Regards,
> Wei
>
>> ---
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 +++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> index 586b281cd531..247024df714f 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -88,8 +88,8 @@
>> next-level-cache = <&CLUSTER0_L2>;
>> clocks = <&stub_clock 0>;
>> operating-points-v2 = <&cpu_opp_table>;
>> -#cooling-cells = <2>; /* min followed by max */
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> dynamic-power-coefficient = <311>;
>> };
>>
>> @@ -101,6 +101,8 @@
>> next-level-cache = <&CLUSTER0_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu2: cpu@2 {
>> @@ -111,6 +113,8 @@
>> next-level-cache = <&CLUSTER0_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu3: cpu@3 {
>> @@ -121,6 +125,8 @@
>> next-level-cache = <&CLUSTER0_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu4: cpu@100 {
>> @@ -131,6 +137,8 @@
>> next-level-cache = <&CLUSTER1_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu5: cpu@101 {
>> @@ -141,6 +149,8 @@
>> next-level-cache = <&CLUSTER1_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu6: cpu@102 {
>> @@ -151,6 +161,8 @@
>> next-level-cache = <&CLUSTER1_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> cpu7: cpu@103 {
>> @@ -161,6 +173,8 @@
>> next-level-cache = <&CLUSTER1_L2>;
>> operating-points-v2 = <&cpu_opp_table>;
>> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
>> +#cooling-cells = <2>; /* min followed by max */
>> +dynamic-power-coefficient = <311>;
>> };
>>
>> CLUSTER0_L2: l2-cache0 {
>>
Re: [PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs
Hi Viresh,
On 2018/5/25 6:40, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Do minor rearrangement as well to keep ordering consistent.
>
> Signed-off-by: Viresh Kumar
Thanks!
Applied to the hisilicon fix tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 586b281cd531..247024df714f 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -88,8 +88,8 @@
> next-level-cache = <&CLUSTER0_L2>;
> clocks = <&stub_clock 0>;
> operating-points-v2 = <&cpu_opp_table>;
> - #cooling-cells = <2>; /* min followed by max */
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> dynamic-power-coefficient = <311>;
> };
>
> @@ -101,6 +101,8 @@
> next-level-cache = <&CLUSTER0_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu2: cpu@2 {
> @@ -111,6 +113,8 @@
> next-level-cache = <&CLUSTER0_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu3: cpu@3 {
> @@ -121,6 +125,8 @@
> next-level-cache = <&CLUSTER0_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu4: cpu@100 {
> @@ -131,6 +137,8 @@
> next-level-cache = <&CLUSTER1_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu5: cpu@101 {
> @@ -141,6 +149,8 @@
> next-level-cache = <&CLUSTER1_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu6: cpu@102 {
> @@ -151,6 +161,8 @@
> next-level-cache = <&CLUSTER1_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> cpu7: cpu@103 {
> @@ -161,6 +173,8 @@
> next-level-cache = <&CLUSTER1_L2>;
> operating-points-v2 = <&cpu_opp_table>;
> cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> + #cooling-cells = <2>; /* min followed by max */
> + dynamic-power-coefficient = <311>;
> };
>
> CLUSTER0_L2: l2-cache0 {
>
Re: [PATCH] arm64: dts: hikey: Fix eMMC corruption regression
Hi John,
On 2018/5/26 4:10, John Stultz wrote:
> This patch is a partial revert of commit
> abd7d0972a19 ("arm64: dts: hikey: Enable HS200 mode on eMMC")
>
> which has been causing eMMC corruption on my HiKey board.
>
> Symptoms usually looked like:
>
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> ...
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc0: new HS200 MMC card at address 0001
> ...
> dwmmc_k3 f723d000.dwmmc0: Unexpected command timeout, state 3
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> print_req_error: I/O error, dev mmcblk0, sector 8810504
> Aborting journal on device mmcblk0p10-8.
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual
> 40HZ div = 31)
> mmc_host mmc0: Bus speed (slot 0) = 14880Hz (slot req 15000Hz, actual
> 14880HZ div = 0)
> EXT4-fs error (device mmcblk0p10): ext4_journal_check_start:61: Detected
> aborted journal
> EXT4-fs (mmcblk0p10): Remounting filesystem read-only
>
> And quite often this would result in a disk that wouldn't properly
> boot even with older kernels.
>
> It seems the max-frequency property added by the above patch is
> causing the problem, so remove it.
>
> Cc: Ryan Grachek
> Cc: Wei Xu
> Cc: Arnd Bergmann
> Cc: Ulf Hansson
> Cc: YongQin Liu
> Cc: Leo Yan
> Signed-off-by: John Stultz
Thanks!
Applied to the hisilicon fix tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index 724a0d3..edb4ee0 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -299,7 +299,6 @@
> /* GPIO blocks 16 thru 19 do not appear to be routed to pins */
>
> dwmmc_0: dwmmc0@f723d000 {
> - max-frequency = <15000>;
> cap-mmc-highspeed;
> mmc-hs200-1_8v;
> non-removable;
>
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
On Sat, May 26, 2018 at 07:30:47PM +0200, Salvatore Mesoraca wrote: > 2018-05-26 17:48 GMT+02:00 Alexey Dobriyan : > > On Sat, May 26, 2018 at 04:50:46PM +0200, Salvatore Mesoraca wrote: > >> Prevent a task from opening, in "write" mode, any /proc/*/mem > >> file that operates on the task's mm. > >> /proc/*/mem is mainly a debugging means and, as such, it shouldn't > >> be used by the inspected process itself. > >> Current implementation always allow a task to access its own > >> /proc/*/mem file. > >> A process can use it to overwrite read-only memory, making > >> pointless the use of security_file_mprotect() or other ways to > >> enforce RO memory. > > > > You can do it in security_ptrace_access_check() > > No, because that hook is skipped when mm == current->mm: > https://elixir.bootlin.com/linux/v4.17-rc6/source/kernel/fork.c#L OK > > or security_file_open() > > This is true, but it looks a bit overkill to me, especially since many of > the macros/functions used to handle proc's files won't be in scope > for an external LSM. > Is there any particular reason why you prefer it done via LSM? Well, it exists to implement all kinds of non-standard restrictions. You're probably blacklisting mprotect() and worry that compromised program might use /proc/self/mem instead. But you need to blacklist much more that mprotect(). I think forking a dummy "worker" process to open your /proc/*/mem and pass a descriptor back should still work with your patch.
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
On 5/26/2018 10:30 AM, Salvatore Mesoraca wrote: > 2018-05-26 17:48 GMT+02:00 Alexey Dobriyan : >> On Sat, May 26, 2018 at 04:50:46PM +0200, Salvatore Mesoraca wrote: >>> Prevent a task from opening, in "write" mode, any /proc/*/mem >>> file that operates on the task's mm. >>> /proc/*/mem is mainly a debugging means and, as such, it shouldn't >>> be used by the inspected process itself. >>> Current implementation always allow a task to access its own >>> /proc/*/mem file. >>> A process can use it to overwrite read-only memory, making >>> pointless the use of security_file_mprotect() or other ways to >>> enforce RO memory. >> You can do it in security_ptrace_access_check() > No, because that hook is skipped when mm == current->mm: > https://elixir.bootlin.com/linux/v4.17-rc6/source/kernel/fork.c#L > >> or security_file_open() > This is true, but it looks a bit overkill to me, especially since many of > the macros/functions used to handle proc's files won't be in scope > for an external LSM. > Is there any particular reason why you prefer it done via LSM? If you did a Yama style LSM it would be easy to configure. Even though it might make no sense to allow this behavior, someone, somewhere is counting on it. > > Thank you, > > Salvatore > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: KASAN: use-after-free Read in crypto_destroy_tfm
On Sat, May 26, 2018 at 7:40 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0644f186fc9d Merge tag 'for_linus' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=102bc25780 > kernel config: https://syzkaller.appspot.com/x/.config?x=61c12b53c2a25ec4 > dashboard link: https://syzkaller.appspot.com/bug?extid=352126a5be7ccb25754e > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+352126a5be7ccb257...@syzkaller.appspotmail.com Eric, do you remember if we had any recent fixes for this? > == > BUG: KASAN: use-after-free in crypto_destroy_tfm+0x2a3/0x300 > crypto/api.c:573 > Read of size 8 at addr 8801d9023238 by task syz-executor6/10078 > > CPU: 1 PID: 10078 Comm: syz-executor6 Not tainted 4.17.0-rc2+ #19 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > print_address_description+0x6c/0x20b mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > crypto_destroy_tfm+0x2a3/0x300 crypto/api.c:573 > crypto_free_rng include/crypto/rng.h:122 [inline] > rng_release+0x18/0x20 crypto/algif_rng.c:124 > alg_do_release crypto/af_alg.c:119 [inline] > alg_sock_destruct+0x92/0xe0 crypto/af_alg.c:362 > __sk_destruct+0xff/0xa40 net/core/sock.c:1566 > sk_destruct+0x78/0x90 net/core/sock.c:1601 > __sk_free+0x22e/0x340 net/core/sock.c:1612 > sk_free+0x42/0x50 net/core/sock.c:1623 > sock_put include/net/sock.h:1664 [inline] > af_alg_release+0x6e/0x90 crypto/af_alg.c:126 > sock_release+0x96/0x1b0 net/socket.c:594 > sock_close+0x16/0x20 net/socket.c:1149 > __fput+0x34d/0x890 fs/file_table.c:209 > fput+0x15/0x20 fs/file_table.c:243 > task_work_run+0x1e4/0x290 kernel/task_work.c:113 > exit_task_work include/linux/task_work.h:22 [inline] > do_exit+0x1aee/0x2730 kernel/exit.c:865 > do_group_exit+0x16f/0x430 kernel/exit.c:968 > get_signal+0x886/0x1960 kernel/signal.c:2469 > do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810 > exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162 > prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] > syscall_return_slowpath arch/x86/entry/common.c:265 [inline] > do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x455979 > RSP: 002b:7f4f4bbc2c68 EFLAGS: 0246 ORIG_RAX: 0036 > RAX: RBX: 7f4f4bbc36d4 RCX: 00455979 > RDX: 0001 RSI: 0117 RDI: 0014 > RBP: 0072bf50 R08: R09: > R10: 204f7000 R11: 0246 R12: > R13: 0519 R14: 006faaf8 R15: 0001 > > Allocated by task 4484: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 > __do_kmalloc_node mm/slab.c:3682 [inline] > __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3696 > __kmalloc_reserve.isra.38+0x3a/0xe0 net/core/skbuff.c:137 > __alloc_skb+0x14d/0x780 net/core/skbuff.c:205 > alloc_skb include/linux/skbuff.h:987 [inline] > netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline] > netlink_sendmsg+0xb01/0xfa0 net/netlink/af_netlink.c:1876 > sock_sendmsg_nosec net/socket.c:629 [inline] > sock_sendmsg+0xd5/0x120 net/socket.c:639 > ___sys_sendmsg+0x805/0x940 net/socket.c:2117 > __sys_sendmsg+0x115/0x270 net/socket.c:2155 > __do_sys_sendmsg net/socket.c:2164 [inline] > __se_sys_sendmsg net/socket.c:2162 [inline] > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162 > do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Freed by task 4484: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 > kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 > __cache_free mm/slab.c:3498 [inline] > kfree+0xd9/0x260 mm/slab.c:3813 > skb_free_head+0x99/0xc0 net/core/skbuff.c:550 > skb_release_data+0x690/0x860 net/core/skbuff.c:570 > skb_release_all+0x4a/0x60 net/core/skbuff.c:627 > __kfree_skb net/core/skbuff.c:641 [inline] > consume_skb+0x18b/0x550 net/core/skbuff.c:701 > netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] > netlink_unicast+0x593/0x740 net/netlink/af_netlink.c:1336 > netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901 > sock_sendmsg_nosec net/socket.c:629 [inline] > sock_sendmsg+0xd5/
WARNING: bad usercopy in __kvm_write_guest_page
Hello, syzbot found the following crash on: HEAD commit:73fcb1a370c7 Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15b3a82780 kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed dashboard link: https://syzkaller.appspot.com/bug?extid=083f3b88782aa3a46bdb compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1027dbcf80 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=159eff9780 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+083f3b88782aa3a46...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) [ cut here ] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'kvm_vcpu' (offset 23192, size 8)! WARNING: CPU: 0 PID: 4554 at mm/usercopy.c:81 usercopy_warn+0xf5/0x120 mm/usercopy.c:76 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4554 Comm: syz-executor726 Not tainted 4.17.0-rc5+ #58 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:usercopy_warn+0xf5/0x120 mm/usercopy.c:76 RSP: 0018:8801ad54f0b0 EFLAGS: 00010286 RAX: 007e RBX: 889d52f0 RCX: 8160aa5d RDX: RSI: 8160f711 RDI: 8801ad54ec10 RBP: 8801ad54f110 R08: 8801d96c8680 R09: 0006 R10: 8801d96c8680 R11: R12: 87d2fa60 R13: 87c19ec0 R14: R15: 0008 __check_heap_object+0x89/0xb5 mm/slab.c:4440 check_heap_object mm/usercopy.c:236 [inline] __check_object_size+0x4c7/0x5d9 mm/usercopy.c:259 check_object_size include/linux/thread_info.h:108 [inline] __copy_to_user include/linux/uaccess.h:104 [inline] __kvm_write_guest_page+0x90/0x140 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1828 kvm_vcpu_write_guest_page arch/x86/kvm/../../../virt/kvm/kvm_main.c:1849 [inline] kvm_vcpu_write_guest+0x65/0xe0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1883 kvm_write_guest_virt_system+0x8a/0x190 arch/x86/kvm/x86.c:4843 handle_vmptrst+0x1d2/0x260 arch/x86/kvm/vmx.c:8196 vmx_handle_exit+0x2c0/0x17b0 arch/x86/kvm/vmx.c:9234 vcpu_enter_guest+0x13af/0x6060 arch/x86/kvm/x86.c:7503 vcpu_run arch/x86/kvm/x86.c:7565 [inline] kvm_arch_vcpu_ioctl_run+0x33e/0x1690 arch/x86/kvm/x86.c:7742 kvm_vcpu_ioctl+0x79d/0x12e0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2560 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x443039 RSP: 002b:7ffc272242b8 EFLAGS: 0286 ORIG_RAX: 0010 RAX: ffda RBX: 004002c8 RCX: 00443039 RDX: RSI: ae80 RDI: 0005 RBP: 006cd018 R08: 2580 R09: 2580 R10: R11: 0286 R12: 00404080 R13: 00404110 R14: R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
On 2018-05-25 16:51, Tudor Ambarus wrote:
> Hi, Peter,
>
> On 04/11/2018 06:34 PM, Nicolas Ferre wrote:
>> I'll try to move forward with your detailed explanation and with my
>> contacts within the "product" team internally.
>
> We have talked with the hardware team, looks like there is an error in
> the description of the Master to Slave Access matrix. CPU accesses DDR2
> port0 through AXI matrix and not AHB. There is no conflict between CPU
> and LCDC DMA when accessing DDR2 ports. This explains why using CPU
> helps.
>
> The slave numbers from "Table 14-3 Master to Slave Access" are wrong.
> The 7th row should be removed and all the other rows from below it,
> shifted up with one level (DDR2 Port 1 is Slave no 7, DDR2 port 2 is
> Slave no 8, ... , APB1 is slave no 11).
Yes, the fact that row 7 (the 8th row, since there is a row 0, but I get
what you mean) should be removed was pretty much what I had guessed. But
what about the other strange things I found? To reiterate, this is my
PRxSy register content (zeroes shown as -):
PRxS0 33--3--3----
PRxS1 33--3--3----
PRxS2 33--
PRxS3 -3333---
PRxS4 33--
PRxS5 3---
PRxS6 33--33--
PRxS7 --3-3--3
PRxS8 -3---3--3--3
PRxS9 --3-3--3-33-333-
PRxS10 3--3
PRxS11 3-3-
PRxS12
PRxS13
PRxS14
PRxS15
So, PRxS7 matches row 8 (DDR2 port 1) in the datasheet.
And PRxS8 matches row 9 (DDR2 port 2) in the datasheet.
But PRxS9 is not matching row 10 (DDR2 port 3)!
And PRxS10-11 match rows 11-12 (APB 0-1) in the datasheet.
But also look at PRxS3 (Internal ROM), there's a missing 3 in the
first slot (A5)! Maybe the priority of that one can't be changed
for some fundamental reason? But there is no hint to that effect
in the datasheet AFAICT...
> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
> (7th slave).
I think I tried to arrange for that last time around. Not sure though,
so I will try again next week...
> Also, some information about your configuration is useful. Can you
> please tell us what NAND DMA configuration did you use? Are you using
> NAND storage for the videos that you are playing on the LCD screen?
Not sure what level of detail you are after?
We use W949D2CBJX5E LPDDR1 memories from Winbond. Years ago, I wrote some
LPDDR1 patches for at91bootstrap to driver/ddramc.c (which predate the
current upstream support) and to board/sama5d3xek/sama5d3xek.c (which doesn't
to this day support LPDDR1 upstream, but I guess it shouldn't and that we
should have a board of our own, so that part isn't really clean and also the
reason I never upstreamed it). Anyway, some other trivial glue was also
needed, but the meat are in those files. I just had a brief look at the
LPDDR1 support in the upstream ddramc.c file and our code is very similar.
But I did notice some differences and I will look into if that difference
is something that matters. I can show provide patches if you think they
are relevant?
We use this in the sam-ba .qml file when we flash the devices with sam-ba and
the nandflash applet (don't know if it's relevant, but it shows that we have
a 16-bit bus):
device: SAMA5D3 {
name: "sama5d3-linea"
aliases: []
description: "SAMA5D3 Linea"
config {
nandflash {
ioset: 1
busWidth: 16
header: 0xc0902405
}
}
}
*time passes*
Oh dear ... you said NAND *DMA* configuration. Nothing special that I know
of. So, the default? Anything specific I should check?
Further, we are not playing any video. The artifacts are visible on a
static screen on an otherwise "idle" system (i.e. just showing whatever
on the screen and accessing the DRAM with DMA is enough to trigger the
visual glitches).
Cheers,
Peter
KASAN: use-after-free Read in crypto_destroy_tfm
Hello, syzbot found the following crash on: HEAD commit:0644f186fc9d Merge tag 'for_linus' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=102bc25780 kernel config: https://syzkaller.appspot.com/x/.config?x=61c12b53c2a25ec4 dashboard link: https://syzkaller.appspot.com/bug?extid=352126a5be7ccb25754e compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+352126a5be7ccb257...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in crypto_destroy_tfm+0x2a3/0x300 crypto/api.c:573 Read of size 8 at addr 8801d9023238 by task syz-executor6/10078 CPU: 1 PID: 10078 Comm: syz-executor6 Not tainted 4.17.0-rc2+ #19 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 crypto_destroy_tfm+0x2a3/0x300 crypto/api.c:573 crypto_free_rng include/crypto/rng.h:122 [inline] rng_release+0x18/0x20 crypto/algif_rng.c:124 alg_do_release crypto/af_alg.c:119 [inline] alg_sock_destruct+0x92/0xe0 crypto/af_alg.c:362 __sk_destruct+0xff/0xa40 net/core/sock.c:1566 sk_destruct+0x78/0x90 net/core/sock.c:1601 __sk_free+0x22e/0x340 net/core/sock.c:1612 sk_free+0x42/0x50 net/core/sock.c:1623 sock_put include/net/sock.h:1664 [inline] af_alg_release+0x6e/0x90 crypto/af_alg.c:126 sock_release+0x96/0x1b0 net/socket.c:594 sock_close+0x16/0x20 net/socket.c:1149 __fput+0x34d/0x890 fs/file_table.c:209 fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1e4/0x290 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1aee/0x2730 kernel/exit.c:865 do_group_exit+0x16f/0x430 kernel/exit.c:968 get_signal+0x886/0x1960 kernel/signal.c:2469 do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810 exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x455979 RSP: 002b:7f4f4bbc2c68 EFLAGS: 0246 ORIG_RAX: 0036 RAX: RBX: 7f4f4bbc36d4 RCX: 00455979 RDX: 0001 RSI: 0117 RDI: 0014 RBP: 0072bf50 R08: R09: R10: 204f7000 R11: 0246 R12: R13: 0519 R14: 006faaf8 R15: 0001 Allocated by task 4484: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 __do_kmalloc_node mm/slab.c:3682 [inline] __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3696 __kmalloc_reserve.isra.38+0x3a/0xe0 net/core/skbuff.c:137 __alloc_skb+0x14d/0x780 net/core/skbuff.c:205 alloc_skb include/linux/skbuff.h:987 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline] netlink_sendmsg+0xb01/0xfa0 net/netlink/af_netlink.c:1876 sock_sendmsg_nosec net/socket.c:629 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:639 ___sys_sendmsg+0x805/0x940 net/socket.c:2117 __sys_sendmsg+0x115/0x270 net/socket.c:2155 __do_sys_sendmsg net/socket.c:2164 [inline] __se_sys_sendmsg net/socket.c:2162 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 4484: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 skb_free_head+0x99/0xc0 net/core/skbuff.c:550 skb_release_data+0x690/0x860 net/core/skbuff.c:570 skb_release_all+0x4a/0x60 net/core/skbuff.c:627 __kfree_skb net/core/skbuff.c:641 [inline] consume_skb+0x18b/0x550 net/core/skbuff.c:701 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0x593/0x740 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:629 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:639 ___sys_sendmsg+0x805/0x940 net/socket.c:2117 __sys_sendmsg+0x115/0x270 net/socket.c:2155 __do_sys_sendmsg net/socket.c:2164 [inline] __se_sys_sendmsg net/socket.c:2162 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162 do_syscall_64+0x1b1/0x800 arch/x86/entry/commo
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
2018-05-26 17:48 GMT+02:00 Alexey Dobriyan : > On Sat, May 26, 2018 at 04:50:46PM +0200, Salvatore Mesoraca wrote: >> Prevent a task from opening, in "write" mode, any /proc/*/mem >> file that operates on the task's mm. >> /proc/*/mem is mainly a debugging means and, as such, it shouldn't >> be used by the inspected process itself. >> Current implementation always allow a task to access its own >> /proc/*/mem file. >> A process can use it to overwrite read-only memory, making >> pointless the use of security_file_mprotect() or other ways to >> enforce RO memory. > > You can do it in security_ptrace_access_check() No, because that hook is skipped when mm == current->mm: https://elixir.bootlin.com/linux/v4.17-rc6/source/kernel/fork.c#L > or security_file_open() This is true, but it looks a bit overkill to me, especially since many of the macros/functions used to handle proc's files won't be in scope for an external LSM. Is there any particular reason why you prefer it done via LSM? Thank you, Salvatore
Re: [PATCH v7 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))
Hello Kirill, The whole patch set looks good to me now. Acked-by: Vladimir Davydov Thanks, Vladimir On Tue, May 22, 2018 at 01:07:10PM +0300, Kirill Tkhai wrote: > Hi, > > this patches solves the problem with slow shrink_slab() occuring > on the machines having many shrinkers and memory cgroups (i.e., > with many containers). The problem is complexity of shrink_slab() > is O(n^2) and it grows too fast with the growth of containers > numbers. > > Let we have 200 containers, and every container has 10 mounts > and 10 cgroups. All container tasks are isolated, and they don't > touch foreign containers mounts. > > In case of global reclaim, a task has to iterate all over the memcgs > and to call all the memcg-aware shrinkers for all of them. This means, > the task has to visit 200 * 10 = 2000 shrinkers for every memcg, > and since there are 2000 memcgs, the total calls of do_shrink_slab() > are 2000 * 2000 = 400. > > 4 million calls are not a number operations, which can takes 1 cpu cycle. > E.g., super_cache_count() accesses at least two lists, and makes arifmetical > calculations. Even, if there are no charged objects, we do these calculations, > and replaces cpu caches by read memory. I observed nodes spending almost 100% > time in kernel, in case of intensive writing and global reclaim. The writer > consumes pages fast, but it's need to shrink_slab() before the reclaimer > reached shrink pages function (and frees SWAP_CLUSTER_MAX pages). Even if > there is no writing, the iterations just waste the time, and slows reclaim > down. > > Let's see the small test below: > > $echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy > $mkdir /sys/fs/cgroup/memory/ct > $echo 4000M > /sys/fs/cgroup/memory/ct/memory.kmem.limit_in_bytes > $for i in `seq 0 4000`; > do mkdir /sys/fs/cgroup/memory/ct/$i; > echo $$ > /sys/fs/cgroup/memory/ct/$i/cgroup.procs; > mkdir -p s/$i; mount -t tmpfs $i s/$i; touch s/$i/file; > done > > Then, let's see drop caches time (5 sequential calls): > $time echo 3 > /proc/sys/vm/drop_caches > > 0.00user 13.78system 0:13.78elapsed 99%CPU > 0.00user 5.59system 0:05.60elapsed 99%CPU > 0.00user 5.48system 0:05.48elapsed 99%CPU > 0.00user 8.35system 0:08.35elapsed 99%CPU > 0.00user 8.34system 0:08.35elapsed 99%CPU > > > Last four calls don't actually shrink something. So, the iterations > over slab shrinkers take 5.48 seconds. Not so good for scalability. > > The patchset solves the problem by making shrink_slab() of O(n) > complexity. There are following functional actions: > > 1)Assign id to every registered memcg-aware shrinker. > 2)Maintain per-memcgroup bitmap of memcg-aware shrinkers, > and set a shrinker-related bit after the first element > is added to lru list (also, when removed child memcg > elements are reparanted). > 3)Split memcg-aware shrinkers and !memcg-aware shrinkers, > and call a shrinker if its bit is set in memcg's shrinker > bitmap. > (Also, there is a functionality to clear the bit, after > last element is shrinked). > > This gives signify performance increase. The result after patchset is applied: > > $time echo 3 > /proc/sys/vm/drop_caches > > 0.00user 1.10system 0:01.10elapsed 99%CPU > 0.00user 0.00system 0:00.01elapsed 64%CPU > 0.00user 0.01system 0:00.01elapsed 82%CPU > 0.00user 0.00system 0:00.01elapsed 64%CPU > 0.00user 0.01system 0:00.01elapsed 82%CPU > > The results show the performance increases at least in 548 times. > > So, the patchset makes shrink_slab() of less complexity and improves > the performance in such types of load I pointed. This will give a profit > in case of !global reclaim case, since there also will be less > do_shrink_slab() calls. > > This patchset is made against linux-next.git tree. > > v7: Refactorings and readability improvements. > > v6: Added missed rcu_dereference() to memcg_set_shrinker_bit(). > Use different functions for allocation and expanding map. > Use new memcg_shrinker_map_size variable in memcontrol.c. > Refactorings. > > v5: Make the optimizing logic under CONFIG_MEMCG_SHRINKER instead of MEMCG && > !SLOB > > v4: Do not use memcg mem_cgroup_idr for iteration over mem cgroups > > v3: Many changes requested in commentaries to v2: > > 1)rebase on prealloc_shrinker() code base > 2)root_mem_cgroup is made out of memcg maps > 3)rwsem replaced with shrinkers_nr_max_mutex > 4)changes around assignment of shrinker id to list lru > 5)everything renamed > > v2: Many changes requested in commentaries to v1: > > 1)the code mostly moved to mm/memcontrol.c; > 2)using IDR instead of array of shrinkers; > 3)added a possibility to assign list_lru shrinker id > at the time of shrinker registering; > 4)reorginized locking and renamed functions and variables. > > --- > > Kirill Tkhai (16): > list_lru: Combine code under the same define > mm: Introduce CONFIG_MEMCG_KMEM as combination of CONFIG_MEMCG && > !CONFIG_SLOB > mm: Assign id to every memcg
Re: Bugs involving maliciously crafted file system
On Thu, May 24, 2018 at 1:41 AM, Theodore Y. Ts'o wrote: > On Wed, May 23, 2018 at 01:01:59PM -0500, Eric Sandeen wrote: >> >> What I'm personally hung up on are the bugs where the "exploit" involves >> merely >> mounting a crafted filesystem that in reality would never (until the heat >> death >> of the universe) corrupt itself into that state on its own; it's the >> "malicious >> image" case, which is quite different than exposing fundamental bugs like the >> SB_BORN race or or the user-exploitable ext4 flaw you mentioned in your >> reply. >> Those are more insidious and/or things which can be hit by real users in >> real life. > > Well, it *can* be hit in real life. If you have a system which auto > mounts USB sticks, then an attacker might be able to weaponize that > bug by creating a USB stick where mounted and the user opens a > particular file, the buffer overrun causes code to be executed that > grabs the user's credentials (e.g., ssh-agent keys, OATH creds, etc.) > and exfiltrates them to a collection server. > > Fedora and Chrome OS might be two such platforms where someone could > very easily create a weaponized exploit tool where you could insert a > file system buffer overrun bug, and "hey presto!" it becomes a serious > zero day vulnerability. > > (I recently suggested to a security researcher who was concerned that > file system developers weren't taking these sorts of things seriously > enough could do a service to the community by creating a demonstration > about how these sorts of bugs can be weaponized. And I suspect it > could be about just as easily on Chrome OS as Fedora, and that can be > one way that an argument could be made to management that more > resources should be applied to this problem. :-) > > Of course, not all bugs triggered by a maliciously crafted file system > are equally weaponizable. An errors=panic or a NULL derefrence are > probably not easily exploitable at all. A buffer overrun (and I fixed > two in ext4 in the last two days while being stuck in a T13 standards > meeting, so I do feel your pain) might be a very different story. > > Solutions > - > > One of the things I've wanted to get help from the syzbot folks is if > there was some kind of machine learning or expert system evaluation > that could be done so malicious image bugs could be binned into > different categories, based on how easily they can be weaponized. > That way, when there is a resource shortage situation, humans can be > more easily guided into detremining which bugs should be prioritized > and given attention, and which we can defer to when we have more time. Hi Ted, I don't see that "some kind of machine learning or expert system evaluation" is feasible. At least not in short/mid-term. There are innocently-looking bugs that actually turn out to be very bad, and there are badly looking at first glance bugs that actually not that bad for some complex reasons. Full security assessment is a complex task and I think stays "human expert area" for now. One can get some coarse estimation by searching for "use-after-free" and "out-of-bounds" on the dashboard. Also note that even the most innocent bugs can block ability to discover deeper and worse bugs during any runtime testing. So ultimately all need to be fixed if we want correct, stable and secure kernel. To significant degree it's like compiler warnings: you either fix them all, or turn them off, there is no middle ground of having thousands of unfixed warnings and still getting benefit from them. > Or maybe it would be useful if there was a way where maintainers could > be able to annotate bugs with priority and severity levels, and maybe > make comments that can be viewed from the Syzbot dashboard UI. This looks more realistic. +Tetsuo proposed something similar: https://github.com/google/syzkaller/issues/608 I think to make it useful we need to settle on some small set of well-defined tags for bugs that we can show on the dashboard. Arbitrary detailed free-form comments can be left on the mailing list threads that are always referenced from the dashboard. What tags would you use today for existing bugs? One would be "security-critical", right? > The other thing that perhaps could be done is to set up a system where > the USB stick is automounted in a guest VM (using libvirt in Fedora, > and perhaps Crostini for Chrome OS), and the contents of the file > system would then get exported from the guest OS to the host OS using > either NFS or 9P. (9P2000.u is the solution that was used in > gVisor[1].) > > [1] https://github.com/google/gvisor > > It could be that putting this kind of security layer in front to > automounted USB sticks is less work than playing whack-a-mole fixing a > lot of security bugs with maliciously crafted file systems. I don't think that auto mounting or "requires root" is significantly relevant in this context. If one needs to use a USB stick, or DVD or just any filesystem that they did not
Re: Why does d_splice_alias need to check IS_ROOT?
On Sun, May 27, 2018 at 12:33:40AM +0800, Lei Chen wrote: > Hello list, > > I'm insteresting in how hard link and denry lookup work and their > implementation. > > I know that this interface tries to connect an inode to a dentry, but > why does it need > to check whether the inode alias IS_ROOT if the inode represents a directory? > And the code process in different way according to check result. What > occasions > are they used for? If it's disconnected (and not an ancestor of the place where we want it), we can just move it in place, no questions asked. If it is *NOT* disconnected, the only thing we can do is to detach it from where it is and move it over. Which takes a lot more care wrt locking.
[PATCH] selftests: intel_pstate: notification about privilege required to run intel_pstate testing script
The intel_pstate related testing script need root level privileges when trying to access certain file for the successful execution of the script.But this is not the case always like when using evaluation only mode, which only require user level privilege. This patch is to notify the user about the privilege the script demands for the successful execution of the test. Signed-off-by: Jeffrin Jose T (Rajagiri SET) --- tools/testing/selftests/intel_pstate/run.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/testing/selftests/intel_pstate/run.sh b/tools/testing/selftests/intel_pstate/run.sh index 6ded61670f6d..4ddd389c2cb9 100755 --- a/tools/testing/selftests/intel_pstate/run.sh +++ b/tools/testing/selftests/intel_pstate/run.sh @@ -33,6 +33,12 @@ EVALUATE_ONLY=0 # Kselftest framework requirement - SKIP code is 4. ksft_skip=4 +msg="skip all tests:" +if [ $UID != 0 ] && [ $EVALUATE_ONLY == 0 ]; then +echo $msg please run this as root >&2 +exit $ksft_skip +fi + if ! uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ | grep -q x86; then echo "$0 # Skipped: Test can only run on x86 architectures." exit $ksft_skip -- 2.17.0
Re: [PATCH 1/1] media: uvc_driver: fix USB Camera ref leak denial of service
Hi David,
On Saturday, 26 May 2018 19:37:18 EEST David Fries wrote:
> Laurent and Mauro,
>
> I've reviewed Philipp Zabel's 49770 patch, it looks like they
> equivalent, but take a different path. My version does the unref in
> uvc_unregister_video, Zabel's does the unref in each caller of
> uvc_unregister_video. I think I would prefer it to be in fewer
> places.
While I agree that avoiding code duplication is a good idea, we also need to
ensure that the unref call is the very last operation we perform, otherwise
we'll risk a use-after-free. The uvc_unregister_video() function is called
last so that's guaranteed with your patch. However, by hiding the unref there
from the callers, I wonder whether it couldn't result in issues in the future
if someone decides to add code after the uvc_unregister_video() calls without
noticing the unref issue.
> Any ideas on the sysfs group 'power' not found bug on removal while on
> use?
I haven't had time to investigate them yet, please feel free to give it a go
without waiting for me :-)
> Thanks, it will be great to get this fixed.
>
> On Sat, May 26, 2018 at 07:21:11PM +0300, Laurent Pinchart wrote:
> > Hi David,
> >
> > Thank you for the patch.
> >
> > On Saturday, 26 May 2018 18:50:46 EEST David Fries wrote:
> > > Commit 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic
> > > variable to a reference count")
> > > didn't take into account that while the old counter was initialized to
> > > 0 (no stream open), kref_init starts with a reference of 1. The
> > > reference count on unplug no longer reaches 0, uvc_delete isn't
> > > called, and evdev doesn't release /dev/input/event*. Plug and unplug
> > > enough times and it runs out of device minors preventing any new input
> > > device and the use of newly plugged in USB video cameras until the
> > > system is rebooted.
> > >
> > > Signed-off-by: David Fries
> > > Cc: Guennadi Liakhovetski
> > > Cc: Laurent Pinchart
> > > Cc: Mauro Carvalho Chehab
> > > Cc: sta...@vger.kernel.org
> >
> > Philipp Zabel has already posted a similar patch, see https://
> > patchwork.linuxtv.org/patch/49770/
> >
> > Mauro,
> >
> > This is a serious issue so I'd like to get the patch merged in v4.18, but
> > it could be argued that it's getting late for that, especially given that
> > the bug has been there since v4.14. Would you be OK merging this in v4.18
> > ? If so could you pick https://patchwork.linuxtv.org/patch/49770/ up, or
> > would you like me to send a pull request ?
> >
> > > ---
> > >
> > > drivers/media/usb/uvc/uvc_driver.c | 11 ---
> > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > > b/drivers/media/usb/uvc/uvc_driver.c index 2469b49..3cbdc87 100644
> > > --- a/drivers/media/usb/uvc/uvc_driver.c
> > > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > > @@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct
> > > uvc_device
> > > *dev) {
> > >
> > > struct uvc_streaming *stream;
> > >
> > > - /* Unregistering all video devices might result in uvc_delete()
being
> > > - * called from inside the loop if there's no open file handle. To
> > > avoid
> > > - * that, increment the refcount before iterating over the streams
and
> > > - * decrement it when done.
> > > - */
> > > - kref_get(&dev->ref);
> > > -
> > >
> > > list_for_each_entry(stream, &dev->streams, list) {
> > >
> > > if (!video_is_registered(&stream->vdev))
> > >
> > > continue;
> > >
> > > @@ -1888,6 +1881,10 @@ static void uvc_unregister_video(struct
> > > uvc_device
> > > *dev) uvc_debugfs_cleanup_stream(stream);
> > >
> > > }
> > >
> > > + /* Release the reference implicit in kref_init from uvc_probe,
> > > + * the UVC device won't be deleted until the last file descriptor
> > > + * is also closed.
> > > + */
> > >
> > > kref_put(&dev->ref, uvc_delete);
> > >
> > > }
--
Regards,
Laurent Pinchart
Re: general protection fault in __radix_tree_delete
On Sun, May 13, 2018 at 10:26:15AM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote: > On Sun, Apr 29, 2018 at 7:00 PM, syzbot > wrote: > > Hello, > > > > syzbot hit the following crash on upstream commit > > cdface5209349930ae1b51338763c8e029971b97 (Sun Apr 29 03:07:21 2018 +) > > Merge tag 'for_linus_stable' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 > > syzbot dashboard link: > > https://syzkaller.appspot.com/bug?extid=549decbd1891d501b6d5 > > > > So far this crash happened 8 times on upstream. > > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6647588371562496 > > syzkaller reproducer: > > https://syzkaller.appspot.com/x/repro.syz?id=4781854846615552 > > Raw console output: > > https://syzkaller.appspot.com/x/log.txt?id=4580574157078528 > > Kernel config: > > https://syzkaller.appspot.com/x/.config?id=7043958930931867332 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+549decbd1891d501b...@syzkaller.appspotmail.com > > It will help syzbot understand when the bug is fixed. See footer for > > details. > > If you forward the report, please keep this part and the footer. > > > This crash was bisected as introduced by: > > commit faeb7833eee0d6afe0ecb6bdfa6042556c2c352e > Author: Roman Kagan > Date: Thu Feb 1 16:48:32 2018 +0300 > > kvm: x86: hyperv: guest->host event signaling via eventfd > > https://gist.githubusercontent.com/dvyukov/df4971d7dfd1b37bedb5bfa0c95f9ebc/raw/ee8b7804788049f80625563e0322090c798c4544/gistfile1.txt > > > > > kasan: CONFIG_KASAN_INLINE enabled > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > general protection fault: [#1] SMP KASAN > > Dumping ftrace buffer: > >(ftrace buffer empty) > > Modules linked in: > > CPU: 0 PID: 4525 Comm: syz-executor786 Not tainted 4.17.0-rc2+ #23 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] > > RIP: 0010:__radix_tree_delete+0x74/0x230 lib/radix-tree.c:1989 > > RSP: 0018:8801d9137108 EFLAGS: 00010206 > > RAX: 0003 RBX: dc00 RCX: 11003b226e3e > > RDX: RSI: 8768eeed RDI: 8801a7dac168 > > RBP: 8801d91371a8 R08: 8801d962c1c0 R09: ed0034fb5811 > > R10: 8801d91372b8 R11: 8801a7dac08f R12: > > R13: 8801a7dac168 R14: 0018 R15: 8801d9137230 > > FS: 01df3880() GS:8801dae0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 2100 CR3: 0001d9104000 CR4: 001426f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > radix_tree_delete_item+0x148/0x2d0 lib/radix-tree.c:2050 > > idr_remove+0x46/0x60 lib/idr.c:157 > > kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1433 [inline] > > kvm_vm_ioctl_hv_eventfd+0x1df/0x24b arch/x86/kvm/hyperv.c:1451 > > kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563 > > kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100 > > vfs_ioctl fs/ioctl.c:46 [inline] > > file_ioctl fs/ioctl.c:500 [inline] > > do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684 > > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 > > __do_sys_ioctl fs/ioctl.c:708 [inline] > > __se_sys_ioctl fs/ioctl.c:706 [inline] > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706 > > do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > RIP: 0033:0x440069 > > RSP: 002b:7ffcf0b02cd8 EFLAGS: 0217 ORIG_RAX: 0010 > > RAX: ffda RBX: 6d766b2f7665642f RCX: 00440069 > > RDX: 2000 RSI: 4018aebd RDI: 00a9 > > RBP: 006cb018 R08: 7ffcf0b02cf0 R09: 7ffcf0b02cf0 > > R10: 7ffcf0b02cf0 R11: 0217 R12: 004018a0 > > R13: 00401930 R14: R15: > > Code: 3f 9a 88 48 c7 45 88 80 ee 68 87 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2 > > f2 c7 40 08 f3 f3 f3 f3 e8 a3 51 10 fa 4c 89 f0 48 c1 e8 03 <80> 3c 18 00 0f > > 85 97 01 00 00 48 8d 55 d8 4c 8d 7a c0 49 8b 1e > > RIP: __read_once_size include/linux/compiler.h:188 [inline] RSP: > > 8801d9137108 > > RIP: __radix_tree_delete+0x74/0x230 lib/radix-tree.c:1989 RSP: > > 8801d9137108 > > ---[ end trace 79327005f044daef ]--- > > > > > > --- > > This bug is generated by a dumb bot. It may contain errors. > > See https://goo.gl/tpsmEJ for details. > > Direct all questions to syzkal...@googlegroups.com. > > > > syzbot will keep track of this bug report. > > If you forgot to add the Reported-by tag, once the fix for this bug is > > merged > > into any tree, please reply to this email with: > > #syz fix: exact-commit-title This seems to have
Re: [PATCH 1/1] media: uvc_driver: fix USB Camera ref leak denial of service
Laurent and Mauro,
I've reviewed Philipp Zabel's 49770 patch, it looks like they
equivalent, but take a different path. My version does the unref in
uvc_unregister_video, Zabel's does the unref in each caller of
uvc_unregister_video. I think I would prefer it to be in fewer
places.
Any ideas on the sysfs group 'power' not found bug on removal while on
use?
Thanks, it will be great to get this fixed.
On Sat, May 26, 2018 at 07:21:11PM +0300, Laurent Pinchart wrote:
> Hi David,
>
> Thank you for the patch.
>
> On Saturday, 26 May 2018 18:50:46 EEST David Fries wrote:
> > Commit 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic
> > variable to a reference count")
> > didn't take into account that while the old counter was initialized to
> > 0 (no stream open), kref_init starts with a reference of 1. The
> > reference count on unplug no longer reaches 0, uvc_delete isn't
> > called, and evdev doesn't release /dev/input/event*. Plug and unplug
> > enough times and it runs out of device minors preventing any new input
> > device and the use of newly plugged in USB video cameras until the
> > system is rebooted.
> >
> > Signed-off-by: David Fries
> > Cc: Guennadi Liakhovetski
> > Cc: Laurent Pinchart
> > Cc: Mauro Carvalho Chehab
> > Cc: sta...@vger.kernel.org
>
> Philipp Zabel has already posted a similar patch, see https://
> patchwork.linuxtv.org/patch/49770/
>
> Mauro,
>
> This is a serious issue so I'd like to get the patch merged in v4.18, but it
> could be argued that it's getting late for that, especially given that the
> bug
> has been there since v4.14. Would you be OK merging this in v4.18 ? If so
> could you pick https://patchwork.linuxtv.org/patch/49770/ up, or would you
> like me to send a pull request ?
>
> > ---
> > drivers/media/usb/uvc/uvc_driver.c | 11 ---
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c index 2469b49..3cbdc87 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct uvc_device
> > *dev) {
> > struct uvc_streaming *stream;
> >
> > - /* Unregistering all video devices might result in uvc_delete() being
> > -* called from inside the loop if there's no open file handle. To avoid
> > -* that, increment the refcount before iterating over the streams and
> > -* decrement it when done.
> > -*/
> > - kref_get(&dev->ref);
> > -
> > list_for_each_entry(stream, &dev->streams, list) {
> > if (!video_is_registered(&stream->vdev))
> > continue;
> > @@ -1888,6 +1881,10 @@ static void uvc_unregister_video(struct uvc_device
> > *dev) uvc_debugfs_cleanup_stream(stream);
> > }
> >
> > + /* Release the reference implicit in kref_init from uvc_probe,
> > +* the UVC device won't be deleted until the last file descriptor
> > +* is also closed.
> > +*/
> > kref_put(&dev->ref, uvc_delete);
> > }
>
> --
> Regards,
>
> Laurent Pinchart
>
>
--
David Fries
Why does d_splice_alias need to check IS_ROOT?
Hello list,
I'm insteresting in how hard link and denry lookup work and their
implementation.
I know that this interface tries to connect an inode to a dentry, but
why does it need
to check whether the inode alias IS_ROOT if the inode represents a directory?
And the code process in different way according to check result. What
occasions
are they used for?
struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
{
if (S_ISDIR(inode->i_mode)) {
struct dentry *new = __d_find_any_alias(inode);
if (unlikely(new)) {
if (unlikely(d_ancestor(new, dentry))) {
/*the code here is to forbidden ancestor hard link*/
} else if (!IS_ROOT(new)) {
__d_unalias(inode, dentry, new);
} else {
__d_move(new, dentry, false);
}
}
}
}
Thanks in advance.
Regards,
Larry
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:18, Laurent Pinchart wrote: > On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote: >> Hi Dimitri, > > And sorry for the spelling mistake :-/ That's also a kinda correct spelling. No worries ;)
Re: [PATCH] crypto: chtls - fix a missing-check bug
On Fri, May 18, 2018 at 02:55:35PM -0500, Wenwen Wang wrote: > In do_chtls_setsockopt(), the tls crypto info is first copied from the > poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the > 'version' of the crypto info is checked. If the version is not as expected, > i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that > the provided crypto info is not supported yet. Then, the 'cipher_type' > field of the 'tmp_crypto_info' is also checked to see if it is > TLS_CIPHER_AES_GCM_128. If it is, the whole struct of > tls12_crypto_info_aes_gcm_128 is copied from the pointer 'optval' and then > the function chtls_setkey() is invoked to set the key. > > Given that the 'optval' pointer resides in userspace, a malicious userspace > process can race to change the data pointed by 'optval' between the two > copies. For example, a user can provide a crypto info with TLS_1_2_VERSION > and TLS_CIPHER_AES_GCM_128. After the first copy, the user can modify the > 'version' and the 'cipher_type' fields to any versions and/or cipher types > that are not allowed. This way, the user can bypass the checks, inject > bad data to the kernel, cause chtls_setkey() to set a wrong key or other > issues. > > This patch reuses the data copied in the first try so as to ensure these > checks will not be bypassed. > > Signed-off-by: Wenwen Wang Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:16, Laurent Pinchart wrote: > Hi Dimitri, > > Thank you for the patch. > > I'll review this in details, but as this patch is based on the "[PATCH/RFC > 1/4] drm: Add colorkey properties" patch I've submitted, please retain the > authorship, both in the Signed-off-by line, and in the patch author in git. Okay. /I think/ I've seen requests to do the other way around for the picked up and re-worked patches, though I don't mind at all to keep your authorship. I'll change the authorship in the next iteration. Waiting for you review comments, thanks.
Re: [PATCH] crypto: inside-secure - do not use memset on MMIO
On Thu, May 17, 2018 at 03:22:14PM +0200, Antoine Tenart wrote:
> This patch fixes the Inside Secure driver which uses a memtset() call to
> set an MMIO area from the cryptographic engine to 0. This is wrong as
> memset() isn't guaranteed to work on MMIO for many reasons. This led to
> kernel paging request panics in certain cases. Use memset_io() instead.
>
> Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto
> engine driver")
> Reported-by: Ofer Heifetz
> Signed-off-by: Antoine Tenart
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 00/10] crypto: inside-secure - AEAD support
On Mon, May 14, 2018 at 03:10:54PM +0200, Antoine Tenart wrote: > This series brings AEAD algorithms to the Inside Secure SafeXcel driver. > The first 7 commits rework the driver to allow the future AEAD addition, > and then 3 commits add AEAD functions and 3 algorithms. > > This is based on top of v4.17-rc5. > > Thanks! > Antoine > > Since v1: > - Reworked the driver to remove VLA's and added a custom on-stack > request definition in the driver, to be used in the invalidation > process. (Patch 1/10 was replaced, patch 8/10 was reworked). > - Rebased on top of v4.17-rc5 (was -rc3). > > Antoine Tenart (10): > crypto: inside-secure - remove VLAs > crypto: inside-secure - rework cipher functions for future AEAD > support > crypto: inside-secure - rework the alg type settings in the context > crypto: inside-secure - make the context control size dynamic > crypto: inside-secure - make the key and context size computation > dynamic > crypto: inside-secure - fix the hash then encrypt/decrypt types > crypto: inside-secure - improve error reporting > crypto: inside-secure - authenc(hmac(sha256),cbc(aes)) support > crypto: inside-secure - authenc(hmac(sha224),cbc(aes)) support > crypto: inside-secure - authenc(hmac(sha1),cbc(aes)) support > > drivers/crypto/Kconfig| 1 + > drivers/crypto/inside-secure/safexcel.c | 32 + > drivers/crypto/inside-secure/safexcel.h | 44 +- > .../crypto/inside-secure/safexcel_cipher.c| 642 ++ > drivers/crypto/inside-secure/safexcel_hash.c | 23 +- > 5 files changed, 600 insertions(+), 142 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/1] media: uvc_driver: fix USB Camera ref leak denial of service
Hi David,
Thank you for the patch.
On Saturday, 26 May 2018 18:50:46 EEST David Fries wrote:
> Commit 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic
> variable to a reference count")
> didn't take into account that while the old counter was initialized to
> 0 (no stream open), kref_init starts with a reference of 1. The
> reference count on unplug no longer reaches 0, uvc_delete isn't
> called, and evdev doesn't release /dev/input/event*. Plug and unplug
> enough times and it runs out of device minors preventing any new input
> device and the use of newly plugged in USB video cameras until the
> system is rebooted.
>
> Signed-off-by: David Fries
> Cc: Guennadi Liakhovetski
> Cc: Laurent Pinchart
> Cc: Mauro Carvalho Chehab
> Cc: sta...@vger.kernel.org
Philipp Zabel has already posted a similar patch, see https://
patchwork.linuxtv.org/patch/49770/
Mauro,
This is a serious issue so I'd like to get the patch merged in v4.18, but it
could be argued that it's getting late for that, especially given that the bug
has been there since v4.14. Would you be OK merging this in v4.18 ? If so
could you pick https://patchwork.linuxtv.org/patch/49770/ up, or would you
like me to send a pull request ?
> ---
> drivers/media/usb/uvc/uvc_driver.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 2469b49..3cbdc87 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct uvc_device
> *dev) {
> struct uvc_streaming *stream;
>
> - /* Unregistering all video devices might result in uvc_delete() being
> - * called from inside the loop if there's no open file handle. To avoid
> - * that, increment the refcount before iterating over the streams and
> - * decrement it when done.
> - */
> - kref_get(&dev->ref);
> -
> list_for_each_entry(stream, &dev->streams, list) {
> if (!video_is_registered(&stream->vdev))
> continue;
> @@ -1888,6 +1881,10 @@ static void uvc_unregister_video(struct uvc_device
> *dev) uvc_debugfs_cleanup_stream(stream);
> }
>
> + /* Release the reference implicit in kref_init from uvc_probe,
> + * the UVC device won't be deleted until the last file descriptor
> + * is also closed.
> + */
> kref_put(&dev->ref, uvc_delete);
> }
--
Regards,
Laurent Pinchart
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote:
> Hi Dimitri,
And sorry for the spelling mistake :-/
> Thank you for the patch.
>
> I'll review this in details, but as this patch is based on the "[PATCH/RFC
> 1/4] drm: Add colorkey properties" patch I've submitted, please retain the
> authorship, both in the Signed-off-by line, and in the patch author in git.
>
> On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent or gain adjustment
> > of the pixels component values.
> >
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds nine generic DRM plane
> > properties related to the color keying to cover various HW capabilities.
> >
> > This patch is based on the initial work done by Laurent Pinchart, most of
> > credits for this patch goes to him.
> >
> > Signed-off-by: Dmitry Osipenko
> > ---
> >
> > drivers/gpu/drm/drm_atomic.c | 36 ++
> > drivers/gpu/drm/drm_blend.c | 229 +++
> > include/drm/drm_blend.h | 3 +
> > include/drm/drm_plane.h | 77
> > 4 files changed, 345 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 895741e9cd7d..5b808cb68654 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane, state->rotation = val;
> >
> > } else if (property == plane->zpos_property) {
> >
> > state->zpos = val;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + state->colorkey.mode = val;
> > + } else if (property == plane->colorkey.min_property) {
> > + state->colorkey.min = val;
> > + } else if (property == plane->colorkey.max_property) {
> > + state->colorkey.max = val;
> > + } else if (property == plane->colorkey.format_property) {
> > + state->colorkey.format = val;
> > + } else if (property == plane->colorkey.mask_property) {
> > + state->colorkey.mask = val;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + state->colorkey.inverted_match = val;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + state->colorkey.replacement_mask = val;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + state->colorkey.replacement_value = val;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + state->colorkey.replacement_format = val;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > state->color_encoding = val;
> >
> > } else if (property == plane->color_range_property) {
> >
> > @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane
> > *plane,
> >
> > *val = state->rotation;
> >
> > } else if (property == plane->zpos_property) {
> >
> > *val = state->zpos;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + *val = state->colorkey.mode;
> > + } else if (property == plane->colorkey.min_property) {
> > + *val = state->colorkey.min;
> > + } else if (property == plane->colorkey.max_property) {
> > + *val = state->colorkey.max;
> > + } else if (property == plane->colorkey.format_property) {
> > + *val = state->colorkey.format;
> > + } else if (property == plane->colorkey.mask_property) {
> > + *val = state->colorkey.mask;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + *val = state->colorkey.inverted_match;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + *val = state->colorkey.replacement_mask;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + *val = state->colorkey.replacement_value;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + *val = state->colorkey.replacement_format;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > *val = state->color_encoding;
> >
> > } else if (property == plane->color_range_property) {
> >
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d7e15e..05e5632ce375 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,11 @@
> >
> > * planes. Without this property th
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
Hi Dimitri,
Thank you for the patch.
I'll review this in details, but as this patch is based on the "[PATCH/RFC
1/4] drm: Add colorkey properties" patch I've submitted, please retain the
authorship, both in the Signed-off-by line, and in the patch author in git.
On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane, state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
> } else if (property == plane->color_encoding_property) {
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
> } else if (property == plane->color_encoding_property) {
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,11 @@
> * planes. Without this property the primary plane is always below the
> cursor * plane, and ordering between all other planes is undefined.
> *
> + * colorkey:
> + * Color keying is set up with drm_plane_create_colorkey_properties().
> + * It adds support for replacing a range of colors with a transparent
> + * color in t
Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand
Le 26/05/2018 à 06:35, Paul Menzel a écrit : Dear Linux folks, Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'akpm' (patches from Andrew) $ make tinyconfig $ make -j120 […] AS arch/powerpc/kernel/head_32.o arch/powerpc/kernel/head_32.S: Assembler messages: arch/powerpc/kernel/head_32.S:1106: Error: missing operand There was a similar problem in 2015, see http://linux-kernel.2935.n7.nabble.com/Missing-operand-for-tlbie-instruction-on-Power7-td1206917.html Which version of binutils do you use ? Christophe scripts/Makefile.build:413: recipe for target 'arch/powerpc/kernel/head_32.o' failed make[1]: *** [arch/powerpc/kernel/head_32.o] Error 1 […] ``` Is this expected? *ppc64_defconfig* and *ppc64e_defconfig* build fine. Kind regards, Paul --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
[PATCH 0/1] media: uvc_driver: fix USB Camera ref leak denial of service
The patch in the following e-mail fixes a reference count bug, it seems to me that uvc_unregister_video is a good location to release the final reference, I find it is called once. It may sound like a lot to plug and unplug the USB camera 250 some times, but in my case "disabled by hub (EMI?), re-enabling..." kept unplugging and plugging in the device until days later it ran out of minors and I lost the video security feed. With this patch, now that the device is actually being removed other problems are showing up. Specifically the following if the camera is removed or `rmmod ehci_pci` while an application is getting video from it. It doesn't happen if the camera is not in use. How do I track that down? sysfs group 'power' not found for kobject 'event10' sysfs group 'power' not found for kobject 'input32' sysfs group 'id' not found for kobject 'input32' sysfs group 'capabilities' not found for kobject 'input32' sysfs group 'power' not found for kobject 'media0' -- David Fries
[PATCH 1/1] media: uvc_driver: fix USB Camera ref leak denial of service
Commit 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic
variable to a reference count")
didn't take into account that while the old counter was initialized to
0 (no stream open), kref_init starts with a reference of 1. The
reference count on unplug no longer reaches 0, uvc_delete isn't
called, and evdev doesn't release /dev/input/event*. Plug and unplug
enough times and it runs out of device minors preventing any new input
device and the use of newly plugged in USB video cameras until the
system is rebooted.
Signed-off-by: David Fries
Cc: Guennadi Liakhovetski
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: sta...@vger.kernel.org
---
drivers/media/usb/uvc/uvc_driver.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 2469b49..3cbdc87 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct uvc_device *dev)
{
struct uvc_streaming *stream;
- /* Unregistering all video devices might result in uvc_delete() being
-* called from inside the loop if there's no open file handle. To avoid
-* that, increment the refcount before iterating over the streams and
-* decrement it when done.
-*/
- kref_get(&dev->ref);
-
list_for_each_entry(stream, &dev->streams, list) {
if (!video_is_registered(&stream->vdev))
continue;
@@ -1888,6 +1881,10 @@ static void uvc_unregister_video(struct uvc_device *dev)
uvc_debugfs_cleanup_stream(stream);
}
+ /* Release the reference implicit in kref_init from uvc_probe,
+* the UVC device won't be deleted until the last file descriptor
+* is also closed.
+*/
kref_put(&dev->ref, uvc_delete);
}
--
2.1.4
>From 32a612bc06a2a1b9215f3b7166342c98043bd925 Mon Sep 17 00:00:00 2001
From: David Fries
Date: Thu, 24 May 2018 23:43:15 -0500
Subject: [PATCH] uvc_driver: UVC kref never reaches zero leading to denial of
service
Commit 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic
variable to a reference count")
didn't take into account that while the counter was
initialized to 0 (no stream open), kref_init starts with a reference
of 1, leading to the device
never reaching 0 and uvc_delete never getting called. This leads to
evdev never getting released and /dev/input/event* eventually running
out of minors preventing any new event devices and new USB cameras from
being usable until the system is rebooted.
In my case "disabled by hub (EMI?), re-enabling..." kept
removing/inserting the device until days later it ran out of minors
and I lost the video security feed.
Now that the device is actually being removed other problems are
showing up. Specifically the following if the camera is removed or
`rmmod ehci_pci` while an application is getting video from it. It
doesn't happen if the camera is not in use. How do I track that down?
sysfs group 'power' not found for kobject 'event10'
sysfs group 'power' not found for kobject 'input32'
sysfs group 'id' not found for kobject 'input32'
sysfs group 'capabilities' not found for kobject 'input32'
sysfs group 'power' not found for kobject 'media0'
Signed-off-by: David Fries
---
drivers/media/usb/uvc/uvc_driver.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 2469b49..3cbdc87 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct uvc_device *dev)
{
struct uvc_streaming *stream;
- /* Unregistering all video devices might result in uvc_delete() being
-* called from inside the loop if there's no open file handle. To avoid
-* that, increment the refcount before iterating over the streams and
-* decrement it when done.
-*/
- kref_get(&dev->ref);
-
list_for_each_entry(stream, &dev->streams, list) {
if (!video_is_registered(&stream->vdev))
continue;
@@ -1888,6 +1881,10 @@ static void uvc_unregister_video(struct uvc_device *dev)
uvc_debugfs_cleanup_stream(stream);
}
+ /* Release the reference implicit in kref_init from uvc_probe,
+* the UVC device won't be deleted until the last file descriptor
+* is also closed.
+*/
kref_put(&dev->ref, uvc_delete);
}
--
2.1.4
[RFC PATCH v2 1/2] drm: Add generic colorkey properties
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds nine generic DRM plane
properties related to the color keying to cover various HW capabilities.
This patch is based on the initial work done by Laurent Pinchart, most of
credits for this patch goes to him.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 36 ++
drivers/gpu/drm/drm_blend.c | 229 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 77
4 files changed, 345 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e9cd7d..5b808cb68654 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->colorkey.mode_property) {
+ state->colorkey.mode = val;
+ } else if (property == plane->colorkey.min_property) {
+ state->colorkey.min = val;
+ } else if (property == plane->colorkey.max_property) {
+ state->colorkey.max = val;
+ } else if (property == plane->colorkey.format_property) {
+ state->colorkey.format = val;
+ } else if (property == plane->colorkey.mask_property) {
+ state->colorkey.mask = val;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ state->colorkey.inverted_match = val;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ state->colorkey.replacement_mask = val;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ state->colorkey.replacement_value = val;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ state->colorkey.replacement_format = val;
} else if (property == plane->color_encoding_property) {
state->color_encoding = val;
} else if (property == plane->color_range_property) {
@@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->colorkey.mode_property) {
+ *val = state->colorkey.mode;
+ } else if (property == plane->colorkey.min_property) {
+ *val = state->colorkey.min;
+ } else if (property == plane->colorkey.max_property) {
+ *val = state->colorkey.max;
+ } else if (property == plane->colorkey.format_property) {
+ *val = state->colorkey.format;
+ } else if (property == plane->colorkey.mask_property) {
+ *val = state->colorkey.mask;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ *val = state->colorkey.inverted_match;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ *val = state->colorkey.replacement_mask;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ *val = state->colorkey.replacement_value;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ *val = state->colorkey.replacement_format;
} else if (property == plane->color_encoding_property) {
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..05e5632ce375 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor
* plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for replacing a range of colors with a transparent
+ * color in the plane.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,227 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colo
[RFC PATCH v2 0/2] Implement standard color keying properties for DRM planes
Hello, DRM maintainers! Laurent Pinchart kindly agreed to allow me to pick up his work on the generic colorkey DRM plane property [0]. I've reworked the original patch a tad, hopefully making it flexible enough to cover various HW capabilities. Changes I've made: - Some code clean up and reshuffle. - Took into account some the Ville's Syrjälä review comments to [0]. - The number of common DRM colorkey properties grows from 4 to 9. New properties: - colorkey.mask - colorkey.format - colorkey.inverted-match - colorkey.replacement-mask - colorkey.replacement-format Renamed properties: - colorkey.value -> colorkey.replacement-value - colorkey.mode userspace-property ENUM's got a bit more explicit names, like "src" -> "src-match-src-replace". - No driver-specific modes / properties allowed, all unsupported features are simply rejected by the drivers. This patchset includes initial colorkey property implementation for the older NVIDIA Tegra's. Please review, thanks. [0] https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html Dmitry Osipenko (2): drm: Add generic colorkey properties drm/tegra: plane: Implement generic colorkey property for older Tegra's drivers/gpu/drm/drm_atomic.c | 36 ++ drivers/gpu/drm/drm_blend.c | 229 ++ drivers/gpu/drm/tegra/dc.c| 31 + drivers/gpu/drm/tegra/dc.h| 7 ++ drivers/gpu/drm/tegra/plane.c | 147 ++ drivers/gpu/drm/tegra/plane.h | 1 + include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 77 8 files changed, 531 insertions(+) -- 2.17.0
[RFC PATCH v2 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's
Color keying allows to draw on top of overlapping planes, like for
example on top of a video plane. Older Tegra's have a limited color
keying capability, such that blending features are reduced when color
keying is enabled. In particular dependent weighting isn't possible,
meaning that cursors plane can't be displayed properly. In most cases
it is more useful to display content on top of video overlay, so
sacrificing mouse cursor in the area of three planes intersection with
colorkey mismatch is a reasonable tradeoff.
This patch implements the generic DRM colorkey property. For the starter
a minimal color keying support is implemented, it is enough to provide
userspace like Opentegra Xorg driver with ability to support color keying
by the XVideo extension.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 31 +++
drivers/gpu/drm/tegra/dc.h| 7 ++
drivers/gpu/drm/tegra/plane.c | 147 ++
drivers/gpu/drm/tegra/plane.h | 1 +
4 files changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 31e12a9dfcb8..a5add64e40e2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -172,6 +172,11 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
state = to_tegra_plane_state(plane->base.state);
+ if (state->ckey_enabled) {
+ background[0] |= BLEND_COLOR_KEY_0;
+ background[2] |= BLEND_COLOR_KEY_0;
+ }
+
if (state->opaque) {
/*
* Since custom fix-weight blending isn't utilized and weight
@@ -776,6 +781,11 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1053,6 +1063,11 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1153,6 +1168,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
{
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc_state *copy;
+ unsigned int i;
copy = kmalloc(sizeof(*copy), GFP_KERNEL);
if (!copy)
@@ -1164,6 +1180,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->div = state->div;
copy->planes = state->planes;
+ for (i = 0; i < 2; i++)
+ copy->ckey[i] = state->ckey[i];
+
return ©->base;
}
@@ -1893,6 +1912,18 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
*crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+ if (dc->soc->has_legacy_blending) {
+ tegra_dc_writel(dc,
+ state->ckey[0].lower, DC_DISP_COLOR_KEY0_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[0].upper, DC_DISP_COLOR_KEY0_UPPER);
+
+ tegra_dc_writel(dc,
+ state->ckey[1].lower, DC_DISP_COLOR_KEY1_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[1].upper, DC_DISP_COLOR_KEY1_UPPER);
+ }
+
value = state->planes << 8 | GENERAL_UPDATE;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_STATE_CONTROL);
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..8209cb7d598a 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -18,6 +18,11 @@
struct tegra_output;
+struct tegra_dc_color_key_state {
+ u32 lower;
+ u32 upper;
+};
+
struct tegra_dc_state {
struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {
unsigned int div;
u32 planes;
+
+ struct tegra_dc_color_key_state ckey[2];
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 0406c2ef432c..ba08b66d2499 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -57,6 +57,7 @@ tegra_plane_atomic_duplicate_state(struct drm_plane *plane)
co
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
On Sat, May 26, 2018 at 04:50:46PM +0200, Salvatore Mesoraca wrote: > Prevent a task from opening, in "write" mode, any /proc/*/mem > file that operates on the task's mm. > /proc/*/mem is mainly a debugging means and, as such, it shouldn't > be used by the inspected process itself. > Current implementation always allow a task to access its own > /proc/*/mem file. > A process can use it to overwrite read-only memory, making > pointless the use of security_file_mprotect() or other ways to > enforce RO memory. You can do it in security_ptrace_access_check() or security_file_open()
[PATCH 2/2] sched: Warn if we fail to migrate a task
__set_cpus_allowed_ptr() makes use of stop_one_cpu() to call
migration_cpu_stop() in order to perform migration of a task away from
the CPU it's currently running on. If all is as expected then this
shouldn't fail, but as the preceding patch shows it's possible for this
assumption to be broken fairly subtly.
Add a warning to ensure that if stop_one_cpu() returns an error
(-ENOENT is the only one it can currently return) then we warn about it
in the kernel log, since this isn't expected to happen.
I considered propogating the error upwards, but this would require a
change to the return values allowed from the sched_setaffinity() syscall
and would require that user programs handle errors other than those
caused by their own bad input to the syscall. So for now this patch
simply warns, which is an improvement over the silent error & incorrect
scheduling we had before.
Signed-off-by: Paul Burton
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2380bc228dd0..cda3affd45b7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1127,7 +1127,8 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
struct migration_arg arg = { p, dest_cpu };
/* Need help from migration thread: drop lock and wait. */
task_rq_unlock(rq, p, &rf);
- stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
+ ret = stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
+ WARN_ON(ret);
tlb_migrate_finish(p->mm);
return 0;
} else if (task_on_rq_queued(p)) {
--
2.17.0
[PATCH 0/2] sched: Fix a race between CPU onlining & user task scheduling
This short series fixes a race condition I've observed in which user tasks can be scheduled on CPUs that are still in the process of being brought online (or rather being made active) by hotplug. I've created a small test case for the observed problem here: https://gist.github.com/paulburton/25187c4f537263a6be9c8aac67bd33bf The issue was first observed on a MIPS system running a test program that was sensitive to CPU affinity, but has been reproduced on x86_64 using the above program too. On my laptop with an Intel i7-5600U CPU the test tends to fail within 10 minutes, but with this series applied runs cleanly overnight. Thanks, Paul Paul Burton (2): sched: Make select_task_rq() require cpu_active() for user tasks sched: Warn if we fail to migrate a task kernel/sched/core.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.17.0
[GIT PULL] KVM fixes for Linux 4.17-rc7
Linus, The following changes since commit 633711e82878dc29083fc5d2605166755e25b57a: kvm: rename KVM_HINTS_DEDICATED to KVM_HINTS_REALTIME (2018-05-17 19:12:13 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus for you to fetch changes up to 696ca779a928d0e93d61c38ffc3a4d8914a9b9a0: KVM: x86: fix #UD address of failed Hyper-V hypercalls (2018-05-25 21:33:31 +0200) KVM fixes for v4.17-rc7 PPC: - Close a hole which could possibly lead to the host timebase getting out of sync. - Three fixes relating to PTEs and TLB entries for radix guests. - Fix a bug which could lead to an interrupt never getting delivered to the guest, if it is pending for a guest vCPU when the vCPU gets offlined. s390: - Fix false negatives in VSIE validity check (Cc stable) x86: - Fix time drift of VMX preemption timer when a guest uses LAPIC timer in periodic mode (Cc stable) - Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow migration from hosts that don't need retpoline mitigation (Cc stable) - Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and CPUID.OSXSAVE (Cc stable) - Report correct RIP after Hyper-V hypercall #UD (introduced in -rc6) Benjamin Herrenschmidt (1): KVM: PPC: Book3S HV: XIVE: Resend re-routed interrupts on CPU priority change David Hildenbrand (1): KVM: s390: vsie: fix < 8k check for the itdba David Vrabel (1): x86/kvm: fix LAPIC timer drift when guest uses periodic mode Jim Mattson (1): kvm: x86: IA32_ARCH_CAPABILITIES is always supported Nicholas Piggin (2): KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page KVM: PPC: Book3S HV: Make radix clear pte when unmapping Paolo Bonzini (1): Merge tag 'kvm-s390-master-4.17-1' of git://git.kernel.org/.../kvms390/linux into kvm-master Paul Mackerras (2): KVM: PPC: Book3S HV: Snapshot timebase offset on guest entry KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path Radim Krčmář (2): Merge tag 'kvm-ppc-fixes-4.17-1' of git://git.kernel.org/.../paulus/powerpc KVM: x86: fix #UD address of failed Hyper-V hypercalls Wei Huang (1): KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed arch/powerpc/include/asm/kvm_book3s.h | 1 + arch/powerpc/kernel/asm-offsets.c | 1 + arch/powerpc/kvm/book3s_64_mmu_radix.c | 6 +- arch/powerpc/kvm/book3s_hv.c| 1 + arch/powerpc/kvm/book3s_hv_rmhandlers.S | 97 +++- arch/powerpc/kvm/book3s_xive_template.c | 108 +--- arch/s390/kvm/vsie.c| 2 +- arch/x86/kvm/cpuid.c| 5 ++ arch/x86/kvm/hyperv.c | 19 +++--- arch/x86/kvm/lapic.c| 16 - arch/x86/kvm/x86.c | 17 +++-- 11 files changed, 198 insertions(+), 75 deletions(-)
[PATCH 1/2] sched: Make select_task_rq() require cpu_active() for user tasks
select_task_rq() is used in a few paths to select the CPU upon which a thread should be run - for example it is used by try_to_wake_up() & by fork or exec balancing. As-is it allows use of any online CPU that is present in the task's cpus_allowed mask. This presents a problem because there is a period whilst CPUs are brought online where a CPU is marked online, but is not yet fully initialized - ie. the period where CPUHP_AP_ONLINE_IDLE <= state < CPUHP_ONLINE. Usually we don't run any user tasks during this window, but there are corner cases where this can happen. An example observed is: - Some user task A, running on CPU X, forks to create task B. - sched_fork() calls __set_task_cpu() with cpu=X, setting task B's struct task_struct cpu field to X. - CPU X is offlined. - Task A, currently somewhere between the __set_task_cpu() in copy_process() and the call to wake_up_new_task(), is migrated to CPU Y by migrate_tasks() when CPU X is offlined. - CPU X is onlined, but still in the CPUHP_AP_ONLINE_IDLE state. The scheduler is now active on CPU X, but there are no user tasks on the runqueue. - Task A runs on CPU Y & reaches wake_up_new_task(). This calls select_task_rq() with cpu=X, taken from task B's struct task_struct, and select_task_rq() allows cpu X to be returned. - Task A enqueues task B on CPU X's runqueue, via activate_task() & enqueue_task(). - CPU X now has a user task on its runqueue before it has reached the CPUHP_ONLINE state. In most cases, the user tasks that schedule on the newly onlined CPU have no idea that anything went wrong, but one case observed to be problematic is if the task goes on to invoke the sched_setaffinity syscall. The newly onlined CPU reaches the CPUHP_AP_ONLINE_IDLE state before the CPU that brought it online calls stop_machine_unpark(). This means that for a portion of the window of time between CPUHP_AP_ONLINE_IDLE & CPUHP_ONLINE the newly onlined CPU's struct cpu_stopper has its enabled field set to false. If a user thread is executed on the CPU during this window and it invokes sched_setaffinity with a CPU mask that does not include the CPU it's running on, then when __set_cpus_allowed_ptr() calls stop_one_cpu() intending to invoke migration_cpu_stop() and perform the actual migration away from the CPU it will simply return -ENOENT rather than calling migration_cpu_stop(). We then return from the sched_setaffinity syscall back to the user task that is now running on a CPU which it just asked not to run on, and which is not present in its cpus_allowed mask. This patch resolves the problem by having select_task_rq() enforce that user tasks run on CPUs that are active - the same requirement that select_fallback_rq() already enforces. This should ensure that newly onlined CPUs reach the CPUHP_AP_ACTIVE state before being able to schedule user tasks, and also implies that bringup_wait_for_ap() will have called stop_machine_unpark() which resolves the sched_setaffinity issue above. I haven't yet investigated them, but it may be of interest to review whether any of the actions performed by hotplug states between CPUHP_AP_ONLINE_IDLE & CPUHP_AP_ACTIVE could have similar unintended effects on user tasks that might schedule before they are reached, which might widen the scope of the problem from just affecting the behaviour of sched_setaffinity. Signed-off-by: Paul Burton Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org --- As described in the series' cover letter I've created a small test case for the observed problem here: https://gist.github.com/paulburton/25187c4f537263a6be9c8aac67bd33bf The issue was first observed on a MIPS system running a test program that was sensitive to CPU affinity, but has been reproduced on x86_64 using the above program too. On my laptop with an Intel i7-5600U CPU the test tends to fail within 10 minutes, but with this series applied runs cleanly overnight. kernel/sched/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index a7bf32aabfda..2380bc228dd0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1565,7 +1565,8 @@ int select_task_rq(struct task_struct *p, int cpu, int sd_flags, int wake_flags) * not worry about this generic constraint ] */ if (unlikely(!cpumask_test_cpu(cpu, &p->cpus_allowed) || -!cpu_online(cpu))) +!cpu_online(cpu) || +(!cpu_active(cpu) && !(p->flags & PF_KTHREAD cpu = select_fallback_rq(task_cpu(p), p); return cpu; -- 2.17.0
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Re: INFO: rcu detected stall in skb_free_head
On Sun, Apr 29, 2018 at 6:33 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > a27fc14219f2e3c4a46ba9177b04d9b52c875532 (Mon Apr 16 21:07:39 2018 +) > Merge branch 'parisc-4.17-3' of > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=cac7c17ec0aca89d3c45 > > Unfortunately, I don't have any reproducer for this crash yet. > Raw console output: > https://syzkaller.appspot.com/x/log.txt?id=6517400396627968 > Kernel config: > https://syzkaller.appspot.com/x/.config?id=-5914490758943236750 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+cac7c17ec0aca89d3...@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > INFO: rcu_sched self-detected stall on CPU > 1-...!: (117917 ticks this GP) idle=036/1/4611686018427387906 > softirq=114416/114416 fqs=32 > (t=125000 jiffies g=60712 c=60711 q=345938) > rcu_sched kthread starved for 124847 jiffies! g60712 c60711 f0x2 > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0 > RCU grace-period kthread stack dump: > rcu_sched R running task23592 9 2 0x8000 > Call Trace: > context_switch kernel/sched/core.c:2848 [inline] > __schedule+0x801/0x1e30 kernel/sched/core.c:3490 > schedule+0xef/0x430 kernel/sched/core.c:3549 > schedule_timeout+0x138/0x240 kernel/time/timer.c:1801 > rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231 > kthread+0x345/0x410 kernel/kthread.c:238 > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 > NMI backtrace for cpu 1 > CPU: 1 PID: 24 Comm: kworker/1:1 Not tainted 4.17.0-rc1+ #6 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: events rht_deferred_worker > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:173 > tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1283 > __run_hrtimer kernel/time/hrtimer.c:1386 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1448 > hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1506 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:kfree+0x124/0x260 mm/slab.c:3814 > RSP: 0018:8801db105450 EFLAGS: 0286 ORIG_RAX: ff13 > RAX: 0007 RBX: 88006c118040 RCX: 11003b3059e7 > RDX: RSI: 8801d982cf90 RDI: 0286 > RBP: 8801db105470 R08: 8801d982ce78 R09: 0002 > R10: 8801d982c640 R11: R12: 0286 > R13: 8801dac00ac0 R14: 85bd7b69 R15: 88006c0f8180 > skb_free_head+0x99/0xc0 net/core/skbuff.c:550 > skb_release_data+0x690/0x860 net/core/skbuff.c:570 > skb_release_all+0x4a/0x60 net/core/skbuff.c:627 > __kfree_skb net/core/skbuff.c:641 [inline] > kfree_skb+0x195/0x560 net/core/skbuff.c:659 > enqueue_to_backlog+0x2fc/0xc90 net/core/dev.c:3968 > netif_rx_internal+0x14d/0xae0 net/core/dev.c:4181 > netif_rx+0xba/0x400 net/core/dev.c:4206 > loopback_xmit+0x283/0x741 drivers/net/loopback.c:91 > __netdev_start_xmit include/linux/netdevice.h:4087 [inline] > netdev_start_xmit include/linux/netdevice.h:4096 [inline] > xmit_one net/core/dev.c:3053 [inline] > dev_hard_start_xmit+0x264/0xc10 net/core/dev.c:3069 > __dev_queue_xmit+0x2724/0x34c0 net/core/dev.c:3584 > dev_queue_xmit+0x17/0x20 net/core/dev.c:3617 > neigh_hh_output include/net/neighbour.h:472 [inline] > neigh_output include/net/neighbour.h:480 [inline] > ip_finish_output2+0x1046/0x1840 net/ipv4/ip_output.c:229 > ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317 > NF_HOOK_COND include/linux/netfilter.h:277 [inline] > ip_output+0x21b/0x850 net/ipv4/ip_output.c:405 > dst_output include/net/dst.h:444 [inline] > ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:1
Re: INFO: rcu detected stall in kmem_cache_alloc_node_trace
On Mon, Apr 30, 2018 at 8:05 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:17dec0a94915 Merge branch 'userns-linus' of > git://git.kerne... > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?id=6093051722203136 > kernel config: > https://syzkaller.appspot.com/x/.config?id=-2735707888269579554 > dashboard link: https://syzkaller.appspot.com/bug?extid=deec965c578bb9b81613 > compiler: gcc (GCC) 8.0.1 20180301 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+deec965c578bb9b81...@syzkaller.appspotmail.com > > sctp: [Deprecated]: syz-executor3 (pid 10218) Use of int in max_burst socket > option. > Use struct sctp_assoc_value instead > sctp: [Deprecated]: syz-executor3 (pid 10218) Use of int in max_burst socket > option. > Use struct sctp_assoc_value instead > random: crng init done > INFO: rcu_sched self-detected stall on CPU > 0-: (120712 ticks this GP) idle=ac6/1/4611686018427387908 > softirq=31693/31693 fqs=31173 > (t=125001 jiffies g=17039 c=17038 q=303419) > NMI backtrace for cpu 0 > CPU: 0 PID: 10218 Comm: syz-executor3 Not tainted 4.16.0+ #1 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x1b9/0x29f lib/dump_stack.c:53 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:162 > tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1170 > __run_hrtimer kernel/time/hrtimer.c:1349 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1411 > hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1469 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3960 > RSP: 0018:8801db006400 EFLAGS: 0282 ORIG_RAX: ff12 > RAX: dc00 RBX: 0282 RCX: > RDX: 11162e55 RSI: 88b90c60 RDI: 0282 > RBP: 8801db006420 R08: ed003b6046c3 R09: ed003b6046c2 > R10: ed003b6046c2 R11: 8801db023613 R12: 8801b2f623c0 > R13: R14: 88009932bb00 R15: > lock_is_held include/linux/lockdep.h:344 [inline] > rcu_read_lock_sched_held+0x108/0x120 kernel/rcu/update.c:117 > trace_kmalloc_node include/trace/events/kmem.h:100 [inline] > kmem_cache_alloc_node_trace+0x34e/0x770 mm/slab.c:3652 > __do_kmalloc_node mm/slab.c:3669 [inline] > __kmalloc_node_track_caller+0x33/0x70 mm/slab.c:3684 > __kmalloc_reserve.isra.38+0x3a/0xe0 net/core/skbuff.c:137 > __alloc_skb+0x14d/0x780 net/core/skbuff.c:205 > alloc_skb include/linux/skbuff.h:987 [inline] > sctp_packet_transmit+0x45e/0x3ba0 net/sctp/output.c:585 > sctp_outq_flush+0x1373/0x4370 net/sctp/outqueue.c:1197 > sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776 > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] > sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191 > sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 #syz fix: sctp: not allow to set rto_min with a value below 200 msecs > call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 > expire_timers kernel/time/timer.c:1363 [inline] > __run_timers+0x79e/0xc50 kernel/time/timer.c:1666 > run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 > __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285 > invoke_softirq kernel/softirq.c:365 [inline] > irq_exit+0x1d1/0x200 kernel/softirq.c:405 > exiting_irq arch/x86/include/asm/apic.h:525 [inline] > smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 > > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:console_unlock+0xcdf/0x1100 kernel/printk/printk.c:2403 > RSP: 0018:8801946eec00 EFLAGS: 0212 ORIG_RAX: fff
Re: INFO: rcu detected stall in sctp_generate_heartbeat_event
On Tue, May 8, 2018 at 2:06 PM, Marcelo Ricardo Leitner wrote: > On Tue, May 08, 2018 at 12:35:02AM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kern.. >> git tree: net-next >> console output: https://syzkaller.appspot.com/x/log.txt?x=119a723780 >> kernel config: https://syzkaller.appspot.com/x/.config?x=aea320d3af5ef99d >> dashboard link: https://syzkaller.appspot.com/bug?extid=e4a5bbd54260c93014f9 >> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >> >> Unfortunately, I don't have any reproducer for this crash yet. > > A reproducer will be welcomed. With just these traces, I don't think > we have enough information. #syz fix: sctp: not allow to set rto_min with a value below 200 msecs
Re: INFO: rcu detected stall in kfree_skbmem
On Mon, May 14, 2018 at 8:04 PM, Xin Long wrote: > On Mon, May 14, 2018 at 9:34 PM, Neil Horman wrote: >> On Fri, May 11, 2018 at 12:00:38PM +0200, Dmitry Vyukov wrote: >>> On Mon, Apr 30, 2018 at 8:09 PM, syzbot >>> wrote: >>> > Hello, >>> > >>> > syzbot found the following crash on: >>> > >>> > HEAD commit:5d1365940a68 Merge >>> > git://git.kernel.org/pub/scm/linux/kerne... >>> > git tree: net-next >>> > console output: >>> > https://syzkaller.appspot.com/x/log.txt?id=5667997129637888 >>> > kernel config: >>> > https://syzkaller.appspot.com/x/.config?id=-5947642240294114534 >>> > dashboard link: >>> > https://syzkaller.appspot.com/bug?extid=fc78715ba3b3257caf6a >>> > compiler: gcc (GCC) 8.0.1 20180413 (experimental) >>> > >>> > Unfortunately, I don't have any reproducer for this crash yet. >>> >>> This looks sctp-related, +sctp maintainers. >>> >> Looking at the entire trace, it appears that we are getting caught in the >> kfree_skb that is getting triggered in enqueue_to_backlog which occurs when >> our >> rx backlog list grows over netdev_max_backlog packets. That suggests to me >> that > It might be a long skb->frag_list that made kfree_skb slow when packing > lots of small chunks to go through lo device? > >> whatever test(s) is/are causing this trace are queuing up a large number of >> frames to be sent over the loopback interface, and are never/rarely getting >> received. Looking up higher in the stack, in the >> sctp_generate_heartbeat_event >> function, we (in addition to the rcu_read_lock in sctp_v6_xmit) we also hold >> the >> socket lock during the entirety of the xmit operaion. Is it possible that we >> are just enqueuing so many frames for xmit that we are blocking progress of >> other threads using the same socket that we cross the RCU self detected stall >> boundary? While its not a fix per se, it might be a worthwhile test to limit >> the number of frames we flush in a single pass. >> >> Neil >> >>> > IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> > Reported-by: syzbot+fc78715ba3b3257ca...@syzkaller.appspotmail.com >>> > >>> > INFO: rcu_sched self-detected stall on CPU >>> > 1-...!: (1 GPs behind) idle=a3e/1/4611686018427387908 >>> > softirq=71980/71983 fqs=33 >>> > (t=125000 jiffies g=39438 c=39437 q=958) >>> > rcu_sched kthread starved for 124829 jiffies! g39438 c39437 f0x0 >>> > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0 >>> > RCU grace-period kthread stack dump: >>> > rcu_sched R running task23768 9 2 0x8000 >>> > Call Trace: >>> > context_switch kernel/sched/core.c:2848 [inline] >>> > __schedule+0x801/0x1e30 kernel/sched/core.c:3490 >>> > schedule+0xef/0x430 kernel/sched/core.c:3549 >>> > schedule_timeout+0x138/0x240 kernel/time/timer.c:1801 >>> > rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231 >>> > kthread+0x345/0x410 kernel/kthread.c:238 >>> > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:411 >>> > NMI backtrace for cpu 1 >>> > CPU: 1 PID: 20560 Comm: syz-executor4 Not tainted 4.16.0+ #1 >>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> > Google 01/01/2011 >>> > Call Trace: >>> > >>> > __dump_stack lib/dump_stack.c:77 [inline] >>> > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 >>> > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 >>> > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 >>> > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 >>> > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] >>> > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 >>> > print_cpu_stall kernel/rcu/tree.c:1525 [inline] >>> > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 >>> > __rcu_pending kernel/rcu/tree.c:3356 [inline] >>> > rcu_pending kernel/rcu/tree.c:3401 [inline] >>> > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 >>> > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 >>> > tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:173 >>> > tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1283 >>> > __run_hrtimer kernel/time/hrtimer.c:1386 [inline] >>> > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1448 >>> > hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1506 >>> > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] >>> > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 >>> > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 >>> > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 >>> > [inline] >>> > RIP: 0010:kmem_cache_free+0xb3/0x2d0 mm/slab.c:3757 >>> > RSP: 0018:8801db105228 EFLAGS: 0282 ORIG_RAX: ff13 >>> > RAX: 0007 RBX: 8800b055c940 RCX: 11003b2345a5 >>> > RDX: RSI: 8801d91a2d80 RDI: 0282 >>> > RBP: 8801db105248 R08: 8801d91a2cb8 R09: 0002 >>>
Re: INFO: rcu detected stall in sctp_packet_transmit
On Wed, May 16, 2018 at 2:12 PM, Dmitry Vyukov wrote: > On Wed, May 16, 2018 at 1:02 PM, Xin Long wrote: wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:961423f9fcbc Merge branch 'sctp-Introduce-sctp_flush_ctx' > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1366aea780 > kernel config: https://syzkaller.appspot.com/x/.config?x=51fb0a6913f757db > dashboard link: > https://syzkaller.appspot.com/bug?extid=ff0b569fb5111dcd1a36 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ff0b569fb5111dcd1...@syzkaller.appspotmail.com > > INFO: rcu_sched self-detected stall on CPU > 0-: (1 GPs behind) idle=dae/1/4611686018427387908 > softirq=93090/93091 fqs=30902 > (t=125000 jiffies g=51107 c=51106 q=972) > NMI backtrace for cpu 0 > CPU: 0 PID: 24668 Comm: syz-executor6 Not tainted 4.17.0-rc4+ #44 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164 > tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274 > __run_hrtimer kernel/time/hrtimer.c:1398 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460 > hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 > RIP: 0010:sctp_v6_xmit+0x259/0x6b0 net/sctp/ipv6.c:219 > RSP: 0018:8801dae068e8 EFLAGS: 0246 ORIG_RAX: ff13 > RAX: 0007 RBX: 8801bb7ec800 RCX: 86f1b345 > RDX: RSI: 86f1b381 RDI: 8801b73d97c4 > RBP: 8801dae06988 R08: 88019505c300 R09: ed003b5c46c2 > R10: ed003b5c46c2 R11: 8801dae23613 R12: 88011fd57300 > R13: 8801bb7ecec8 R14: 0029 R15: 0002 > sctp_packet_transmit+0x26f6/0x3ba0 net/sctp/output.c:642 > sctp_outq_flush_transports net/sctp/outqueue.c:1164 [inline] > sctp_outq_flush+0x5f5/0x3430 net/sctp/outqueue.c:1212 > sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776 > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] > sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191 > sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 Shocks, this timer event again. Can we try to minimize the repo.syz and get a short script, not neccessary to reproduce the issue 100%. we need to know what it was doing when this happened. Thanks. >>> >>> It's possible to reply the whole log from console output following >>> these instructions: >>> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md >> Thanks, it's running now. >> Usually how long will it take to finish running this 5000-line log? > > If you run with -repeat=0 then it will run infinitely repeating the > log again and again. If you see: > > parsed 1000 programs > ... > executed 5000 programs > > then it looped 5 times already. You can run with -repeat=10. > > syzbot has tried replaying the log, but for some reason it wasn't able > to reproduce the crash (maybe accumulated state, or maybe it crashed > in a different way). You can also try logs from other sctp hangs. #syz fix: sctp: not allow to set rto_min with a value below 200 msecs
Re: INFO: rcu detected stall in ip_route_output_key_hash
On Wed, May 16, 2018 at 5:29 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1138c47780 > kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1 > dashboard link: https://syzkaller.appspot.com/bug?extid=769a7ccbbb4b5074f125 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+769a7ccbbb4b5074f...@syzkaller.appspotmail.com > > netlink: 4 bytes leftover after parsing attributes in process > `syz-executor2'. > random: crng init done > INFO: rcu_sched self-detected stall on CPU > 1-...!: (121515 ticks this GP) idle=e7e/1/4611686018427387908 > softirq=31362/31362 fqs=7 > (t=125000 jiffies g=16439 c=16438 q=668508) > rcu_sched kthread starved for 124958 jiffies! g16439 c16438 f0x2 > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0 > RCU grace-period kthread stack dump: > rcu_sched R running task23768 9 2 0x8000 > Call Trace: > context_switch kernel/sched/core.c:2848 [inline] > __schedule+0x801/0x1e30 kernel/sched/core.c:3490 > schedule+0xef/0x430 kernel/sched/core.c:3549 > schedule_timeout+0x138/0x240 kernel/time/timer.c:1801 > rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231 > kthread+0x345/0x410 kernel/kthread.c:238 > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 > NMI backtrace for cpu 1 > CPU: 1 PID: 4488 Comm: syz-fuzzer Not tainted 4.17.0-rc4+ #45 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164 > tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274 > __run_hrtimer kernel/time/hrtimer.c:1398 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460 > hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 > RIP: 0010:rcu_is_watching+0x6/0x140 kernel/rcu/tree.c:1071 > RSP: :8801daf06620 EFLAGS: 0206 ORIG_RAX: ff13 > RAX: 8801ad526240 RBX: RCX: 8656 > RDX: 0100 RSI: 86b8 RDI: 0001 > RBP: 8801daf06628 R08: 8801ad526240 R09: 0002 > R10: 8801ad526240 R11: R12: 11003b5e0cca > R13: 88008ff1a100 R14: R15: 8801daf066d0 > rcu_read_unlock include/linux/rcupdate.h:684 [inline] > ip_route_output_key_hash+0x2cd/0x390 net/ipv4/route.c:2303 > __ip_route_output_key include/net/route.h:124 [inline] > ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2557 > ip_route_output_key include/net/route.h:134 [inline] > sctp_v4_get_dst+0x50e/0x17a0 net/sctp/protocol.c:447 > sctp_transport_route+0x132/0x360 net/sctp/transport.c:303 > sctp_packet_config+0x926/0xdd0 net/sctp/output.c:118 > sctp_outq_select_transport+0x2bb/0x9c0 net/sctp/outqueue.c:877 > sctp_outq_flush_ctrl.constprop.12+0x2ad/0xe60 net/sctp/outqueue.c:911 > sctp_outq_flush+0x2ef/0x3430 net/sctp/outqueue.c:1203 > sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776 > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] > sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191 > sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 #syz fix: sctp: not allow to set rto_min with a value below 200 msecs > call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 > expire_timers kernel/time/timer.c:1363 [inline] > __run_timers+0x79e/0xc50 kernel/time/timer.c:1666 > run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 > __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285 > invoke_softirq kernel/softirq.c:365 [inline] > irq_exit+0x1d1/0x200 kernel/softirq.c:405 > exiting_irq arch/x86/include/asm/apic.h:525 [inline]
Re: INFO: rcu detected stall in save_stack_trace
On Mon, May 21, 2018 at 7:25 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0b449a441dac Merge tag 'dmaengine-fix-4.17-rc6' of git://g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=127ec33780 > kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed > dashboard link: https://syzkaller.appspot.com/bug?extid=0f775f734aa841af54cc > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17d3a84f80 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1077082780 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+0f775f734aa841af5...@syzkaller.appspotmail.com > > 8021q: adding VLAN 0 to HW filter on device team0 > 8021q: adding VLAN 0 to HW filter on device team0 > 8021q: adding VLAN 0 to HW filter on device team0 > 8021q: adding VLAN 0 to HW filter on device team0 > 8021q: adding VLAN 0 to HW filter on device team0 > INFO: rcu_sched self-detected stall on CPU > 0-...!: (124935 ticks this GP) idle=042/1/4611686018427387908 > softirq=14940/14940 fqs=5 > (t=125000 jiffies g=7464 c=7463 q=430266) > NMI backtrace for cpu 0 > CPU: 0 PID: 6412 Comm: ip Not tainted 4.17.0-rc5+ #59 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164 > tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274 > __run_hrtimer kernel/time/hrtimer.c:1398 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460 > hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 > RIP: 0010:__save_stack_trace+0x53/0xd0 arch/x86/kernel/stacktrace.c:43 > RSP: 0018:8801dae06ce0 EFLAGS: 0282 ORIG_RAX: ff13 > RAX: 85da28ea RBX: 8801dae06d78 RCX: 0001 > RDX: 11003b5c0da5 RSI: 8801c08b7758 RDI: 85da28ea > RBP: 8801dae06d58 R08: 8801dae06d18 R09: 8801c0a62180 > R10: ed003b5c0da6 R11: 8801dae06d37 R12: > R13: R14: 8801c0a62180 R15: 88007c262427 > save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60 > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 > kmem_cache_alloc_node+0x144/0x780 mm/slab.c:3644 > __alloc_skb+0x111/0x780 net/core/skbuff.c:193 > alloc_skb include/linux/skbuff.h:987 [inline] > _sctp_make_chunk+0x58/0x280 net/sctp/sm_make_chunk.c:1417 > sctp_make_control net/sctp/sm_make_chunk.c:1464 [inline] > sctp_make_heartbeat+0x8f/0x430 net/sctp/sm_make_chunk.c:1177 > sctp_sf_heartbeat.isra.23+0x26/0x180 net/sctp/sm_statefuns.c:1005 > sctp_sf_sendbeat_8_3+0x38e/0x550 net/sctp/sm_statefuns.c:1049 > sctp_do_sm+0x1ab/0x7160 net/sctp/sm_sideeffect.c:1188 > sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 > call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 > expire_timers kernel/time/timer.c:1363 [inline] > __run_timers+0x79e/0xc50 kernel/time/timer.c:1666 > run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 > __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285 > invoke_softirq kernel/softirq.c:365 [inline] > irq_exit+0x1d1/0x200 kernel/softirq.c:405 > exiting_irq arch/x86/include/asm/apic.h:525 [inline] > smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 > > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:kmem_cache_free+0xb3/0x2d0 mm/slab.c:3757 > RSP: 0018:8801c08b7568 EFLAGS: 0286 ORIG_RAX: ff13 > RAX: 0007 RBX: 8801bb77f300 RCX: > RDX: RSI: 0001 RDI: 0286 > RBP: 8801c08b7588 R08: 8801c08b7310 R09:
Re: INFO: rcu detected stall in corrupted
On Thu, May 24, 2018 at 11:02 AM, Xin Long wrote: > On Thu, May 24, 2018 at 7:13 AM, Marcelo Ricardo Leitner > wrote: >> On Mon, May 21, 2018 at 11:13:46AM -0700, Eric Dumazet wrote: >>> >>> >>> On 05/21/2018 11:09 AM, David Miller wrote: >>> > From: syzbot >>> > Date: Mon, 21 May 2018 11:05:02 -0700 >>> > >>> >> find_match+0x244/0x13a0 net/ipv6/route.c:691 >>> >> find_rr_leaf net/ipv6/route.c:729 [inline] >>> >> rt6_select net/ipv6/route.c:779 [inline] >>> > >>> > Hmmm, endless loop in find_rr_leaf or similar? >>> > >>> >>> >>> I do not think so, this really looks like SCTP specific >>> , we now have dozens of traces all sharing : >>> >>> sctp_transport_route+0xad/0x450 net/sctp/transport.c:293 >>> sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123 >>> sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894 >>> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776 >>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] >>> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] >>> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191 >>> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 >>> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 >>> >>> >>> Some kind of infinite loop. >>> >>> When the hrtimer fires, it can point to any code that sits below but does >>> not necessarily have a bug. >> >> Agreed. Xin Long identified the root cause. syzkaller is setting too >> aggressive parameters to SCTP RTO, leading to issues with the >> heartbeat timer. > Right, I will prepare a fix soon with your suggestion rto_min value "HZ/5" > Thanks. #syz fix: sctp: not allow to set rto_min with a value below 200 msecs
Re: [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
On 05/11/2018 03:27 AM, Samuel Holland wrote: > The Allwinner A64 SoC is known [1] to have an unstable architectural > timer, which manifests itself most obviously in the time jumping forward > a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a > timer frequency of 24 MHz, implying that the time went slightly backward > (and this was interpreted by the kernel as it jumping forward and > wrapping around past the epoch). > > Further investigation revealed instability in the low bits of CNTVCT at > the point a high bit rolls over. This leads to power-of-two cycle > forward and backward jumps. (Testing shows that forward jumps are about > twice as likely as backward jumps.) > > Without trapping reads to CNTVCT, a userspace program is able to read it > in a loop faster than it changes. A test program running on all 4 CPU > cores that reported jumps larger than 100 ms was run for 13.6 hours and > reported the following: > > Count | Event > ---+--- > 9940 | jumped backward 699ms >268 | jumped backward 1398ms > 1 | jumped backward 2097ms > 16020 | jumped forward 175ms > 6443 | jumped forward 699ms > 2976 | jumped forward 1398ms > 9 | jumped forward356516ms > 9 | jumped forward357215ms > 4 | jumped forward714430ms > 1 | jumped forward 3578440ms > > This works out to a jump larger than 100 ms about every 5.5 seconds on > each CPU core. > > The largest jump (almost an hour!) was the following sequence of reads: > 0x007f → 0x0093feff → 0x0080 > > Note that the middle bits don't necessarily all read as all zeroes or > all ones during the anomalous behavior; however the low 11 bits checked > by the function in this patch have never been observed with any other > value. > > Also note that smaller jumps are much more common, with the smallest > backward jumps of 2048 cycles observed over 400 times per second on each > core. (Of course, this is partially due to lower bits rolling over more > frequently.) Any one of these could have caused the 95 year time skip. > > Similar anomalies were observed while reading CNTPCT (after patching the > kernel to allow reads from userspace). However, the jumps are much less > frequent, and only small jumps were observed. The same program as before > (except now reading CNTPCT) observed after 72 hours: > > Count | Event > ---+--- > 17 | jumped backward 699ms > 52 | jumped forward 175ms > 2831 | jumped forward 699ms > 5 | jumped forward 1398ms > > > > Because the CPU can read the CNTPCT/CNTVCT registers faster than they > change, performing two reads of the register and comparing the high bits > (like other workarounds) is not a workable solution. And because the > timer can jump both forward and backward, no pair of reads can > distinguish a good value from a bad one. The only way to guarantee a > good value from consecutive reads would be to read _three_ times, and > take the middle value iff the three values are 1) individually unique > and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if > an anomaly is detected. > > However, since there is a distinct pattern to the bad values, we can > optimize the common case (2046/2048 of the time) to a single read by > simply ignoring values that match the pattern. This still takes no more > than 3 cycles in the worst case, and requires much less code. Clever solution, and indeed much less costly than other workarounds. FWIW, I tested this on a Pine64 and can confirm that it works. I put a test program here: https://github.com/apritzel/pine64/blob/master/tools/test_timer.c This only checks for consecutive reads going backwards, but within a split second yells on an unpatched kernel: https://gist.github.com/apritzel/fc78ca6edb17be2024d5adfd35edb520 Applying the patch and adding the DT property fixed that for me. I second Marc's request for an upper bound on the loop. Question is just what we do when we reach the loop count limit? But regardless, given that this fixes this nasty issue: Tested-by: Andre Przywara Cheers, Andre.
[PATCH] powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"
From: Colin Ian King Trivial fix to spelling mistake in hmi_error_types text Signed-off-by: Colin Ian King --- arch/powerpc/platforms/powernv/opal-hmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/opal-hmi.c b/arch/powerpc/platforms/powernv/opal-hmi.c index 4efc95b4c7d4..586ec71a4e17 100644 --- a/arch/powerpc/platforms/powernv/opal-hmi.c +++ b/arch/powerpc/platforms/powernv/opal-hmi.c @@ -177,7 +177,7 @@ static void print_hmi_event_info(struct OpalHMIEvent *hmi_evt) "Processor recovery occurred for masked error", "Timer facility experienced an error", "TFMR SPR is corrupted", - "UPS (Uniterrupted Power System) Overflow indication", + "UPS (Uninterrupted Power System) Overflow indication", "An XSCOM operation failure", "An XSCOM operation completed", "SCOM has set a reserved FIR bit to cause recovery", -- 2.17.0
[PATCH] 9p: fix spelling mistake "Uknown" -> "Unknown"
From: Colin Ian King
Trivial fix to spelling mistake in pr_info message text
Signed-off-by: Colin Ian King
---
fs/9p/v9fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 0429c8ee58f1..89bac3d2f05b 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -343,7 +343,7 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
v9ses->uid = make_kuid(current_user_ns(), uid);
if (!uid_valid(v9ses->uid)) {
ret = -EINVAL;
- pr_info("Uknown uid %s\n", s);
+ pr_info("Unknown uid %s\n", s);
}
}
--
2.17.0
[PATCH] ALSA: seq: fix spelling mistake "Unamed" -> "Unnamed"
From: Colin Ian King Trivial fix to spelling mistake in string Signed-off-by: Colin Ian King --- sound/core/seq/seq_ports.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/seq/seq_ports.c b/sound/core/seq/seq_ports.c index d21ece9f8d73..24d90abfc64d 100644 --- a/sound/core/seq/seq_ports.c +++ b/sound/core/seq/seq_ports.c @@ -669,7 +669,7 @@ int snd_seq_event_port_attach(int client, /* Set up the port */ memset(&portinfo, 0, sizeof(portinfo)); portinfo.addr.client = client; - strlcpy(portinfo.name, portname ? portname : "Unamed port", + strlcpy(portinfo.name, portname ? portname : "Unnamed port", sizeof(portinfo.name)); portinfo.capability = cap; -- 2.17.0
