March 2020 - Linux-stable-mirror

[PATCH] iommu/dma: Fix MSI reservation allocation

by Marc Zyngier

The way cookie_init_hw_msi_region() allocates the iommu_dma_msi_page structures doesn't match the way iommu_put_dma_cookie() frees them. The former performs a single allocation of all the required structures, while the latter tries to free them one at a time. It doesn't quite work for the main use case (the GICv3 ITS where the range is 64kB) when the base ganule size is 4kB. This leads to a nice slab corruption on teardown, which is easily observable by simply creating a VF on a SRIOV-capable device, and tearing it down immediately (no need to even make use of it). Fix it by allocating iommu_dma_msi_page structures one at a time. Fixes: 7c1b058c8b5a3 ("iommu/dma: Handle IOMMU API reserved regions") Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Joerg Roedel <jroedel(a)suse.de> Cc: Eric Auger <eric.auger(a)redhat.com> Cc: Will Deacon <will(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/iommu/dma-iommu.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index a2e96a5fd9a7..01fa64856c12 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -171,25 +171,37 @@ static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie, phys_addr_t start, phys_addr_t end) { struct iova_domain *iovad = &cookie->iovad; - struct iommu_dma_msi_page *msi_page; - int i, num_pages; + struct iommu_dma_msi_page *msi_page, *tmp; + int i, num_pages, ret = 0; + phys_addr_t base; - start -= iova_offset(iovad, start); + base = start -= iova_offset(iovad, start); num_pages = iova_align(iovad, end - start) >> iova_shift(iovad); - msi_page = kcalloc(num_pages, sizeof(*msi_page), GFP_KERNEL); - if (!msi_page) - return -ENOMEM; - for (i = 0; i < num_pages; i++) { - msi_page[i].phys = start; - msi_page[i].iova = start; - INIT_LIST_HEAD(&msi_page[i].list); - list_add(&msi_page[i].list, &cookie->msi_page_list); + msi_page = kmalloc(sizeof(*msi_page), GFP_KERNEL); + if (!msi_page) { + ret = -ENOMEM; + break; + } + msi_page->phys = start; + msi_page->iova = start; + INIT_LIST_HEAD(&msi_page->list); + list_add(&msi_page->list, &cookie->msi_page_list); start += iovad->granule; } - return 0; + if (ret) { + list_for_each_entry_safe(msi_page, tmp, + &cookie->msi_page_list, list) { + if (msi_page->phys >= base && msi_page->phys < start) { + list_del(&msi_page->list); + kfree(msi_page); + } + } + } + + return ret; } static int iova_reserve_pci_windows(struct pci_dev *dev, -- 2.20.1

4 years, 10 months

3
3
0 0

[PATCH v4 v4.4.y 0/7] Backported fixes for 4.4 stable tree

by Ajay Kaher

[Posting again after correcting CC’ed e-mail id] These patches include few backported fixes for the 4.4 stable tree. I would appreciate if you could kindly consider including them in the next release. Ajay --- [Changes from v3]: - Dropped [Patch v3 8/8] [2] as patches 1-7 are independent from patch 8 and patch 8 may require more work. [Changes from v2]: Merged following changes from Vlastimil's series [1]: - Added page_ref_count() in [Patch v3 5/8] - Added missing refcount overflow checks on x86 and s390 [Patch v3 5/8] - Added [Patch v3 8/8] - Removed 7aef4172c795 i.e. [Patch v2 3/8] [1] https://lore.kernel.org/stable/20191108093814.16032-1-vbabka@suse.cz/ [2] https://lore.kernel.org/stable/1576529149-14269-9-git-send-email-akaher@vmw… --- [PATCH v4 1/7]: Backporting of upstream commit f958d7b528b1: mm: make page ref count overflow check tighter and more explicit [PATCH v4 2/7]: Backporting of upstream commit 88b1a17dfc3e: mm: add 'try_get_page()' helper function [PATCH v4 3/7]: Backporting of upstream commit a3e328556d41: mm, gup: remove broken VM_BUG_ON_PAGE compound check for hugepages [PATCH v4 4/7]: Backporting of upstream commit d63206ee32b6: mm, gup: ensure real head page is ref-counted when using hugepages [PATCH v4 5/7]: Backporting of upstream commit 8fde12ca79af: mm: prevent get_user_pages() from overflowing page refcount [PATCH v4 6/7]: Backporting of upstream commit 7bf2d1df8082: pipe: add pipe_buf_get() helper [PATCH v4 7/7]: Backporting of upstream commit 15fab63e1e57: fs: prevent page refcount overflow in pipe_buf_get

4 years, 10 months

2
9
0 0

4.19 "perf stat: Fix shadow stats for clock events"

by Rantala, Tommi T. (Nokia - FI/Espoo)

Hi Greg, Sasha, Can you please include this perf stat fix to 4.19? These two commits needed: commit eb08d006054e7e374592068919e32579988602d4 Author: Ravi Bangoria <ravi.bangoria(a)linux.ibm.com> Date: Thu Nov 15 15:25:32 2018 +0530 perf stat: Use perf_evsel__is_clocki() for clock events commit 57ddf09173c1e7d0511ead8924675c7198e56545 Author: Ravi Bangoria <ravi.bangoria(a)linux.ibm.com> Date: Fri Nov 16 09:58:43 2018 +0530 perf stat: Fix shadow stats for clock events -Tommi

4 years, 10 months

2
1
0 0

[PATCH 4.14] tuntap: correctly set SOCKWQ_ASYNC_NOSPACE

by Tommi Rantala

From: Jason Wang <jasowang(a)redhat.com> [ Upstream commit 2f3ab6221e4c87960347d65c7cab9bd917d1f637 ] When link is down, writes to the device might fail with -EIO. Userspace needs an indication when the status is resolved. As a fix, tun_net_open() attempts to wake up writers - but that is only effective if SOCKWQ_ASYNC_NOSPACE has been set in the past. This is not the case of vhost_net which only poll for EPOLLOUT after it meets errors during sendmsg(). This patch fixes this by making sure SOCKWQ_ASYNC_NOSPACE is set when socket is not writable or device is down to guarantee EPOLLOUT will be raised in either tun_chr_poll() or tun_sock_write_space() after device is up. Cc: Hannes Frederic Sowa <hannes(a)stressinduktion.org> Cc: Eric Dumazet <edumazet(a)google.com> Fixes: 1bd4978a88ac2 ("tun: honor IFF_UP in tun_get_user()") Signed-off-by: Jason Wang <jasowang(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com> --- drivers/net/tun.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 3086211829a7..ba34f61d70de 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1134,6 +1134,13 @@ static void tun_net_init(struct net_device *dev) dev->max_mtu = MAX_MTU - dev->hard_header_len; } +static bool tun_sock_writeable(struct tun_struct *tun, struct tun_file *tfile) +{ + struct sock *sk = tfile->socket.sk; + + return (tun->dev->flags & IFF_UP) && sock_writeable(sk); +} + /* Character device part */ /* Poll */ @@ -1156,10 +1163,14 @@ static unsigned int tun_chr_poll(struct file *file, poll_table *wait) if (!skb_array_empty(&tfile->tx_array)) mask |= POLLIN | POLLRDNORM; - if (tun->dev->flags & IFF_UP && - (sock_writeable(sk) || - (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &sk->sk_socket->flags) && - sock_writeable(sk)))) + /* Make sure SOCKWQ_ASYNC_NOSPACE is set if not writable to + * guarantee EPOLLOUT to be raised by either here or + * tun_sock_write_space(). Then process could get notification + * after it writes to a down device and meets -EIO. + */ + if (tun_sock_writeable(tun, tfile) || + (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &sk->sk_socket->flags) && + tun_sock_writeable(tun, tfile))) mask |= POLLOUT | POLLWRNORM; if (tun->dev->reg_state != NETREG_REGISTERED) -- 2.21.1

4 years, 10 months

2
1
0 0

[PATCH linux-4.4.y/linux-4.9.y v2] slip: stop double free sl->dev in slip_open

by yangerkun

After include 3b5a39979daf ("slip: Fix memory leak in slip_open error path") and e58c19124189 ("slip: Fix use-after-free Read in slip_open") with 4.4.y/4.9.y. We will trigger a bug since we can double free sl->dev in slip_open. Actually, we should backport cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.") too since it has delete free_netdev from sl_free_netdev. Fix it by delete free_netdev from slip_open. Signed-off-by: yangerkun <yangerkun(a)huawei.com> --- drivers/net/slip/slip.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/slip/slip.c b/drivers/net/slip/slip.c index 0f8d5609ed51..d4a33baa33b6 100644 --- a/drivers/net/slip/slip.c +++ b/drivers/net/slip/slip.c @@ -868,7 +868,6 @@ err_free_chan: tty->disc_data = NULL; clear_bit(SLF_INUSE, &sl->flags); sl_free_netdev(sl->dev); - free_netdev(sl->dev); err_exit: rtnl_unlock(); -- 2.23.0.rc2.8.gff66981f45

4 years, 10 months

2
1
0 0

Fixes for 4.19 stable

by Vishnu Rangayyan

Hi, I still see high (upto 30%) ksoftirqd cpu use with 4.19.101+ after these 2 back ports went in for 4.19.101 (had all 4 backports applied earlier to our tree): commit f6783319737f28e4436a69611853a5a098cbe974 sched/fair: Fix insertion in rq->leaf_cfs_rq_list commit 5d299eabea5a251fbf66e8277704b874bbba92dc sched/fair: Add tmp_alone_branch assertion perf shows for any given ksoftirqd, with 20k-30k processes on the system with high scheduler load: 58.88% ksoftirqd/0 [kernel.kallsyms] [k] update_blocked_averages Can we backport these 2 also, confirmed that it fixes this behavior of ksoftirqd. commit 039ae8bcf7a5f4476f4487e6bf816885fb3fb617 upstream commit 31bc6aeaab1d1de8959b67edbed5c7a4b3cdbe7c upstream The second one doesn’t apply cleanly, there’s a small change for the last diff, where pelt needs renaming to task (cfg_rq_clock_pelt was cfs_rq_clock_task in 4.19.y) in that unchanged part of the diff: @@ -7700,10 +7720,6 @@ static void update_blocked_averages(int cpu) for_each_leaf_cfs_rq(rq, cfs_rq) { struct sched_entity *se; - /* throttled entities do not contribute to load */ - if (throttled_hierarchy(cfs_rq)) - continue; - if (update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq)) update_tg_load_avg(cfs_rq, 0); I can post that patch with that rename if required. Thanks Vishnu

4 years, 10 months

4
4
0 0

[PATCH 5.6] mt76: fix array overflow on receiving too many fragments for a packet

by Felix Fietkau

If the hardware receives an oversized packet with too many rx fragments, skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages. This becomes especially visible if it corrupts the freelist pointer of a slab page. Cc: stable(a)vger.kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> --- drivers/net/wireless/mediatek/mt76/dma.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c index 6173c80189ba..1847f55e199b 100644 --- a/drivers/net/wireless/mediatek/mt76/dma.c +++ b/drivers/net/wireless/mediatek/mt76/dma.c @@ -447,10 +447,13 @@ mt76_add_fragment(struct mt76_dev *dev, struct mt76_queue *q, void *data, struct page *page = virt_to_head_page(data); int offset = data - page_address(page); struct sk_buff *skb = q->rx_head; + struct skb_shared_info *shinfo = skb_shinfo(skb); - offset += q->buf_offset; - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset, len, - q->buf_size); + if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) { + offset += q->buf_offset; + skb_add_rx_frag(skb, shinfo->nr_frags, page, offset, len, + q->buf_size); + } if (more) return; -- 2.24.0

4 years, 10 months

3
2
0 0

[PATCH v5 2/5] MIPS: DTS: CI20: fix PMU definitions for ACT8600

by H. Nikolaus Schaller

There is a ACT8600 on the CI20 board and the bindings of the ACT8865 driver have changed without updating the CI20 device tree. Therefore the PMU can not be probed successfully and is running in power-on reset state. Fix DT to match the latest act8865-regulator bindings. Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes") Cc: stable(a)vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> Reviewed-by: Paul Cercueil <paul(a)crapouillou.net> --- arch/mips/boot/dts/ingenic/ci20.dts | 47 ++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/arch/mips/boot/dts/ingenic/ci20.dts b/arch/mips/boot/dts/ingenic/ci20.dts index 59c104289ece..ae391e0cd38a 100644 --- a/arch/mips/boot/dts/ingenic/ci20.dts +++ b/arch/mips/boot/dts/ingenic/ci20.dts @@ -4,6 +4,7 @@ #include "jz4780.dtsi" #include <dt-bindings/clock/ingenic,tcu.h> #include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/regulator/active-semi,8865-regulator.h> / { compatible = "img,ci20", "ingenic,jz4780"; @@ -166,65 +167,81 @@ reg = <0x5a>; status = "okay"; +/* +Optional input supply properties: +- for act8600: + - vp1-supply: The input supply for DCDC_REG1 + - vp2-supply: The input supply for DCDC_REG2 + - vp3-supply: The input supply for DCDC_REG3 + - inl-supply: The input supply for LDO_REG5, LDO_REG6, LDO_REG7 and LDO_REG8 + SUDCDC_REG4, LDO_REG9 and LDO_REG10 do not have separate supplies. +*/ + regulators { vddcore: SUDCDC1 { - regulator-name = "VDDCORE"; + regulator-name = "DCDC_REG1"; regulator-min-microvolt = <1100000>; regulator-max-microvolt = <1100000>; regulator-always-on; }; vddmem: SUDCDC2 { - regulator-name = "VDDMEM"; + regulator-name = "DCDC_REG2"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; regulator-always-on; }; vcc_33: SUDCDC3 { - regulator-name = "VCC33"; + regulator-name = "DCDC_REG3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-always-on; }; vcc_50: SUDCDC4 { - regulator-name = "VCC50"; + regulator-name = "SUDCDC_REG4"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; regulator-always-on; }; vcc_25: LDO_REG5 { - regulator-name = "VCC25"; + regulator-name = "LDO_REG5"; regulator-min-microvolt = <2500000>; regulator-max-microvolt = <2500000>; regulator-always-on; }; wifi_io: LDO_REG6 { - regulator-name = "WIFIIO"; + regulator-name = "LDO_REG6"; regulator-min-microvolt = <2500000>; regulator-max-microvolt = <2500000>; regulator-always-on; }; vcc_28: LDO_REG7 { - regulator-name = "VCC28"; + regulator-name = "LDO_REG7"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; regulator-always-on; }; vcc_15: LDO_REG8 { - regulator-name = "VCC15"; + regulator-name = "LDO_REG8"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; regulator-always-on; }; - vcc_18: LDO_REG9 { - regulator-name = "VCC18"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; + vrtc_18: LDO_REG9 { + regulator-name = "LDO_REG9"; + /* Despite the datasheet stating 3.3V for REG9 and + driver expecting that, REG9 outputs 1.8V. + Likely the CI20 uses a chip variant. + Since it is a simple on/off LDO the exact values + do not matter. + */ + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; regulator-always-on; }; vcc_11: LDO_REG10 { - regulator-name = "VCC11"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; + regulator-name = "LDO_REG10"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; regulator-always-on; }; }; -- 2.23.0

4 years, 10 months

2
4
0 0

[PATCH] rtc/cmos: Protect rtc_lock from interrupts

by Chris Wilson

cmos_interrrupt() is called directly on resume paths, and by the irqhandler. It currently assumes that it can only be invoked directly from a hardirq, and so leads to the lockdep splat: <4>[ 259.166718] WARNING: inconsistent lock state <4>[ 259.166725] 5.6.0-rc3-CI-CI_DRM_8038+ #1 Tainted: G U <4>[ 259.166727] -------------------------------- <4>[ 259.166731] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. <4>[ 259.166741] rtcwake/4221 [HC0[0]:SC0[0]:HE1:SE1] takes: <4>[ 259.166745] ffffffff82635198 (rtc_lock){?...}, at: cmos_interrupt+0x18/0x100 <4>[ 259.166768] {IN-HARDIRQ-W} state was registered at: <4>[ 259.166780] lock_acquire+0xa7/0x1c0 <4>[ 259.166790] _raw_spin_lock+0x2a/0x40 <4>[ 259.166799] cmos_interrupt+0x18/0x100 <4>[ 259.166808] rtc_handler+0x75/0xc0 <4>[ 259.166822] acpi_ev_fixed_event_detect+0xf9/0x132 <4>[ 259.166829] acpi_ev_sci_xrupt_handler+0xb/0x28 <4>[ 259.166838] acpi_irq+0x13/0x30 <4>[ 259.166849] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 259.166859] handle_irq_event_percpu+0x2b/0x70 <4>[ 259.166868] handle_irq_event+0x2f/0x50 <4>[ 259.166875] handle_fasteoi_irq+0x8e/0x150 <4>[ 259.166883] do_IRQ+0x7e/0x160 <4>[ 259.166891] ret_from_intr+0x0/0x35 <4>[ 259.166898] mwait_idle+0x7e/0x200 <4>[ 259.166905] do_idle+0x1bb/0x260 <4>[ 259.166912] cpu_startup_entry+0x14/0x20 <4>[ 259.166921] start_secondary+0x15f/0x1b0 <4>[ 259.166929] secondary_startup_64+0xa4/0xb0 <4>[ 259.167264] irq event stamp: 41593 <4>[ 259.167275] hardirqs last enabled at (41593): [<ffffffff81a394e7>] _raw_spin_unlock_irqrestore+0x47/0x60 <4>[ 259.167285] hardirqs last disabled at (41592): [<ffffffff81a3926d>] _raw_spin_lock_irqsave+0xd/0x50 <4>[ 259.167296] softirqs last enabled at (41568): [<ffffffff81e00385>] __do_softirq+0x385/0x47f <4>[ 259.167306] softirqs last disabled at (41561): [<ffffffff810babaa>] irq_exit+0xba/0xc0 <4>[ 259.167309] other info that might help us debug this: <4>[ 259.167312] Possible unsafe locking scenario: <4>[ 259.167314] CPU0 <4>[ 259.167316] ---- <4>[ 259.167319] lock(rtc_lock); <4>[ 259.167324] <Interrupt> <4>[ 259.167326] lock(rtc_lock); <4>[ 259.167332] *** DEADLOCK *** <4>[ 259.167337] 6 locks held by rtcwake/4221: <4>[ 259.167665] #0: ffff888175e89408 (sb_writers#5){.+.+}, at: vfs_write+0x1a4/0x1d0 <4>[ 259.167687] #1: ffff88816e112080 (&of->mutex){+.+.}, at: kernfs_fop_write+0xdd/0x1b0 <4>[ 259.167706] #2: ffff888179be85e0 (kn->count#236){.+.+}, at: kernfs_fop_write+0xe6/0x1b0 <4>[ 259.167728] #3: ffffffff82641e00 (system_transition_mutex){+.+.}, at: pm_suspend+0xb3/0x3b0 <4>[ 259.167748] #4: ffffffff826b3ea0 (acpi_scan_lock){+.+.}, at: acpi_suspend_begin+0x47/0x80 <4>[ 259.167763] #5: ffff888178f6b960 (&dev->mutex){....}, at: device_resume+0x92/0x1c0 <4>[ 259.167778] stack backtrace: <4>[ 259.167788] CPU: 1 PID: 4221 Comm: rtcwake Tainted: G U 5.6.0-rc3-CI-CI_DRM_8038+ #1 <4>[ 259.168106] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019 <4>[ 259.168110] Call Trace: <4>[ 259.168123] dump_stack+0x71/0x9b <4>[ 259.168133] mark_lock+0x49a/0x500 <4>[ 259.168457] ? print_shortest_lock_dependencies+0x200/0x200 <4>[ 259.168469] __lock_acquire+0x6d4/0x15d0 <4>[ 259.168479] ? __lock_acquire+0x460/0x15d0 <4>[ 259.168490] lock_acquire+0xa7/0x1c0 <4>[ 259.168500] ? cmos_interrupt+0x18/0x100 <4>[ 259.168824] _raw_spin_lock+0x2a/0x40 <4>[ 259.168834] ? cmos_interrupt+0x18/0x100 <4>[ 259.168843] cmos_interrupt+0x18/0x100 <4>[ 259.169159] cmos_resume+0x1fd/0x290 <4>[ 259.169174] ? __acpi_pm_set_device_wakeup+0x24/0x100 <4>[ 259.169498] pnp_bus_resume+0x5e/0x90 <4>[ 259.169509] ? pnp_bus_suspend+0x10/0x10 <4>[ 259.169518] dpm_run_callback+0x64/0x280 <4>[ 259.169530] device_resume+0xd4/0x1c0 <4>[ 259.169540] ? dpm_watchdog_set+0x60/0x60 <4>[ 259.169860] dpm_resume+0x106/0x410 <4>[ 259.169870] ? dpm_resume_early+0x38c/0x3e0 <4>[ 259.169881] dpm_resume_end+0x8/0x10 <4>[ 259.170195] suspend_devices_and_enter+0x16f/0xbe0 <4>[ 259.170211] ? rcu_read_lock_sched_held+0x4d/0x80 <4>[ 259.170528] pm_suspend+0x344/0x3b0 <4>[ 259.170542] state_store+0x78/0xe0 <4>[ 259.170559] kernfs_fop_write+0x112/0x1b0 <4>[ 259.170579] vfs_write+0xb9/0x1d0 <4>[ 259.170896] ksys_write+0x9f/0xe0 <4>[ 259.170907] do_syscall_64+0x4f/0x220 <4>[ 259.170918] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 259.171229] RIP: 0033:0x7f9b4f3cb154 <4>[ 259.171240] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 b1 07 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 <4>[ 259.171245] RSP: 002b:00007ffc057ce438 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 <4>[ 259.171253] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f9b4f3cb154 <4>[ 259.171257] RDX: 0000000000000004 RSI: 000055f4b3d185a0 RDI: 000000000000000a <4>[ 259.171572] RBP: 000055f4b3d185a0 R08: 000055f4b3d165e0 R09: 00007f9b4fab7740 <4>[ 259.171576] R10: 000055f4b3d14010 R11: 0000000000000246 R12: 000055f4b3d16500 <4>[ 259.171580] R13: 0000000000000004 R14: 00007f9b4f6a32a0 R15: 00007f9b4f6a2760 Fixes: c6d3a278cc12 ("rtc: cmos: acknowledge ACPI driven wake alarms upon resume") Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Zhang Rui <rui.zhang(a)intel.com> Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: Alessandro Zummo <a.zummo(a)towertech.it> Cc: <stable(a)vger.kernel.org> # v4.18+ --- drivers/rtc/rtc-cmos.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index b795fe4cbd2e..7754225c6f9d 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -651,8 +651,9 @@ static irqreturn_t cmos_interrupt(int irq, void *p) { u8 irqstat; u8 rtc_control; + unsigned long flags; - spin_lock(&rtc_lock); + spin_lock_irqsave(&rtc_lock, flags); /* When the HPET interrupt handler calls us, the interrupt * status is passed as arg1 instead of the irq number. But @@ -686,7 +687,7 @@ static irqreturn_t cmos_interrupt(int irq, void *p) hpet_mask_rtc_irq_bit(RTC_AIE); CMOS_READ(RTC_INTR_FLAGS); } - spin_unlock(&rtc_lock); + spin_unlock_irqrestore(&rtc_lock, flags); if (is_intr(irqstat)) { rtc_update_irq(p, 1, irqstat); -- 2.25.1

4 years, 10 months

2
1
0 0

[PATCH v3 1/3] usb: core: hub: fix unhandled return by employing a void function

by Eugeniu Rosca

Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET): *** CID 1458999: Error handling issues (CHECKED_RETURN) /drivers/usb/core/hub.c: 1869 in hub_probe() 1863 1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) 1865 hub->quirk_check_port_auto_suspend = 1; 1866 1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) { 1868 hub->quirk_disable_autosuspend = 1; >>> CID 1458999: Error handling issues (CHECKED_RETURN) >>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times). 1869 usb_autopm_get_interface(intf); 1870 } 1871 1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) 1873 return 0; 1874 Rather than checking the return value of 'usb_autopm_get_interface()', switch to the usb_autopm_get_interface_no_resume() API, as per: On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote: ------ 8< ------ > This change (i.e. 'ret = usb_autopm_get_interface') is not necessary, > because the resume operation cannot fail at this point (interfaces > are always powered-up during probe). A better solution would be to > call usb_autopm_get_interface_no_resume() instead. ------ 8< ------ Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: Hardik Gajjar <hgajjar(a)de.adit-jv.com> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: stable(a)vger.kernel.org # v4.14+ Reported-by: scan-admin(a)coverity.com Suggested-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Eugeniu Rosca <erosca(a)de.adit-jv.com> --- v3: - Make the summary line more clear - s/autpm/autopm/ in patch description - Cc <stable> with v4.14+ since v4.14.x is the earliest stable kernel which accepted commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") v2: - [Alan Stern] Use usb_autopm_get_interface_no_resume() instead of usb_autopm_get_interface() - Augment commit description to provide background - Link: https://lore.kernel.org/lkml/20200225183057.31953-1-erosca@de.adit-jv.com v1: - Link: https://lore.kernel.org/lkml/20200225130846.20236-1-erosca@de.adit-jv.com --- drivers/usb/core/hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 1d212f82c69b..1105983b5c1c 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1866,7 +1866,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) { hub->quirk_disable_autosuspend = 1; - usb_autopm_get_interface(intf); + usb_autopm_get_interface_no_resume(intf); } if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) -- 2.25.1

4 years, 10 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2020