summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-24comedi: Adjust range_table_list allocation typeKees Cook
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The returned type is "struct comedi_lrange **", but the assigned type, while technically matching, is const qualified. Since there is no general way to remove const qualifiers, switch the returned type to match the assign type. No change in allocation size results. Link: https://patch.msgid.link/20250426061015.work.971-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-11-24btrfs: use end_pos variable where needed in btrfs_dirty_folio()Filipe Manana
We have a couple places doing the computation "pos + write_bytes" when we already have it in the local variable "end_pos". Change then to use the variable instead and make source code smaller. Also make the variable const since it's not supposed to change. This also has a very slight reduction in the module size. Before: $ size fs/btrfs/btrfs.ko text data bss dec hex filename 1915990 161647 15592 2093229 1ff0ad fs/btrfs/btrfs.ko After: $ size fs/btrfs/btrfs.ko text data bss dec hex filename 1915974 161647 15592 2093213 1ff09d fs/btrfs/btrfs.ko Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: fix racy bitfield write in btrfs_clear_space_info_full()Boris Burkov
From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on writes to space_info->flush, regardless of locking. Fixes: 957780eb2788 ("Btrfs: introduce ticketed enospc infrastructure") Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: fix comment in alloc_bitmap() and drop stale TODORajeev Tapadia
All callers of alloc_bitmap() hold a transaction handle, so GFP_NOFS is needed to avoid deadlocks on recursion. Update the comment and drop the stale TODO. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Rajeev Tapadia <rtapadia730@gmail.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: fix double free of qgroup record after failure to add delayed ref headMiquel Sabaté Solà
In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object. Fixes: 6ef8fbce0104 ("btrfs: fix missing error handling when adding delayed ref with qgroups enabled") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: subpage: rename macro variables to avoid shadowingDavid Sterba
When compiling with -Wshadow there are warnings in the subpage helper macros that are used in functions like btrfs_subpage_dump_bitmap() or btrfs_subpage_clear_and_test_dirty() that also use 'bfs' (for struct btrfs_folio_state) or blocks_per_folio. Add '__' to the macro variables and unify naming in all subpage macros. Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: refactor allocation size calculation in alloc_btrfs_io_context()Mehdi Ben Hadj Khelifa
Use struct_size() to replace the open-coded calculation, remove the comment as use of the helper is self explanatory. Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: fix trivial -Wshadow warningsDavid Sterba
When compiling with -Wshadow (also in 'make W=2' build) there are several reports of shadowed variables that seem to be harmless: - btrfs_do_encoded_write() - we can reuse 'ordered', there's no previous value that would need to be preserved - scrub_write_endio() - we need a standalone 'i' for bio iteration - scrub_stripe() - duplicate ret2 for errors that must not overwrite 'ret' - btrfs_subpage_set_writeback() - 'flags' is used for another irqsave lock but is not overwritten when reused for xarray due to scoping, but for clarity let's rename it - process_dir_items_leaf() - duplicate 'ret', used only for immediate checks Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: print-tree: use string format for key namesDavid Sterba
There's a warning when -Wformat=2 is used: fs/btrfs/print-tree.c: In function ‘key_type_string’: fs/btrfs/print-tree.c:424:17: warning: format not a string literal and no format arguments [-Wformat-nonliteral] 424 | scnprintf(buf, buf_size, key_to_str[key->type]); We're printing fixed strings from a table so there's no problem but let's fix the warning so we could enable the warning in fs/btrfs/. Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: remove unnecessary NULL fs_info check from find_lock_delalloc_range()Qu Wenruo
[STATIC CHECK REPORT] Smatch is reporting that find_lock_delalloc_range() used to do a null pointer check before accessing fs_info, but now we're accessing it for sectorsize unconditionally. [FALSE ALERT] This is a false alert, the existing null pointer check is introduced in commit f7b12a62f008 ("btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size"), but way before that, commit 7c0260ee098d ("btrfs: tests, require fs_info for root") is already forcing every btrfs_root to have a correct fs_info pointer. So there is no way that btrfs_root::fs_info is NULL. [FIX] Just remove the unnecessary NULL pointer checker. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: f7b12a62f008 ("btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size") Closes: https://lore.kernel.org/r/202509250925.4L4JQTtn-lkp@intel.com/ Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24btrfs: use single return value variable in btrfs_relocate_block_group()Filipe Manana
We are using 'ret' and 'err' variables to track return values and errors, which is pattern that is error prone and we had quite some bugs due to this pattern in the past. Simplify this and use a single variable, named 'ret', to track errors and the return value. Also rename the variable 'rw' to 'bg_is_ro' which is more meaningful name, and change its type from int to bool. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-11-24PCI: Use max() instead of max_t() to ease static analysisDavid Laight
In this code: used_buses = max_t(unsigned int, available_buses, pci_hotplug_bus_size - 1); max_t() casts the 'unsigned long' pci_hotplug_bus_size (either 32 or 64 bits) to 'unsigned int' (32 bits) result type, so there's a potential of discarding significant bits. Instead, use max(a, b), which casts 'unsigned int' to 'unsigned long' and cannot discard significant bits. In this case, pci_hotplug_bus_size is constrained to <= 0xff by pci_setup() so this doesn't fix a bug, but it makes static analysis easier. Signed-off-by: David Laight <david.laight.linux@gmail.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251119224140.8616-26-david.laight.linux@gmail.com
2025-11-24perf docs: arm-spe: Document new SPE filtering featuresJames Clark
FEAT_SPE_EFT and FEAT_SPE_FDS etc have new user facing format attributes so document them. Also document existing 'event_filter' bits that were missing from the doc and the fact that latency values are stored in the weight field. Reviewed-by: Leo Yan <leo.yan@arm.com> Tested-by: Leo Yan <leo.yan@arm.com> Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: James Clark <james.clark@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-11-24perf tools: Add support for perf_event_attr::config4James Clark
perf_event_attr has gained a new field, config4, so add support for it extending the existing configN support. Reviewed-by: Leo Yan <leo.yan@arm.com> Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Leo Yan <leo.yan@arm.com> Signed-off-by: James Clark <james.clark@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-11-24tools headers UAPI: Sync linux/perf_event.h with the kernel sourcesJames Clark
To pickup config4 changes. Tested-by: Leo Yan <leo.yan@arm.com> Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: James Clark <james.clark@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-11-24ACPI: tools: pfrut: fix memory leak and resource leak in pfrut.cMalaya Kumar Rout
Static analysis found an issue in pfrut.c cppcheck output before this patch: tools/power/acpi/tools/pfrut/pfrut.c:225:3: error: Resource leak: fd_update [resourceLeak] tools/power/acpi/tools/pfrut/pfrut.c:269:3: error: Resource leak: fd_update [resourceLeak] tools/power/acpi/tools/pfrut/pfrut.c:269:3: error: Resource leak: fd_update_log [resourceLeak] tools/power/acpi/tools/pfrut/pfrut.c:365:4: error: Memory leak: addr_map_capsule [memleak] tools/power/acpi/tools/pfrut/pfrut.c:424:4: error: Memory leak: log_buf [memleak] cppcheck output after this patch: No resource leaks found Fix by closing file descriptors and freeing allocated memory. Signed-off-by: Malaya Kumar Rout <mrout@redhat.com> Link: https://patch.msgid.link/20251120170001.251968-1-mrout@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-24hwmon: (vt8231) Convert macros to functions to avoid TOCTOUGui-Dong Han
The macro FAN_FROM_REG evaluates its arguments multiple times. When used with shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function to ensure arguments are evaluated only once. Additionally, in fan_div_store, move the reading of the old register value and the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data, preventing race conditions during fan divider updates. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20251124165900.4713-1-hanguidong02@gmail.com [groeck: Dropped unnecessary line split] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-24ACPI: property: use min() instead of min_t()David Laight
min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'. Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long' and so cannot discard significant bits. In this case the 'unsigned long' value is small enough that the result is ok. Detected by an extra check added to min_t(). Signed-off-by: David Laight <david.laight.linux@gmail.com> [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20251119224140.8616-14-david.laight.linux@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-24hwmon: (emc2103) Add locking to avoid TOCTOUGui-Dong Han
The functions fan1_input_show and fan1_target_show check shared data for zero before using it as a divisor. These accesses are currently lockless. If the data changes to zero between the check and the division, it causes a divide-by-zero error. Explicitly acquire the update lock around these checks and calculations to ensure the data remains stable, preventing Time-of-Check to Time-of-Use (TOCTOU) race conditions. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20251124165508.4667-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-24cpuidle: governors: teo: Add missing space to the descriptionRafael J. Wysocki
There is a missing space in the governor description comment, so add it. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5059034.31r3eYUQgx@rafael.j.wysocki
2025-11-24PM: hibernate: Extra cleanup of comments in swap handling codeRafael J. Wysocki
Continue recent cleanups of comments in the swap handling code. Unify the use of white space in the comments, drop some unuseful comments outside function bodies, and move some other comments into function bodies. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5943864.DvuYhMxLoT@rafael.j.wysocki
2025-11-24objtool: Trim trailing NOPs in alternativeAlexandre Chartre
When disassembling alternatives replace trailing NOPs with a single indication of the number of bytes covered with NOPs. Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/20251121095340.464045-31-alexandre.chartre@oracle.com
2025-11-24objtool: Add wide output for disassemblyAlexandre Chartre
Add the --wide option to provide a wide output when disassembling. With this option, the disassembly of alternatives is displayed side-by-side instead of one above the other. Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/20251121095340.464045-30-alexandre.chartre@oracle.com
2025-11-24objtool: Compact output for alternatives with one instructionAlexandre Chartre
When disassembling, if an instruction has alternatives which are all made of a single instruction then print each alternative on a single line (instruction + description) so that the output is more compact. Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/20251121095340.464045-29-alexandre.chartre@oracle.com
2025-11-24objtool: Improve naming of group alternativesAlexandre Chartre
Improve the naming of group alternatives by showing the feature name and flags used by the alternative. Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/20251121095340.464045-28-alexandre.chartre@oracle.com
2025-11-24objtool: Add Function to get the name of a CPU featureAlexandre Chartre
Add a function to get the name of a CPU feature. The function is architecture dependent and currently only implemented for x86. The feature names are automatically generated from the cpufeatures.h include file. Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/20251121095340.464045-27-alexandre.chartre@oracle.com
2025-11-24Add RSPI support for RZ/T2H and RZ/N2HMark Brown
Merge series from Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>: Add support for RZ/T2H and RZ/N2H.
2025-11-24x86_64/bug: Inline the UD1Peter Zijlstra
(Ab)use the static_call infrastructure to convert all: call __WARN_trap instances into the desired: ud1 (%edx), %rdi eliminating the CALL/RET, but more importantly, fixing the fact that all WARNs will have: RIP: 0010:__WARN_trap+0 Basically, by making it a static_call trampoline call, objtool will collect the callsites, and then the inline rewrite will hit the special case and replace the code with the magic instruction. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.456717741@infradead.org
2025-11-24x86/bug: Implement WARN_ONCE()Peter Zijlstra
Implement WARN_ONCE like WARN using BUGFLAG_ONCE. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.339309119@infradead.org
2025-11-24x86_64/bug: Implement __WARN_printf()Peter Zijlstra
The basic idea is to have __WARN_printf() be a vararg function such that the compiler can do the optimal calling convention for us. This function body will be a #UD and then set up a va_list in the exception from pt_regs. But because the trap will be in a called function, the bug_entry must be passed in. Have that be the first argument, with the format tucked away inside the bug_entry. The comments should clarify the real fun details. The big downside is that all WARNs will now show: RIP: 0010:__WARN_trap:+0 One possible solution is to simply discard the top frame when unwinding. A follow up patch takes care of this slightly differently by abusing the x86 static_call implementation. This changes (with the next patches): WARN_ONCE(preempt_count() != 2*PREEMPT_DISABLE_OFFSET, "corrupted preempt_count: %s/%d/0x%x\n", from: cmpl $2, %ecx #, _7 jne .L1472 ... .L1472: cmpb $0, __already_done.11(%rip) je .L1513 ... .L1513 movb $1, __already_done.11(%rip) movl 1424(%r14), %edx # _15->pid, _15->pid leaq 1912(%r14), %rsi #, _17 movq $.LC43, %rdi #, call __warn_printk # ud2 .pushsection __bug_table,"aw" 2: .long 1b - . # bug_entry::bug_addr .long .LC1 - . # bug_entry::file .word 5093 # bug_entry::line .word 2313 # bug_entry::flags .org 2b + 12 .popsection .pushsection .discard.annotate_insn,"M", @progbits, 8 .long 1b - . .long 8 # ANNOTYPE_REACHABLE .popsection into: cmpl $2, %ecx #, _7 jne .L1442 #, ... .L1442: lea (2f)(%rip), %rdi 1: .pushsection __bug_table,"aw" 2: .long 1b - . # bug_entry::bug_addr .long .LC43 - . # bug_entry::format .long .LC1 - . # bug_entry::file .word 5093 # bug_entry::line .word 2323 # bug_entry::flags .org 2b + 16 .popsection movl 1424(%r14), %edx # _19->pid, _19->pid leaq 1912(%r14), %rsi #, _13 ud1 (%edx), %rdi Notably, by pushing everything into the exception handler it can take care of the ONCE thing. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.213813530@infradead.org
2025-11-24x86/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILEDPeter Zijlstra
Since we have an explicit format string, use it for the condition string instead of frobbing it in the file string. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.097401406@infradead.org
2025-11-24x86/bug: Add BUG_FORMAT basicsPeter Zijlstra
Opt-in to BUG_FORMAT for x86_64, adjust the BUGTABLE helper and for now, just store NULL pointers. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115757.980264454@infradead.org
2025-11-24soc: renesas: Use bitfield helpersGeert Uytterhoeven
Use the field_get() helper, instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24clk: renesas: Use bitfield helpersGeert Uytterhoeven
Use the FIELD_{GET,PREP}() and field_{get,prep}() helpers for const respective non-const bitfields, instead of open-coding the same operations. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24ALSA: usb-audio: Convert to common field_{get,prep}() helpersGeert Uytterhoeven
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24soc: renesas: rz-sysc: Convert to common field_get() helperGeert Uytterhoeven
Drop the driver-specific field_get() macro, in favor of the globally available variant from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24pinctrl: ma35: Convert to common field_{get,prep}() helpersGeert Uytterhoeven
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: mlx90614: Convert to common field_{get,prep}() helpersGeert Uytterhoeven
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: dac: Convert to common field_prep() helperGeert Uytterhoeven
Drop the driver-specific field_prep() macro, in favor of the globally available variant from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24gpio: aspeed: Convert to common field_{get,prep}() helpersGeert Uytterhoeven
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24EDAC/ie31200: Convert to common field_get() helperGeert Uytterhoeven
Drop the driver-specific field_get() macro, in favor of the globally available variant from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24crypto: qat - convert to common field_get() helperGeert Uytterhoeven
Drop the driver-specific field_get() macro, in favor of the globally available variant from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24clk: at91: Convert to common field_{get,prep}() helpersGeert Uytterhoeven
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24bitfield: Add non-constant field_{prep,get}() helpersGeert Uytterhoeven
The existing FIELD_{GET,PREP}() macros are limited to compile-time constants. However, it is very common to prepare or extract bitfield elements where the bitfield mask is not a compile-time constant. To avoid this limitation, the AT91 clock driver and several other drivers already have their own non-const field_{prep,get}() macros. Make them available for general use by adding them to <linux/bitfield.h>, and improve them slightly: 1. Avoid evaluating macro parameters more than once, 2. Replace "ffs() - 1" by "__ffs()", 3. Support 64-bit use on 32-bit architectures, 4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is actually constant. This is deliberately not merged into the existing FIELD_{GET,PREP}() macros, as people expressed the desire to keep stricter variants for increased safety, or for performance critical paths. Yury: use __mask withing new macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Crt Mori <cmo@melexis.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Richard Genoud <richard.genoud@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24bitfield: Add less-checking __FIELD_{GET,PREP}()Geert Uytterhoeven
The BUILD_BUG_ON_MSG() check against "~0ull" works only with "unsigned (long) long" _mask types. For constant masks, that condition is usually met, as GENMASK() yields an UL value. The few places where the constant mask is stored in an intermediate variable were fixed by changing the variable type to u64 (see e.g. [1] and [2]). However, for non-constant masks, smaller unsigned types should be valid, too, but currently lead to "result of comparison of constant 18446744073709551615 with expression of type ... is always false"-warnings with clang and W=1. Hence refactor the __BF_FIELD_CHECK() helper, and factor out __FIELD_{GET,PREP}(). The later lack the single problematic check, but are otherwise identical to FIELD_{GET,PREP}(), and are intended to be used in the fully non-const variants later. [1] commit 5c667d5a5a3ec166 ("clk: sp7021: Adjust width of _m in HWM_FIELD_PREP()") [2] commit cfd6fb45cfaf46fa ("crypto: ccree - avoid out-of-range warnings from clang") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://git.kernel.org/torvalds/c/5c667d5a5a3ec166 [1] Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24ALSA: usb-audio: #undef field_{get,prep}() before local definitionGeert Uytterhoeven
Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24soc: renesas: rz-sysc: #undef field_get() before local definitionGeert Uytterhoeven
Prepare for the advent of a globally available common field_get() macro by undefining the symbol before defining a local variant. This prevents redefinition warnings from the C preprocessor when introducing the common macro later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24pinctrl: ma35: #undef field_{get,prep}() before local definitionGeert Uytterhoeven
Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: mlx90614: #undef field_{get,prep}() before local definitionGeert Uytterhoeven
Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: dac: ad3530r: #undef field_prep() before local definitionGeert Uytterhoeven
Prepare for the advent of a globally available common field_prep() macro by undefining the symbol before defining a local variant. This prevents redefinition warnings from the C preprocessor when introducing the common macro later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>