May 2019 - Linux-stable-mirror

[PATCH] Input: i8042 - disable KBD port on Late-2016 Razer Blade Stealth

by Lyude Paul

The late 2016 model of the Razer Blade Stealth has a built-in USB keyboard, but for some reason the BIOS exposes an i8042 controller with a connected KBD port. While this fake AT Keyboard device doesn't appear to report any events, attempting to change the state of the caps lock LED on it from on to off causes the entire system to hang. So, introduce a quirk table for disabling keyboard probing by default, i8042_dmi_nokbd_table, and add this specific model of Razer laptop to that table. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/input/serio/i8042-x86ia64io.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h index 136f6e7bf797..888f5f6feebf 100644 --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -884,6 +884,22 @@ static const struct dmi_system_id __initconst i8042_dmi_kbdreset_table[] = { { } }; +static const struct dmi_system_id i8042_dmi_nokbd_table[] __initconst = { + { + /* + * Razer Blade Stealth (Late 2016 model) - Keyboard is on USB + * but the system exposes a fake AT keyboard that crashes the + * system if the caps lock LED is changed + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Razer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Blade Stealth"), + DMI_MATCH(DMI_PRODUCT_VERSION, "2.04"), + }, + }, + { } +}; + #endif /* CONFIG_X86 */ #ifdef CONFIG_PNP @@ -1040,6 +1056,9 @@ static int __init i8042_pnp_init(void) #ifdef CONFIG_X86 if (dmi_check_system(i8042_dmi_nopnp_table)) i8042_nopnp = true; + + if (dmi_check_system(i8042_dmi_nokbd_table)) + i8042_nokbd = true; #endif if (i8042_nopnp) { -- 2.20.1

5 years, 5 months

3
5
0 0

[PATCH] mm/mmap: fix the adjusted length error

by jianhong chen

In linux version 4.4, a 32-bit process may fail to allocate 64M hugepage memory by function shmat even though there is a 64M memory gap in the process. It is the adjusted length that causes the problem, introduced from commit db4fbfb9523c935 ("mm: vm_unmapped_area() lookup function"). Accounting for the worst case alignment overhead, function unmapped_area and unmapped_area_topdown adjust the search length before searching for available vma gap. This is an estimated length, sum of the desired length and the longest alignment offset, which can cause misjudgement if the system has very few virtual memory left. For example, if the longest memory gap available is 64M, we can’t get it from the system by allocating 64M hugepage memory via shmat function. The reason is that it requires a longger length, the sum of the desired length(64M) and the longest alignment offset. To fix this error ,we can calculate the alignment offset of gap_start or gap_end to get a desired gap_start or gap_end value, before searching for the available gap. In this way, we don't need to adjust the search length. Problem reproduces procedure: 1. allocate a lot of virtual memory segments via shmat and malloc 2. release one of the biggest memory segment via shmdt 3. attach the biggest memory segment via shmat e.g. process maps: 00008000-00009000 r-xp 00000000 00:12 3385 /tmp/memory_mmap 00011000-00012000 rw-p 00001000 00:12 3385 /tmp/memory_mmap 27536000-f756a000 rw-p 00000000 00:00 0 f756a000-f7691000 r-xp 00000000 01:00 560 /lib/libc-2.11.1.so f7691000-f7699000 ---p 00127000 01:00 560 /lib/libc-2.11.1.so f7699000-f769b000 r--p 00127000 01:00 560 /lib/libc-2.11.1.so f769b000-f769c000 rw-p 00129000 01:00 560 /lib/libc-2.11.1.so f769c000-f769f000 rw-p 00000000 00:00 0 f769f000-f76c0000 r-xp 00000000 01:00 583 /lib/libgcc_s.so.1 f76c0000-f76c7000 ---p 00021000 01:00 583 /lib/libgcc_s.so.1 f76c7000-f76c8000 rw-p 00020000 01:00 583 /lib/libgcc_s.so.1 f76c8000-f76e5000 r-xp 00000000 01:00 543 /lib/ld-2.11.1.so f76e9000-f76ea000 rw-p 00000000 00:00 0 f76ea000-f76ec000 rw-p 00000000 00:00 0 f76ec000-f76ed000 r--p 0001c000 01:00 543 /lib/ld-2.11.1.so f76ed000-f76ee000 rw-p 0001d000 01:00 543 /lib/ld-2.11.1.so f7800000-f7a00000 rw-s 00000000 00:0e 0 /SYSV000000ea (deleted) fba00000-fca00000 rw-s 00000000 00:0e 65538 /SYSV000000ec (deleted) fca00000-fce00000 rw-s 00000000 00:0e 98307 /SYSV000000ed (deleted) fce00000-fd800000 rw-s 00000000 00:0e 131076 /SYSV000000ee (deleted) ff913000-ff934000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] from 0xf7a00000 to fba00000, it has 64M memory gap, but we can't get it from kernel. Signed-off-by: jianhong chen <chenjianhong2(a)huawei.com> Cc: stable(a)vger.kernel.org --- mm/mmap.c | 43 +++++++++++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index bd7b9f2..c5a5782 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1865,6 +1865,22 @@ unsigned long mmap_region(struct file *file, unsigned long addr, return error; } +static inline unsigned long gap_start_offset(struct vm_unmapped_area_info *info, + unsigned long addr) +{ + /* get gap_start offset to adjust gap address to the + * desired alignment + */ + return (info->align_offset - addr) & info->align_mask; +} + +static inline unsigned long gap_end_offset(struct vm_unmapped_area_info *info, + unsigned long addr) +{ + /* get gap_end offset to adjust gap address to the desired alignment */ + return (addr - info->align_offset) & info->align_mask; +} + unsigned long unmapped_area(struct vm_unmapped_area_info *info) { /* @@ -1879,10 +1895,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) struct vm_area_struct *vma; unsigned long length, low_limit, high_limit, gap_start, gap_end; - /* Adjust search length to account for worst case alignment overhead */ - length = info->length + info->align_mask; - if (length < info->length) - return -ENOMEM; + length = info->length; /* Adjust search limits by the desired length */ if (info->high_limit < length) @@ -1914,6 +1927,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) } gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0; + gap_start += gap_start_offset(info, gap_start); check_current: /* Check if current node has a suitable gap */ if (gap_start > high_limit) @@ -1942,6 +1956,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) struct vm_area_struct, vm_rb); if (prev == vma->vm_rb.rb_left) { gap_start = vm_end_gap(vma->vm_prev); + gap_start += gap_start_offset(info, gap_start); gap_end = vm_start_gap(vma); goto check_current; } @@ -1951,17 +1966,17 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) check_highest: /* Check highest gap, which does not precede any rbtree node */ gap_start = mm->highest_vm_end; + gap_start += gap_start_offset(info, gap_start); gap_end = ULONG_MAX; /* Only for VM_BUG_ON below */ if (gap_start > high_limit) return -ENOMEM; found: /* We found a suitable gap. Clip it with the original low_limit. */ - if (gap_start < info->low_limit) + if (gap_start < info->low_limit) { gap_start = info->low_limit; - - /* Adjust gap address to the desired alignment */ - gap_start += (info->align_offset - gap_start) & info->align_mask; + gap_start += gap_start_offset(info, gap_start); + } VM_BUG_ON(gap_start + info->length > info->high_limit); VM_BUG_ON(gap_start + info->length > gap_end); @@ -1974,16 +1989,14 @@ unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info) struct vm_area_struct *vma; unsigned long length, low_limit, high_limit, gap_start, gap_end; - /* Adjust search length to account for worst case alignment overhead */ - length = info->length + info->align_mask; - if (length < info->length) - return -ENOMEM; + length = info->length; /* * Adjust search limits by the desired length. * See implementation comment at top of unmapped_area(). */ gap_end = info->high_limit; + gap_end -= gap_end_offset(info, gap_end); if (gap_end < length) return -ENOMEM; high_limit = gap_end - length; @@ -2020,6 +2033,7 @@ unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info) check_current: /* Check if current node has a suitable gap */ gap_end = vm_start_gap(vma); + gap_end -= gap_end_offset(info, gap_end); if (gap_end < low_limit) return -ENOMEM; if (gap_start <= high_limit && @@ -2054,13 +2068,14 @@ unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info) found: /* We found a suitable gap. Clip it with the original high_limit. */ - if (gap_end > info->high_limit) + if (gap_end > info->high_limit) { gap_end = info->high_limit; + gap_end -= gap_end_offset(info, gap_end); + } found_highest: /* Compute highest gap address at the desired alignment */ gap_end -= info->length; - gap_end -= (gap_end - info->align_offset) & info->align_mask; VM_BUG_ON(gap_end < info->low_limit); VM_BUG_ON(gap_end < gap_start); -- 1.8.5.6

5 years, 5 months

4
5
0 0

[PATCH v3 2/2] Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in hci_uart_set_flow_control()

by Myungho Jung

tiocmget() or tiocmset() operations are optional. Just return from hci_uart_set_flow_control() if tiocmget() or tiocmset() operation is NULL. Fixes: 2a973dfada2b ("hci_uart: Add new line discipline enhancements") Cc: <stable(a)vger.kernel.org> # 4.2 Signed-off-by: Myungho Jung <mhjungk(a)gmail.com> --- Changes in v2: - Remove braces in if statment Changes in v3: - Split into 2 patches - Add stable CC and fixes tags drivers/bluetooth/hci_ldisc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c index fbf7b4df23ab..cb31c2d8d826 100644 --- a/drivers/bluetooth/hci_ldisc.c +++ b/drivers/bluetooth/hci_ldisc.c @@ -314,6 +314,10 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool enable) return; } + /* tiocmget() and tiocmset() operations are optional */ + if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset) + return; + if (enable) { /* Disable hardware flow control */ ktermios = tty->termios; -- 2.17.1

5 years, 5 months

2
1
0 0

CKI hackfest @Plumbers invite

by Veronika Kabatova

Hi, as some of you have heard, CKI Project is planning hackfest CI meetings after Plumbers conference this year (Sept. 12-13). We would like to invite everyone who has interest in CI for kernel to come and join us. The early agenda with summary is at the end of the email. If you think there's something important missing let us know! Also let us know in case you'd want to lead any of the sessions, we'd be happy to delegate out some work :) Please send us an email as soon as you decide to come and feel free to invite other people who should be present. We are not planning to cap the attendance right now but need to solve the logistics based on the interest. The event is free to attend, no additional registration except letting us know is needed. Feel free to contact us if you have any questions, Veronika CKI Project ----------------------------------------------------------- Here is an early agenda we put together: - Introductions - Common place for upstream results, result publishing in general - The discussion on the mailing list is going strong so we might be able to substitute this session for a different one in case everything is solved by September. - Test result interpretation and bug detection - How to autodetect infrastructure failures, regressions/new bugs and test bugs? How to handle continuous failures due to known bugs in both tests and kernel? What's your solution? Can people always trust the results they receive? - Getting results to developers/maintainers - Aimed at kernel developers and maintainers, share your feedback and expectations. - How much data should be sent in the initial communication vs. a click away in a dashboard? Do you want incremental emails with new results as they come in? - What about adding checks to tested patches in Patchwork when patch series are being tested? - Providing enough data/script to reproduce the failure. What if special HW is needed? - Onboarding new kernel trees to test - Aimed at kernel developers and maintainers. - Which trees are most prone to bring in new problems? Which are the most critical ones? Do you want them to be tested? Which tests do you feel are most beneficial for specific trees or in general? - Security when testing untrusted patches - How do we merge, compile, and test patches that have untrusted code in them and have not yet been reviewed? How do we avoid abuse of systems, information theft, or other damage? - Check out the original patch that sparked the discussion at https://patchwork.ozlabs.org/patch/862123/ - Avoiding effort duplication - Food for thought by GregKH - X different CI systems running ${TEST} on latest stable kernel on x86_64 might look useless on the first look but is it? AMD/Intel CPUs, different network cards, different graphic drivers, compilers, kernel configuration... How do we distribute the workload to avoid doing the same thing all over again while still running in enough different environments to get the most coverage? - Common hardware pools - Is this something people are interested in? Would be helpful especially for HW that's hard to access, eg. ppc64le or s390x systems. Companies could also sing up to share their HW for testing to ensure kernel works with their products.

5 years, 6 months

9
14
0 0

[stable/4.14.y PATCH 0/3] mmc: Fix a potential resource leak when shutting down request queue.

by Raul E Rangel

I think we should cherry-pick 41e3efd07d5a02c80f503e29d755aa1bbb4245de https://lore.kernel.org/patchwork/patch/856512/ into 4.14. It fixes a potential resource leak when shutting down the request queue. Once this patch is applied, there is a potential for a null pointer dereference. That's what the second patch fixes. The third patch is just an optimization to stop processing earlier. See https://patchwork.kernel.org/patch/10925469/ for the initial motivation. This commit applies to v4.14.116. It is already included in 4.19. 4.19 doesn't suffer from the null pointer dereference because later commits migrate the mmc stack to blk-mq. I tested this patch set by randomly connecting/disconnecting the SD card. I got over 189650 itarations without a problem. Thanks, Raul Adrian Hunter (1): mmc: block: Simplify cleaning up the queue Raul E Rangel (2): mmc: Fix null pointer dereference in mmc_init_request mmc: Kill the request if the queuedata has been removed drivers/mmc/core/block.c | 17 ++++++++++++----- drivers/mmc/core/queue.c | 14 +++++++++++--- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.21.0.1020.gf2820cf01a-goog

5 years, 6 months

5
11
0 0

[PATCH] Smack: Restore the smackfsdef mount option and add missing prefixes

by David Howells

From: Casey Schaufler <casey(a)schaufler-ca.com> The 5.1 mount system rework changed the smackfsdef mount option to smackfsdefault. This fixes the regression by making smackfsdef treated the same way as smackfsdefault. Also fix the smack_param_specs[] to have "smack" prefixes on all the names. This isn't visible to a user unless they either: (a) Try to mount a filesystem that's converted to the internal mount API and that implements the ->parse_monolithic() context operation - and only then if they call security_fs_context_parse_param() rather than security_sb_eat_lsm_opts(). There are no examples of this upstream yet, but nfs will probably want to do this for nfs2 or nfs3. (b) Use fsconfig() to configure the filesystem - in which case security_fs_context_parse_param() will be called. This issue is that smack_sb_eat_lsm_opts() checks for the "smack" prefix on the options, but smack_fs_context_parse_param() does not. Fixes: c3300aaf95fb ("smack: get rid of match_token()") Fixes: 2febd254adc4 ("smack: Implement filesystem context security hooks") Cc: stable(a)vger.kernel.org Reported-by: Jose Bollo <jose.bollo(a)iot.bzh> Signed-off-by: Casey Schaufler <casey(a)schaufler-ca.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Tested-by: Casey Schaufler <casey(a)schaufler-ca.com> --- security/smack/smack_lsm.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 0de725f88bed..d99450b4f511 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -68,6 +68,7 @@ static struct { int len; int opt; } smk_mount_opts[] = { + {"smackfsdef", sizeof("smackfsdef") - 1, Opt_fsdefault}, A(fsdefault), A(fsfloor), A(fshat), A(fsroot), A(fstransmute) }; #undef A @@ -682,11 +683,12 @@ static int smack_fs_context_dup(struct fs_context *fc, } static const struct fs_parameter_spec smack_param_specs[] = { - fsparam_string("fsdefault", Opt_fsdefault), - fsparam_string("fsfloor", Opt_fsfloor), - fsparam_string("fshat", Opt_fshat), - fsparam_string("fsroot", Opt_fsroot), - fsparam_string("fstransmute", Opt_fstransmute), + fsparam_string("smackfsdef", Opt_fsdefault), + fsparam_string("smackfsdefault", Opt_fsdefault), + fsparam_string("smackfsfloor", Opt_fsfloor), + fsparam_string("smackfshat", Opt_fshat), + fsparam_string("smackfsroot", Opt_fsroot), + fsparam_string("smackfstransmute", Opt_fstransmute), {} };

5 years, 6 months

5
6
0 0

[PATCH AUTOSEL 5.1 001/375] gfs2: Fix lru_count going negative

by Sasha Levin

From: Ross Lagerwall <ross.lagerwall(a)citrix.com> [ Upstream commit 7881ef3f33bb80f459ea6020d1e021fc524a6348 ] Under certain conditions, lru_count may drop below zero resulting in a large amount of log spam like this: vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \ negative objects to delete nr=-1 This happens as follows: 1) A glock is moved from lru_list to the dispose list and lru_count is decremented. 2) The dispose function calls cond_resched() and drops the lru lock. 3) Another thread takes the lru lock and tries to add the same glock to lru_list, checking if the glock is on an lru list. 4) It is on a list (actually the dispose list) and so it avoids incrementing lru_count. 5) The glock is moved to lru_list. 5) The original thread doesn't dispose it because it has been re-added to the lru list but the lru_count has still decreased by one. Fix by checking if the LRU flag is set on the glock rather than checking if the glock is on some list and rearrange the code so that the LRU flag is added/removed precisely when the glock is added/removed from lru_list. Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/gfs2/glock.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index d32964cd11176..e4f6d39500bcc 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -183,15 +183,19 @@ static int demote_ok(const struct gfs2_glock *gl) void gfs2_glock_add_to_lru(struct gfs2_glock *gl) { + if (!(gl->gl_ops->go_flags & GLOF_LRU)) + return; + spin_lock(&lru_lock); - if (!list_empty(&gl->gl_lru)) - list_del_init(&gl->gl_lru); - else + list_del(&gl->gl_lru); + list_add_tail(&gl->gl_lru, &lru_list); + + if (!test_bit(GLF_LRU, &gl->gl_flags)) { + set_bit(GLF_LRU, &gl->gl_flags); atomic_inc(&lru_count); + } - list_add_tail(&gl->gl_lru, &lru_list); - set_bit(GLF_LRU, &gl->gl_flags); spin_unlock(&lru_lock); } @@ -201,7 +205,7 @@ static void gfs2_glock_remove_from_lru(struct gfs2_glock *gl) return; spin_lock(&lru_lock); - if (!list_empty(&gl->gl_lru)) { + if (test_bit(GLF_LRU, &gl->gl_flags)) { list_del_init(&gl->gl_lru); atomic_dec(&lru_count); clear_bit(GLF_LRU, &gl->gl_flags); @@ -1159,8 +1163,7 @@ void gfs2_glock_dq(struct gfs2_holder *gh) !test_bit(GLF_DEMOTE, &gl->gl_flags)) fast_path = 1; } - if (!test_bit(GLF_LFLUSH, &gl->gl_flags) && demote_ok(gl) && - (glops->go_flags & GLOF_LRU)) + if (!test_bit(GLF_LFLUSH, &gl->gl_flags) && demote_ok(gl)) gfs2_glock_add_to_lru(gl); trace_gfs2_glock_queue(gh, 0); @@ -1456,6 +1459,7 @@ __acquires(&lru_lock) if (!spin_trylock(&gl->gl_lockref.lock)) { add_back_to_lru: list_add(&gl->gl_lru, &lru_list); + set_bit(GLF_LRU, &gl->gl_flags); atomic_inc(&lru_count); continue; } @@ -1463,7 +1467,6 @@ __acquires(&lru_lock) spin_unlock(&gl->gl_lockref.lock); goto add_back_to_lru; } - clear_bit(GLF_LRU, &gl->gl_flags); gl->gl_lockref.count++; if (demote_ok(gl)) handle_callback(gl, LM_ST_UNLOCKED, 0, false); @@ -1498,6 +1501,7 @@ static long gfs2_scan_glock_lru(int nr) if (!test_bit(GLF_LOCK, &gl->gl_flags)) { list_move(&gl->gl_lru, &dispose); atomic_dec(&lru_count); + clear_bit(GLF_LRU, &gl->gl_flags); freed++; continue; } -- 2.20.1

5 years, 6 months

6
87
0 0

[PATCH] Revert "usb: core: remove local_irq_save() around ->complete() handler"

by Soeren Moch

This reverts commit ed194d1367698a0872a2b75bbe06b3932ce9df3a. In contrast to the original patch description, apparently not all handlers were audited properly. E.g. my RT5370 based USB WIFI adapter (driver in drivers/net/wireless/ralink/rt2x00) hangs after a while under heavy load. This revert fixes this. Also revert the follow-up patch d6142b91e9cc249b3aa22c90fade67e2e2d52cdb ("usb: core: remove flags variable in __usb_hcd_giveback_urb()"), since now we need the flags variable again. Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # 4.20+ Signed-off-by: Soeren Moch <smoch(a)web.de> --- drivers/usb/core/hcd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 94d22551fc1b..08d25fcf8b8e 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1739,6 +1739,7 @@ static void __usb_hcd_giveback_urb(struct urb *urb) struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus); struct usb_anchor *anchor = urb->anchor; int status = urb->unlinked; + unsigned long flags; urb->hcpriv = NULL; if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) && @@ -1755,7 +1756,20 @@ static void __usb_hcd_giveback_urb(struct urb *urb) /* pass ownership to the completion handler */ urb->status = status; + + /* + * We disable local IRQs here avoid possible deadlock because + * drivers may call spin_lock() to hold lock which might be + * acquired in one hard interrupt handler. + * + * The local_irq_save()/local_irq_restore() around complete() + * will be removed if current USB drivers have been cleaned up + * and no one may trigger the above deadlock situation when + * running complete() in tasklet. + */ + local_irq_save(flags); urb->complete(urb); + local_irq_restore(flags); usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); -- 2.17.1

5 years, 6 months

5
10
0 0

[PATCH] media: v4l2-ioctl: clear fields in s_parm

by Naresh Kamboju

From: Hans Verkuil <hans.verkuil(a)cisco.com> commit 8a7c5594c02022ca5fa7fb603e11b3e1feb76ed5 upstream. Zero the reserved capture/output array. Zero the extendedmode (it is never used in drivers). Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY, as that is the only valid flag. Cc: <stable(a)vger.kernel.org> # v4.9 v4.14 Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> --- drivers/media/v4l2-core/v4l2-ioctl.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 4510e8a37244..699e5f8e0a71 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1959,7 +1959,22 @@ static int v4l_s_parm(const struct v4l2_ioctl_ops *ops, struct v4l2_streamparm *p = arg; int ret = check_fmt(file, p->type); - return ret ? ret : ops->vidioc_s_parm(file, fh, p); + if (ret) + return ret; + + /* Note: extendedmode is never used in drivers */ + if (V4L2_TYPE_IS_OUTPUT(p->type)) { + memset(p->parm.output.reserved, 0, + sizeof(p->parm.output.reserved)); + p->parm.output.extendedmode = 0; + p->parm.output.outputmode &= V4L2_MODE_HIGHQUALITY; + } else { + memset(p->parm.capture.reserved, 0, + sizeof(p->parm.capture.reserved)); + p->parm.capture.extendedmode = 0; + p->parm.capture.capturemode &= V4L2_MODE_HIGHQUALITY; + } + return ops->vidioc_s_parm(file, fh, p); } static int v4l_queryctrl(const struct v4l2_ioctl_ops *ops, -- 2.17.1

5 years, 6 months

2
1
0 0

Re: [PATCH 2/2] HID: wacom: Don't report anything prior to the tool entering range

by Jason Gerecke

I can produce a version of this patch specific to v4.14.113. Please let me know the proper process for submitting such a patch. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours.... On Thu, Apr 25, 2019 at 5:15 AM Sasha Levin <sashal(a)kernel.org> wrote: > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: a48324de6d4d HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range. > > The bot has tested the following trees: v5.0.9, v4.19.36, v4.14.113. > > v5.0.9: Build OK! > v4.19.36: Build OK! > v4.14.113: Failed to apply! Possible dependencies: > 87046b6c995c ("HID: wacom: Add support for 3rd generation Intuos BT") > c947218951da ("HID: wacom: Add support for One by Wacom (CTL-472 / CTL-672)") > > > How should we proceed with this patch? > > -- > Thanks, > Sasha

5 years, 6 months

3
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2019