summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-09-29docs: netlink: clarify the historical baggage of Netlink flagsJakub Kicinski
nlmsg_flags are full of historical baggage, inconsistencies and strangeness. Try to document it more thoroughly. Explain the meaning of the ECHO flag (and while at it clarify the comment in the uAPI). Handwave a little about the NEW request flags and how they make sense on the surface but cater to really old paradigm before commands were a thing. I will add more notes on how to make use of ECHO and discouragement for reuse of flags to the kernel-side documentation. Link: https://lore.kernel.org/r/20220927212306.823862-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-29vhost/vsock: Use kvmalloc/kvfree for larger packets.Junichi Uekawa
When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [<ffffffffb6a0df64>] dump_stack+0x97/0xdb [<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138 [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8 [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d [<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19 [<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb [<ffffffffb66682f3>] __kmalloc+0x177/0x1f7 [<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d [<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost] [<ffffffffb683ddce>] kthread+0xfd/0x105 [<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80 [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 Work around by doing kvmalloc instead. Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by: Junichi Uekawa <uekawa@chromium.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20220928064538.667678-1-uekawa@chromium.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-29clk: fixed-rate: add devm_clk_hw_register_fixed_rateDmitry Baryshkov
Add devm_clk_hw_register_fixed_rate(), devres-managed helper to register fixed-rate clock. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220916061740.87167-3-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-29clk: asm9260: use parent index to link the reference clockDmitry Baryshkov
Rewrite clk-asm9260 to use parent index to use the reference clock. During this rework two helpers are added: - clk_hw_register_mux_table_parent_data() to supplement clk_hw_register_mux_table() but using parent_data instead of parent_names - clk_hw_register_fixed_rate_parent_accuracy() to be used instead of directly calling __clk_hw_register_fixed_rate(). The later function is an internal API, which is better not to be called directly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220916061740.87167-2-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-29Merge tag 'mtk-clk-for-6.1' of ↵Stephen Boyd
https://git.kernel.org/pub/scm/linux/kernel/git/wens/linux into clk-mtk Pull MediaTek clk driver updates from Chen-Yu Tsai: A lot of clean up work, as well as new drivers and new functions - New clock drivers for MediaTek Helio X10 MT6795 - Add missing DPI1_HDMI clock in MT8195 VDOSYS1 - Clock driver changes to support GPU DVFS on MT8183, MT8192, MT8195 - Fix GPU clock topology on MT8195 - Propogate rate changes from GPU clock gate up the tree - Clock mux notifiers for GPU-related PLLs - Conversion of more "simple" drivers to mtk_clk_simple_probe() - Hook up mtk_clk_simple_remove() for "simple" MT8192 clock drivers - Fixes to previous |struct clk| to |struct clk_hw| conversion - Shrink MT8192 clock driver by deduplicating clock parent lists * tag 'mtk-clk-for-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/wens/linux: (31 commits) clk: mediatek: mt8192: deduplicate parent clock lists clk: mediatek: Migrate remaining clk_unregister_*() to clk_hw_unregister_*() clk: mediatek: fix unregister function in mtk_clk_register_dividers cleanup clk: mediatek: clk-mt8192: Add clock mux notifier for mfg_pll_sel clk: mediatek: clk-mt8192-mfg: Propagate rate changes to parent clk: mediatek: clk-mt8195-topckgen: Drop univplls from mfg mux parents clk: mediatek: clk-mt8195-topckgen: Add GPU clock mux notifier clk: mediatek: clk-mt8195-topckgen: Register mfg_ck_fast_ref as generic mux clk: mediatek: clk-mt8195-mfg: Reparent mfg_bg3d and propagate rate changes clk: mediatek: mt8183: Add clk mux notifier for MFG mux clk: mediatek: mux: add clk notifier functions clk: mediatek: mt8183: mfgcfg: Propagate rate changes to parent clk: mediatek: Use mtk_clk_register_gates_with_dev in simple probe clk: mediatek: gate: Export mtk_clk_register_gates_with_dev clk: mediatek: add VDOSYS1 clock dt-bindings: clk: mediatek: Add MT8195 DPI clocks clk: mediatek: mt8192: add mtk_clk_simple_remove clk: mediatek: mt8183: use mtk_clk_simple_probe to simplify driver clk: mediatek: mt6797: use mtk_clk_simple_probe to simplify driver clk: mediatek: mt6779: use mtk_clk_simple_probe to simplify driver ...
2022-09-30drm/msm: Fix build break with recent mm treeRob Clark
9178e3dcb121 ("mm: discard __GFP_ATOMIC") removed __GFP_ATOMIC, replacing it with a check for not __GFP_DIRECT_RECLAIM. Reported-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220929161404.2769414-1-robdclark@gmail.com
2022-09-30m68k: update config filesLukas Bulwahn
Clean up config files by: - removing configs that were deleted in the past - removing configs not in tree and without recently pending patches - adding new configs that are replacements for old configs in the file For some detailed information, see Link. Link: https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulwahn@gmail.com/ Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2022-09-29sbitmap: fix lockup while swappingHugh Dickins
Commit 4acb83417cad ("sbitmap: fix batched wait_cnt accounting") is a big improvement: without it, I had to revert to before commit 040b83fcecfb ("sbitmap: fix possible io hung due to lost wakeup") to avoid the high system time and freezes which that had introduced. Now okay on the NVME laptop, but 4acb83417cad is a disaster for heavy swapping (kernel builds in low memory) on another: soon locking up in sbitmap_queue_wake_up() (into which __sbq_wake_up() is inlined), cycling around with waitqueue_active() but wait_cnt 0 . Here is a backtrace, showing the common pattern of outer sbitmap_queue_wake_up() interrupted before setting wait_cnt 0 back to wake_batch (in some cases other CPUs are idle, in other cases they're spinning for a lock in dd_bio_merge()): sbitmap_queue_wake_up < sbitmap_queue_clear < blk_mq_put_tag < __blk_mq_free_request < blk_mq_free_request < __blk_mq_end_request < scsi_end_request < scsi_io_completion < scsi_finish_command < scsi_complete < blk_complete_reqs < blk_done_softirq < __do_softirq < __irq_exit_rcu < irq_exit_rcu < common_interrupt < asm_common_interrupt < _raw_spin_unlock_irqrestore < __wake_up_common_lock < __wake_up < sbitmap_queue_wake_up < sbitmap_queue_clear < blk_mq_put_tag < __blk_mq_free_request < blk_mq_free_request < dd_bio_merge < blk_mq_sched_bio_merge < blk_mq_attempt_bio_merge < blk_mq_submit_bio < __submit_bio < submit_bio_noacct_nocheck < submit_bio_noacct < submit_bio < __swap_writepage < swap_writepage < pageout < shrink_folio_list < evict_folios < lru_gen_shrink_lruvec < shrink_lruvec < shrink_node < do_try_to_free_pages < try_to_free_pages < __alloc_pages_slowpath < __alloc_pages < folio_alloc < vma_alloc_folio < do_anonymous_page < __handle_mm_fault < handle_mm_fault < do_user_addr_fault < exc_page_fault < asm_exc_page_fault See how the process-context sbitmap_queue_wake_up() has been interrupted, after bringing wait_cnt down to 0 (and in this example, after doing its wakeups), before advancing wake_index and refilling wake_cnt: an interrupt-context sbitmap_queue_wake_up() of the same sbq gets stuck. I have almost no grasp of all the possible sbitmap races, and their consequences: but __sbq_wake_up() can do nothing useful while wait_cnt 0, so it is better if sbq_wake_ptr() skips on to the next ws in that case: which fixes the lockup and shows no adverse consequence for me. The check for wait_cnt being 0 is obviously racy, and ultimately can lead to lost wakeups: for example, when there is only a single waitqueue with waiters. However, lost wakeups are unlikely to matter in these cases, and a proper fix requires redesign (and benchmarking) of the batched wakeup code: so let's plug the hole with this bandaid for now. Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Keith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/9c2038a7-cdc5-5ee-854c-fbc6168bf16@google.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-29io_uring/net: fix notif cqe reorderingPavel Begunkov
send zc is not restricted to !IO_URING_F_UNLOCKED anymore and so we can't use task-tw ordering trick to order notification cqes with requests completions. In this case leave it alone and let io_send_zc_cleanup() flush it. Cc: stable@vger.kernel.org Fixes: 53bdc88aac9a2 ("io_uring/notif: order notif vs send CQEs") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/0031f3a00d492e814a4a0935a2029a46d9c9ba06.1664486545.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-29io_uring/net: don't update msg_name if not providedPavel Begunkov
io_sendmsg_copy_hdr() may clear msg->msg_name if the userspace didn't provide it, we should retain NULL in this case. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/97d49f61b5ec76d0900df658cfde3aa59ff22121.1664486545.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-30Merge tag 'drm-intel-next-fixes-2022-09-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix release build bug in 'remove GuC log size module parameters' (John Harrison) - Remove ipc_enabled from struct drm_i915_private (Jani Nikula) - Do not cleanup obj with NULL bo->resource (Nirmoy Das) - Fix device info for devices without display (Jani Nikula) - Force DPLL calculation for TC ports after readout (Ville Syrjälä) - Use i915_vm_put on ppgtt_create error paths (Chris Wilson) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YzWqtwPNxAe+r9FO@tursulin-desk
2022-09-29binfmt: remove taso from linux_binprm structLukas Bulwahn
With commit 987f20a9dcce ("a.out: Remove the a.out implementation"), the use of the special taso flag for alpha architectures in the linux_binprm struct is gone. Remove the definition of taso in the linux_binprm struct. No functional change. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220929203903.9475-1-lukas.bulwahn@gmail.com
2022-09-30Merge tag 'drm-intel-fixes-2022-09-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Restrict forced preemption to the active context (Chris) - Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YzXAkH1a32pYJD33@intel.com
2022-09-30Merge tag 'amd-drm-fixes-6.0-2022-09-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.0-2022-09-29: amdgpu: - GC 11.x fixes - SMU 13.x fixes - DCN 3.1.4 fixes - DCN 3.2.x fixes - GC 9.x fix - Fence fix - SR-IOV supend/resume fix - PSR regression fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220929144003.8363-1-alexander.deucher@amd.com
2022-09-30Merge tag 'drm-misc-fixes-2022-09-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * bridge/analogix: Revert earlier suspend fix * bridge/lt8912b: Fix corrupt display output Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YzWvHhaqHhYirn4L@linux-uq9g
2022-09-29of: fdt: Remove unused struct fdt_scan_statusYuan Can
After commit bba04d965d06("of/fdt: remove unused of_scan_flat_dt_by_path"), no one use struct fdt_scan_status, so remove it. Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20220927133739.98493-1-yuancan@huawei.com Signed-off-by: Rob Herring <robh@kernel.org>
2022-09-29dt-bindings: display: st,stm32-dsi: Handle data-lanes in DSI port nodeMarek Vasut
Handle 'data-lanes' property of the DSI output endpoint, it is possible to describe DSI link with 1 or 2 data lanes this way. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20220926234501.583115-1-marex@denx.de Signed-off-by: Rob Herring <robh@kernel.org>
2022-09-29io_uring: don't gate task_work run on TIF_NOTIFY_SIGNALJens Axboe
This isn't a reliable mechanism to tell if we have task_work pending, we really should be looking at whether we have any items queued. This is problematic if forward progress is gated on running said task_work. One such example is reading from a pipe, where the write side has been closed right before the read is started. The fput() of the file queues TWA_RESUME task_work, and we need that task_work to be run before ->release() is called for the pipe. If ->release() isn't called, then the read will sit forever waiting on data that will never arise. Fix this by io_run_task_work() so it checks if we have task_work pending rather than rely on TIF_NOTIFY_SIGNAL for that. The latter obviously doesn't work for task_work that is queued without TWA_SIGNAL. Reported-by: Christiano Haesbaert <haesbaert@haesbaert.org> Cc: stable@vger.kernel.org Link: https://github.com/axboe/liburing/issues/665 Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-29Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds
Pull coredump fix from Al Viro: "Fix for breakage in dump_user_range()" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: [coredump] don't use __kernel_write() on kmap_local_page()
2022-09-29Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
No conflicts. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-29drm/panel: simple: Use dev_err_probe() to simplify codeYuan Can
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220929015503.17301-3-yuancan@huawei.com
2022-09-29drm/panel: panel-edp: Use dev_err_probe() to simplify codeYuan Can
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220929015503.17301-2-yuancan@huawei.com Link: https://patchwork.freedesktop.org/patch/msgid/20220929015503.17301-2-yuancan@huawei.com
2022-09-29Bluetooth: L2CAP: Fix user-after-freeLuiz Augusto von Dentz
This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 Link: https://lore.kernel.org/lkml/20220622082716.478486-1-lee.jones@linaro.org Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
2022-09-29prandom: make use of smaller types in prandom_u32_maxJason A. Donenfeld
When possible at compile-time, make use of smaller types in prandom_u32_max(), so that we can use smaller batches from random.c, which in turn leads to a 2x or 4x performance boost. This makes a difference, for example, in kfence, which needs a fast stream of small numbers (booleans). At the same time, we use the occasion to update the old documentation on these functions. prandom_u32() and prandom_bytes() have direct replacements now in random.h, while prandom_u32_max() remains useful as a prandom.h function, since it's not cryptographically secure by virtue of not being evenly distributed. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Acked-by: Marco Elver <elver@google.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29random: add 8-bit and 16-bit batchesJason A. Donenfeld
There are numerous places in the kernel that would be sped up by having smaller batches. Currently those callsites do `get_random_u32() & 0xff` or similar. Since these are pretty spread out, and will require patches to multiple different trees, let's get ahead of the curve and lay the foundation for `get_random_u8()` and `get_random_u16()`, so that it's then possible to start submitting conversion patches leisurely. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29utsname: contribute changes to RNGJason A. Donenfeld
On some small machines with little entropy, a quasi-unique hostname is sometimes a relevant factor. I've seen, for example, 8 character alpha-numeric serial numbers. In addition, the time at which the hostname is set is usually a decent measurement of how long early boot took. So, call add_device_randomness() on new hostnames, which feeds its arguments to the RNG in addition to a fresh cycle counter. Low cost hooks like this never hurt and can only ever help, and since this costs basically nothing for an operation that is never a fast path, this is an overall easy win. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29random: use init_utsname() instead of utsname()Jason A. Donenfeld
Rather than going through the current-> indirection for utsname, at this point in boot, init_utsname()==utsname(), so just use it directly that way. Additionally, init_utsname() appears to be available nearly always, so move it into random_init_early(). Suggested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29kfence: use better stack hash seedJason A. Donenfeld
As of the prior commit, the RNG will have incorporated both a cycle counter value and RDRAND, in addition to various other environmental noise. Therefore, using get_random_u32() will supply a stronger seed than simply using random_get_entropy(). N.B.: random_get_entropy() should be considered an internal API of random.c and not generally consumed. Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Marco Elver <elver@google.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29random: split initialization into early step and later stepJason A. Donenfeld
The full RNG initialization relies on some timestamps, made possible with initialization functions like time_init() and timekeeping_init(). However, these are only available rather late in initialization. Meanwhile, other things, such as memory allocator functions, make use of the RNG much earlier. So split RNG initialization into two phases. We can provide arch randomness very early on, and then later, after timekeeping and such are available, initialize the rest. This ensures that, for example, slabs are properly randomized if RDRAND is available. Without this, CONFIG_SLAB_FREELIST_RANDOM=y loses a degree of its security, because its random seed is potentially deterministic, since it hasn't yet incorporated RDRAND. It also makes it possible to use a better seed in kfence, which currently relies on only the cycle counter. Another positive consequence is that on systems with RDRAND, running with CONFIG_WARN_ALL_UNSEEDED_RANDOM=y results in no warnings at all. One subtle side effect of this change is that on systems with no RDRAND, RDTSC is now only queried by random_init() once, committing the moment of the function call, instead of multiple times as before. This is intentional, as the multiple RDTSCs in a loop before weren't accomplishing very much, with jitter being better provided by try_to_generate_entropy(). Plus, filling blocks with RDTSC is still being done in extract_entropy(), which is necessarily called before random bytes are served anyway. Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-29checkpatch: warn on usage of VM_BUG_ON() and other BUG variantsDavid Hildenbrand
checkpatch does not point out that VM_BUG_ON() and friends should be avoided, however, Linus notes: VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". [1] So let's warn on VM_BUG_ON() and other BUG variants as well. While at it, make it clearer that the kernel really shouldn't be crashed. As there are some subsystem BUG macros that actually don't end up crashing the kernel -- for example, KVM_BUG_ON() -- exclude these manually. [1] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com Signed-off-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20220923113426.52871-3-david@redhat.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")David Hildenbrand
Linus notes [1] that the introduction of new code that uses VM_BUG_ON() is just as bad as BUG_ON(), because it will crash the kernel on distributions that enable CONFIG_DEBUG_VM (like Fedora): VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". [2] This resulted in a more generic discussion about usage of BUG() and friends. While there might be corner cases that still deserve a BUG_ON(), most BUG_ON() cases should simply use WARN_ON_ONCE() and implement a recovery path if reasonable: The only possible case where BUG_ON can validly be used is "I have some fundamental data corruption and cannot possibly return an error". [2] As a very good approximation is the general rule: "absolutely no new BUG_ON() calls _ever_" [2] ... not even if something really shouldn't ever happen and is merely for documenting that an invariant always has to hold. However, there are sill exceptions where BUG_ON() may be used: If you have a "this is major internal corruption, there's no way we can continue", then BUG_ON() is appropriate. [3] There is only one good BUG_ON(): Now, that said, there is one very valid sub-form of BUG_ON(): BUILD_BUG_ON() is absolutely 100% fine. [2] While WARN will also crash the machine with panic_on_warn set, that's exactly to be expected: So we have two very different cases: the "virtual machine with good logging where a dead machine is fine" - use 'panic_on_warn'. And the actual real hardware with real drivers, running real loads by users. [4] The basic idea is that warnings will similarly get reported by users and be found during testing. However, in contrast to a BUG(), there is a way to actually influence the expected behavior (e.g., panic_on_warn) and to eventually keep the machine alive to extract some debug info. Ingo notes that not all WARN_ON_ONCE cases need recovery. If we don't ever expect this code to trigger in any case, recovery code is not really helpful. I'd prefer to keep all these warnings 'simple' - i.e. no attempted recovery & control flow, unless we ever expect these to trigger. [5] There have been different rules floating around that were never properly documented. Let's try to clarify. [1] https://lkml.kernel.org/r/CAHk-=wiEAH+ojSpAgx_Ep=NKPWHU8AdO3V56BXcCsU97oYJ1EA@mail.gmail.com [2] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com [3] https://lkml.kernel.org/r/CAHk-=wit-DmhMfQErY29JSPjFgebx_Ld+pnerc4J2Ag990WwAA@mail.gmail.com [4] https://lore.kernel.org/r/CAHk-=wgF7K2gSSpy=m_=K3Nov4zaceUX9puQf1TjkTJLA2XC_g@mail.gmail.com [5] https://lore.kernel.org/r/YwIW+mVeZoTOxn%2F4@gmail.com Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20220923113426.52871-2-david@redhat.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29Documentation: devres: add missing IO helperYang Yingliang
Add missing devm_request_free_mem_region() to devres.rst. It's introduced by commit 0092908d16c6 ("mm: factor out a devm_request_free_mem_region helper"). Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220927080215.1359979-1-yangyingliang@huawei.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29Documentation: devres: update IRQ helperYang Yingliang
devm_irq_sim_init() has been changed to devm_irq_domain_create_sim() in commit 337cbeb2c13e ("genirq/irq_sim: Simplify the API"). Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220927083819.12484-1-yangyingliang@huawei.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29Documentation/mm: modify page_referenced to folio_referencedVernon Yang
Since commit b3ac04132c4b ("mm/rmap: Turn page_referenced() into folio_referenced()") the page_referenced function name was modified, so fix it up to use the correct one. Signed-off-by: Vernon Yang <vernon2gm@gmail.com> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Link: https://lore.kernel.org/r/20220926152032.74621-1-vernon2gm@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29Documentation/CoC: Reflect current CoC interpretation and practicesKristen Carlson Accardi
The Code of Conduct interpretation does not reflect the current practices of the CoC committee or the TAB. Update the documentation to remove references to initial committees and boot strap periods since it is past that time, and note that the this document does serve as the documentation for the CoC committee processes. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220926211149.2278214-1-kristen@linux.intel.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs/doc-guide: Add documentation on SPHINX_IMGMATHAkira Yokosawa
Now that building html docs with math expressions does not need texlive packages, remove the note on the requirement in the "Sphinx Install" section. Instead, add sections of "Math Expressions in HTML" and "Choice of Math Renderer". Describe the effect of setting SPHINX_IMGMATH in the latter section. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/a67e3279-6bc7-ee2c-2b49-9275252460b0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: process/5.Posting.rst: clarify use of Reported-by: tagThorsten Leemhuis
Bring the description on when to use the Reported-by: tag found in Documentation/process/5.Posting.rst more in line with the description in Documentation/process/submitting-patches.rst: before this change the two were contradicting each other, as the latter is way more permissive and only states '[...] if the bug was reported in private, then ask for permission first before using the Reported-by tag.' Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Link: https://lore.kernel.org/r/2fc7162dfb76e04da5ea903c9c170d913e735dad.1664372256.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs, kprobes: Fix the wrong location of KprobesTiezhu Yang
After commit 22471e1313f2 ("kconfig: use a menu in arch/Kconfig to reduce clutter"), the location of Kprobes is under "General architecture-dependent options" rather than "General setup". Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Fixes: 22471e1313f2 ("kconfig: use a menu in arch/Kconfig to reduce clutter") Link: https://lore.kernel.org/r/1663322106-12178-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29drm/amdgpu: Enable sram on vcn_4_0_2Sonny Jiang
Enable sram on vcn_4_0_2 Signed-off-by: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: James Zhu <James.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-29drm/amdgpu: Enable VCN DPG for GC11_0_1Sonny Jiang
Enable VCN DPG on GC11_0_1 Signed-off-by: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: James Zhu <James.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-29perf build: Fixup disabling of -Wdeprecated-declarations for the python ↵Arnaldo Carvalho de Melo
scripting engine A brown paper bag where -Wno-error=deprecated-declarations was added from compiler output when the right thing is to add -Wno-deprecated-declarations, fix it. Fixes: 4ee3c4da8b1b9c22 ("perf scripting python: Do not build fail on deprecation warnings") Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-29dt-bindings: timer: Add power-domains for TI timer-dm on K3Tony Lindgren
On K3 SoCs, the power-domains property is needed. On the earlier SoCs, the power-domains property is handled by the interconnect target module parent device. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220919112357.64997-1-tony@atomide.com Signed-off-by: Rob Herring <robh@kernel.org>
2022-09-29Merge branch 'fp' into docs-mwJonathan Corbet
The top-level index.rst file is the entry point for the kernel's documentation, especially for readers of the HTML output. It is currently a mess containing everything we thought to throw in there. Firefox says it would require 26 pages of paper to print it. That is not a user-friendly introduction. This series aims to improve our documentation entry point with a focus on rewriting index.rst. The result is, IMO, simpler and more approachable. For anybody who wants to see the rendered results without building the docs, have a look at: https://static.lwn.net/kerneldoc/ This time around I've rendered the pages using the "Read The Docs" theme, since that's what everybody will get by default. That theme ignores the directives regarding the left column, so the results are not as good there. I have a series proposing a default-theme change in the works, but that's a separate topic. This is only a beginning; I think this kind of organizational effort has to be pushed down into the lower layers of the docs tree itself. But one has to start somewhere.
2022-09-29docs: add a man-pages link to the front pageJonathan Corbet
Readers looking for user-oriented information may benefit from it. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Reviewed-by: David Vernet <void@manifault.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-8-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: put atomic*.txt and memory-barriers.txt into the core-api bookJonathan Corbet
These files describe part of the core API, but have never been converted to RST due to ... let's say local oppposition. So, create a set of special-purpose wrappers to ..include these files into a separate page so that they can be a part of the htmldocs build. Then link them into the core-api manual and remove them from the "staging" dumping ground. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Reviewed-by: David Vernet <void@manifault.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-7-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: move asm-annotations.rst into core-apiJonathan Corbet
This one file should not really be in the top-level documentation directory. core-api/ may not be a perfect fit but seems to be best, so move it there. Adjust a couple of internal document references to make them location-independent, and point checkpatch.pl at the new location. Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Joe Perches <joe@perches.com> Reviewed-by: David Vernet <void@manifault.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-6-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: remove some index.rst cruftJonathan Corbet
There is some useless boilerplate text that was added by sphinx when this file was first created; take it out. Reviewed-by: David Vernet <void@manifault.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-5-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: reconfigure the HTML left columnJonathan Corbet
Use the html_sidebars directive to get a more useful set of links in the left column. Unfortunately, this is a no-op with the default RTD theme, but others observe it. Reviewed-by: David Vernet <void@manifault.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-4-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: Rewrite the front pageJonathan Corbet
The front page is the entry point to the documentation, especially for people who read it online. It's a big mess of everything we could think to toss into it. Rewrite the page with an eye toward simplicity and making it easy for readers to get going toward what they really want to find. This is only a beginning, but it makes our docs more approachable than before. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: David Vernet <void@manifault.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-3-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-09-29docs: promote the title of process/index.rstJonathan Corbet
...otherwise Sphinx won't cooperate when trying to list it explicitly in the top-level index.rst file Reviewed-by: David Vernet <void@manifault.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220927160559.97154-2-corbet@lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
generated by cgit (git 2.34.1) at 2025-09-13 16:17:06 +0000