| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In the merge 260f6f4fda93 ("Merge tag 'drm-next-2025-07-30' of
https://gitlab.freedesktop.org/drm/kernel"), the formatting in the
conflict resolution doesn't match what `make rustfmt` wants to make it.
Fix it up appropriately.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
As type##_replace_bits() has no side effects it is only useful if its
return value is checked. Add __must_check to enforce this usage. To have
the bits replaced in-place typep##_replace_bits() can be used instead.
Although, type_##_get_bits() and type_##_encode_bits() are harder to misuse
they are still only useful if the return value is checked. For
consistency, also add __must_check to these.
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
The definitions of GENMASK() and GENMASK_ULL() do not depend any more
on __GENMASK() and __GENMASK_ULL(). Duplicate the existing unit tests
so that __GENMASK{,ULL}() are still covered.
Because __GENMASK() and __GENMASK_ULL() do use GENMASK_INPUT_CHECK(),
drop the TEST_GENMASK_FAILURES negative tests.
It would be good to have a small assembly test case for GENMASK*() in
case somebody decides to unify both in the future. However, I lack
expertise in assembly to do so. Instead add a FIXME message to
highlight the absence of the asm unit test.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
The newly introduced GENMASK_TYPE() macro can also be used to generate
the pre-existing non-asm GENMASK*() variants.
Apply GENMASK_TYPE() to GENMASK(), GENMASK_ULL() and GENMASK_U128().
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
In an upcoming change, the non-asm GENMASK*() will all be unified to
depend on GENMASK_TYPE() which indirectly depend on sizeof(), something
not available in asm.
Instead of adding further complexity to GENMASK_TYPE() to make it work
for both asm and non asm, just split the definition of the two variants.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
Commit 94f753143028("x86/resctrl: Optimize cpumask_any_housekeeping()")
switched the only user of cpumask_nth_andnot() to other cpumask
functions, but left the function cpumask_nth_andnot() unused.
This makes function find_nth_andnot_bit() unused as well. Delete them.
Signed-off-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
|
|
The dedicated helper is more verbose and efficient comparing to
cpumask_next() followed by cpumask_first().
Signed-off-by: "Yury Norov [NVIDIA]" <yury.norov@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
|
|
The current algorithm of picking a random CPU works OK for dense online
cpumask, but if cpumask is non-dense, the distribution of picked CPUs
is skewed.
For example, on 8-CPU board with CPUs 4-7 offlined, the probability of
selecting CPU 0 is 5/8. Accordingly, cpus 1, 2 and 3 are chosen with
probability 1/8 each. The proper algorithm should pick each online CPU
with probability 1/4.
Switch it to cpumask_random(), which has better statistical
characteristics.
CC: Andrew Morton <akpm@linux-foundation.org>
Acked-by: John Stultz <jstultz@google.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: "Yury Norov [NVIDIA]" <yury.norov@gmail.com>
|
|
When looking at performance issues around directory caching, or debugging
directory lease issues, it is helpful to be able to display the current
directory leases (as we can e.g. or open files). Create pseudo-file
/proc/fs/cifs/open_dirs that displays current directory leases. Here
is sample output:
cat /proc/fs/cifs/open_dirs
Version:1
Format:
<tree id> <sess id> <persistent fid> <path>
Num entries: 3
0xce4c1c68 0x7176aa54 0xd95ef58e \dira valid file info, valid dirents
0xce4c1c68 0x7176aa54 0xd031e211 \dir5 valid file info, valid dirents
0xce4c1c68 0x7176aa54 0x96533a90 \dir1 valid file info
Reviewed-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
CSC is not accessible by VF drivers, so disable its support flag on VF
to prevent further initialization attempts.
Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support")
Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>
Cc: Alexander Usyskin <alexander.usyskin@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://lore.kernel.org/r/20250729123437.5933-1-lukasz.laguna@intel.com
(cherry picked from commit 552dbba1caaf0cb40ce961806d757615e26ec668)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Clarify that Winbond octal capable chips may be clocked at up to 166MHz,
which is their absolute maximum.
No per-operation maximum value (captured with a "0" in the table)
involves that in these cases the maximum frequency of the chip applies,
ie. the one commonly described in the DT.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
w35n0xjw chips can run at up to 166MHz in octal mode, but this is only
possible after programming various VCR registers.
Implement the new ->configure_chip() hook for this purpose.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
w25n0xjw chips have a high-speed capability hidden in a configuration
register. Once enabled, dual/quad SDR reads may be performed at a much
higher frequency.
Implement the new ->configure_chip() hook for this purpose and configure
the SR4 register accordingly.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
There is already a manufacturer hook, which is manufacturer specific but
not chip specific. We no longer have access to the actual NAND identity
at this stage so let's add a per-chip configuration hook to align the
chip configuration (if any) with the core's setting.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
These macros had initially no frequency field. When I added the "maximum
operation frequency" field, I did it initially on very common macros and
I decided to add an optional field for that (with VA_ARGS) in order to
prevent massively unreadable changes. I then added new variants in the
spinand.h header, and requested a frequency field for them by
default. Some times later, I also added maximum frequencies to other
existing variants, but I did it incorrectly, without noticing I was
wrong because the field was optional.
This mix is error prone, so let's do what I should have done since the
very beginning: add a frequency field to all READ_FROM_CACHE variants.
There is no functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
No functional change, just a style fix to align with the other
macros all around.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
In order to pick the best variant, the duration of each typical
operation is derived and then compared. These durations are based on the
maximum capabilities of the chips, which are commonly the limiting
factors. However there are other possible limiting pieces, such as the
hardware layout, EMC considerations and in some cases, the SPI controller
itself.
We need to take this into account to further refine our variant choice,
so let's use the actual frequency that will be used for the operation
instead of the theoretical maximum.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
|
|
spi_mem_calc_op_duration() is deriving the duration of a specific op, by
multiplying the number of cycles with the time a cycle will last. This
time was measured in nanoseconds, which means at high frequencies the
delta between two frequencies might not be properly catch due to
roundings.
For instance, the Winbond driver has a changing number of dummy cycles
depending on the speed, adding +8 dummy cycles when running at 166MHz
compared to 162MHz.
Both frequencies would lead to using a 6ns delay per cycle for the op
duration computation, whereas in practice there is a small difference
which actually offsets the number of extra dummy cycles on a normal page
read.
Augmenting the precision of the calculation by using picoseconds
prevents selecting a lower frequency if we can do slightly better with
another frequency involving more cycles. As a result, the above
situation leads to comparing cycles of 6024 and 6172 picoseconds which
leads to picking the most efficient variant.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Setup the pmecc data setup time as 3 clock cycles for 133MHz as recommended
by the datasheet.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Reported-by: Zixun LI <admin@hifiphile.com>
Closes: https://lore.kernel.org/all/c015bb20-6a57-4f63-8102-34b3d83e0f5b@microchip.com
Suggested-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Since commit 3d1f08b032dc ("mtd: spinand: Use the external ECC engine
logic") the spinand_write_page() function ignores the errors returned
by spinand_wait(). Change the code to propagate those up to the stack
as it was done before the offending change.
Cc: stable@vger.kernel.org
Fixes: 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The DMA map functions can fail and should be tested for errors.
Fixes: 4774fb0a48aa ("mtd: nand/fsmc: Add DMA support")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Rule: add
Link: https://lore.kernel.org/stable/20250702065806.20983-2-fourier.thomas%40gmail.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The DMA map functions can fail and should be tested for errors.
Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Some SLC NANDs like H27U4G8F2D expose a valid JEDEC ID yet they don't
support the read-retry mechanism, and fail.
Since SLC NANDs don't require read-retry, continue only if the bits per
cell is bigger than 1.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
It seems like what was intended is to test if the dma_map of the
previous line failed but the wrong dma address was passed.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Rule: add
Link: https://lore.kernel.org/stable/20250702064515.18145-2-fourier.thomas%40gmail.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Currently we attempt to get the amount of flipped bits from a hardware
location which is reset on every subpage. Instead obtain total flipped
bits stat from hardware accumulator. In addition identify the correct
maximum subpage corrected bits.
Signed-off-by: David Regan <dregan@broadcom.com>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The DMA map functions can fail and should be tested for errors.
Fixes: d8701fe890ec ("mtd: rawnand: renesas: Add new NAND controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
- GD5F1GM9UExxG (ID:c89101 3.3V)
- GD5F1GM9RExxG (ID:c88101 1.8V)
Both device feature:
- 1Gb density (1024 blocks)
- 2048-byte page size with 128-byte OOB
- 8-bit ECC requirement per 512 bytes
- Quad I/O Read support (opcode EBH)
- tPROG ≤ 300us typical page program time
Testing environment:
- Platform: Raspberry PI-5 (Linux raspberry 6.15.0-rc6-v8)
- Operations verified:
* Full device read/write/erase cycles on all blocks
* Nandspeed:
~ GD5F1GM9UE: 2.75MB/s read, 1.99MB/s write, 41.26MB/s erase
~ GD5F1GM9RE: 1.84MB/s read, 1.45MB/s write, 41.04MS/s erase
* Nandbiterrs: Both corredted 8-bit errors per 512 bytes
* Stresstest: Both 144k cycles 0 bad block growth
Full test log:
-U: https://gist.github.com/WT-886/b0f41fb50ddac3adc0020222c1f89b61
-R: https://gist.github.com/WT-886/8784e72f4632d519814928ff49225963
Datasheet:
-https://github.com/WT-886/DATASHEET/blob/main/GD5F1GM9-v1.0.pdf
Signed-off-by: Teng Wu <gigadevice2025@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Use kernel provided standard helper function to replace hard-coded
strings
Signed-off-by: Yuesong Li <liyuesong@vivo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Convert the TI TPS65910 documentation to DT schema format.
Fix incorrect I2C address in example: should be 0x2d.
TPS65910 datasheet: https://www.ti.com/lit/gpn/tps65910
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250708210448.56384-1-s-ramamoorthy@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Move some Cirrus parts so they are grouped together alphabetically in
menuconfig. Also move the Maxim 5970 out of the middle of the Cirrus
parts and put it with the other Maxim parts. No functional changes
just alphabetising.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20250709133103.3482015-1-ckeepax@opensource.cirrus.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20250704075432.3220321-1-sakari.ailus@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
In order to support Clang's stack depth tracking (for Linux's kstack_erase
feature), the coverage sanitizer needed to be disabled for __init (and
__head) section code. Doing this universally (i.e. for GCC too) created
a number of unexpected problems, ranging from changes to inlining logic
to failures to DCE code on earlier GCC versions.
Since this change is only needed for Clang, specialize it so that GCC
doesn't see the change as it isn't needed there (the GCC implementation
of kstack_erase uses a GCC plugin that removes stack depth tracking
instrumentation from __init sections during a late pass in the IR).
Successfully build and boot tested with GCC 12 and Clang 22.
Fixes: 381a38ea53d2 ("init.h: Disable sanitizer coverage for __init and __head")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202507270258.neWuiXLd-lkp@intel.com/
Reported-by: syzbot+5245cb609175fb6e8122@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6888d004.a00a0220.26d0e1.0004.GAE@google.com/
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Marco Elver <elver@google.com>
Link: https://lore.kernel.org/r/20250729234055.it.233-kees@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
When FORTIFY_SOURCE reports about a run-time buffer overread, the wrong
buffer size was being shown in the error message. (The bounds checking
was correct.)
Fixes: 3d965b33e40d ("fortify: Improve buffer overflow reporting")
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20250729231817.work.023-kees@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
Certain targets disable kstack_erase by filtering out KSTACK_ERASE_CFLAGS
rather than adding DISABLE_KSTACK_ERASE. The renaming to kstack_erase
missed the CFLAGS export, which broke those build targets (e.g. x86
vdso32).
Fixes: 76261fc7d1be ("stackleak: Split KSTACK_ERASE_CFLAGS from GCC_PLUGINS_CFLAGS")
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
Don't populate the read-only 'type' on the stack at run time,
instead make it static.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/20250714160858.1234719-1-colin.i.king@gmail.com
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The intent was to create a single column table, however the markup used
was actually for a header which led to docs build failures:
Sphinx parallel build error:
docutils.utils.SystemMessage: Documentation/virt/kvm/devices/arm-vgic-v3.rst:128: (SEVERE/4) Unexpected section title or transition.
Fix the issue by converting the attempted table to an unordered list.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/linux-next/20250729142217.0d4e64cd@canb.auug.org.au/
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Message-ID: <20250729152242.3232229-1-oliver.upton@linux.dev>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
As per the i.MX93 TRM, section 67.3.2.1 "MOD register update", the value
of the TPM counter does NOT get updated when writing MOD.MOD unless
SC.CMOD != 0. Therefore, with the current code, assuming the following
sequence:
1) pwm_disable()
2) pwm_apply_might_sleep() /* period is changed here */
3) pwm_enable()
and assuming only one channel is active, if CNT.COUNT is higher than the
MOD.MOD value written during the pwm_apply_might_sleep() call then, when
re-enabling the PWM during pwm_enable(), the counter will end up resetting
after UINT32_MAX - CNT.COUNT + MOD.MOD cycles instead of MOD.MOD cycles as
normally expected.
Fix this problem by forcing a reset of the TPM counter before MOD.MOD is
written.
Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support")
Cc: stable@vger.kernel.org
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Link: https://lore.kernel.org/r/20250728194144.22884-1-laurentiumihalcea111@gmail.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
The period generated by the hardware is
(PWMDWIDTH + 1) << CLKDIV) / freq
according to my tests with a signal analyser and also the documentation.
The current algorithm doesn't consider the `+ 1` part and so configures
slightly too high periods. The same issue exists for the duty cycle
setting. So subtract 1 from both the register values for period and
duty cycle. If period is 0, bail out, if duty_cycle is 0, just disable
the PWM which results in a constant low output.
Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/6d1fa87a76f8020bfe3171529b8e19baffceab10.1753717973.git.u.kleine-koenig@baylibre.com
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
Stop handling the clocks in pwm_mediatek_enable() and
pwm_mediatek_disable(). This is a preparing change for the next commit
that requires that clocks and the enable bit are handled separately.
Also move these two functions a bit further up in the source file to
make them usable in pwm_mediatek_config(), which is needed in the next
commit, too.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/55c94fe2917ece152ee1e998f4675642a7716f13.1753717973.git.u.kleine-koenig@baylibre.com
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
In dbAllocCtl(), read_metapage() increases the reference count of the
metapage. However, when dp->tree.budmin < 0, the function returns -EIO
without calling release_metapage() to decrease the reference count,
leading to a memory leak.
Add release_metapage(mp) before the error return to properly manage
the metapage reference count and prevent the leak.
Fixes: a5f5e4698f8abbb25fe4959814093fb5bfa1aa9d ("jfs: fix shift-out-of-bounds in dbSplit")
Signed-off-by: Zheng Yu <zheng.yu@northwestern.edu>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
|
|
When testing a series of commits that also includes changes to the Linux
tools directory, it is useless to test the changes in tools as they may
not affect the kernel itself. Doing tests on the kernel for changes that
do not affect the kernel is a waste of time.
Add a PATCHCHECK_SKIP that takes a series of shas that will be skipped
while doing the individual commit tests.
For example, the runtime verification may have a series of commits like:
$ git log --abbrev-commit --pretty=oneline fac5493251a6~1..HEAD
3d3800b4f7f4 rv: Remove rv_reactor's reference counter
3d3c376118b5 rv: Merge struct rv_reactor_def into struct rv_reactor
24cbfe18d55a rv: Merge struct rv_monitor_def into struct rv_monitor
b0c08dd5348d rv: Remove unused field in struct rv_monitor_def
58d5f0d437a8 (debiantesting-x86-64/trace/rv/core) rv: Return init error when registering monitors
560473f2e2d7 verification/rvgen: Organise Kconfig entries for nested monitors
9efcf590827c tools/dot2c: Fix generated files going over 100 column limit
1160ccaf772f tools/rv: Stop gracefully also on SIGTERM
f60227f34489 tools/rv: Do not skip idle in trace
f3735df6281e verification/rvgen: Do not generate unused variables
6fb37c2a27eb verification/rvgen: Generate each variable definition only once
8cfcf9b0e92f verification/rvgen: Support the 'next' operator
fac5493251a6 rv: Allow to configure the number of per-task monitor
Where the first commit touches the kernel followed by a series of commits
that do not, and ends with commits that do. Instead of having to add
multiple patchcheck tests to handle the gaps, just include the commits
that should not be tested:
$ git log --abbrev-commit --pretty=oneline fac5493251a6~1..HEAD |
grep -e verification -e tools/ | cut -d' ' -f1 |
while read a ; do echo -n "$a "; done
560473f2e2d7 9efcf590827c 1160ccaf772f f60227f34489 f3735df6281e 6fb37c2a27eb 8cfcf9b0e92f
Then set PATCHCHECK_SKIP to that, and those commits will be skipped.
PATCHCHECK_SKIP = 560473f2e2d7 9efcf590827c 1160ccaf772f f60227f34489 f3735df6281e 6fb37c2a27eb 8cfcf9b0e92f
Cc: John 'Warthog9' Hawley <warthog9@kernel.org>
Cc: Dhaval Giani <dhaval.giani@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/20250725112153.1dd06b84@gandalf.local.home
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Since preempt_count_add/del() are tracable functions, it is not allowed
to use preempt_disable/enable() in ftrace handlers. Without this fix,
probing on `preempt_count_add%return` will cause an infinite recursion
of fprobes.
To fix this problem, use preempt_disable/enable_notrace() in
fprobe_return().
Link: https://lore.kernel.org/all/175374642359.1471729.1054175011228386560.stgit@mhiramat.tok.corp.google.com/
Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
|
Delete fexit_noreturns.c files and migrate the cases into
tracing_failure.c files.
The result:
$ tools/testing/selftests/bpf/test_progs -t tracing_failure/fexit_noreturns
#467/4 tracing_failure/fexit_noreturns:OK
#467 tracing_failure:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20250724151454.499040-5-kafai.wan@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
The result:
$ tools/testing/selftests/bpf/test_progs -t tracing_failure/tracing_deny
#468/3 tracing_failure/tracing_deny:OK
#468 tracing_failure:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20250724151454.499040-4-kafai.wan@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Show the rejected function name when attaching tracing programs to
functions in deny list.
With this change, we know why tracing programs can't attach to functions
like __rcu_read_lock() from log.
$ ./fentry
libbpf: prog '__rcu_read_lock': BPF program load failed: -EINVAL
libbpf: prog '__rcu_read_lock': -- BEGIN PROG LOAD LOG --
Attaching tracing programs to function '__rcu_read_lock' is rejected.
Suggested-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
Acked-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20250724151454.499040-3-kafai.wan@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
With this change, we know the precise rejected function name when
attaching fexit/fmod_ret to __noreturn functions from log.
$ ./fexit
libbpf: prog 'fexit': BPF program load failed: -EINVAL
libbpf: prog 'fexit': -- BEGIN PROG LOAD LOG --
Attaching fexit/fmod_ret to __noreturn function 'do_exit' is rejected.
Suggested-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
Acked-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20250724151454.499040-2-kafai.wan@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
audit_policy() does not support any other algorithm, so the crypto_shash
abstraction provides no value. Just use the SHA-256 library API
instead, which is much simpler and easier to use.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Fan Wu <wufan@kernel.org>
|
|
DTS example in the bindings should be indented with 2- or 4-spaces and
aligned with opening '- |', so correct any differences like 3-spaces or
mixtures 2- and 4-spaces in one binding.
No functional changes here, but saves some comments during reviews of
new patches built on existing code.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
Link: https://lore.kernel.org/r/20250107131456.247610-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250725100241.120106-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
When gmin_get_config_var() calls efi.get_variable() and the EFI variable
is larger than the expected buffer size, two behaviors combine to create
a stack buffer overflow:
1. gmin_get_config_var() does not return the proper error code when
efi.get_variable() fails. It returns the stale 'ret' value from
earlier operations instead of indicating the EFI failure.
2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
*out_len to the required buffer size but writes no data to the output
buffer. However, due to bug #1, gmin_get_var_int() believes the call
succeeded.
The caller gmin_get_var_int() then performs:
- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64
- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size
- Due to bug #1, thinks call succeeded with len=required_size
- Executes val[len] = 0, writing past end of 65-byte stack buffer
This creates a stack buffer overflow when EFI variables are larger than
64 bytes. Since EFI variables can be controlled by firmware or system
configuration, this could potentially be exploited for code execution.
Fix the bug by returning proper error codes from gmin_get_config_var()
based on EFI status instead of stale 'ret' value.
The gmin_get_var_int() function is called during device initialization
for camera sensor configuration on Intel Bay Trail and Cherry Trail
platforms using the atomisp camera stack.
Reported-by: zepta <z3ptaa@gmail.com>
Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com
Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API")
Reviewed-by: Hans de Goede <hansg@kernel.org>
Link: https://lore.kernel.org/r/20250724080756.work.741-kees@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
Fix a typo that uses ',' instead of ';' for line delimiter.
Link: https://lore.kernel.org/linux-trace-kernel/175366879192.487099.5714468217360139639.stgit@mhiramat.tok.corp.google.com/
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
|
Miguel Ojeda
Ben Horgan
Vincent Mailhol
Shaopeng Tan
Yury Norov [NVIDIA]
Steve French
Lukasz Laguna
Miquel Raynal
Balamanikandan Gunasundar
Gabor Juhos
Thomas Fourier
Hector Palacios
David Regan
Teng Wu
Yuesong Li
Shree Ramamoorthy
Charles Keepax
Sakari Ailus
Kees Cook
Colin Ian King
Oliver Upton
Laurentiu Mihalcea
Uwe Kleine-König
Zheng Yu
Steven Rostedt
Masami Hiramatsu (Google)
KaFai Wan
Eric Biggers
Krzysztof Kozlowski