The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y
git checkout FETCH_HEAD
git cherry-pick -x 1364a3c391aedfeb32aa025303ead3d7c91cdf9d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023101516-genetics-gratify-225c@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^..
Possible dependencies:
1364a3c391ae ("block: Don't invalidate pagecache for invalid falloc modes")
05bdb9965305 ("block: replace fmode_t with a block-specific type for block open flags")
5e4ea834676e ("block: remove unused fmode_t arguments from ioctl handlers")
cfb425761c79 ("block: move a few internal definitions out of blkdev.h")
99b07780814e ("rnbd-srv: replace sess->open_flags with a "bool readonly"")
658afed19cee ("mtd: block: use a simple bool to track open for write")
7d9d7d59d44b ("nvme: replace the fmode_t argument to the nvme ioctl handlers with a simple bool")
2e80089c1824 ("scsi: replace the fmode_t argument to scsi_ioctl with a simple bool")
5f4eb9d5413f ("scsi: replace the fmode_t argument to scsi_cmd_allowed with a simple bool")
81b1fb7d17c0 ("fs: remove sb->s_mode")
3f0b3e785e8b ("block: add a sb_open_mode helper")
2736e8eeb0cc ("block: use the holder as indication for exclusive opens")
2ef789288afd ("btrfs: don't pass a holder for non-exclusive blkdev_get_by_path")
29499ab060fe ("bcache: don't pass a stack address to blkdev_get_by_path")
c889d0793d9d ("swsusp: don't pass a stack address to blkdev_get_by_path")
ae220766d87c ("block: remove the unused mode argument to ->release")
d32e2bf83791 ("block: pass a gendisk to ->open")
444aa2c58cb3 ("block: pass a gendisk on bdev_check_media_change")
7ae24fcee992 ("cdrom: remove the unused mode argument to cdrom_release")
473399b50de1 ("cdrom: remove the unused mode argument to cdrom_ioctl")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1364a3c391aedfeb32aa025303ead3d7c91cdf9d Mon Sep 17 00:00:00 2001
From: Sarthak Kukreti <sarthakkukreti(a)chromium.org>
Date: Wed, 11 Oct 2023 13:12:30 -0700
Subject: [PATCH] block: Don't invalidate pagecache for invalid falloc modes
Only call truncate_bdev_range() if the fallocate mode is supported. This
fixes a bug where data in the pagecache could be invalidated if the
fallocate() was called on the block device with an invalid mode.
Fixes: 25f4c41415e5 ("block: implement (some of) fallocate for block devices")
Cc: stable(a)vger.kernel.org
Reported-by: "Darrick J. Wong" <djwong(a)kernel.org>
Signed-off-by: Sarthak Kukreti <sarthakkukreti(a)chromium.org>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org>
Signed-off-by: Mike Snitzer <snitzer(a)kernel.org>
Fixes: line? I've never seen those wrapped.
Link: https://lore.kernel.org/r/20231011201230.750105-1-sarthakkukreti@chromium.o…
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/fops.c b/block/fops.c
index acff3d5d22d4..73e42742543f 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -772,24 +772,35 @@ static long blkdev_fallocate(struct file *file, int mode, loff_t start,
filemap_invalidate_lock(inode->i_mapping);
- /* Invalidate the page cache, including dirty pages. */
- error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
- if (error)
- goto fail;
-
+ /*
+ * Invalidate the page cache, including dirty pages, for valid
+ * de-allocate mode calls to fallocate().
+ */
switch (mode) {
case FALLOC_FL_ZERO_RANGE:
case FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE:
+ error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+ if (error)
+ goto fail;
+
error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT,
len >> SECTOR_SHIFT, GFP_KERNEL,
BLKDEV_ZERO_NOUNMAP);
break;
case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE:
+ error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+ if (error)
+ goto fail;
+
error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT,
len >> SECTOR_SHIFT, GFP_KERNEL,
BLKDEV_ZERO_NOFALLBACK);
break;
case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE | FALLOC_FL_NO_HIDE_STALE:
+ error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+ if (error)
+ goto fail;
+
error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT,
len >> SECTOR_SHIFT, GFP_KERNEL);
break;
On Sun, Nov 19, 2023 at 08:12:48PM -0500, Stefan Berger wrote:
> Documentation/filesystems/ramfs-rootfs-initramfs.rst states:
>
> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
> default. To force ramfs, add "rootfstype=ramfs" to the kernel command
> line.
>
> This currently does not work when root= is provided since then
> saved_root_name contains a string and rootfstype= is ignored. Therefore,
> ramfs is currently always chosen when root= is provided.
Maybe it is a good idea to just fully remove ramfs? initramfs will
always be tmpfs. And tmpfs will always be enabled.
As well as I understand, ramfs was originally introduced, because
tmpfs seemed too big. So, it seemed to be a good idea to have small fs
(ramfs), which is always enabled.
I just did an experiment. I compiled the kernel with a very small
config. And without TMPFS and SHMEM. I got 1059440 bytes image. Then I
enabled TMPFS and SHMEM, and I got 1072976 bytes. So tmpfs adds 13536
bytes, i. e. 14k, which is a very small amount. It adds 1.3 % to the
kernel even with very small config.
So I propose to remove ramfs and always enable tmpfs. This will
decrease complexity.
Here are my configs (x86_64). Just enough to run busybox in "qemu -serial stdio"
make KCONFIG_ALLCONFIG="$FILE" allnoconfig
CONFIG_64BIT=y
CONFIG_PRINTK=y
CONFIG_SERIAL_8250=y
CONFIG_TTY=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BINFMT_ELF=y
CONFIG_EMBEDDED=y
CONFIG_EXPERT=y
CONFIG_TMPFS=n # Try to change this to "y"
CONFIG_SHMEM=n # Try to change this to "y"
Here is full docker reproducer:
# Reproducible
# 20230227 = 20230227T000000Z = 20230226T090712Z
FROM debian:sid-20230227
ENV LC_ALL C.UTF-8
RUN sed -i 's~^URIs:.*$~URIs:
http://snapshot.debian.org/archive/debian/20230226T090712Z~'
/etc/apt/sources.list.d/debian.sources
RUN echo 'Acquire::Check-Valid-Until "false";' >
/etc/apt/apt.conf.d/02acquire-check-valid-until
RUN apt-get update && apt-get install -y apt-utils whiptail
RUN apt-get update && apt-get install -y busybox-static
qemu-system-x86 make gcc git flex bison bc libelf-dev less nano cpio
RUN git clone --depth=1 -b v6.2
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
RUN : > /.config
# See Linux f8f0d06438e5c810d1e13b5f8c2fed501fe36e9c
RUN echo 'CONFIG_64BIT=y' >> /.config
RUN echo 'CONFIG_PRINTK=y' >> /.config
RUN echo 'CONFIG_SERIAL_8250=y' >> /.config
RUN echo 'CONFIG_TTY=y' >> /.config
RUN echo 'CONFIG_SERIAL_8250_CONSOLE=y' >> /.config
RUN echo 'CONFIG_BLK_DEV_INITRD=y' >> /.config
RUN echo 'CONFIG_RD_GZIP=y' >> /.config
RUN echo 'CONFIG_BINFMT_ELF=y' >> /.config
RUN echo 'CONFIG_EMBEDDED=y' >> /.config
RUN echo 'CONFIG_EXPERT=y' >> /.config
RUN echo 'CONFIG_TMPFS=y' >> /.config # try "n"
RUN echo 'CONFIG_SHMEM=y' >> /.config # try "n"
RUN cd linux && make KCONFIG_ALLCONFIG=/.config allnoconfig
RUN cd linux && make -j4
RUN mkdir /initramfs && cp /bin/busybox /initramfs && cd /initramfs &&
ln -s busybox sh && find . | cpio --create --format=newc --quiet |
gzip > /initramfs.cpio.gz
RUN echo "qemu-system-x86_64 -M microvm -m 64M -serial stdio -display
none -kernel /linux/arch/x86/boot/bzImage -initrd /initramfs.cpio.gz
-append 'quiet console=ttyS0 earlyprintk=ttyS0 rdinit=/sh' -nodefaults
-no-user-config" > /root/.bash_history
--
Askar Safin
After updating bb_free in mb_free_blocks, it is possible to return without
updating bb_fragments because the block being freed is found to have
already been freed, which leads to inconsistency between bb_free and
bb_fragments.
Since the group may be unlocked in ext4_grp_locked_error(), this can lead
to problems such as dividing by zero when calculating the average fragment
length. Hence move the update of bb_free to after the block double-free
check guarantees that the corresponding statistics are updated only after
the core block bitmap is modified.
Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit")
CC: stable(a)vger.kernel.org # 3.10
Signed-off-by: Baokun Li <libaokun1(a)huawei.com>
---
fs/ext4/mballoc.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index f6131ba514c8..1f15774971d7 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1910,11 +1910,6 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
mb_check_buddy(e4b);
mb_free_blocks_double(inode, e4b, first, count);
- this_cpu_inc(discard_pa_seq);
- e4b->bd_info->bb_free += count;
- if (first < e4b->bd_info->bb_first_free)
- e4b->bd_info->bb_first_free = first;
-
/* access memory sequentially: check left neighbour,
* clear range and then check right neighbour
*/
@@ -1941,10 +1936,16 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
} else {
mb_regenerate_buddy(e4b);
+ goto check;
}
- goto done;
+ return;
}
+ this_cpu_inc(discard_pa_seq);
+ e4b->bd_info->bb_free += count;
+ if (first < e4b->bd_info->bb_first_free)
+ e4b->bd_info->bb_first_free = first;
+
/* let's maintain fragments counter */
if (left_is_free && right_is_free)
e4b->bd_info->bb_fragments--;
@@ -1969,9 +1970,9 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
if (first <= last)
mb_buddy_mark_free(e4b, first >> 1, last >> 1);
-done:
mb_set_largest_free_order(sb, e4b->bd_info);
mb_update_avg_fragment_size(sb, e4b->bd_info);
+check:
mb_check_buddy(e4b);
}
--
2.31.1
In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.
If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.
Therefore, update move_len after each extent move to avoid the issue.
Reported-by: Wei Chen <harperchen1110(a)gmail.com>
Reported-by: xingwei lee <xrivendell7(a)gmail.com>
Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR…
Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base")
CC: stable(a)vger.kernel.org # 3.18
Signed-off-by: Baokun Li <libaokun1(a)huawei.com>
---
fs/ext4/move_extent.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 3aa57376d9c2..391efa6d4c56 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -618,6 +618,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
goto out;
o_end = o_start + len;
+ *moved_len = 0;
while (o_start < o_end) {
struct ext4_extent *ex;
ext4_lblk_t cur_blk, next_blk;
@@ -672,7 +673,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
*/
ext4_double_up_write_data_sem(orig_inode, donor_inode);
/* Swap original branches with new branches */
- move_extent_per_page(o_filp, donor_inode,
+ *moved_len += move_extent_per_page(o_filp, donor_inode,
orig_page_index, donor_page_index,
offset_in_page, cur_len,
unwritten, &ret);
@@ -682,9 +683,6 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk,
o_start += cur_len;
d_start += cur_len;
}
- *moved_len = o_start - orig_blk;
- if (*moved_len > len)
- *moved_len = len;
out:
if (*moved_len) {
--
2.31.1
Sending this again because Apple mail decided to default to HTML
mails since the last update apparently *sigh*
Hi,
> On Dec 27, 2023, at 11:30, Johan Hovold <johan(a)kernel.org> wrote:
>
> On Mon, Dec 25, 2023 at 09:26:05PM +0100, Paul Menzel wrote:
>
>> Thank you very much for the patch. I am adding Johan to Cc field.
>
> Thanks for the report. Guess I could use a break from the proverbial
> eggnog.
>
>> Am 25.12.23 um 21:01 schrieb Felix Zhang:
>>> Starting v6.5, Bluetooth does not work at all on my T2 MacBookAir9,1
>>> with the BCM4377 chip. When I boot up the computer, go into
>> Somehow a blank line snug in above.
>>> bluetoothctl, and then try to run commands like scan on, show, list,
>>> it returns "No default controller available." I have tried reloading
>>> the
>> It’d be great if you reflowed for 75 characters per line (also below).
>>> kernel module, in which the log outputs "{Added,Removed} hci0
>>> (unconfigured)." With this patch, I am able to use Bluetooth as
>>> normal
>>> without any errors regarding hci0 being unconfigured. However, an
>>> issue is still present where sometimes hci_bcm4377 will have to be
>>> reloaded in order to get bluetooth to work. I believe this was still
>>> present before the previously mentioned commit.
>>> Due to the bit HCI_QUIRK_USE_BDADDR_PROPERTY being always set in
>>> drivers/bluetooth/hci_bcm4377.c (line 2371), the chip would be left
>>> unconfigured on kernels compiled after commit 6945795bc81a
>>> ("Bluetooth:
>>> fix use-bdaddr-property quirk") due to a change in its logic. On the
>>> M1 Macs, the device would be configured in the devicetree. However,
>>> that is not the case on T2 Macs. Because the bluetooth adapter is
>>> left
>>> unconfigured, it is not usable in the operating system. In order to
>>> circumvent this issue, a flag is added to prevent the bit from being
>>> set on the BCM4377, while setting it on the other devices.
>
> The commit you tracked this down to restored the original semantics for
> HCI_QUIRK_USE_BDADDR_PROPERTY, which means that it should only be set
> for devices with an invalid address.
>
> The Broadcom BCM4377 driver has so far been setting this flag
> unconditionally which now potentially results in also valid addresses
> being marked as invalid.
>
> I've just sent a patch that makes sure to only mark invalid addresses as
> invalid:
>
> https://lore.kernel.org/lkml/20231227101003.10534-1-johan+linaro@kernel.org/
>
> Note however that the flag still needs to be set in case your device
> lacks storage for a unique device address so you cannot simply drop it
> for some device classes as you do below (unless you are certain that
> these devices will always have a valid address).
We do know that though.
BCM4377 is present on Apple’s x86 Macs and always has internal storage
for the address. If the board comes up without an address there’s nothing
much we can do because the address isn’t provided by ACPI or anything
else and setting the invalid address quirk for that situation seems appropriate.
BCM4378/4387 is present on Apple’s ARM Macs and never has internal storage.
The address is always provided by our bootloader in the device tree.
These should always unconditionally set HCI_QUIRK_USE_BDADDR_PROPERTY
just like this patch does.
Best,
Sven
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 926fe783c8a64b33997fec405cf1af3e61aed441
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023102922-handwrite-unpopular-0e1d@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 926fe783c8a64b33997fec405cf1af3e61aed441 Mon Sep 17 00:00:00 2001
From: Andrii Nakryiko <andrii(a)kernel.org>
Date: Fri, 27 Oct 2023 16:31:26 -0700
Subject: [PATCH] tracing/kprobes: Fix symbol counting logic by looking at
modules as well
Recent changes to count number of matching symbols when creating
a kprobe event failed to take into account kernel modules. As such, it
breaks kprobes on kernel module symbols, by assuming there is no match.
Fix this my calling module_kallsyms_on_each_symbol() in addition to
kallsyms_on_each_match_symbol() to perform a proper counting.
Link: https://lore.kernel.org/all/20231027233126.2073148-1-andrii@kernel.org/
Cc: Francis Laniel <flaniel(a)linux.microsoft.com>
Cc: stable(a)vger.kernel.org
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols")
Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org>
Acked-by: Song Liu <song(a)kernel.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 95c5b0668cb7..e834f149695b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -714,14 +714,30 @@ static int count_symbols(void *data, unsigned long unused)
return 0;
}
+struct sym_count_ctx {
+ unsigned int count;
+ const char *name;
+};
+
+static int count_mod_symbols(void *data, const char *name, unsigned long unused)
+{
+ struct sym_count_ctx *ctx = data;
+
+ if (strcmp(name, ctx->name) == 0)
+ ctx->count++;
+
+ return 0;
+}
+
static unsigned int number_of_same_symbols(char *func_name)
{
- unsigned int count;
+ struct sym_count_ctx ctx = { .count = 0, .name = func_name };
+
+ kallsyms_on_each_match_symbol(count_symbols, func_name, &ctx.count);
- count = 0;
- kallsyms_on_each_match_symbol(count_symbols, func_name, &count);
+ module_kallsyms_on_each_symbol(NULL, count_mod_symbols, &ctx);
- return count;
+ return ctx.count;
}
static int __trace_kprobe_create(int argc, const char *argv[])
Hacks to mask a race between HBA scan job and bridge re-configuration(s)
during hotplug.
I don't like it a bit but it something that could be done quickly
and solves problems that were reported.
Other options to discuss/possibly more invasive:
1: make sure pci_assign_unassigned_bridge_resources() doesn't reconfigure
bridge if it's not necessary.
2. make SCSI_SCAN_ASYNC job wait till hotplug is finished for all slots on
the bridge or somehow restart the job if it fails
3. any other ideas?
1st reported: https://lore.kernel.org/r/9eb669c0-d8f2-431d-a700-6da13053ae54@proxmox.com
CC: Dongli Zhang <dongli.zhang(a)oracle.com>
CC: linux-acpi(a)vger.kernel.org
CC: linux-pci(a)vger.kernel.org
CC: imammedo(a)redhat.com
CC: mst(a)redhat.com
CC: rafael(a)kernel.org
CC: lenb(a)kernel.org
CC: bhelgaas(a)google.com
CC: mika.westerberg(a)linux.intel.com
CC: boris.ostrovsky(a)oracle.com
CC: joe.jin(a)oracle.com
CC: stable(a)vger.kernel.org
CC: linux-kernel(a)vger.kernel.org
CC: Fiona Ebner <f.ebner(a)proxmox.com>
CC: Thomas Lamprecht <t.lamprecht(a)proxmox.com>
Igor Mammedov (2):
PCI: acpiphp: enable slot only if it hasn't been enabled already
PCI: acpiphp: slowdown hotplug if hotplugging multiple devices at a
time
drivers/pci/hotplug/acpiphp_glue.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--
2.39.3
Hi!
The Tegra20 requires an enabled VDE power domain during startup. As the
VDE is currently not used, it is disabled during runtime.
Since 8f0c714ad9be, there is a workaround for the "normal restart path"
which enables the VDE before doing PMC's warm reboot. This workaround is
not executed in the "emergency restart path", leading to a hang-up
during start.
This series implements and registers a new pmic-based restart handler
for boards with tps6586x. This cold reboot ensures that the VDE power
domain is enabled during startup on tegra20-based boards.
Since bae1d3a05a8b, i2c transfers are non-atomic while preemption is
disabled (which is e.g. done during panic()). This could lead to
warnings ("Voluntary context switch within RCU") in i2c-based restart
handlers during emergency restart. The state of preemption should be
detected by i2c_in_atomic_xfer_mode() to use atomic i2c xfer when
required. Beside the new system_state check, the check is the same as
the one pre v5.2.
---
v7:
- 5/5: drop mode check (suggested by Dmitry)
- Link to v6: https://lore.kernel.org/r/20230327-tegra-pmic-reboot-v6-0-af44a4cd82e9@skid…
v6:
- drop 4/6 to abort restart on unexpected failure (suggested by Dmitry)
- 4,5: fix comments in handlers (suggested by Lee)
- 4,5: same delay for both handlers (suggested by Lee)
v5:
- introduce new 3 & 4, therefore 3 -> 5, 4 -> 6
- 3: provide dev to sys_off handler, if it is known
- 4: return NOTIFY_DONE from sys_off_notify, to avoid skipping
- 5: drop Reviewed-by from Dmitry, add poweroff timeout
- 5,6: return notifier value instead of direct errno from handler
- 5,6: use new dev field instead of passing dev as cb_data
- 5,6: increase timeout values based on error observations
- 6: skip unsupported reboot modes in restart handler
---
Benjamin Bara (5):
kernel/reboot: emergency_restart: set correct system_state
i2c: core: run atomic i2c xfer when !preemptible
kernel/reboot: add device to sys_off_handler
mfd: tps6586x: use devm-based power off handler
mfd: tps6586x: register restart handler
drivers/i2c/i2c-core.h | 2 +-
drivers/mfd/tps6586x.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
include/linux/reboot.h | 3 +++
kernel/reboot.c | 4 ++++
4 files changed, 50 insertions(+), 9 deletions(-)
---
base-commit: 197b6b60ae7bc51dd0814953c562833143b292aa
change-id: 20230327-tegra-pmic-reboot-4175ff814a4b
Best regards,
--
Benjamin Bara <benjamin.bara(a)skidata.com>
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y
git checkout FETCH_HEAD
git cherry-pick -x b86f4b790c998afdbc88fe1aa55cfe89c4068726
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123006-koala-satirical-e348@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^..
Possible dependencies:
b86f4b790c99 ("dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata()")
86a3238c7b9b ("dm: change "unsigned" to "unsigned int"")
7533afa1d27b ("dm: send just one event on resize, not two")
5cd6d1d53a1f ("dm integrity: Remove bi_sector that's only used by commented debug code")
22c40e134c4c ("dm cache: Add some documentation to dm-cache-background-tracker.h")
86e4d3e8d183 ("dm-crypt: provide dma_alignment limit in io_hints")
c3adefb5baf3 ("Merge tag 'for-6.0/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b86f4b790c998afdbc88fe1aa55cfe89c4068726 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 5 Dec 2023 16:39:16 +0100
Subject: [PATCH] dm-integrity: don't modify bio's immutable bio_vec in
integrity_metadata()
__bio_for_each_segment assumes that the first struct bio_vec argument
doesn't change - it calls "bio_advance_iter_single((bio), &(iter),
(bvl).bv_len)" to advance the iterator. Unfortunately, the dm-integrity
code changes the bio_vec with "bv.bv_len -= pos". When this code path
is taken, the iterator would be out of sync and dm-integrity would
report errors. This happens if the machine is out of memory and
"kmalloc" fails.
Fix this bug by making a copy of "bv" and changing the copy instead.
Fixes: 7eada909bfd7 ("dm: add integrity target")
Cc: stable(a)vger.kernel.org # v4.12+
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Mike Snitzer <snitzer(a)kernel.org>
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index e85c688fd91e..c5f03aab4552 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -1755,11 +1755,12 @@ static void integrity_metadata(struct work_struct *w)
sectors_to_process = dio->range.n_sectors;
__bio_for_each_segment(bv, bio, iter, dio->bio_details.bi_iter) {
+ struct bio_vec bv_copy = bv;
unsigned int pos;
char *mem, *checksums_ptr;
again:
- mem = bvec_kmap_local(&bv);
+ mem = bvec_kmap_local(&bv_copy);
pos = 0;
checksums_ptr = checksums;
do {
@@ -1768,7 +1769,7 @@ static void integrity_metadata(struct work_struct *w)
sectors_to_process -= ic->sectors_per_block;
pos += ic->sectors_per_block << SECTOR_SHIFT;
sector += ic->sectors_per_block;
- } while (pos < bv.bv_len && sectors_to_process && checksums != checksums_onstack);
+ } while (pos < bv_copy.bv_len && sectors_to_process && checksums != checksums_onstack);
kunmap_local(mem);
r = dm_integrity_rw_tag(ic, checksums, &dio->metadata_block, &dio->metadata_offset,
@@ -1793,9 +1794,9 @@ static void integrity_metadata(struct work_struct *w)
if (!sectors_to_process)
break;
- if (unlikely(pos < bv.bv_len)) {
- bv.bv_offset += pos;
- bv.bv_len -= pos;
+ if (unlikely(pos < bv_copy.bv_len)) {
+ bv_copy.bv_offset += pos;
+ bv_copy.bv_len -= pos;
goto again;
}
}