30 Dec, 2020
40 commits
-
[ Upstream commit 4509b42c38963f495b49aa50209c34337286ecbe ]
These functions accomplish the same thing but have different
implementations.unpin_user_page() has a bug where it calls mod_node_page_state() after
calling put_page() which creates a risk that the page could have been
hot-uplugged from the system.Fix this by using put_compound_head() as the only implementation.
__unpin_devmap_managed_user_page() and related can be deleted as well in
favour of the simpler, but slower, version in put_compound_head() that has
an extra atomic page_ref_sub, but always calls put_page() which internally
contains the special devmap code.Move put_compound_head() to be directly after try_grab_compound_head() so
people can find it in future.Link: https://lkml.kernel.org/r/0-v1-6730d4ee0d32+40e6-gup_combine_put_jgg@nvidia.com
Fixes: 1970dc6f5226 ("mm/gup: /proc/vmstat: pin_user_pages (FOLL_PIN) reporting")
Signed-off-by: Jason Gunthorpe
Reviewed-by: John Hubbard
Reviewed-by: Ira Weiny
Reviewed-by: Jan Kara
CC: Joao Martins
CC: Jonathan Corbet
CC: Dan Williams
CC: Dave Chinner
CC: Christoph Hellwig
CC: Jane Chu
CC: "Kirill A. Shutemov"
CC: Michal Hocko
CC: Mike Kravetz
CC: Shuah Khan
CC: Muchun Song
CC: Vlastimil Babka
CC: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 57efa1fe5957694fa541c9062de0a127f0b9acb0 ]
Since commit 70e806e4e645 ("mm: Do early cow for pinned pages during
fork() for ptes") pages under a FOLL_PIN will not be write protected
during COW for fork. This means that pages returned from
pin_user_pages(FOLL_WRITE) should not become write protected while the pin
is active.However, there is a small race where get_user_pages_fast(FOLL_PIN) can
establish a FOLL_PIN at the same time copy_present_page() is write
protecting it:CPU 0 CPU 1
get_user_pages_fast()
internal_get_user_pages_fast()
copy_page_range()
pte_alloc_map_lock()
copy_present_page()
atomic_read(has_pinned) == 0
page_maybe_dma_pinned() == false
atomic_set(has_pinned, 1);
gup_pgd_range()
gup_pte_range()
pte_t pte = gup_get_pte(ptep)
pte_access_permitted(pte)
try_grab_compound_head()
pte = pte_wrprotect(pte)
set_pte_at();
pte_unmap_unlock()
// GUP now returns with a write protected pageThe first attempt to resolve this by using the write protect caused
problems (and was missing a barrrier), see commit f3c64eda3e50 ("mm: avoid
early COW write protect games during fork()")Instead wrap copy_p4d_range() with the write side of a seqcount and check
the read side around gup_pgd_range(). If there is a collision then
get_user_pages_fast() fails and falls back to slow GUP.Slow GUP is safe against this race because copy_page_range() is only
called while holding the exclusive side of the mmap_lock on the src
mm_struct.[akpm@linux-foundation.org: coding style fixes]
Link: https://lore.kernel.org/r/CAHk-=wi=iCnYCARbPGjkVJu9eyYeZ13N64tZYLdOB8CP5Q_PLw@mail.gmail.comLink: https://lkml.kernel.org/r/2-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
Fixes: f3c64eda3e50 ("mm: avoid early COW write protect games during fork()")
Signed-off-by: Jason Gunthorpe
Suggested-by: Linus Torvalds
Reviewed-by: John Hubbard
Reviewed-by: Jan Kara
Reviewed-by: Peter Xu
Acked-by: "Ahmed S. Darwish" [seqcount_t parts]
Cc: Andrea Arcangeli
Cc: "Aneesh Kumar K.V"
Cc: Christoph Hellwig
Cc: Hugh Dickins
Cc: Jann Horn
Cc: Kirill Shutemov
Cc: Kirill Tkhai
Cc: Leon Romanovsky
Cc: Michal Hocko
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit c28b1fc70390df32e29991eedd52bd86e7aba080 ]
Patch series "Add a seqcount between gup_fast and copy_page_range()", v4.
As discussed and suggested by Linus use a seqcount to close the small race
between gup_fast and copy_page_range().Ahmed confirms that raw_write_seqcount_begin() is the correct API to use
in this case and it doesn't trigger any lockdeps.I was able to test it using two threads, one forking and the other using
ibv_reg_mr() to trigger GUP fast. Modifying copy_page_range() to sleep
made the window large enough to reliably hit to test the logic.This patch (of 2):
The next patch in this series makes the lockless flow a little more
complex, so move the entire block into a new function and remove a level
of indention. Tidy a bit of cruft:- addr is always the same as start, so use start
- Use the modern check_add_overflow() for computing end = start + len
- nr_pinned/pages << PAGE_SHIFT needs the LHS to be unsigned long to
avoid shift overflow, make the variables unsigned long to avoid coding
casts in both places. nr_pinned was missing its cast- The handling of ret and nr_pinned can be streamlined a bit
No functional change.
Link: https://lkml.kernel.org/r/0-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
Link: https://lkml.kernel.org/r/1-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jan Kara
Reviewed-by: John Hubbard
Reviewed-by: Peter Xu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 7eded018bfeccb365963bb51be731a9f99aeea59 ]
We need to move the check under the non-headless case, otherwise
we always reserve the VGA save size.Fixes: 157fe68d74c2ad ("drm/amdgpu: fix size calculation with stolen vga memory")
Reviewed-by: Guchun Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin -
[ Upstream commit b2ce5dbc15819ea4bef47dbd368239cb1e965158 ]
Commit e1c92a7fbbc5 ("perf tests: Add another metric parsing test") add
another test for metric parsing. The test goes through all metrics
compiled for arch within pmu events and try to parse them.Right now this test is failing in powerpc machine.
Result in power9 platform:
[command]# ./perf test 10
10: PMU events :
10.1: PMU event table sanity : Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics : Skip (some metrics failed)
10.4: Parsing of PMU event table metrics with fake PMUs : FAILED!Issue is we are passing different runtime parameter value in
"expr__find_other" and "expr__parse" function which is called from
function `metric_parse_fake`. And because of this parsing of hv-24x7
metrics is failing.[command]# ./perf test 10 -vv
.....
hv_24x7/pm_mcs01_128b_rd_disp_port01,chip=1/ not found
expr__parse failed
test child finished with -1
---- end ----
PMU events subtest 4: FAILED!This patch fix this issue and change runtime parameter value to '0' in
expr__parse function.Result in power9 platform after this patch:
[command]# ./perf test 10
10: PMU events :
10.1: PMU event table sanity : Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics : Skip (some metrics failed)
10.4: Parsing of PMU event table metrics with fake PMUs : OkFixes: e1c92a7fbbc5 ("perf tests: Add another metric parsing test")
Signed-off-by: Kajol Jain
Acked-by: Ian Rogers
Acked-by: Jiri Olsa
Cc: Madhavan Srinivasan
Cc: Ravi Bangoria
Link: http://lore.kernel.org/lkml/20201119152411.46041-1-kjain@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin -
[ Upstream commit d0edaa28a1f7830997131cbce87b6c52472825d1 ]
The DMA address returned by dma_map_single() should be checked with
dma_mapping_error(). Fix the ps3stor_setup() function accordingly.Fixes: 80071802cb9c ("[POWERPC] PS3: Storage Driver Core")
Signed-off-by: Vincent Stehlé
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20201213182622.23047-1-vincent.stehle@laposte.net
Signed-off-by: Sasha Levin -
[ Upstream commit ef0e3b650f8ddc54bb70868852f50642ee3ae765 ]
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
In Power10, this is a 8bit field, so patch fixes the
current code to modify the MMCRA[TECM] extraction macro to
handle this change. ISA v3.1 says this is a 7 bit field but
POWER10 it's actually 8 bits which will hopefully be fixed
in ISA v3.1 update.Fixes: 170a315f41c6 ("powerpc/perf: Support to export MMCRA[TEC*] field to userspace")
Signed-off-by: Madhavan Srinivasan
Signed-off-by: Athira Rajeev
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/1608022578-1532-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin -
[ Upstream commit ee46d16d2e40bebc2aa790fd7b6a056466ff895c ]
It can take multiple iterations until all components for an attached DSI
bridge are up leading to several:[ 3.796425] mxsfb 30320000.lcd-controller: Cannot connect bridge: -517
[ 3.816952] mxsfb 30320000.lcd-controller: [drm:mxsfb_probe [mxsfb]] *ERROR* failed to attach bridge: -517Silence this by checking for -EPROBE_DEFER and using dev_err_probe() so
we set a deferred reason in case a dependency fails to probe (which
quickly happens on small config/DT changes due to the rather long probe
chain which can include bridges, phys, panels, backights, leds, etc.).This also removes the only DRM_DEV_ERROR() usage, the rest of the driver
uses dev_err().Signed-off-by: Guido Günther
Fixes: c42001e357f7 ("drm: mxsfb: Use drm_panel_bridge")
Signed-off-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/d5761eb871adde5464ba112b89d966568bc2ff6c.1608020391.git.agx@sigxcpu.org
Signed-off-by: Sasha Levin -
[ Upstream commit a4485baefa1efa596702ebffd5a9c760d42b14b5 ]
add the code to release the nfc firmware when the firmware image size is
wrong.Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
Signed-off-by: Bongsu Jeon
Reviewed-by: Krzysztof Kozlowski
Link: https://lore.kernel.org/r/20201213095850.28169-1-bongsu.jeon@samsung.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin -
[ Upstream commit e246b7c035d74abfb3507fa10082d0c42cc016c3 ]
As part of the cma_dev release, that pointer will be set to NULL. In case
it happens in rdma_bind_addr() (part of an error flow), the next call to
addr_handler() will have a call to cma_acquire_dev_by_src_ip() which will
overwrite sgid_attr without releasing it.WARNING: CPU: 2 PID: 108 at drivers/infiniband/core/cma.c:606 cma_bind_sgid_attr drivers/infiniband/core/cma.c:606 [inline]
WARNING: CPU: 2 PID: 108 at drivers/infiniband/core/cma.c:606 cma_acquire_dev_by_src_ip+0x470/0x4b0 drivers/infiniband/core/cma.c:649
CPU: 2 PID: 108 Comm: kworker/u8:1 Not tainted 5.10.0-rc6+ #257
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: ib_addr process_one_req
RIP: 0010:cma_bind_sgid_attr drivers/infiniband/core/cma.c:606 [inline]
RIP: 0010:cma_acquire_dev_by_src_ip+0x470/0x4b0 drivers/infiniband/core/cma.c:649
Code: 66 d9 4a ff 4d 8b 6e 10 49 8d bd 1c 08 00 00 e8 b6 d6 4a ff 45 0f b6 bd 1c 08 00 00 41 83 e7 01 e9 49 fd ff ff e8 90 c5 29 ff 0b e9 80 fe ff ff e8 84 c5 29 ff 4c 89 f7 e8 2c d9 4a ff 4d 8b
RSP: 0018:ffff8881047c7b40 EFLAGS: 00010293
RAX: ffff888104789c80 RBX: 0000000000000001 RCX: ffffffff820b8ef8
RDX: 0000000000000000 RSI: ffffffff820b9080 RDI: ffff88810cd4c998
RBP: ffff8881047c7c08 R08: ffff888104789c80 R09: ffffed10209f4036
R10: ffff888104fa01ab R11: ffffed10209f4035 R12: ffff88810cd4c800
R13: ffff888105750e28 R14: ffff888108f0a100 R15: ffff88810cd4c998
FS: 0000000000000000(0000) GS:ffff888119c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000104e60005 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
addr_handler+0x266/0x350 drivers/infiniband/core/cma.c:3190
process_one_req+0xa3/0x300 drivers/infiniband/core/addr.c:645
process_one_work+0x54c/0x930 kernel/workqueue.c:2272
worker_thread+0x82/0x830 kernel/workqueue.c:2418
kthread+0x1ca/0x220 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296Fixes: ff11c6cd521f ("RDMA/cma: Introduce and use cma_acquire_dev_by_src_ip()")
Link: https://lore.kernel.org/r/20201213132940.345554-5-leon@kernel.org
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin -
[ Upstream commit e89938902927a54abebccc9537991aca5237dfaf ]
If the MR cache entry invalidation failed, then we detach this entry from
the cache, therefore we must to free the memory as well.Allcation backtrace for the leaker:
[] alloc_cache_mr+0x23/0xc0 [mlx5_ib]
[] create_cache_mr+0x3f/0xf0 [mlx5_ib]
[] mlx5_ib_alloc_implicit_mr+0x41/0×210 [mlx5_ib]
[] mlx5_ib_reg_user_mr+0x9e/0×6e0 [mlx5_ib]
[] create_qp+0x2fc/0xf00 [ib_uverbs]
[] ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ+0x1d9/0×230 [ib_uverbs]
[] rdma_alloc_commit_uobject+0xb5/0×120 [ib_uverbs]
[] uverbs_alloc+0x2b/0xf0 [ib_uverbs]
[] ksysioctl+0x234/0×7d0
[] __x64_sys_ioctl+0x16/0×20
[] do_syscall_64+0x59/0×2e0Fixes: 1769c4c57548 ("RDMA/mlx5: Always remove MRs from the cache before destroying them")
Link: https://lore.kernel.org/r/20201213132940.345554-2-leon@kernel.org
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin -
[ Upstream commit ac9645c87380e39a8fa87a1b51721efcdea89dbf ]
When receiving pages data, return value 'ret' when positive includes
`buf->page_base`, so we should subtract that before it is used for
changing `offset` and comparing against `want`.This was discovered on the very rare cases where the server returned a
chunk of bytes that when added to the already received amount of bytes
for the pages happened to match the current `recv.len`, for example
on this case:buf->page_base : 258356
actually received from socket: 1740
ret : 260096
want : 260096In this case neither of the two 'if ... goto out' trigger, and we
continue to tail parsing.Worth to mention that the ensuing EMSGSIZE from the continued execution of
`xs_read_xdr_buf` may be observed by an application due to 4 superfluous
bytes being added to the pages data.Fixes: 277e4ab7d530 ("SUNRPC: Simplify TCP receive code by switching to using iterators")
Signed-off-by: Dan Aloni
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin -
[ Upstream commit 9431f7c199ab0d02da1482d62255e0b4621cb1b5 ]
xterm serial channel was leaking a fd used in setting up the
port helperThis bug is prehistoric - it predates switching to git. The "fixes"
header here is really just to mark all the versions we would like this to
apply to which is "Anything from the Cretaceous period onwards".No dinosaurs were harmed in fixing this bug.
Fixes: b40997b872cd ("um: drivers/xterm.c: fix a file descriptor leak")
Signed-off-by: Anton Ivanov
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin -
[ Upstream commit 9b1c0c0e25dcccafd30e7d4c150c249cc65550eb ]
Fix a logical error in tty reading. We get 0 and errno == EAGAIN
on the first attempt to read from a closed file descriptor.Compared to that a true EAGAIN is EAGAIN and -1.
If we check errno for EAGAIN first, before checking the return
value we miss the fact that the descriptor is closed.This bug is as old as the driver. It was not showing up with
the original POLL based IRQ controller, because it was
producing multiple events. Switching to EPOLL unmasked it.Fixes: ff6a17989c08 ("Epoll based IRQ controller")
Signed-off-by: Anton Ivanov
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin -
[ Upstream commit e3a01cbee9c5f2c6fc813dd6af007716e60257e7 ]
Ensure that file closes, connection closes, etc are propagated
as interrupts in the interrupt controller.Fixes: ff6a17989c08 ("Epoll based IRQ controller")
Signed-off-by: Anton Ivanov
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin -
[ Upstream commit 3cded66330591cfd2554a3fd5edca8859ea365a2 ]
Fix to return PTR_ERR() error code from the error handling case where
ubifs_hash_get_desc() failed instead of 0 in ubifs_init_authentication(),
as done elsewhere in this function.Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Wang ShaoBo
Reviewed-by: Sascha Hauer
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin -
[ Upstream commit 6f733cb2e7db38f8141b14740bcde577844a03b7 ]
A reboot notifier, which stops the WDT by calling the stop hook without
any check, would be registered when we set WDOG_STOP_ON_REBOOT flag.Howerer we allow the WDT driver to omit the stop hook since commit
"d0684c8a93549" ("watchdog: Make stop function optional") and provide
a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag
in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to
control reboot policy"). Together that commits make user potential to
insert a watchdog driver that don't provide a stop hook but with the
stop_on_reboot parameter set, then dereferencing of null pointer occurs
on system reboot.Check the stop hook before registering the reboot notifier to fix the
issue.Fixes: d0684c8a9354 ("watchdog: Make stop function optional")
Signed-off-by: Wang Wensheng
Reviewed-by: Guenter Roeck
Link: https://lore.kernel.org/r/20201109130512.28121-1-wangwensheng4@huawei.com
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Sasha Levin -
[ Upstream commit 3e07d240939803bed9feb2a353d94686a411a7ca ]
As the specification described, users must check busy bit before start
a new loading operation to make sure that the previous loading is done
and the device is ready to accept a new one.[ chunyan: Massaged changelog ]
Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver")
Signed-off-by: Lingling Xu
Signed-off-by: Chunyan Zhang
Reviewed-by: Guenter Roeck
Link: https://lore.kernel.org/r/20201029023933.24548-3-zhang.lyra@gmail.com
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Sasha Levin -
[ Upstream commit f61a59acb462840bebcc192f754fe71b6a16ff99 ]
sprd_wdt_start() would return fail if the loading operation is not completed
in a certain time, disabling watchdog for that case would probably cause
the kernel crash when kick watchdog later, that's too bad, so remove the
watchdog disable operation for the fail case to make sure other parts in
the kernel can run normally.[ chunyan: Massaged changelog ]
Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver")
Signed-off-by: Lingling Xu
Signed-off-by: Chunyan Zhang
Reviewed-by: Guenter Roeck
Link: https://lore.kernel.org/r/20201029023933.24548-2-zhang.lyra@gmail.com
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Sasha Levin -
[ Upstream commit 8ae2511112d2e18bc7d324b77f965d34083a25a2 ]
If HAS_IOMEM is not defined and SIRFSOC_WATCHDOG is enabled,
the build fails with the following error.drivers/watchdog/sirfsoc_wdt.o: in function `sirfsoc_wdt_probe':
sirfsoc_wdt.c:(.text+0x112):
undefined reference to `devm_platform_ioremap_resource'Reported-by: Necip Fazil Yildiran
Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
Link: https://lore.kernel.org/r/20201108162550.27660-2-linux@roeck-us.net
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Sasha Levin -
[ Upstream commit 7f6f1dfb2dcbe5d2bfa213f2df5d74c147cd5954 ]
The following kbuild warning is seen on a system without HAS_IOMEM.
WARNING: unmet direct dependencies detected for MFD_SYSCON
Depends on [n]: HAS_IOMEM [=n]
Selected by [y]:
- ARMADA_37XX_WATCHDOG [=y] && WATCHDOG [=y] && (ARCH_MVEBU || COMPILE_TESTThis results in a subsequent compile error.
drivers/watchdog/armada_37xx_wdt.o: in function `armada_37xx_wdt_probe':
armada_37xx_wdt.c:(.text+0xdc): undefined reference to `devm_ioremap'Add the missing dependency.
Reported-by: Necip Fazil Yildiran
Fixes: 54e3d9b518c8 ("watchdog: Add support for Armada 37xx CPU watchdog")
Link: https://lore.kernel.org/r/20201108162550.27660-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Sasha Levin -
[ Upstream commit 2f5fbc4305d07725bfebaedb09e57271315691ef ]
We have a problem if we use gpio-keys and configure wakeups such that
we only want one edge to wake us up. AKA:
wakeup-event-action = ;
wakeup-source;Specifically we end up with a phantom interrupt that blocks suspend if
the line was already high and we want wakeups on rising edges (AKA we
want the GPIO to go low and then high again before we wake up). The
opposite is also problematic.Specifically, here's what's happening today:
1. Normally, gpio-keys configures to look for both edges. Due to the
current workaround introduced in commit c3c0c2e18d94 ("pinctrl:
qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the
line was high we'd configure for falling edges.
2. At suspend time, we change to look for rising edges.
3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt.We can solve this by just clearing the phantom interrupt.
NOTE: it is possible that this could cause problems for a client with
very specific needs, but there's not much we can do with this
hardware. As an example, let's say the interrupt signal is currently
high and the client is looking for falling edges. The client now
changes to look for rising edges. The client could possibly expect
that if the line has a short pulse low (and back high) that it would
always be detected. Specifically no matter when the pulse happened,
it should either have tripped the (old) falling edge trigger or the
(new) rising edge trigger. We will simply not trip it. We could
narrow down the race a bit by polling our parent before changing
types, but no matter what we do there will still be a period of time
where we can't tell the difference between a real transition (or more
than one transition) and the phantom.Fixes: f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")
Signed-off-by: Douglas Anderson
Signed-off-by: Marc Zyngier
Tested-by: Maulik Shah
Reviewed-by: Maulik Shah
Reviewed-by: Stephen Boyd
Link: https://lore.kernel.org/r/20201211141514.v4.1.I2702919afc253e2a451bebc3b701b462b2d22344@changeid
Signed-off-by: Sasha Levin -
[ Upstream commit f57ad6a9885e8399897daee3249cabccf9c972f8 ]
Currently 6G specific tlvs have duplicate entries which is causing
scan failures. Fix this by removing the duplicate entries of the same
tlv. This also fixes out-of-bound memory writes caused due to
adding tlvs when num_hint_bssid and num_hint_s_ssid are ZEROs.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01386-QCAHKSWPL_SILICONZ-1
Fixes: 74601ecfef6e ("ath11k: Add support for 6g scan hint")
Reported-by: Carl Huang
Signed-off-by: Pradeep Kumar Chitrapu
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/1607609124-17250-7-git-send-email-kvalo@codeaurora.org
Signed-off-by: Sasha Levin -
[ Upstream commit 9d5522199505c761575c8ea31dcfd9a2a8d73614 ]
irqchip shared with multiple gpiochips, leads to recursive call of
gpiochip_irq_mask/gpiochip_irq_unmask which was assigned to
rqchip->irq_mask/irqchip->irq_unmask, these happens becouse of
only irqchip->irq_enable == gpiochip_irq_enable is checked.Let's add an additional check to make sure shared irqchip is detected
even if irqchip->irq_enable wasn't defined.Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
Signed-off-by: Nikita Shubin
Link: https://lore.kernel.org/r/20201210070514.13238-1-nikita.shubin@maquefel.me
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit 603bee935f38080a3674c763c50787751e387779 ]
The high 6 bits of traffic class in GRH is DSCP (Differentiated Services
Codepoint), the driver should shift it before the hardware gets it when
using RoCEv2.Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function")
Fixes: fba429fcf9a5 ("RDMA/hns: Fix missing fields in address vector")
Link: https://lore.kernel.org/r/1607650657-35992-4-git-send-email-liweihang@huawei.com
Signed-off-by: Weihang Li
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin -
[ Upstream commit 4ddeacf68a3dd05f346b63f4507e1032a15cc3cc ]
Whether to enable the these features should better depend on the enable
flags, not the value of related fields.Fixes: 5c1f167af112 ("RDMA/hns: Init SRQ table for hip08")
Fixes: 3cb2c996c9dc ("RDMA/hns: Add support for SCCC in size of 64 Bytes")
Link: https://lore.kernel.org/r/1607650657-35992-3-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang
Signed-off-by: Weihang Li
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin -
[ Upstream commit 1c0ca9cd1741687f529498ddb899805fc2c51caa ]
For ib_copy_from_user(), the length of udata may not be the same as that
of cmd. For ib_copy_to_user(), the length of udata may not be the same as
that of resp. So limit the length to prevent out-of-bounds read and write
operations from ib_copy_from_user() and ib_copy_to_user().Fixes: de77503a5940 ("RDMA/hns: RDMA/hns: Assign rq head pointer when enable rq record db")
Fixes: 633fb4d9fdaa ("RDMA/hns: Use structs to describe the uABI instead of opencoding")
Fixes: ae85bf92effc ("RDMA/hns: Optimize qp param setup flow")
Fixes: 6fd610c5733d ("RDMA/hns: Support 0 hop addressing for SRQ buffer")
Fixes: 9d9d4ff78884 ("RDMA/hns: Update the kernel header file of hns")
Link: https://lore.kernel.org/r/1607650657-35992-2-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang
Signed-off-by: Weihang Li
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin -
[ Upstream commit e2de925bbfe321ba0588c99f577c59386ab1f428 ]
According to different sections of the TRM, the hchan_cnt of CAP3 includes
the number of uchan in UDMA, thus the start offset of the normal channels
are hchan_cnt.Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level information from hardware")
Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20201208090440.31792-2-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin -
[ Upstream commit fc6c7cd3878641fd43189f15697e7ad0871f5c1a ]
ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in
data->chip_data and uses it for calling ti_sci irq_free() and then
mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc()
is storing p_hwirq(parent's hardware irq) which is translated from out_irq.
This is causing resource leakage and eventually out_irq resources might
be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq
in data->chip_data.Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
Signed-off-by: Lokesh Vutla
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
Signed-off-by: Sasha Levin -
[ Upstream commit b10d5fd489b0c67f59cbdd28d95f4bd9f76a62f2 ]
On a successful probe, the driver tries to print a success message with
INTA device id. It uses pdev->id for printing the id but id is stored in
inta->ti_sci_id. Fix it by correcting the dev_info parameter.Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
Signed-off-by: Lokesh Vutla
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
Signed-off-by: Sasha Levin -
[ Upstream commit 3841245e8498a789c65dedd7ffa8fb2fee2c0684 ]
The alpine-msi driver has an interesting allocation error handling,
where it frees the same interrupts repeatedly. Hilarity follows.This code is probably never executed, but let's fix it nonetheless.
Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
Signed-off-by: Marc Zyngier
Reviewed-by: Antoine Tenart
Cc: Tsahee Zidenberg
Cc: Antoine Tenart
Link: https://lore.kernel.org/r/20201129135525.396671-1-maz@kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit 85a7555575a0e48f9b73db310d0d762a08a46d63 ]
The error handling frees "ctl" but it's still on the "dsp->ctl_list"
list so that could result in a use after free. Remove it from the list
before returning.Fixes: 2323736dca72 ("ASoC: wm_adsp: Add basic support for rev 1 firmware file format")
Signed-off-by: Dan Carpenter
Acked-by: Charles Keepax
Link: https://lore.kernel.org/r/X9B0keV/02wrx9Xs@mwanda
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit f879ac8ed6c83ce05fcb53815a8ea83c5b6099a1 ]
It should be !is_multicast_ether_addr() in ieee80211_rx_h_sta_process()
for the rx_stats update, below commit remove the !, this patch is to
change it back.It lead the rx rate "iw wlan0 station dump" become invalid for some
scenario when IEEE80211_HW_USES_RSS is set.Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons")
Signed-off-by: Wen Gong
Link: https://lore.kernel.org/r/1607483189-3891-1-git-send-email-wgong@codeaurora.org
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin -
[ Upstream commit f65607cdbc6b0da356ef5a22552ddd9313cf87a0 ]
When we set up a TDLS station, we set sta->sta.bandwidth solely based
on the capabilities, because the "what's the current bandwidth" check
is bypassed and only applied for other types of stations.This leads to the unfortunate scenario that the sta->sta.bandwidth is
160 MHz if both stations support it, but we never actually configure
this bandwidth unless the AP is already using 160 MHz; even for wider
bandwidth support we only go up to 80 MHz (at least right now.)For iwlwifi, this can also lead to firmware asserts, telling us that
we've configured the TX rates for a higher bandwidth than is actually
available due to the PHY configuration.For non-TDLS, we check against the interface's requested bandwidth,
but we explicitly skip this check for TDLS to cope with the wider BW
case. Change this to
(a) still limit to the TDLS peer's own chandef, which gets factored
into the overall PHY configuration we request from the driver,
and
(b) limit it to when the TDLS peer is authorized, because it's only
factored into the channel context in this case.Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers")
Signed-off-by: Johannes Berg
Signed-off-by: Luca Coelho
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin -
[ Upstream commit d33a23b0532d5d1b5b700e8641661261e7dbef61 ]
The bitreverse helper is almost always built into the kernel,
but in a rare randconfig build it is possible to hit a case
in which it is a loadable module while the atmel-i2c driver
is built-in:arm-linux-gnueabi-ld: drivers/crypto/atmel-i2c.o: in function `atmel_i2c_checksum':
atmel-i2c.c:(.text+0xa0): undefined reference to `byte_rev_table'Add one more 'select' statement to prevent this.
Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Signed-off-by: Arnd Bergmann
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin -
[ Upstream commit e1efdb604f5c9903a5d92ef42244009d3c04880f ]
The platform device driver name is "max77693-muic", so advertise it
properly in the modalias string. This fixes automated module loading when
this driver is compiled as a module.Fixes: db1b9037424b ("extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device")
Signed-off-by: Marek Szyprowski
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit 88149082bb8ef31b289673669e080ec6a00c2e59 ]
If generic_drop_inode() returns true, it means iput_final() can evict
this inode regardless of whether it is dirty or not. If we check
I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be
evicted unconditionally. This is not the desired behavior because
I_DONTCACHE only means the inode shouldn't be cached on the LRU list.
As for whether we need to evict this inode, this is what
generic_drop_inode() should do. This patch corrects the usage of
I_DONTCACHE.This patch was proposed in [1].
[1]: https://lore.kernel.org/linux-fsdevel/20200831003407.GE12096@dread.disaster.area/
Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer")
Signed-off-by: Hao Li
Reviewed-by: Dave Chinner
Reviewed-by: Ira Weiny
Signed-off-by: Al Viro
Signed-off-by: Sasha Levin -
[ Upstream commit 092fde0f863b72b67c4d6dc03844f5658fc00a35 ]
Fix a possible hang in xdpsock that can occur when using multiple
threads. In this case, one or more of the threads might get stuck in
the while-loop in tx_only after the user has signaled the main thread
to stop execution. In this case, no more Tx packets will be sent, so a
thread might get stuck in the aforementioned while-loop. Fix this by
introducing a test inside the while-loop to check if the benchmark has
been terminated. If so, return from the function.Fixes: cd9e72b6f210 ("samples/bpf: xdpsock: Add option to specify batch size")
Signed-off-by: Magnus Karlsson
Signed-off-by: Daniel Borkmann
Link: https://lore.kernel.org/bpf/20201210163407.22066-1-magnus.karlsson@gmail.com
Signed-off-by: Sasha Levin -
[ Upstream commit 7671edeb193910482a9b0c22cd32176e7de7b2ed ]
To get better performance, current gpmi driver collected and chained all
small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
wait for complete at the end.But some random DMA timeout found in this new driver, with the help of
ftrace, we found the root cause is as follows:Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
DMA transfers and the DMA chain triggered at the end. It waits for bch
completion and check jiffies if it's timeout. The typical function graph
shown below,63.216351 | 1) | gpmi_ecc_read_page() {
63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
63.216354 | 1) | gpmi_nfc_exec_op() {
63.216355 | 1) | gpmi_chain_command() {
63.216356 | 1) | mxs_dma_prep_slave_sg() {
63.216357 | 1) | /* mxs chan ccw idx: 0 */
63.216358 | 1) 1.750 us | }
63.216359 | 1) | mxs_dma_prep_slave_sg() {
63.216360 | 1) | /* mxs chan ccw idx: 1 */
63.216361 | 1) 2.000 us | }
63.216361 | 1) 6.500 us | }
63.216362 | 1) | gpmi_chain_command() {
63.216363 | 1) | mxs_dma_prep_slave_sg() {
63.216364 | 1) | /* mxs chan ccw idx: 2 */
63.216365 | 1) 1.750 us | }
63.216366 | 1) | mxs_dma_prep_slave_sg() {
63.216367 | 1) | /* mxs chan ccw idx: 3 */
63.216367 | 1) 1.750 us | }
63.216368 | 1) 5.875 us | }
63.216369 | 1) | /* gpmi_chain_wait_ready */
63.216370 | 1) | mxs_dma_prep_slave_sg() {
63.216372 | 1) | /* mxs chan ccw idx: 4 */
63.216373 | 1) 3.000 us | }
63.216374 | 1) | /* gpmi_chain_data_read */
63.216376 | 1) | mxs_dma_prep_slave_sg() {
63.216377 | 1) | /* mxs chan ccw idx: 5 */
63.216378 | 1) 2.000 us | }
63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
63.216712 | 0) 2.625 us | mxs_dma_int_handler();
63.216717 | 0) 4.250 us | bch_irq();
63.216723 | 0) 1.250 us | mxs_dma_tasklet();
63.216723 | 1) | /* jiffies left 250 */
63.216725 | 1) ! 372.000 us | }
63.216726 | 1) 2.625 us | gpmi_count_bitflips();
63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled,
sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
handled, this messed up the next DMA chain and causes DMA timeout. Check
the trace log when issue happened.63.218923 | 1) | gpmi_ecc_read_page() {
63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
63.218926 | 1) | gpmi_nfc_exec_op() {
63.218927 | 1) | gpmi_chain_command() {
63.218928 | 1) | mxs_dma_prep_slave_sg() {
63.218929 | 1) | /* mxs chan ccw idx: 0 */
63.218929 | 1) 1.625 us | }
63.218931 | 1) | mxs_dma_prep_slave_sg() {
63.218931 | 1) | /* mxs chan ccw idx: 1 */
63.218932 | 1) 1.750 us | }
63.218933 | 1) 5.875 us | }
63.218934 | 1) | gpmi_chain_command() {
63.218934 | 1) | mxs_dma_prep_slave_sg() {
63.218935 | 1) | /* mxs chan ccw idx: 2 */
63.218936 | 1) 1.875 us | }
63.218937 | 1) | mxs_dma_prep_slave_sg() {
63.218938 | 1) | /* mxs chan ccw idx: 3 */
63.218939 | 1) 1.625 us | }
63.218939 | 1) 5.875 us | }
63.218940 | 1) | /* gpmi_chain_wait_ready */
63.218941 | 1) | mxs_dma_prep_slave_sg() {
63.218942 | 1) | /* mxs chan ccw idx: 4 */
63.218942 | 1) 1.625 us | }
63.218943 | 1) | /* gpmi_chain_data_read */
63.218944 | 1) | mxs_dma_prep_slave_sg() {
63.218945 | 1) | /* mxs chan ccw idx: 5 */
63.218947 | 1) 2.375 us | }
63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
63.219276 | 0) 5.125 us | bch_irq();
Reviewed-by: Sascha Hauer
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-3-han.xu@nxp.com
Signed-off-by: Sasha Levin -
[ Upstream commit ad8566d3555c4731e6b48823b92d3929b0394c14 ]
Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function
fails to avoid a resource leak.Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
Signed-off-by: Dan Carpenter
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda
Signed-off-by: Sasha Levin
