- 26 Jan, 2019 40 commits
-
-
Arnaldo Carvalho de Melo authored
[ Upstream commit bd8d57fb ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/parse-events.c: In function 'print_symbol_events': util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'print_symbol_events.constprop', inlined from 'print_events' at util/parse-events.c:2508:2: util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'print_symbol_events.constprop', inlined from 'print_events' at util/parse-events.c:2511:2: util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: 947b4ad1 ("perf list: Fix max event string size") Link: https://lkml.kernel.org/n/tip-b663e33bm6x8hrkie4uxh7u2@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 2f530253 ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this specific case this would only happen if fgets() was buggy, as its man page states that it should read one less byte than the size of the destination buffer, so that it can put the nul byte at the end of it, so it would never copy 255 non-nul chars, as fgets reads into the orig buffer at most 254 non-nul chars and terminates it. But lets just switch to strlcpy to keep the original intent and silence the gcc 8.2 warning. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: In function 'cpu_model', inlined from 'svg_cpu_box' at util/svghelper.c:378:2: util/svghelper.c:337:5: error: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Werror=stringop-truncation] strncpy(cpu_m, &buf[13], 255); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Fixes: f48d55ce ("perf: Add a SVG helper library file") Link: https://lkml.kernel.org/n/tip-xzkoo0gyr56gej39ltivuh9g@git.kernel.orgSigned-off-by:
-
Florian Fainelli authored
[ Upstream commit 24f96733 ] The breakpoint tests on the ARM 32-bit kernel are broken in several ways. The breakpoint length requested does not necessarily match whether the function address has the Thumb bit (bit 0) set or not, and this does matter to the ARM kernel hw_breakpoint infrastructure. See [1] for background. [1]: https://lkml.org/lkml/2018/11/15/205 As Will indicated, the overflow handling would require single-stepping which is not supported at the moment. Just disable those tests for the ARM 32-bit platforms and update the comment above to explain these limitations. Co-developed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20181203191138.2419-1-f.fainelli@gmail.comSigned-off-by:
-
Adrian Hunter authored
[ Upstream commit 1c6f709b ] Users should never use 'pt=0', but if they do it may give a meaningless error: $ perf record -e intel_pt/pt=0/u uname Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (intel_pt/pt=0/u). Fix that by forcing 'pt=1'. Committer testing: # perf record -e intel_pt/pt=0/u uname Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (intel_pt/pt=0/u). /bin/dmesg | grep -i perf may provide additional information. # perf record -e intel_pt/pt=0/u uname pt=0 doesn't make sense, forcing pt=1 Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.020 MB perf.data ] # Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Tested-by:
-
Sergey Senozhatsky authored
[ Upstream commit d7240214 ] LKP has hit yet another circular locking dependency between uart console drivers and debugobjects [1]: CPU0 CPU1 rhltable_init() __init_work() debug_object_init uart_shutdown() /* db->lock */ /* uart_port->lock */ debug_print_object() free_page() printk() call_console_drivers() debug_check_no_obj_freed() /* uart_port->lock */ /* db->lock */ debug_print_object() So there are two dependency chains: uart_port->lock -> db->lock And db->lock -> uart_port->lock This particular circular locking dependency can be addressed in several ways: a) One way would be to move debug_print_object() out of db->lock scope and, thus, break the db->lock -> uart_port->lock chain. b) Another one would be to free() transmit buffer page out of db->lock in UART code; which is what this patch does. It makes sense to apply a) and b) independently: there are too many things going on behind free(), none of which depend on uart_port->lock. The patch fixes transmit buffer page free() in uart_shutdown() and, additionally, in uart_port_startup() (as was suggested by Dmitry Safonov). [1] https://lore.kernel.org/lkml/20181211091154.GL23332@shao2-debian/T/#uSigned-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Waiman Long <longman@redhat.com> Cc: Dmitry Safonov <dima@arista.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johannes Thumshirn authored
[ Upstream commit 1690dd41 ] In the error handling block, err holds the return value of either btrfs_del_root_ref() or btrfs_del_inode_ref() but it hasn't been checked since it's introduction with commit fe66a05a (Btrfs: improve error handling for btrfs_insert_dir_item callers) in 2012. If the error handling in the error handling fails, there's not much left to do and the abort either happened earlier in the callees or is necessary here. So if one of btrfs_del_root_ref() or btrfs_del_inode_ref() failed, abort the transaction, but still return the original code of the failure stored in 'ret' as this will be reported to the user. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Anand Jain authored
[ Upstream commit d189dd70 ] The device replace cancel thread can race with the replace start thread and if fs_info::scrubs_running is not yet set, btrfs_scrub_cancel() will fail to stop the scrub thread. The scrub thread continues with the scrub for replace which then will try to write to the target device and which is already freed by the cancel thread. scrub_setup_ctx() warns as tgtdev is NULL. struct scrub_ctx *scrub_setup_ctx(struct btrfs_device *dev, int is_dev_replace) { ... if (is_dev_replace) { WARN_ON(!fs_info->dev_replace.tgtdev); <=== sctx->pages_per_wr_bio = SCRUB_PAGES_PER_WR_BIO; sctx->wr_tgtdev = fs_info->dev_replace.tgtdev; sctx->flush_all_writes = false; } [ 6724.497655] BTRFS info (device sdb): dev_replace from /dev/sdb (devid 1) to /dev/sdc started [ 6753.945017] BTRFS info (device sdb): dev_replace from /dev/sdb (devid 1) to /dev/sdc canceled [ 6852.426700] WARNING: CPU: 0 PID: 4494 at fs/btrfs/scrub.c:622 scrub_setup_ctx.isra.19+0x220/0x230 [btrfs] ... [ 6852.428928] RIP: 0010:scrub_setup_ctx.isra.19+0x220/0x230 [btrfs] ... [ 6852.432970] Call Trace: [ 6852.433202] btrfs_scrub_dev+0x19b/0x5c0 [btrfs] [ 6852.433471] btrfs_dev_replace_start+0x48c/0x6a0 [btrfs] [ 6852.433800] btrfs_dev_replace_by_ioctl+0x3a/0x60 [btrfs] [ 6852.434097] btrfs_ioctl+0x2476/0x2d20 [btrfs] [ 6852.434365] ? do_sigaction+0x7d/0x1e0 [ 6852.434623] do_vfs_ioctl+0xa9/0x6c0 [ 6852.434865] ? syscall_trace_enter+0x1c8/0x310 [ 6852.435124] ? syscall_trace_enter+0x1c8/0x310 [ 6852.435387] ksys_ioctl+0x60/0x90 [ 6852.435663] __x64_sys_ioctl+0x16/0x20 [ 6852.435907] do_syscall_64+0x50/0x180 [ 6852.436150] entry_SYSCALL_64_after_hwframe+0x49/0xbe Further, as the replace thread enters scrub_write_page_to_dev_replace() without the target device it panics: static int scrub_add_page_to_wr_bio(struct scrub_ctx *sctx, struct scrub_page *spage) { ... bio_set_dev(bio, sbio->dev->bdev); <====== [ 6929.715145] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 .. [ 6929.717106] Workqueue: btrfs-scrub btrfs_scrub_helper [btrfs] [ 6929.717420] RIP: 0010:scrub_write_page_to_dev_replace+0xb4/0x260 [btrfs] .. [ 6929.721430] Call Trace: [ 6929.721663] scrub_write_block_to_dev_replace+0x3f/0x60 [btrfs] [ 6929.721975] scrub_bio_end_io_worker+0x1af/0x490 [btrfs] [ 6929.722277] normal_work_helper+0xf0/0x4c0 [btrfs] [ 6929.722552] process_one_work+0x1f4/0x520 [ 6929.722805] ? process_one_work+0x16e/0x520 [ 6929.723063] worker_thread+0x46/0x3d0 [ 6929.723313] kthread+0xf8/0x130 [ 6929.723544] ? process_one_work+0x520/0x520 [ 6929.723800] ? kthread_delayed_work_timer_fn+0x80/0x80 [ 6929.724081] ret_from_fork+0x3a/0x50 Fix this by letting the btrfs_dev_replace_finishing() to do the job of cleaning after the cancel, including freeing of the target device. btrfs_dev_replace_finishing() is called when btrfs_scub_dev() returns along with the scrub return status. Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
-
Hans van Kranenburg authored
[ Upstream commit baf92114 ] Commit 92e222df "btrfs: alloc_chunk: fix DUP stripe size handling" fixed calculating the stripe_size for a new DUP chunk. However, the same calculation reappears a bit later, and that one was not changed yet. The resulting bug that is exposed is that the newly allocated device extents ('stripes') can have a few MiB overlap with the next thing stored after them, which is another device extent or the end of the disk. The scenario in which this can happen is: * The block device for the filesystem is less than 10GiB in size. * The amount of contiguous free unallocated disk space chosen to use for chunk allocation is 20% of the total device size, or a few MiB more or less. An example: - The filesystem device is 7880MiB (max_chunk_size gets set to 788MiB) - There's 1578MiB unallocated raw disk space left in one contiguous piece. In this case stripe_size is first calculated as 789MiB, (half of 1578MiB). Since 789MiB (stripe_size * data_stripes) > 788MiB (max_chunk_size), we enter the if block. Now stripe_size value is immediately overwritten while calculating an adjusted value based on max_chunk_size, which ends up as 788MiB. Next, the value is rounded up to a 16MiB boundary, 800MiB, which is actually more than the value we had before. However, the last comparison fails to detect this, because it's comparing the value with the total amount of free space, which is about twice the size of stripe_size. In the example above, this means that the resulting raw disk space being allocated is 1600MiB, while only a gap of 1578MiB has been found. The second device extent object for this DUP chunk will overlap for 22MiB with whatever comes next. The underlying problem here is that the stripe_size is reused all the time for different things. So, when entering the code in the if block, stripe_size is immediately overwritten with something else. If later we decide we want to have the previous value back, then the logic to compute it was copy pasted in again. With this change, the value in stripe_size is not unnecessarily destroyed, so the duplicated calculation is not needed any more. Signed-off-by:
Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit 5eb19381 ] Enhance btrfs_verify_dev_extents() to remember previous checked dev extents, so it can verify no dev extents can overlap. Analysis from Hans: "Imagine allocating a DATA|DUP chunk. In the chunk allocator, we first set... max_stripe_size = SZ_1G; max_chunk_size = BTRFS_MAX_DATA_CHUNK_SIZE ... which is 10GiB. Then... /* we don't want a chunk larger than 10% of writeable space */ max_chunk_size = min(div_factor(fs_devices->total_rw_bytes, 1), max_chunk_size); Imagine we only have one 7880MiB block device in this filesystem. Now max_chunk_size is down to 788MiB. The next step in the code is to search for max_stripe_size * dev_stripes amount of free space on the device, which is in our example 1GiB * 2 = 2GiB. Imagine the device has exactly 1578MiB free in one contiguous piece. This amount of bytes will be put in devices_info[ndevs - 1].max_avail Next we recalculate the stripe_size (which is actually the device extent length), based on the actual maximum amount of available raw disk space: stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); stripe_size is now 789MiB Next we do... data_stripes = num_stripes / ncopies ...where data_stripes ends up as 1, because num_stripes is 2 (the amount of device extents we're going to have), and DUP has ncopies 2. Next there's a check... if (stripe_size * data_stripes > max_chunk_size) ...which matches because 789MiB * 1 > 788MiB. We go into the if code, and next is... stripe_size = div_u64(max_chunk_size, data_stripes); ...which resets stripe_size to max_chunk_size: 788MiB Next is a fun one... /* bump the answer up to a 16MB boundary */ stripe_size = round_up(stripe_size, SZ_16M); ...which changes stripe_size from 788MiB to 800MiB. We're not done changing stripe_size yet... /* But don't go higher than the limits we found while searching * for free extents */ stripe_size = min(devices_info[ndevs - 1].max_avail, stripe_size); This is bad. max_avail is twice the stripe_size (we need to fit 2 device extents on the same device for DUP). The result here is that 800MiB < 1578MiB, so it's unchanged. However, the resulting DUP chunk will need 1600MiB disk space, which isn't there, and the second dev_extent might extend into the next thing (next dev_extent? end of device?) for 22MiB. The last shown line of code relies on a situation where there's twice the value of stripe_size present as value for the variable stripe_size when it's DUP. This was actually the case before commit 92e222df "btrfs: alloc_chunk: fix DUP stripe size handling", from which I quote: "[...] in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size." In the previous version of the code, the 16MiB alignment (why is this done, by the way?) would result in a 50% chance that it would actually do an 8MiB alignment for the individual dev_extents, since it was operating on double the size. Does this matter? Does it matter that stripe_size can be set to anything which is not 16MiB aligned because of the amount of remaining available disk space which is just taken? What is the main purpose of this round_up? The most straightforward thing to do seems something like... stripe_size = min( div_u64(devices_info[ndevs - 1].max_avail, dev_stripes), stripe_size ) ..just putting half of the max_avail into stripe_size." Link: https://lore.kernel.org/linux-btrfs/b3461a38-e5f8-f41d-c67c-2efac8129054@mendix.com/Reported-by:
Qu Wenruo <wqu@suse.com> [ add analysis from report ] Signed-off-by:
-
Jonas Danielsson authored
[ Upstream commit ae460c11 ] On our AT91SAM9260 board we use the same sdio bus for wifi and for the sd card slot. This caused the atmel-mci to give the following splat on the serial console: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44 Modules linked in: CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 #14 Hardware name: Atmel AT91SAM9 [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14) [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4) [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24) [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44) [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc) [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164) [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0) [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330) [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310) [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac) [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118) [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118) [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34) ---[ end trace 594371ddfa284bd6 ]--- This is: WARN_ON(host->cmd); This was fixed on our board by letting atmci_request_end determine what state we are in. Instead of unconditionally setting it to STATE_IDLE on STATE_END_REQUEST. Signed-off-by:
Jonas Danielsson <jonas@orbital-systems.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit fbac5977 ] An unterminated string literal followed by new line is passed to the parser (with "multi-line strings not supported" warning shown), then handled properly there. On the other hand, an unterminated string literal at end of file is never passed to the parser, then results in memory leak. [Test Code] ----------(Kconfig begin)---------- source "Kconfig.inc" config A bool "a" -----------(Kconfig end)----------- --------(Kconfig.inc begin)-------- config B bool "b\No new line at end of file ---------(Kconfig.inc end)--------- [Summary from Valgrind] Before the fix: LEAK SUMMARY: definitely lost: 16 bytes in 1 blocks ... After the fix: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks ... Eliminate the memory leak path by handling this case. Of course, such a Kconfig file is wrong already, so I will add an error message later. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 77c1c0fa ] Currently, warn_ignore_character() displays invalid file name and line number. The lexer should use current_file->name and yylineno, while the parser should use zconf_curname() and zconf_lineno(). This difference comes from that the lexer is always going ahead of the parser. The parser needs to look ahead one token to make a shift/reduce decision, so the lexer is requested to scan more text from the input file. This commit fixes the warning message from warn_ignored_character(). [Test Code] ----(Kconfig begin)---- / -----(Kconfig end)----- [Output] Before the fix: <none>:0:warning: ignoring unsupported character '/' After the fix: Kconfig:1:warning: ignoring unsupported character '/' Signed-off-by:
-
Jiong Wang authored
[ Upstream commit e434b8cd ] Currently, the destination register is marked as unknown for 32-bit sub-register move (BPF_MOV | BPF_ALU) whenever the source register type is SCALAR_VALUE. This is too conservative that some valid cases will be rejected. Especially, this may turn a constant scalar value into unknown value that could break some assumptions of verifier. For example, test_l4lb_noinline.c has the following C code: struct real_definition *dst 1: if (!get_packet_dst(&dst, &pckt, vip_info, is_ipv6)) 2: return TC_ACT_SHOT; 3: 4: if (dst->flags & F_IPV6) { get_packet_dst is responsible for initializing "dst" into valid pointer and return true (1), otherwise return false (0). The compiled instruction sequence using alu32 will be: 412: (54) (u32) r7 &= (u32) 1 413: (bc) (u32) r0 = (u32) r7 414: (95) exit insn 413, a BPF_MOV | BPF_ALU, however will turn r0 into unknown value even r7 contains SCALAR_VALUE 1. This causes trouble when verifier is walking the code path that hasn't initialized "dst" inside get_packet_dst, for which case 0 is returned and we would then expect verifier concluding line 1 in the above C code pass the "if" check, therefore would skip fall through path starting at line 4. Now, because r0 returned from callee has became unknown value, so verifier won't skip analyzing path starting at line 4 and "dst->flags" requires dereferencing the pointer "dst" which actually hasn't be initialized for this path. This patch relaxed the code marking sub-register move destination. For a SCALAR_VALUE, it is safe to just copy the value from source then truncate it into 32-bit. A unit test also included to demonstrate this issue. This test will fail before this patch. This relaxation could let verifier skipping more paths for conditional comparison against immediate. It also let verifier recording a more accurate/strict value for one register at one state, if this state end up with going through exit without rejection and it is used for state comparison later, then it is possible an inaccurate/permissive value is better. So the real impact on verifier processed insn number is complex. But in all, without this fix, valid program could be rejected. >From real benchmarking on kernel selftests and Cilium bpf tests, there is no impact on processed instruction number when tests ares compiled with default compilation options. There is slightly improvements when they are compiled with -mattr=+alu32 after this patch. Also, test_xdp_noinline/-mattr=+alu32 now passed verification. It is rejected before this fix. Insn processed before/after this patch: default -mattr=+alu32 Kernel selftest === test_xdp.o 371/371 369/369 test_l4lb.o 6345/6345 5623/5623 test_xdp_noinline.o 2971/2971 rejected/2727 test_tcp_estates.o 429/429 430/430 Cilium bpf === bpf_lb-DLB_L3.o: 2085/2085 1685/1687 bpf_lb-DLB_L4.o: 2287/2287 1986/1982 bpf_lb-DUNKNOWN.o: 690/690 622/622 bpf_lxc.o: 95033/95033 N/A bpf_netdev.o: 7245/7245 N/A bpf_overlay.o: 2898/2898 3085/2947 NOTE: - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by verifier due to another issue inside verifier on supporting alu32 binary. - Each cilium bpf program could generate several processed insn number, above number is sum of them. v1->v2: - Restrict the change on SCALAR_VALUE. - Update benchmark numbers on Cilium bpf tests. Signed-off-by:
Jiong Wang <jiong.wang@netronome.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 33309ecd ] The dcache_by_line_op macro suffers from a couple of small problems: First, the GAS directives that are currently being used rely on assembler behavior that is not documented, and probably not guaranteed to produce the correct behavior going forward. As a result, we end up with some undefined symbols in cache.o: $ nm arch/arm64/mm/cache.o ... U civac ... U cvac U cvap U cvau This is due to the fact that the comparisons used to select the operation type in the dcache_by_line_op macro are comparing symbols not strings, and even though it seems that GAS is doing the right thing here (undefined symbols by the same name are equal to each other), it seems unwise to rely on this. Second, when patching in a DC CVAP instruction on CPUs that support it, the fallback path consists of a DC CVAU instruction which may be affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE. Solve these issues by unrolling the various maintenance routines and using the conditional directives that are documented as operating on strings. To avoid the complexity of nested alternatives, we move the DC CVAP patching to __clean_dcache_area_pop, falling back to a branch to __clean_dcache_area_poc if DCPOP is not supported by the CPU. Reported-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Lucas Stach authored
[ Upstream commit f7542d81 ] The exclusive gates may be set up in the wrong way by software running before the clock driver comes up. In that case the exclusive setup is locked in its initial state, as the complementary function can't be activated without disabling the initial setup first. To avoid this lock situation, reset the exclusive gates to the off state and allow the kernel to provide the proper setup. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Dong Aisheng <Aisheng.dong@nxp.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Qian Cai authored
[ Upstream commit 6e883067 ] If the kernel is configured with KASAN_EXTRA, the stack size is increased significantly due to setting the GCC -fstack-reuse option to "none" [1]. As a result, it can trigger a stack overrun quite often with 32k stack size compiled using GCC 8. For example, this reproducer https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c can trigger a "corrupted stack end detected inside scheduler" very reliably with CONFIG_SCHED_STACK_END_CHECK enabled. There are other reports at: https://lore.kernel.org/lkml/1542144497.12945.29.camel@gmx.us/ https://lore.kernel.org/lkml/721E7B42-2D55-4866-9C1A-3E8D64F33F9C@gmx.us/ There are just too many functions that could have a large stack with KASAN_EXTRA due to large local variables that have been called over and over again without being able to reuse the stacks. Some noticiable ones are, size 7536 shrink_inactive_list 7440 shrink_page_list 6560 fscache_stats_show 3920 jbd2_journal_commit_transaction 3216 try_to_unmap_one 3072 migrate_page_move_mapping 3584 migrate_misplaced_transhuge_page 3920 ip_vs_lblcr_schedule 4304 lpfc_nvme_info_show 3888 lpfc_debugfs_nvmestat_data.constprop There are other 49 functions over 2k in size while compiling kernel with "-Wframe-larger-than=" on this machine. Hence, it is too much work to change Makefiles for each object to compile without -fsanitize-address-use-after-scope individually. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
Dmitry V. Levin authored
[ Upstream commit b708a3cc ] I've stumbled over the current macro-expand behaviour of the test harness: $ gcc -Wall -xc - <<'__EOF__' TEST(macro) { int status = 0; ASSERT_TRUE(WIFSIGNALED(status)); } TEST_HARNESS_MAIN __EOF__ $ ./a.out [==========] Running 1 tests from 1 test cases. [ RUN ] global.macro <stdin>:4:global.macro:Expected 0 (0) != (((signed char) (((status) & 0x7f) + 1) >> 1) > 0) (0) global.macro: Test terminated by assertion [ FAIL ] global.macro [==========] 0 / 1 tests passed. [ FAILED ] With this change the output of the same test looks much more comprehensible: [==========] Running 1 tests from 1 test cases. [ RUN ] global.macro <stdin>:4:global.macro:Expected 0 (0) != WIFSIGNALED(status) (0) global.macro: Test terminated by assertion [ FAIL ] global.macro [==========] 0 / 1 tests passed. [ FAILED ] The issue is very similar to the bug fixed in glibc assert(3) three years ago: https://sourceware.org/bugzilla/show_bug.cgi?id=18604 Cc: Shuah Khan <shuah@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Cc: linux-kselftest@vger.kernel.org Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Shuah Khan <shuah@kernel.org> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit ad669505 ] A session must only be released after all code that accesses the session structure has finished. Make sure that this is the case by introducing a new command counter per session that is only decremented after the .release_cmd() callback has finished. This patch fixes the following crash: BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c/0x130 Read of size 4 at addr ffff8801534b16e4 by task rmdir/14805 CPU: 16 PID: 14805 Comm: rmdir Not tainted 4.18.0-rc2-dbg+ #5 Call Trace: dump_stack+0xa4/0xf5 print_address_description+0x6f/0x270 kasan_report+0x241/0x360 __asan_load4+0x78/0x80 do_raw_spin_lock+0x1c/0x130 _raw_spin_lock_irqsave+0x52/0x60 srpt_set_ch_state+0x27/0x70 [ib_srpt] srpt_disconnect_ch+0x1b/0xc0 [ib_srpt] srpt_close_session+0xa8/0x260 [ib_srpt] target_shutdown_sessions+0x170/0x180 [target_core_mod] core_tpg_del_initiator_node_acl+0xf3/0x200 [target_core_mod] target_fabric_nacl_base_release+0x25/0x30 [target_core_mod] config_item_release+0x9c/0x110 [configfs] config_item_put+0x26/0x30 [configfs] configfs_rmdir+0x3b8/0x510 [configfs] vfs_rmdir+0xb3/0x1e0 do_rmdir+0x262/0x2c0 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: David Disseldorp <ddiss@suse.de> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
David Disseldorp authored
[ Upstream commit 0de26357 ] spc5r17.pdf specifies: 4.3.1 ASCII data field requirements ASCII data fields shall contain only ASCII printable characters (i.e., code values 20h to 7Eh) and may be terminated with one or more ASCII null (00h) characters. ASCII data fields described as being left-aligned shall have any unused bytes at the end of the field (i.e., highest offset) and the unused bytes shall be filled with ASCII space characters (20h). LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR IDENTIFICATION field in the INQUIRY Device Identification VPD Page are zero-terminated/zero-padded. Fix this inconsistency by using space-padding for all of the above fields. Signed-off-by:
David Disseldorp <ddiss@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Bryant G. Ly <bly@catalogicsoftware.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
yupeng authored
[ Upstream commit 0fbe82e6 ] after set SO_DONTROUTE to 1, the IP layer should not route packets if the dest IP address is not in link scope. But if the socket has cached the dst_entry, such packets would be routed until the sk_dst_cache expires. So we should clean the sk_dst_cache when a user set SO_DONTROUTE option. Below are server/client python scripts which could reprodue this issue: server side code: ========================================================================== import socket import struct import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('0.0.0.0', 9000)) s.listen(1) sock, addr = s.accept() sock.setsockopt(socket.SOL_SOCKET, socket.SO_DONTROUTE, struct.pack('i', 1)) while True: sock.send(b'foo') time.sleep(1) ========================================================================== client side code: ========================================================================== import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('server_address', 9000)) while True: data = s.recv(1024) print(data) ========================================================================== Signed-off-by:
yupeng <yupeng0921@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Gao Xiang authored
[ Upstream commit 848bd9ac ] The root cause is the race as follows: Thread #0 Thread #1 z_erofs_vle_unzip_kickoff z_erofs_submit_and_unzip struct z_erofs_vle_unzip_io io[] atomic_add_return() wait_event() [end of function] wake_up() Fix it by taking the waitqueue lock between atomic_add_return and wake_up to close such the race. kernel message: Unable to handle kernel paging request at virtual address 97f7052caa1303dc ... Workqueue: kverityd verity_work task: ffffffe32bcb8000 task.stack: ffffffe3298a0000 PC is at __wake_up_common+0x48/0xa8 LR is at __wake_up+0x3c/0x58 ... Call trace: ... [<ffffff94a08ff648>] __wake_up_common+0x48/0xa8 [<ffffff94a08ff8b8>] __wake_up+0x3c/0x58 [<ffffff94a0c11b60>] z_erofs_vle_unzip_kickoff+0x40/0x64 [<ffffff94a0c118e4>] z_erofs_vle_read_endio+0x94/0x134 [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8 [<ffffff94a1076540>] dec_pending+0x134/0x32c [<ffffff94a1076f28>] clone_endio+0x90/0xf4 [<ffffff94a0c83c9c>] bio_endio+0xe4/0xf8 [<ffffff94a1095024>] verity_work+0x210/0x368 [<ffffff94a08c4150>] process_one_work+0x188/0x4b4 [<ffffff94a08c45bc>] worker_thread+0x140/0x458 [<ffffff94a08cad48>] kthread+0xec/0x108 [<ffffff94a0883ab4>] ret_from_fork+0x10/0x1c Code: d1006273 54000260 f9400804 b9400019 (b85fc081) ---[ end trace be9dde154f677cd1 ]--- Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Gao Xiang <gaoxiang25@huawei.com> Signed-off-by:
-
Vivek Gautam authored
[ Upstream commit de2563bc ] Turning on CONFIG_DMA_API_DEBUG_SG results in the following error: [ 460.308650] ------------[ cut here ]------------ [ 460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536] [ 460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254 [ 460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev [ 460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G W 4.19.1 #82 [ 460.384223] Hardware name: Google Cheza (rev1) (DT) [ 460.389251] pstate: 60400009 (nZCv daif +PAN -UAO) [ 460.394191] pc : debug_dma_map_sg+0x174/0x254 [ 460.398680] lr : debug_dma_map_sg+0x174/0x254 [ 460.403162] sp : ffffff80200c37d0 [ 460.406583] x29: ffffff80200c3830 x28: 0000000000010000 [ 460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80 [ 460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290 [ 460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290 [ 460.428470] x21: ffffff8009037000 x20: 0000000000000001 [ 460.433936] x19: ffffff80091b0000 x18: 0000000000000000 [ 460.439411] x17: 0000000000000000 x16: 000000000000f251 [ 460.444885] x15: 0000000000000006 x14: 0720072007200720 [ 460.450354] x13: ffffff800af536e0 x12: 0000000000000000 [ 460.455822] x11: 0000000000000000 x10: 0000000000000000 [ 460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00 [ 460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80 [ 460.472230] x5 : 0000000000000000 x4 : 0000000000000000 [ 460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948 [ 460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a [ 460.488640] Call trace: [ 460.491165] debug_dma_map_sg+0x174/0x254 [ 460.495307] vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg] [ 460.501150] __vb2_queue_alloc+0x164/0x374 [videobuf2_common] [ 460.507076] vb2_core_reqbufs+0xfc/0x23c [videobuf2_common] [ 460.512815] vb2_reqbufs+0x44/0x5c [videobuf2_v4l2] [ 460.517853] v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem] [ 460.523144] v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem] [ 460.528976] v4l_reqbufs+0x30/0x40 [ 460.532480] __video_do_ioctl+0x36c/0x454 [ 460.536610] video_usercopy+0x25c/0x51c [ 460.540572] video_ioctl2+0x38/0x48 [ 460.544176] v4l2_ioctl+0x60/0x74 [ 460.547602] do_video_ioctl+0x948/0x3520 [ 460.551648] v4l2_compat_ioctl32+0x60/0x98 [ 460.555872] __arm64_compat_sys_ioctl+0x134/0x20c [ 460.560718] el0_svc_common+0x9c/0xe4 [ 460.564498] el0_svc_compat_handler+0x2c/0x38 [ 460.568982] el0_svc_compat+0x8/0x18 [ 460.572672] ---[ end trace ce209b87b2f3af88 ]--- >From above warning one would deduce that the sg segment will overflow the device's capacity. In reality, the hardware can accommodate larger sg segments. So, initialize the max segment size properly to weed out this warning. Based on a similar patch sent by Sean Paul for mdss: https://patchwork.kernel.org/patch/10671457/Signed-off-by:
Vivek Gautam <vivek.gautam@codeaurora.org> Acked-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Yu Zhao authored
[ Upstream commit 23aa128b ] AMD platform device acp_audio_dma can only be created by parent PCI device driver (drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c). Pass struct device of the parent to snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use correct dma_ops. Otherwise, it will use default dma_ops which is nommu_dma_ops on x86_64 even when IOMMU is enabled and set to non passthrough mode. Though platform device inherits some dma related fields during its creation in mfd_add_device(), we can't simply pass its struct device to snd_pcm_lib_preallocate_pages() because dma_ops is not among the inherited fields. Even it were, drivers/iommu/amd_iommu.c would ignore it because get_device_id() doesn't handle platform device. This change shouldn't give us any trouble even struct device of the parent becomes null or represents some non PCI device in the future, because get_dma_ops() correctly handles null struct device or uses the default dma_ops if struct device doesn't have it set. Signed-off-by:
Yu Zhao <yuzhao@google.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit b2e9a4ed ] Clang warns: drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit conversion from 'int' to 'char' changes value from 159 to -97 [-Wconstant-conversion] app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Wconstant-conversion] app_info[1] = (EN50221_TAG_APP_INFO >> 8) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit conversion from 'int' to 'char' changes value from 159 to -97 [-Wconstant-conversion] app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Wconstant-conversion] app_info[1] = (EN50221_TAG_CA_INFO >> 8) & 0xff; ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ 4 warnings generated. Change app_info's type to unsigned char to match the type of the member msg in struct ca_msg, which is the only thing passed into the app_info parameter in this function. Link: https://github.com/ClangBuiltLinux/linux/issues/105Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 2b038cbc ] When booting a pseries kernel with PREEMPT enabled, it dumps the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is pseries_processor_idle_init+0x5c/0x22c CPU: 13 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc3-00090-g12201a0128bc-dirty #828 Call Trace: [c000000429437ab0] [c0000000009c8878] dump_stack+0xec/0x164 (unreliable) [c000000429437b00] [c0000000005f2f24] check_preemption_disabled+0x154/0x160 [c000000429437b90] [c000000000cab8e8] pseries_processor_idle_init+0x5c/0x22c [c000000429437c10] [c000000000010ed4] do_one_initcall+0x64/0x300 [c000000429437ce0] [c000000000c54500] kernel_init_freeable+0x3f0/0x500 [c000000429437db0] [c0000000000112dc] kernel_init+0x2c/0x160 [c000000429437e20] [c00000000000c1d0] ret_from_kernel_thread+0x5c/0x6c This happens because the code calls get_lppaca() which calls get_paca() and it checks if preemption is disabled through check_preemption_disabled(). Preemption should be disabled because the per CPU variable may make no sense if there is a preemption (and a CPU switch) after it reads the per CPU data and when it is used. In this device driver specifically, it is not a problem, because this code just needs to have access to one lppaca struct, and it does not matter if it is the current per CPU lppaca struct or not (i.e. when there is a preemption and a CPU migration). That said, the most appropriate fix seems to be related to avoiding the debug_smp_processor_id() call at get_paca(), instead of calling preempt_disable() before get_paca(). Signed-off-by:
Breno Leitao <leitao@debian.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 8d4a8622 ] Currently xmon needs to get devtree_lock (through rtas_token()) during its invocation (at crash time). If there is a crash while devtree_lock is being held, then xmon tries to get the lock but spins forever and never get into the interactive debugger, as in the following case: int *ptr = NULL; raw_spin_lock_irqsave(&devtree_lock, flags); *ptr = 0xdeadbeef; This patch avoids calling rtas_token(), thus trying to get the same lock, at crash time. This new mechanism proposes getting the token at initialization time (xmon_init()) and just consuming it at crash time. This would allow xmon to be possible invoked independent of devtree_lock being held or not. Signed-off-by:
Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by:
-
Daniel Axtens authored
[ Upstream commit 10e1fdb9 ] Currently, disconnecting a USB webcam while it is in use prints out a number of warnings, such as: WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90 sysfs group ffffffffa7cd0780 not found for kobject 'event13' This has been noticed before. [0] This is because of the order in which things are torn down. If there are no streams active during a USB disconnect: - uvc_disconnect() is invoked via device_del() through the bus notifier mechanism. - this calls uvc_unregister_video(). - uvc_unregister_video() unregisters the video device for each stream, - because there are no streams open, it calls uvc_delete() - uvc_delete() calls uvc_status_cleanup(), which cleans up the status input device. - uvc_delete() calls media_device_unregister(), which cleans up the media device - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all return, and we end up back in device_del(). - device_del() then cleans up the sysfs folder for the camera with dpm_sysfs_remove(). Because uvc_status_cleanup() and media_device_unregister() have already been called, this all works nicely. If, on the other hand, there *are* streams active during a USB disconnect: - uvc_disconnect() is invoked - this calls uvc_unregister_video() - uvc_unregister_video() unregisters the video device for each stream, - uvc_unregister_video() and uvc_disconnect() return, and we end up back in device_del(). - device_del() then cleans up the sysfs folder for the camera with dpm_sysfs_remove(). Because the status input device and the media device are children of the USB device, this also deletes their sysfs folders. - Sometime later, the final stream is closed, invoking uvc_release(). - uvc_release() calls uvc_delete() - uvc_delete() calls uvc_status_cleanup(), which cleans up the status input device. Because the sysfs directory has already been removed, this causes a WARNing. - uvc_delete() calls media_device_unregister(), which cleans up the media device. Because the sysfs directory has already been removed, this causes another WARNing. To fix this, we need to make sure the devices are always unregistered before the end of uvc_disconnect(). To this, move the unregistration into the disconnect path: - split uvc_status_cleanup() into two parts, one on disconnect that unregisters and one on delete that frees. - move v4l2_device_unregister() and media_device_unregister() into the disconnect path. [0]: https://lkml.org/lkml/2016/12/8/657 [Renamed uvc_input_cleanup() to uvc_input_unregister()] Signed-off-by:
Daniel Axtens <dja@axtens.net> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Joel Fernandes (Google) authored
[ Upstream commit 30696378 ] The ramoops backend currently calls persistent_ram_save_old() even if a buffer is empty. While this appears to work, it is does not seem like the right thing to do and could lead to future bugs so lets avoid that. It also prevents misleading prints in the logs which claim the buffer is valid. I got something like: found existing buffer, size 0, start 0 When I was expecting: no valid data in buffer (sig = ...) This bails out early (and reports with pr_debug()), since it's an acceptable state. Signed-off-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Co-developed-by:
-
A.s. Dong authored
[ Upstream commit 9e5ef7a5 ] As the commit 2893c379 ("clk: make strings in parent name arrays const"), let's make the parent strings const, otherwise we may meet the following warning when compiling: drivers/clk/imx/clk-imx7ulp.c: In function 'imx7ulp_clocks_init': drivers/clk/imx/clk-imx7ulp.c:73:35: warning: passing argument 5 of 'imx_clk_mux_flags' discards 'const' qualifier from pointer target type clks[IMX7ULP_CLK_APLL_PRE_SEL] = imx_clk_mux_flags("apll_pre_sel", base + 0x508, 0, 1, pll_pre_sels, ARRAY_SIZE(pll_pre_sels), CLK_SET_PARENT_GATE); ^ In file included from drivers/clk/imx/clk-imx7ulp.c:23:0: drivers/clk/imx/clk.h:200:27: note: expected 'const char **' but argument is of type 'const char * const*' ... Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Daniel Santos authored
[ Upstream commit a788c527 ] jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER is defined then a write buffer is available and has been initialized. However, this does is not the case when the mtd device has no out-of-band buffer: int jffs2_nand_flash_setup(struct jffs2_sb_info *c) { if (!c->mtd->oobsize) return 0; ... The resulting call to cancel_delayed_work_sync passing a uninitialized (but zeroed) delayed_work struct forces lockdep to become disabled. [ 90.050639] overlayfs: upper fs does not support tmpfile. [ 90.652264] INFO: trying to register non-static key. [ 90.662171] the code is fine but needs lockdep annotation. [ 90.673090] turning off the locking correctness validator. [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0 [ 90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7 [ 90.713349] 80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff [ 90.730020] 00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420 [ 90.746690] 6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90 [ 90.763362] 80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000 [ 90.780033] ... [ 90.784902] Call Trace: [ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148 [ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c [ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c [ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc [ 90.828345] [<8003f27c>] flush_work+0x200/0x24c [ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210 [ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54 [ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120 [ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c [ 90.875067] [<80014424>] syscall_common+0x34/0x58 Signed-off-by:
Daniel Santos <daniel.santos@pobox.com> Reviewed-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 3db5e0ba ] When building the kernel with Clang, some disabled warnings appear because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to this list so that the build is clean again. -Wpointer-sign was disabled for the whole kernel before the beginning of Git history. -Waddress-of-packed-member was disabled for the whole kernel and for the early boot code in these commits: bfb38988 ("kbuild: clang: Disable 'address-of-packed-member' warning") 20c6c189 ("x86/boot: Disable the address-of-packed-member compiler warning"). -Wgnu was disabled for the whole kernel and for the early boot code in these commits: 61163efa ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang") 6c3b56b1 ("x86/boot: Disable Clang warnings about GNU extensions"). [ mingo: Made the changelog more readable. ] Tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chuck Lever authored
[ Upstream commit b024dd0e ] FRWR memory registration is done with a series of calls and WRs. 1. ULP invokes ib_dma_map_sg() 2. ULP invokes ib_map_mr_sg() 3. ULP posts an IB_WR_REG_MR on the Send queue Step 2 generates an iova. It is permissible for ULPs to change this iova (with certain restrictions) between steps 2 and 3. rxe_map_mr_sg captures the MR's iova but later when rxe processes the REG_MR WR, it ignores the MR's iova field. If a ULP alters the MR's iova after step 2 but before step 3, rxe never captures that change. When the remote sends an RDMA Read targeting that MR, rxe looks up the R_key, but the altered iova does not match the iova stored in the MR, causing the RDMA Read request to fail. Reported-by:
Anna Schumaker <schumaker.anna@gmail.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 3b34c14f ] As amd_uvd_resume() accesses the uvd ring, it must be initialised first or else we trigger errors like: [ 5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17 [ 5.595969] [drm] PSP loading UVD firmware [ 5.596266] ------------[ cut here ]------------ [ 5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null) [ 5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80 [ 5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage [ 5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G W 4.20.0-0.rc1.git4.1.fc30.x86_64 #1 [ 5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018 [ 5.596303] RIP: 0010:debug_print_object+0x6a/0x80 [ 5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3 [ 5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282 [ 5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006 [ 5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60 [ 5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000 [ 5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69 [ 5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000 [ 5.596313] FS: 00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000 [ 5.596314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0 [ 5.596317] Call Trace: [ 5.596321] debug_object_assert_init+0x14a/0x180 [ 5.596327] del_timer+0x2e/0x90 [ 5.596383] amdgpu_fence_process+0x47/0x100 [amdgpu] [ 5.596430] amdgpu_uvd_resume+0xf6/0x120 [amdgpu] [ 5.596475] uvd_v7_0_sw_init+0xe0/0x280 [amdgpu] [ 5.596523] amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu] [ 5.596563] ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu] [ 5.596604] amdgpu_driver_load_kms+0x86/0x330 [amdgpu] [ 5.596614] drm_dev_register+0x115/0x150 [drm] [ 5.596654] amdgpu_pci_probe+0xbd/0x120 [amdgpu] [ 5.596658] local_pci_probe+0x41/0x90 [ 5.596661] pci_device_probe+0x188/0x1a0 [ 5.596666] really_probe+0xf8/0x3b0 [ 5.596669] driver_probe_device+0xb3/0xf0 [ 5.596672] __driver_attach+0xe1/0x110 [ 5.596674] ? driver_probe_device+0xf0/0xf0 [ 5.596676] bus_for_each_dev+0x79/0xc0 [ 5.596679] bus_add_driver+0x155/0x230 [ 5.596681] ? 0xffffffffc07d9000 [ 5.596683] driver_register+0x6b/0xb0 [ 5.596685] ? 0xffffffffc07d9000 [ 5.596688] do_one_initcall+0x5d/0x2be [ 5.596691] ? rcu_read_lock_sched_held+0x79/0x80 [ 5.596693] ? kmem_cache_alloc_trace+0x264/0x290 [ 5.596695] ? do_init_module+0x22/0x210 [ 5.596698] do_init_module+0x5a/0x210 [ 5.596701] load_module+0x2137/0x2430 [ 5.596703] ? lockdep_hardirqs_on+0xed/0x180 [ 5.596714] ? __do_sys_init_module+0x150/0x1a0 [ 5.596715] __do_sys_init_module+0x150/0x1a0 [ 5.596722] do_syscall_64+0x60/0x1f0 [ 5.596725] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 5.596726] RIP: 0033:0x7f762b877dee [ 5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48 [ 5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee [ 5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060 [ 5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002 [ 5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060 [ 5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000 [ 5.596740] irq event stamp: 134618 [ 5.596743] hardirqs last enabled at (134617): [<ffffffffa513d52e>] console_unlock+0x45e/0x610 [ 5.596744] hardirqs last disabled at (134618): [<ffffffffa50037e8>] trace_hardirqs_off_thunk+0x1a/0x1c [ 5.596746] softirqs last enabled at (133146): [<ffffffffa5e00365>] __do_softirq+0x365/0x47c [ 5.596748] softirqs last disabled at (133139): [<ffffffffa50c64f9>] irq_exit+0x119/0x120 [ 5.596749] ---[ end trace eaee508abfebccdc ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Manish Rangankar authored
[ Upstream commit d5632b11 ] The kernel panic was observed after switch side perturbation, BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8132b5a0>] strcmp+0x20/0x40 PGD 0 Oops: 0000 [#1] SMP CPU: 8 PID: 647 Comm: kworker/8:1 Tainted: G W OE ------------ 3.10.0-693.el7.x86_64 #1 Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/20/2018 Workqueue: slowpath-13:00. qed_slowpath_task [qed] task: ffff880429eb8fd0 ti: ffff880429190000 task.ti: ffff880429190000 RIP: 0010:[<ffffffff8132b5a0>] [<ffffffff8132b5a0>] strcmp+0x20/0x40 RSP: 0018:ffff880429193c68 EFLAGS: 00010202 RAX: 000000000000000a RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88042bda7a41 RBP: ffff880429193c68 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000007 R11: ffff88042b3af338 R12: ffff880420b007a0 R13: ffff88081aa56af8 R14: 0000000000000001 R15: ffff88081aa50410 FS: 0000000000000000(0000) GS:ffff88042fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000019f2000 CR4: 00000000003407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff880429193d20 ffffffffc02a0c90 ffffc90004b32000 ffff8803fd3ec600 ffff88042bda7800 ffff88042bda7a00 ffff88042bda7840 ffff88042bda7a40 0000000129193d10 2e3836312e323931 ff000a342e363232 ffffffffc01ad99d Call Trace: [<ffffffffc02a0c90>] qedi_get_protocol_tlv_data+0x270/0x470 [qedi] [<ffffffffc01ad99d>] ? qed_mfw_process_tlv_req+0x24d/0xbf0 [qed] [<ffffffffc01653ae>] qed_mfw_fill_tlv_data+0x5e/0xd0 [qed] [<ffffffffc01ad9b9>] qed_mfw_process_tlv_req+0x269/0xbf0 [qed] Fix kernel NULL pointer deref by checking for session is online before getting iSCSI TLV data. Signed-off-by:
Manish Rangankar <manish.rangankar@cavium.com> Reviewed-by:
-
Jiada Wang authored
[ Upstream commit 489db5d9 ] pcm3168 codec support runtime_[resume|suspend], whenever it is not active, it enters suspend mode, and it's clock and regulators will be disabled. so there is no need to disable them again in remove callback. Otherwise we got following kernel warnings, when unload pcm3168a driver [ 222.257514] unbalanced disables for amp-en-regulator [ 222.262526] ------------[ cut here ]------------ [ 222.267158] WARNING: CPU: 0 PID: 2423 at drivers/regulator/core.c:2264 _regulator_disable+0x28/0x108 [ 222.276291] Modules linked in: [ 222.279343] snd_soc_pcm3168a_i2c(-) [ 222.282916] snd_aloop [ 222.285272] arc4 [ 222.287194] wl18xx [ 222.289289] wlcore [ 222.291385] mac80211 [ 222.293654] cfg80211 [ 222.295923] aes_ce_blk [ 222.298366] crypto_simd [ 222.300896] cryptd [ 222.302992] aes_ce_cipher [ 222.305696] crc32_ce [ 222.307965] ghash_ce [ 222.310234] aes_arm64 [ 222.312590] gf128mul [ 222.314860] snd_soc_rcar [ 222.317476] sha2_ce [ 222.319658] xhci_plat_hcd [ 222.322362] sha256_arm64 [ 222.324978] xhci_hcd [ 222.327247] sha1_ce [ 222.329430] renesas_usbhs [ 222.332133] evdev [ 222.334142] sha1_generic [ 222.336758] rcar_gen3_thermal [ 222.339810] cpufreq_dt [ 222.342253] ravb_streaming(C) [ 222.345304] wlcore_sdio [ 222.347834] thermal_sys [ 222.350363] udc_core [ 222.352632] mch_core(C) [ 222.355161] usb_dmac [ 222.357430] snd_soc_pcm3168a [ 222.360394] snd_soc_ak4613 [ 222.363184] gpio_keys [ 222.365540] virt_dma [ 222.367809] nfsd [ 222.369730] ipv6 [ 222.371652] autofs4 [ 222.373834] [last unloaded: snd_soc_pcm3168a_i2c] [ 222.378629] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 222.388196] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 222.396199] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 222.402117] PC is at _regulator_disable+0x28/0x108 [ 222.406906] LR is at _regulator_disable+0x28/0x108 [ 222.411695] pc : [<ffff0000083bd89c>] lr : [<ffff0000083bd89c>] pstate: 00000145 [ 222.419089] sp : ffff00000a0a3c80 [ 222.422401] x29: ffff00000a0a3c80 [ 222.425799] x28: ffff8006fa8c6200 [ 222.429199] x27: ffff0000086f1000 [ 222.432597] x26: 000000000000006a [ 222.435997] x25: 0000000000000124 [ 222.439395] x24: 0000000000000018 [ 222.442795] x23: 0000000000000006 [ 222.446193] x22: ffff8006f925d490 [ 222.449592] x21: ffff8006f9ac2068 [ 222.452991] x20: ffff8006f9ac2000 [ 222.456390] x19: 0000000000000005 [ 222.459787] x18: 000000000000000a [ 222.463186] x17: 0000000000000000 [ 222.466584] x16: 0000000000000000 [ 222.469984] x15: 000000000d3f616a [ 222.473382] x14: 0720072007200720 [ 222.476781] x13: 0720072007200720 [ 222.480179] x12: 0720072007200720 [ 222.483578] x11: 0720072007200720 [ 222.486975] x10: 0720072007200720 [ 222.490375] x9 : 0720072007200720 [ 222.493773] x8 : 07200772076f0774 [ 222.497172] x7 : 0000000000000000 [ 222.500570] x6 : 0000000000000007 [ 222.503969] x5 : 0000000000000000 [ 222.507367] x4 : 0000000000000000 [ 222.510766] x3 : 0000000000000000 [ 222.514164] x2 : c790b852091e2600 [ 222.517563] x1 : 0000000000000000 [ 222.520961] x0 : 0000000000000028 [ 222.524361] Call trace: [ 222.526805] Exception stack(0xffff00000a0a3b40 to 0xffff00000a0a3c80) [ 222.533245] 3b40: 0000000000000028 0000000000000000 c790b852091e2600 0000000000000000 [ 222.541075] 3b60: 0000000000000000 0000000000000000 0000000000000007 0000000000000000 [ 222.548905] 3b80: 07200772076f0774 0720072007200720 0720072007200720 0720072007200720 [ 222.556735] 3ba0: 0720072007200720 0720072007200720 0720072007200720 000000000d3f616a [ 222.564564] 3bc0: 0000000000000000 0000000000000000 000000000000000a 0000000000000005 [ 222.572394] 3be0: ffff8006f9ac2000 ffff8006f9ac2068 ffff8006f925d490 0000000000000006 [ 222.580224] 3c00: 0000000000000018 0000000000000124 000000000000006a ffff0000086f1000 [ 222.588053] 3c20: ffff8006fa8c6200 ffff00000a0a3c80 ffff0000083bd89c ffff00000a0a3c80 [ 222.595883] 3c40: ffff0000083bd89c 0000000000000145 0000000000000000 0000000000000000 [ 222.603713] 3c60: 0000ffffffffffff ffff00000a0a3c30 ffff00000a0a3c80 ffff0000083bd89c [ 222.611543] [<ffff0000083bd89c>] _regulator_disable+0x28/0x108 [ 222.617375] [<ffff0000083bd9c4>] regulator_disable+0x48/0x68 [ 222.623033] [<ffff0000083be8e4>] regulator_bulk_disable+0x58/0xc0 [ 222.629134] [<ffff0000007d831c>] pcm3168a_remove+0x30/0x50 [snd_soc_pcm3168a] [ 222.636270] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 222.644106] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 222.649766] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 222.656640] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 222.661951] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 222.667609] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 222.673268] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 222.678666] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 222.687019] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 222.692850] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 222.699289] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 222.707119] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 222.714948] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 222.722778] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 222.730607] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 222.738436] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 222.746266] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 222.754096] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 222.761926] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 222.769755] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 222.777589] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 222.782899] ---[ end trace eaf8939a3698b1a8 ]--- [ 222.787609] Failed to disable VCCDA2: -5 [ 222.791649] ------------[ cut here ]------------ [ 222.796283] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:595 clk_core_disable+0xc/0x1d8 [ 222.804460] Modules linked in: [ 222.807511] snd_soc_pcm3168a_i2c(-) [ 222.811083] snd_aloop [ 222.813439] arc4 [ 222.815360] wl18xx [ 222.817456] wlcore [ 222.819551] mac80211 [ 222.821820] cfg80211 [ 222.824088] aes_ce_blk [ 222.826531] crypto_simd [ 222.829060] cryptd [ 222.831155] aes_ce_cipher [ 222.833859] crc32_ce [ 222.836127] ghash_ce [ 222.838396] aes_arm64 [ 222.840752] gf128mul [ 222.843020] snd_soc_rcar [ 222.845637] sha2_ce [ 222.847818] xhci_plat_hcd [ 222.850522] sha256_arm64 [ 222.853138] xhci_hcd [ 222.855407] sha1_ce [ 222.857589] renesas_usbhs [ 222.860292] evdev [ 222.862300] sha1_generic [ 222.864917] rcar_gen3_thermal [ 222.867968] cpufreq_dt [ 222.870410] ravb_streaming(C) [ 222.873461] wlcore_sdio [ 222.875991] thermal_sys [ 222.878520] udc_core [ 222.880789] mch_core(C) [ 222.883318] usb_dmac [ 222.885587] snd_soc_pcm3168a [ 222.888551] snd_soc_ak4613 [ 222.891341] gpio_keys [ 222.893696] virt_dma [ 222.895965] nfsd [ 222.897886] ipv6 [ 222.899808] autofs4 [ 222.901990] [last unloaded: snd_soc_pcm3168a_i2c] [ 222.906783] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 222.916349] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 222.924351] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 222.930270] PC is at clk_core_disable+0xc/0x1d8 [ 222.934799] LR is at clk_core_disable_lock+0x20/0x34 [ 222.939761] pc : [<ffff0000083ab9b8>] lr : [<ffff0000083acd28>] pstate: 800001c5 [ 222.947154] sp : ffff00000a0a3cf0 [ 222.950466] x29: ffff00000a0a3cf0 [ 222.953864] x28: ffff8006fa8c6200 [ 222.957263] x27: ffff0000086f1000 [ 222.960661] x26: 000000000000006a [ 222.964061] x25: 0000000000000124 [ 222.967458] x24: 0000000000000015 [ 222.970858] x23: ffff8006f9ffa8d0 [ 222.974256] x22: ffff8006faf16480 [ 222.977655] x21: ffff0000007e7040 [ 222.981053] x20: ffff8006faadd100 [ 222.984452] x19: 0000000000000140 [ 222.987850] x18: 000000000000000a [ 222.991249] x17: 0000000000000000 [ 222.994647] x16: 0000000000000000 [ 222.998046] x15: 000000000d477819 [ 223.001444] x14: 0720072007200720 [ 223.004843] x13: 0720072007200720 [ 223.008242] x12: 0720072007200720 [ 223.011641] x11: 0720072007200720 [ 223.015039] x10: 0720072007200720 [ 223.018438] x9 : 0720072007200720 [ 223.021837] x8 : 0720072007200720 [ 223.025236] x7 : 0000000000000000 [ 223.028634] x6 : 0000000000000007 [ 223.032034] x5 : 0000000000000000 [ 223.035432] x4 : 0000000000000000 [ 223.038831] x3 : 0000000000000000 [ 223.042229] x2 : 0000000004720471 [ 223.045628] x1 : 0000000000000000 [ 223.049026] x0 : ffff8006faadd100 [ 223.052426] Call trace: [ 223.054870] Exception stack(0xffff00000a0a3bb0 to 0xffff00000a0a3cf0) [ 223.061309] 3ba0: ffff8006faadd100 0000000000000000 [ 223.069139] 3bc0: 0000000004720471 0000000000000000 0000000000000000 0000000000000000 [ 223.076969] 3be0: 0000000000000007 0000000000000000 0720072007200720 0720072007200720 [ 223.084798] 3c00: 0720072007200720 0720072007200720 0720072007200720 0720072007200720 [ 223.092628] 3c20: 0720072007200720 000000000d477819 0000000000000000 0000000000000000 [ 223.100458] 3c40: 000000000000000a 0000000000000140 ffff8006faadd100 ffff0000007e7040 [ 223.108287] 3c60: ffff8006faf16480 ffff8006f9ffa8d0 0000000000000015 0000000000000124 [ 223.116117] 3c80: 000000000000006a ffff0000086f1000 ffff8006fa8c6200 ffff00000a0a3cf0 [ 223.123947] 3ca0: ffff0000083acd28 ffff00000a0a3cf0 ffff0000083ab9b8 00000000800001c5 [ 223.131777] 3cc0: ffff00000a0a3cf0 ffff0000083acd1c 0000ffffffffffff ffff8006faadd100 [ 223.139606] 3ce0: ffff00000a0a3cf0 ffff0000083ab9b8 [ 223.144483] [<ffff0000083ab9b8>] clk_core_disable+0xc/0x1d8 [ 223.150054] [<ffff0000083acd58>] clk_disable+0x1c/0x28 [ 223.155198] [<ffff0000007d8328>] pcm3168a_remove+0x3c/0x50 [snd_soc_pcm3168a] [ 223.162334] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 223.170167] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 223.175826] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 223.182700] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 223.188012] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 223.193669] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 223.199329] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 223.204726] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 223.213079] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 223.218909] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 223.225349] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 223.233179] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 223.241008] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 223.248838] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 223.256668] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 223.264497] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 223.272327] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 223.280157] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 223.287986] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 223.295816] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 223.303648] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 223.308958] ---[ end trace eaf8939a3698b1a9 ]--- [ 223.313752] ------------[ cut here ]------------ [ 223.318383] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:477 clk_core_unprepare+0xc/0x1ac [ 223.326733] Modules linked in: [ 223.329784] snd_soc_pcm3168a_i2c(-) [ 223.333356] snd_aloop [ 223.335712] arc4 [ 223.337633] wl18xx [ 223.339728] wlcore [ 223.341823] mac80211 [ 223.344092] cfg80211 [ 223.346360] aes_ce_blk [ 223.348803] crypto_simd [ 223.351332] cryptd [ 223.353428] aes_ce_cipher [ 223.356131] crc32_ce [ 223.358400] ghash_ce [ 223.360668] aes_arm64 [ 223.363024] gf128mul [ 223.365293] snd_soc_rcar [ 223.367909] sha2_ce [ 223.370091] xhci_plat_hcd [ 223.372794] sha256_arm64 [ 223.375410] xhci_hcd [ 223.377679] sha1_ce [ 223.379861] renesas_usbhs [ 223.382564] evdev [ 223.384572] sha1_generic [ 223.387188] rcar_gen3_thermal [ 223.390239] cpufreq_dt [ 223.392682] ravb_streaming(C) [ 223.395732] wlcore_sdio [ 223.398261] thermal_sys [ 223.400790] udc_core [ 223.403059] mch_core(C) [ 223.405588] usb_dmac [ 223.407856] snd_soc_pcm3168a [ 223.410820] snd_soc_ak4613 [ 223.413609] gpio_keys [ 223.415965] virt_dma [ 223.418234] nfsd [ 223.420155] ipv6 [ 223.422076] autofs4 [ 223.424258] [last unloaded: snd_soc_pcm3168a_i2c] [ 223.429050] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457 [ 223.438616] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [ 223.446618] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000 [ 223.452536] PC is at clk_core_unprepare+0xc/0x1ac [ 223.457239] LR is at clk_unprepare+0x28/0x3c [ 223.461506] pc : [<ffff0000083ab5a4>] lr : [<ffff0000083ace4c>] pstate: 60000145 [ 223.468900] sp : ffff00000a0a3d00 [ 223.472211] x29: ffff00000a0a3d00 [ 223.475609] x28: ffff8006fa8c6200 [ 223.479009] x27: ffff0000086f1000 [ 223.482407] x26: 000000000000006a [ 223.485807] x25: 0000000000000124 [ 223.489205] x24: 0000000000000015 [ 223.492604] x23: ffff8006f9ffa8d0 [ 223.496003] x22: ffff8006faf16480 [ 223.499402] x21: ffff0000007e7040 [ 223.502800] x20: ffff8006faf16420 [ 223.506199] x19: ffff8006faadd100 [ 223.509597] x18: 000000000000000a [ 223.512997] x17: 0000000000000000 [ 223.516395] x16: 0000000000000000 [ 223.519794] x15: 0000000000000000 [ 223.523192] x14: 00000033fe89076c [ 223.526591] x13: 0000000000000400 [ 223.529989] x12: 0000000000000400 [ 223.533388] x11: 0000000000000000 [ 223.536786] x10: 00000000000009e0 [ 223.540185] x9 : ffff00000a0a3be0 [ 223.543583] x8 : ffff8006fa8c6c40 [ 223.546982] x7 : ffff8006fa8c6400 [ 223.550380] x6 : 0000000000000001 [ 223.553780] x5 : 0000000000000000 [ 223.557178] x4 : ffff8006fa8c6200 [ 223.560577] x3 : 0000000000000000 [ 223.563975] x2 : ffff8006fa8c6200 [ 223.567374] x1 : 0000000000000000 [ 223.570772] x0 : ffff8006faadd100 [ 223.574170] Call trace: [ 223.576615] Exception stack(0xffff00000a0a3bc0 to 0xffff00000a0a3d00) [ 223.583054] 3bc0: ffff8006faadd100 0000000000000000 ffff8006fa8c6200 0000000000000000 [ 223.590884] 3be0: ffff8006fa8c6200 0000000000000000 0000000000000001 ffff8006fa8c6400 [ 223.598714] 3c00: ffff8006fa8c6c40 ffff00000a0a3be0 00000000000009e0 0000000000000000 [ 223.606544] 3c20: 0000000000000400 0000000000000400 00000033fe89076c 0000000000000000 [ 223.614374] 3c40: 0000000000000000 0000000000000000 000000000000000a ffff8006faadd100 [ 223.622204] 3c60: ffff8006faf16420 ffff0000007e7040 ffff8006faf16480 ffff8006f9ffa8d0 [ 223.630033] 3c80: 0000000000000015 0000000000000124 000000000000006a ffff0000086f1000 [ 223.637863] 3ca0: ffff8006fa8c6200 ffff00000a0a3d00 ffff0000083ace4c ffff00000a0a3d00 [ 223.645693] 3cc0: ffff0000083ab5a4 0000000060000145 0000000000000140 ffff8006faadd100 [ 223.653523] 3ce0: 0000ffffffffffff ffff0000083ace44 ffff00000a0a3d00 ffff0000083ab5a4 [ 223.661353] [<ffff0000083ab5a4>] clk_core_unprepare+0xc/0x1ac [ 223.667103] [<ffff0000007d8330>] pcm3168a_remove+0x44/0x50 [snd_soc_pcm3168a] [ 223.674239] [<ffff0000007e5010>] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c] [ 223.682070] [<ffff0000084b9d9c>] i2c_device_remove+0x38/0x70 [ 223.687731] [<ffff00000843cd5c>] device_release_driver_internal+0xd0/0x1c0 [ 223.694604] [<ffff00000843ced8>] driver_detach+0x70/0x7c [ 223.699915] [<ffff00000843bf68>] bus_remove_driver+0x74/0xa0 [ 223.705572] [<ffff00000843d7e4>] driver_unregister+0x48/0x4c [ 223.711230] [<ffff0000084ba8dc>] i2c_del_driver+0x24/0x30 [ 223.716628] [<ffff0000007e5078>] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c] [ 223.724980] [<ffff00000811bd28>] SyS_delete_module+0x198/0x1d4 [ 223.730811] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000) [ 223.737250] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8 [ 223.745079] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000 [ 223.752909] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005 [ 223.760739] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000 [ 223.768568] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000 [ 223.776398] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001 [ 223.784227] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010 [ 223.792057] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130 [ 223.799886] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a [ 223.807715] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 223.815546] [<ffff0000080832c0>] el0_svc_naked+0x34/0x38 [ 223.820855] ---[ end trace eaf8939a3698b1aa ]--- Fix this issue by only disable clock and regulators in remove callback when CONFIG_PM isn't defined Signed-off-by:
Jiada Wang <jiada_wang@mentor.com> Signed-off-by:
-
Ondrej Mosnacek authored
[ Upstream commit 2cbdcb88 ] If a superblock has the MS_SUBMOUNT flag set, we should always allow mounting it. These mounts are done automatically by the kernel either as part of mounting some parent mount (e.g. debugfs always mounts tracefs under "tracing" for compatibility) or they are mounted automatically as needed on subdirectory accesses (e.g. NFS crossmnt mounts). Since such automounts are either an implicit consequence of the parent mount (which is already checked) or they can happen during regular accesses (where it doesn't make sense to check against the current task's context), the mount permission check should be skipped for them. Without this patch, attempts to access contents of an automounted directory can cause unexpected SELinux denials. In the current kernel tree, the MS_SUBMOUNT flag is set only via vfs_submount(), which is called only from the following places: - AFS, when automounting special "symlinks" referencing other cells - CIFS, when automounting "referrals" - NFS, when automounting subtrees - debugfs, when automounting tracefs In all cases the submounts are meant to be transparent to the user and it makes sense that if mounting the master is allowed, then so should be the automounts. Note that CAP_SYS_ADMIN capability checking is already skipped for (SB_KERNMOUNT|SB_SUBMOUNT) in: - sget_userns() in fs/super.c: if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !(type->fs_flags & FS_USERNS_MOUNT) && !capable(CAP_SYS_ADMIN)) return ERR_PTR(-EPERM); - sget() in fs/super.c: /* Ensure the requestor has permissions over the target filesystem */ if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !ns_capable(user_ns, CAP_SYS_ADMIN)) return ERR_PTR(-EPERM); Verified internally on patched RHEL 7.6 with a reproducer using NFS+httpd and selinux-tesuite. Fixes: 93faccbb ("fs: Better permission checking for submounts") Signed-off-by:
Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Anatolij Gustschin authored
[ Upstream commit 30522a95 ] Currently registering CvP managers works only for first probed CvP device, for all other devices it is refused due to duplicated chkcfg sysfs entry: fpga_manager fpga3: Altera CvP FPGA Manager @0000:0c:00.0 registered sysfs: cannot create duplicate filename '/bus/pci/drivers/altera-cvp/chkcfg' CPU: 0 PID: 3808 Comm: bash Tainted: G O 4.19.0-custom+ #5 Call Trace: dump_stack+0x46/0x5b sysfs_warn_dup+0x53/0x60 sysfs_add_file_mode_ns+0x16d/0x180 sysfs_create_file_ns+0x51/0x60 altera_cvp_probe+0x16f/0x2a0 [altera_cvp] local_pci_probe+0x3f/0xa0 ? pci_match_device+0xb1/0xf0 pci_device_probe+0x116/0x170 really_probe+0x21b/0x2c0 driver_probe_device+0x4b/0xe0 bind_store+0xcb/0x130 kernfs_fop_write+0xfd/0x180 __vfs_write+0x21/0x150 ? selinux_file_permission+0xdc/0x130 vfs_write+0xa8/0x1a0 ? find_vma+0xd/0x60 ksys_write+0x3d/0x90 do_syscall_64+0x44/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... altera-cvp 0000:0c:00.0: Can't create sysfs chkcfg file fpga_manager fpga3: fpga_mgr_unregister Altera CvP FPGA Manager @0000:0c:00.0 Move chkcfg creation to module init as suggested by Alan. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Acked-by:
Alan Tull <atull@kernel.org> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit ceb94bc5 ] This patch adds a safety connection way for "forced_b_device" with "workaround_for_vbus" like below: < Example for R-Car E3 Ebisu > # modprobe <any usb gadget driver> # echo 1 > /sys/kernel/debug/ee020000.usb/b_device (connect a usb cable to host side.) # echo 2 > /sys/kernel/debug/ee020000.usb/b_device Previous code should have connected a usb cable before the "b_device" is set to 1 on the Ebisu board. However, if xHCI driver on the board is probed, it causes some troubles: - Conflicts USB VBUS/signals between the board and another host. - "Cannot enable. Maybe the USB cable is bad?" might happen on both the board and another host with a usb hub. - Cannot enumerate a usb gadget correctly because an interruption of VBUS change happens unexpectedly. Reported-by:
Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Daniel T. Lee authored
[ Upstream commit 5a863813 ] Currently, kprobe_events failure won't be handled properly. Due to calling system() indirectly to write to kprobe_events, it can't be identified whether an error is derived from kprobe or system. // buf = "echo '%c:%s %s' >> /s/k/d/t/kprobe_events" err = system(buf); if (err < 0) { printf("failed to create kprobe .."); return -1; } For example, running ./tracex7 sample in ext4 partition, "echo p:open_ctree open_ctree >> /s/k/d/t/kprobe_events" gets 256 error code system() failure. => The error comes from kprobe, but it's not handled correctly. According to man of system(3), it's return value just passes the termination status of the child shell rather than treating the error as -1. (don't care success) Which means, currently it's not working as desired. (According to the upper code snippet) ex) running ./tracex7 with ext4 env. # Current Output sh: echo: I/O error failed to open event open_ctree # Desired Output failed to create kprobe 'open_ctree' error 'No such file or directory' The problem is, error can't be verified whether from child ps or system. But using write() directly can verify the command failure, and it will treat all error as -1. So I suggest using write() directly to 'kprobe_events' rather than calling system(). Signed-off-by:
Daniel T. Lee <danieltimlee@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit ad9b2b8e ] The public S805 datasheet only mentions that HHI_SYS_CPU_CLK_CNTL1[20:29] contains a divider called "cpu_scale_div". Unfortunately it does not mention how to use the register contents. The Amlogic 3.10 GPL kernel sources are using the following code to calculate the CPU clock based on that register (taken from arch/arm/mach-meson8/clock.c in the 3.10 Amlogic kernel, shortened to make it easier to read): N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF; if (sel == 3) /* use cpu_scale_div */ div = 2 * N; else div = ... /* not relevant for this example */ cpu_clk = parent_clk / div; This suggests that the formula is: parent_rate / 2 * register_value However, running perf (which can measure the CPU clock rate thanks to the ARM PMU) shows that this formula is not correct. This can be reproduced with the following steps: 1. boot into u-boot 2. let the CPU clock run off the XTAL clock: mw.l 0xC110419C 0x30 1 3. set the cpu_scale_div register: to value 0x1: mw.l 0xC110415C 0x801016A2 1 to value 0x2: mw.l 0xC110415C 0x802016A2 1 to value 0x5: mw.l 0xC110415C 0x805016A2 1 4. let the CPU clock run off cpu_scale_div: mw.l 0xC110419C 0xbd 1 5. boot Linux 6. run: perf stat -aB stress --cpu 4 --timeout 10 7. check the "cycles" value I get the following results depending on the cpu_scale_div value: - (cpu_in_sel - this is the input clock for cpu_scale_div - runs at 1.2GHz) - 0x1 = 300MHz - 0x2 = 200MHz - 0x5 = 100MHz This means that the actual formula to calculate the output of the cpu_scale_div clock is: parent_rate / 2 * (register value + 1). The register value 0x0 is reserved. When letting the CPU clock run off the cpu_scale_div while the value is 0x0 the whole board hangs (even in u-boot). I also verified this with the TWD timer: when adding this to the .dts without specifying it's clock it will auto-detect the PERIPH (which is the input clock of the TWD) clock rate (and the result is shown in the kernel log). On Meson8, Meson8b and Meson8m2 the PERIPH clock is CPUCLK divided by 4. This also matched for all three test-cases from above (in all cases the TWD timer clock rate was approx. one fourth of the CPU clock rate). A small note regarding the "fixes" tag: the original issue seems to exist virtually since forever. Even commit 28b9fcd0 ("clk: meson8b: Add support for Meson8b clocks") seems to handle this wrong. I still decided to use commit 251b6fd3 ("clk: meson: rework meson8b cpu clock") because this is the first commit which gets the CPU hiearchy correct and thus it's the first commit where the cpu_scale_div register is used correctly (apart from the bug in the cpu_scale_table). Fixes: 251b6fd3 ("clk: meson: rework meson8b cpu clock") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20180927085921.24627-2-martin.blumenstingl@googlemail.comSigned-off-by:
-
