syzbot reported a warning like below [1]:
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0
...
Call Trace:
<TASK>
invalidate_bh_lru+0x99/0x150
smp_call_function_many_cond+0xe2a/0x10c0
? generic_remap_file_range_prep+0x50/0x50
? __brelse+0xa0/0xa0
? __mutex_lock+0x21c/0x12d0
? smp_call_on_cpu+0x250/0x250
? rcu_read_lock_sched_held+0xb/0x60
? lock_release+0x587/0x810
? __brelse+0xa0/0xa0
? generic_remap_file_range_prep+0x50/0x50
on_each_cpu_cond_mask+0x3c/0x80
blkdev_flush_mapping+0x13a/0x2f0
blkdev_put_whole+0xd3/0xf0
blkdev_put+0x222/0x760
deactivate_locked_super+0x96/0x160
deactivate_super+0xda/0x100
cleanup_mnt+0x222/0x3d0
task_work_run+0x149/0x240
? task_work_cancel+0x30/0x30
do_exit+0xb29/0x2a40
? reacquire_held_locks+0x4a0/0x4a0
? do_raw_spin_lock+0x12a/0x2b0
? mm_update_next_owner+0x7c0/0x7c0
? rwlock_bug.part.0+0x90/0x90
? zap_other_threads+0x234/0x2d0
do_group_exit+0xd0/0x2a0
__x64_sys_exit_group+0x3a/0x50
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The cause of the issue is that brelse() is called on both ofibh.sbh
and ofibh.ebh by udf_find_entry() when it returns NULL. However,
brelse() is called by udf_rename(), too. So, b_count on buffer_head
becomes unbalanced.
This patch fixes the issue by not calling brelse() by udf_rename()
when udf_find_entry() returns NULL.
Link: https://syzkaller.appspot.com/bug?id=8297f45698159c6bca8a1f87dc983667c1a1c851 [1]
Reported-by: syzbot+7902cd7684bc35306224@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20221023095741.271430-1-syoshida@redhat.com
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
On Tegra186 and later, various FUSE offsets are restricted and cannot be
accessed from CCPLEX. Currently nvmem binary interface allows reading
such offsets from userspace, which results in RAS errors.
Add nvmem keepout lists to avoid any reads to restricted offsets.
Signed-off-by: Kartik <kkartik@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra FUSE block size, availability and offsets can vary from one SoC
generation to another.
Signed-off-by: Kartik <kkartik@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable generic PCM loopback driver.
On NVIDIA Jetson platforms, customers use this to loop data between
container based applications and host OS.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable RT5640 and TAS2552 audio codec drivers.
NVIDIA Jetson platforms have 40-pin GPIO expanders where custom
audio cards can be connected. Support for above codecs is typically
required. Also NVIDIA Jetson AGX Orin platform has RT5640 as onboard
codec. To support these enable driver build for these codecs.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Chromebooks don't have backlight in ACPI table, they suppose to use
native backlight in this case. Check presence of the CrOS embedded
controller ACPI device and prefer the native backlight if EC found.
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 2600bfa3df ("ACPI: video: Add acpi_video_backlight_use_native() helper")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20221024141210.67784-1-dmitry.osipenko@collabora.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For SLAB_TYPESAFE_BY_RCU caches we use call_rcu to perform empty slab
freeing. The rcu callback rcu_free_slab() calls __free_slab() that
currently includes checking the slab consistency for caches with
SLAB_CONSISTENCY_CHECKS flags. This check needs the slab->objects field
to be intact.
Because in the next patch we want to allow rcu_head in struct slab to
become larger in debug configurations and thus potentially overwrite
more fields through a union than slab_list, we want to limit the fields
used in rcu_free_slab(). Thus move the consistency checks to
free_slab() before call_rcu(). This can be done safely even for
SLAB_TYPESAFE_BY_RCU caches where accesses to the objects can still
occur after freeing them.
As a result, only the slab->slab_cache field has to be physically
separate from rcu_head for the freeing callback to work. We also save
some cycles in the rcu callback for caches with consistency checks
enabled.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
These two functions perform the following optimizations.
1. Delete the type cast of foo pointer. Void * does not need to convert
the type.
2. Delete the initialization assignment of bh variable, which is
assigned first.
Signed-off-by: Li zeming <zeming@nfschina.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20221012104235.3331-1-zeming@nfschina.com
This fixes the following sparse warning:
sparse warnings: (new ones prefixed by >>)
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: sparse: invalid assignment: |=
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: left side has type restricted __poll_t
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: right side has type int
Fixes: dd2bc5cc9e ("ipmi: ssif_bmc: Add SSIF BMC driver")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/all/202210181103.ontD9tRT-lkp@intel.com/
Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
Message-Id: <20221024075956.3312552-1-quan@os.amperecomputing.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Currently the SPI PXA2xx devices on Intel platforms can be instantiated
via the following paths:
1) as ACPI LPSS device on Haswell, Bay Trail and Cherry Trail;
2) as ACPI LPSS device on the Sky Lake and newer;
3) as PCI LPSS device on Haswell, Bay Trail and Cherry Trail;
4) as PCI LPSS device on the Sky Lake and newer;
5) as PCI device via ID table.
Each of these cases provides some platform related data differently,
i.e.:
1) via drivers/acpi/acpi_lpss.c and drivers/spi/spi-pxa2xx.c
2) via drivers/mfd/intel-lpss-acpi.c
3) via drivers/spi/spi-pxa2xx-pci.c
4) via drivers/mfd/intel-lpss-pci.c and drivers/spi/spi-pxa2xx.c
5) via drivers/spi/spi-pxa2xx-pci.c
This approach has two downsides:
a) there is no data propagated in the case #2 because we can't have
two or more drivers to match the same ACPI ID and hence some cases
are still not supported (Sky Lake and newer ACPI enabled LPSS);
b) the data is duplicated over two drivers in the cases #1 & #4 and,
besides to be a bloatware, it is error prone (e.g. Lakefield has
a wrong data right now due to missed PCI entry in the spi-pxa2xx.c).
This series fixes the downsides, and enables previously unsupported
cases.
There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically
While at it, fix some awkward indentations.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Variable loops is just being incremented and it's never used
anywhere else. The variable and the increment are redundant so
remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20221024130803.2156295-1-colin.i.king@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Variable dest_frames is just being incremented and it's never used
anywhere else. The variable and the increment are redundant so
remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20221024130415.2155860-1-colin.i.king@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The type of parameter generation has been u32 since the beginning,
however all callers pass a u64 generation, so unify the types to prevent
potential loss.
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 9ed0a72e5b ("btrfs: send: fix failures when processing inodes with
no links") tries to fix all incremental send cases of orphan inodes the
send operation will meet. However, there's still a bug causing the corner
subcase fails with a ENOENT error.
Here's shortened steps of that subcase:
$ btrfs subvolume create vol
$ touch vol/foo
$ btrfs subvolume snapshot -r vol snap1
$ btrfs subvolume snapshot -r vol snap2
# Turn the second snapshot to RW mode and delete the file while
# holding an open file descriptor on it
$ btrfs property set snap2 ro false
$ exec 73<snap2/foo
$ rm snap2/foo
# Set the second snapshot back to RO mode and do an incremental send
# with an unusal reverse order
$ btrfs property set snap2 ro true
$ btrfs send -p snap2 snap1 > /dev/null
At subvol snap1
ERROR: send ioctl failed with -2: No such file or directory
It's subcase 3 of BTRFS_COMPARE_TREE_CHANGED in the commit 9ed0a72e5b
("btrfs: send: fix failures when processing inodes with no links"). And
it's not a common case. We still have not met it in the real world.
Theoretically, this case can happen in a batch cascading snapshot backup.
In cascading backups, the receive operation in the middle may cause orphan
inodes to appear because of the open file descriptors on the snapshot files
during receiving. And if we don't do the batch snapshot backups in their
creation order, then we can have an inode, which is an orphan in the parent
snapshot but refers to a file in the send snapshot. Since an orphan inode
has no paths, the send operation will fail with a ENOENT error if it
tries to generate a path for it.
In that patch, this subcase will be treated as an inode with a new
generation. However, when the routine tries to delete the old paths in
the parent snapshot, the function process_all_refs() doesn't check whether
there are paths recorded or not before it calls the function
process_recorded_refs(). And the function process_recorded_refs() try
to get the first path in the parent snapshot in the beginning. Since it has
no paths in the parent snapshot, the send operation fails.
To fix this, we can easily put a link count check to avoid entering the
deletion routine like what we do a link count check to avoid creating a
new one. Moreover, we can assume that the function process_all_refs()
can always collect references to process because we know it has a
positive link count.
Fixes: 9ed0a72e5b ("btrfs: send: fix failures when processing inodes with no links")
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: BingJing Chang <bingjingc@synology.com>
Signed-off-by: David Sterba <dsterba@suse.com>
