From: Arnd Bergmann <arnd(a)arndb.de>
An older cleanup of mine inadvertently removed geode-gx1 and geode-lx
from the list of CPUs that are known to support a working cmpxchg8b.
Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency")
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/x86/Kconfig.cpu | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2a7279d80460..42e6a40876ea 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -368,7 +368,7 @@ config X86_HAVE_PAE
config X86_CMPXCHG64
def_bool y
- depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7
+ depends on X86_HAVE_PAE || M586TSC || M586MMX || MK6 || MK7 || MGEODEGX1 || MGEODE_LX
# this should be set for all -march=.. options where the compiler
# generates cmov.
--
2.39.5
Hi Carlos,
Please pull this branch with changes for xfs against 6.13-rc1.
As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts. Please let me know if you
encounter any problems.
--D
The following changes since commit feffde684ac29a3b7aec82d2df850fbdbdee55e4:
Merge tag 'for-6.13-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux (2024-12-03 11:02:17 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/fixes-6.13_2024-12-03
for you to fetch changes up to 641a4a63154885060b7900f86bb45582f07e964b:
xfs: fix sb_spino_align checks for large fsblock sizes (2024-12-03 18:54:49 -0800)
----------------------------------------------------------------
xfs: bug fixes for 6.13 [v2 1/2]
Here are some bugfixes for 6.13 that have been accumulating since 6.12
was released.
With a bit of luck, this should all go splendidly.
Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org>
----------------------------------------------------------------
Darrick J. Wong (22):
xfs: fix off-by-one error in fsmap's end_daddr usage
xfs: metapath scrubber should use the already loaded inodes
xfs: keep quota directory inode loaded
xfs: return a 64-bit block count from xfs_btree_count_blocks
xfs: don't drop errno values when we fail to ficlone the entire range
xfs: separate healthy clearing mask during repair
xfs: set XFS_SICK_INO_SYMLINK_ZAPPED explicitly when zapping a symlink
xfs: mark metadir repair tempfiles with IRECOVERY
xfs: fix null bno_hint handling in xfs_rtallocate_rtg
xfs: fix error bailout in xfs_rtginode_create
xfs: update btree keys correctly when _insrec splits an inode root block
xfs: fix scrub tracepoints when inode-rooted btrees are involved
xfs: unlock inodes when erroring out of xfs_trans_alloc_dir
xfs: only run precommits once per transaction object
xfs: avoid nested calls to __xfs_trans_commit
xfs: don't lose solo superblock counter update transactions
xfs: don't lose solo dquot update transactions
xfs: separate dquot buffer reads from xfs_dqflush
xfs: clean up log item accesses in xfs_qm_dqflush{,_done}
xfs: attach dquot buffer to dquot log item buffer
xfs: convert quotacheck to attach dquot buffers
xfs: fix sb_spino_align checks for large fsblock sizes
fs/xfs/libxfs/xfs_btree.c | 33 +++++--
fs/xfs/libxfs/xfs_btree.h | 2 +-
fs/xfs/libxfs/xfs_ialloc_btree.c | 4 +-
fs/xfs/libxfs/xfs_rtgroup.c | 2 +-
fs/xfs/libxfs/xfs_sb.c | 11 ++-
fs/xfs/scrub/agheader.c | 6 +-
fs/xfs/scrub/agheader_repair.c | 6 +-
fs/xfs/scrub/fscounters.c | 2 +-
fs/xfs/scrub/health.c | 57 +++++++-----
fs/xfs/scrub/ialloc.c | 4 +-
fs/xfs/scrub/metapath.c | 68 ++++++--------
fs/xfs/scrub/refcount.c | 2 +-
fs/xfs/scrub/scrub.h | 6 ++
fs/xfs/scrub/symlink_repair.c | 3 +-
fs/xfs/scrub/tempfile.c | 10 +-
fs/xfs/scrub/trace.h | 2 +-
fs/xfs/xfs_bmap_util.c | 2 +-
fs/xfs/xfs_dquot.c | 195 +++++++++++++++++++++++++++++++++------
fs/xfs/xfs_dquot.h | 6 +-
fs/xfs/xfs_dquot_item.c | 51 +++++++---
fs/xfs/xfs_dquot_item.h | 7 ++
fs/xfs/xfs_file.c | 8 ++
fs/xfs/xfs_fsmap.c | 38 ++++----
fs/xfs/xfs_inode.h | 2 +-
fs/xfs/xfs_qm.c | 95 +++++++++++++------
fs/xfs/xfs_qm.h | 1 +
fs/xfs/xfs_quota.h | 7 +-
fs/xfs/xfs_rtalloc.c | 2 +-
fs/xfs/xfs_trans.c | 58 ++++++------
fs/xfs/xfs_trans_ail.c | 2 +-
fs/xfs/xfs_trans_dquot.c | 31 ++++++-
31 files changed, 495 insertions(+), 228 deletions(-)
Dear Linux community,
I am leading a project at Samsung where we utilized your kernel 5.15 in our system. Recently we faced an important kernel panic issue whose fix must be following patch:
https://lore.kernel.org/all/1946ef9f774851732eed78760a78ec40dbc6d178.166759…
The problem for us is that this patch must be available from kernel 6.1 onwards.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive…
Clear to us is that it is not integrated into K5.15 yet: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive…
On the other side we can see that this patch was already applied to Android Common Kernel android13-5.15 https://android-review.googlesource.com/q/I51dbcdc5dc536b0e69c6187b2d7ac6a2…. In particular, we can see the same implementation in the recent ACK release https://android.googlesource.com/kernel/common/+/refs/tags/android13-5.15-2… given on https://source.android.com/docs/core/architecture/kernel/gki-android13-5_15…
Do you have any plan to adjust your implementation in drivers/iommu/iommu.c in K5.15 as present in K6.1? If not, since the issue in our project is very critical for us, may I ask you kindly to trigger the sync of K5.15 and K6.1 soon?
I would appreciate highly your response and any support.
Kind regards / Mit freundlichen Grüßen
-Confidential-
Bilge Aydin
Project Manager
Phone:: +49-89-45578-1055 · Mobile:: +49-160-8855875 · Email: b.aydin(a)samsung.com
Samsung Semiconductor Europe GmbH
Einsteinstrasse 174, 81677 München, Deutschland
Jurisdiction and registered Munich / Germany, HRB Nr. 253778
Managing Director: Dermot Ryan
www.samsung.com/semiconductor/solutions/automotive
This communication (including any attachments) contains information which may be confidential and/or privileged. It is for the exclusive use of the intended recipient(s) so, if you have received this communication in error, please do not distribute, copy or use this communication or its contents but notify the sender immediately and then destroy any copies of it. Due to the nature of the Internet, the sender is unable to ensure the integrity of this message. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of the company the sender works for.
On 2024-12-09 11:27 am, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> iommu/arm-smmu: Defer probe of clients after smmu device bound
>
> to the 6.6-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> iommu-arm-smmu-defer-probe-of-clients-after-smmu-dev.patch
> and it can be found in the queue-6.6 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
FWIW the correct resolution for cherry-picking this directly is the
logically-straightforward one, as below (git is mostly just confused by
the context)
Cheers,
Robin.
----->8-----
diff --cc drivers/iommu/arm/arm-smmu/arm-smmu.c
index d6d1a2a55cc0,14618772a3d6..000000000000
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@@ -1357,10 -1435,19 +1357,21 @@@ static struct iommu_device *arm_smmu_pr
fwspec = dev_iommu_fwspec_get(dev);
if (ret)
goto out_free;
- } else {
+ } else if (fwspec && fwspec->ops == &arm_smmu_ops) {
smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
+
+ /*
+ * Defer probe if the relevant SMMU instance hasn't finished
+ * probing yet. This is a fragile hack and we'd ideally
+ * avoid this race in the core code. Until that's ironed
+ * out, however, this is the most pragmatic option on the
+ * table.
+ */
+ if (!smmu)
+ return ERR_PTR(dev_err_probe(dev, -EPROBE_DEFER,
+ "smmu dev has not bound yet\n"));
+ } else {
+ return ERR_PTR(-ENODEV);
}
ret = -EINVAL;
>
>
>
> commit 62dc845a353efab2254480df8ae7d06175627313
> Author: Pratyush Brahma <quic_pbrahma(a)quicinc.com>
> Date: Fri Oct 4 14:34:28 2024 +0530
>
> iommu/arm-smmu: Defer probe of clients after smmu device bound
>
> [ Upstream commit 229e6ee43d2a160a1592b83aad620d6027084aad ]
>
> Null pointer dereference occurs due to a race between smmu
> driver probe and client driver probe, when of_dma_configure()
> for client is called after the iommu_device_register() for smmu driver
> probe has executed but before the driver_bound() for smmu driver
> has been called.
>
> Following is how the race occurs:
>
> T1:Smmu device probe T2: Client device probe
>
> really_probe()
> arm_smmu_device_probe()
> iommu_device_register()
> really_probe()
> platform_dma_configure()
> of_dma_configure()
> of_dma_configure_id()
> of_iommu_configure()
> iommu_probe_device()
> iommu_init_device()
> arm_smmu_probe_device()
> arm_smmu_get_by_fwnode()
> driver_find_device_by_fwnode()
> driver_find_device()
> next_device()
> klist_next()
> /* null ptr
> assigned to smmu */
> /* null ptr dereference
> while smmu->streamid_mask */
> driver_bound()
> klist_add_tail()
>
> When this null smmu pointer is dereferenced later in
> arm_smmu_probe_device, the device crashes.
>
> Fix this by deferring the probe of the client device
> until the smmu device has bound to the arm smmu driver.
>
> Fixes: 021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
> Cc: stable(a)vger.kernel.org
> Co-developed-by: Prakash Gupta <quic_guptap(a)quicinc.com>
> Signed-off-by: Prakash Gupta <quic_guptap(a)quicinc.com>
> Signed-off-by: Pratyush Brahma <quic_pbrahma(a)quicinc.com>
> Link: https://lore.kernel.org/r/20241004090428.2035-1-quic_pbrahma@quicinc.com
> [will: Add comment]
> Signed-off-by: Will Deacon <will(a)kernel.org>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 8203a06014d71..b40ffa1ec2db6 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -1354,6 +1354,17 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
> goto out_free;
> } else {
> smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> +
> + /*
> + * Defer probe if the relevant SMMU instance hasn't finished
> + * probing yet. This is a fragile hack and we'd ideally
> + * avoid this race in the core code. Until that's ironed
> + * out, however, this is the most pragmatic option on the
> + * table.
> + */
> + if (!smmu)
> + return ERR_PTR(dev_err_probe(dev, -EPROBE_DEFER,
> + "smmu dev has not bound yet\n"));
> }
>
> ret = -EINVAL;
From: Jason Gerecke <jason.gerecke(a)wacom.com>
If an LED has a default_trigger set prior to being registered with
the subsystem, that trigger will be executed with a brightness value
defined by `trigger->brightness`. Our driver was not setting this
value, which was causing problems. It would cause the selected LED
to be turned off, as well as corrupt the hlv/llv values assigned to
other LEDs (since calling `wacom_led_brightness_set` will overite
these values).
This patch sets the value of `trigger->brightness` to an appropriate
value. We use `wacom_leds_brightness_get` to transform the llv/hlv
values into a brightness that is understood by the rest of the LED
subsystem.
Fixes: 822c91e72eac ("leds: trigger: Store brightness set by led_trigger_event()")
Cc: stable(a)vger.kernel.org # v6.10+
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
---
drivers/hid/wacom_sys.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 2bc45b24075c3..e60ca39ac7adc 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1370,17 +1370,6 @@ static int wacom_led_register_one(struct device *dev, struct wacom *wacom,
if (!name)
return -ENOMEM;
- if (!read_only) {
- led->trigger.name = name;
- error = devm_led_trigger_register(dev, &led->trigger);
- if (error) {
- hid_err(wacom->hdev,
- "failed to register LED trigger %s: %d\n",
- led->cdev.name, error);
- return error;
- }
- }
-
led->group = group;
led->id = id;
led->wacom = wacom;
@@ -1397,6 +1386,19 @@ static int wacom_led_register_one(struct device *dev, struct wacom *wacom,
led->cdev.brightness_set = wacom_led_readonly_brightness_set;
}
+ if (!read_only) {
+ led->trigger.name = name;
+ if (id == wacom->led.groups[group].select)
+ led->trigger.brightness = wacom_leds_brightness_get(led);
+ error = devm_led_trigger_register(dev, &led->trigger);
+ if (error) {
+ hid_err(wacom->hdev,
+ "failed to register LED trigger %s: %d\n",
+ led->cdev.name, error);
+ return error;
+ }
+ }
+
error = devm_led_classdev_register(dev, &led->cdev);
if (error) {
hid_err(wacom->hdev,
--
2.47.1
From: Haibo Chen <haibo.chen(a)nxp.com>
Dummy usually used for rx, so combine the dummy buswidth check only
for rx mode.
Find issue after commit 98d1fb94ce75 ("mtd: spi-nor: core: replace
dummy buswidth from addr to data") on imx8mn-ddr4-evk board. On this
board, rx=4, tx=1, without the upper commit, chose SNOR_CMD_READ_1_1_4,
after this commit, chose SNOR_CMD_READ(1_1_1). This is because when
dummy buswidth = 4, spi_check_buswidth_req(mem, op->dummy.buswidth, true)
do not return the expected result.
Combine the cmd.buswidth and addr.buswidth check to tx is reasonable,
but for dummy buswidth, need to check the rx mode.
Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers")
Cc: stable(a)vger.kernel.org
Signed-off-by: Haibo Chen <haibo.chen(a)nxp.com>
---
drivers/spi/spi-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index abc6792e738c..bc9f09a9e5a0 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -150,7 +150,7 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
return false;
if (op->dummy.nbytes &&
- spi_check_buswidth_req(mem, op->dummy.buswidth, true))
+ spi_check_buswidth_req(mem, op->dummy.buswidth, false))
return false;
if (op->data.dir != SPI_MEM_NO_DATA &&
--
2.34.1
There is a recent ML report that mounting a large fs backed by hardware
RAID56 controller (with one device missing) took too much time, and
systemd seems to kill the mount attempt.
In that case, the only error message is:
BTRFS error (device sdj): open_ctree failed
There is no reason on why the failure happened, making it very hard to
understand the reason.
At least output the error number (in the particular case it should be
-EINTR) to provide some clue.
Link: https://lore.kernel.org/linux-btrfs/9b9c4d2810abcca2f9f76e32220ed9a90febb23…
Reported-by: Christoph Anton Mitterer <calestyo(a)scientia.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
---
fs/btrfs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 7dfe5005129a..f6eaaf20229d 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -971,7 +971,7 @@ static int btrfs_fill_super(struct super_block *sb,
err = open_ctree(sb, fs_devices);
if (err) {
- btrfs_err(fs_info, "open_ctree failed");
+ btrfs_err(fs_info, "open_ctree failed: %d", err);
return err;
}
--
2.47.1
This patch series is to fix bugs in drivers/of/irq.c
Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com>
---
Zijun Hu (8):
of/irq: Fix wrong value of variable @len in of_irq_parse_imap_parent()
of/irq: Correct element count for array @dummy_imask in API of_irq_parse_raw()
of/irq: Fix device node refcount leakage in API of_irq_parse_raw()
of/irq: Fix using uninitialized variable @addr_len in API of_irq_parse_one()
of/irq: Fix device node refcount leakage in API of_irq_parse_one()
of/irq: Fix device node refcount leakages in of_irq_count()
of/irq: Fix device node refcount leakages in of_irq_init()
of/irq: Fix device node refcount leakage in API irq_of_parse_and_map()
drivers/of/irq.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
---
base-commit: 16ef9c9de0c48b836c5996c6e9792cb4f658c8f1
change-id: 20241208-of_irq_fix-659514bc9aa3
Best regards,
--
Zijun Hu <quic_zijuhu(a)quicinc.com>
Clippy in the upcoming Rust 1.83.0 spots a spurious empty line since the
`clippy::empty_line_after_doc_comments` warning is now enabled by default
given it is part of the `suspicious` group [1]:
error: empty line after doc comment
--> drivers/gpu/drm/drm_panic_qr.rs:931:1
|
931 | / /// They must remain valid for the duration of the function call.
932 | |
| |_
933 | #[no_mangle]
934 | / pub unsafe extern "C" fn drm_panic_qr_generate(
935 | | url: *const i8,
936 | | data: *mut u8,
937 | | data_len: usize,
... |
940 | | tmp_size: usize,
941 | | ) -> u8 {
| |_______- the comment documents this function
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#empty_line_after_…
= note: `-D clippy::empty-line-after-doc-comments` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::empty_line_after_doc_comments)]`
= help: if the empty line is unintentional remove it
Thus remove the empty line.
Cc: stable(a)vger.kernel.org
Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen")
Link: https://github.com/rust-lang/rust-clippy/pull/13091 [1]
Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org>
---
I added the Fixes and stable tags since it would be nice to keep the 6.12 LTS
Clippy-clean (since that one is the first that supports several Rust compilers).
drivers/gpu/drm/drm_panic_qr.rs | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_panic_qr.rs b/drivers/gpu/drm/drm_panic_qr.rs
index 09500cddc009..ef2d490965ba 100644
--- a/drivers/gpu/drm/drm_panic_qr.rs
+++ b/drivers/gpu/drm/drm_panic_qr.rs
@@ -929,7 +929,6 @@ fn draw_all(&mut self, data: impl Iterator<Item = u8>) {
/// * `tmp` must be valid for reading and writing for `tmp_size` bytes.
///
/// They must remain valid for the duration of the function call.
-
#[no_mangle]
pub unsafe extern "C" fn drm_panic_qr_generate(
url: *const i8,
base-commit: b7ed2b6f4e8d7f64649795e76ee9db67300de8eb
--
2.47.0