During suspend and resume, the channel state needs to be saved locally.
Otherwise, the endpoint may access the channels while they were being
suspended and causing access violations.
Fix it by saving the channel state locally during suspend and resume.
Cc: <stable(a)vger.kernel.org> # 5.19
Fixes: e4b7b5f0f30a ("bus: mhi: ep: Add support for suspending and resuming channels")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/bus/mhi/ep/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index 2362fcc8b32c..bcaaba97ef63 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -1122,6 +1122,7 @@ void mhi_ep_suspend_channels(struct mhi_ep_cntrl *mhi_cntrl)
dev_dbg(&mhi_chan->mhi_dev->dev, "Suspending channel\n");
/* Set channel state to SUSPENDED */
+ mhi_chan->state = MHI_CH_STATE_SUSPENDED;
tmp &= ~CHAN_CTX_CHSTATE_MASK;
tmp |= FIELD_PREP(CHAN_CTX_CHSTATE_MASK, MHI_CH_STATE_SUSPENDED);
mhi_cntrl->ch_ctx_cache[i].chcfg = cpu_to_le32(tmp);
@@ -1151,6 +1152,7 @@ void mhi_ep_resume_channels(struct mhi_ep_cntrl *mhi_cntrl)
dev_dbg(&mhi_chan->mhi_dev->dev, "Resuming channel\n");
/* Set channel state to RUNNING */
+ mhi_chan->state = MHI_CH_STATE_RUNNING;
tmp &= ~CHAN_CTX_CHSTATE_MASK;
tmp |= FIELD_PREP(CHAN_CTX_CHSTATE_MASK, MHI_CH_STATE_RUNNING);
mhi_cntrl->ch_ctx_cache[i].chcfg = cpu_to_le32(tmp);
--
2.25.1
There is a good chance that while the channel ring gets processed, the STOP
or RESET command for the channel might be received from the MHI host. In
those cases, the entire channel ring processing needs to be protected by
chan->lock to prevent the race where the corresponding channel ring might
be reset.
While at it, let's also add a sanity check to make sure that the ring is
started before processing it. Because, if the STOP/RESET command gets
processed while mhi_ep_ch_ring_worker() waited for chan->lock, the ring
would've been reset.
Cc: <stable(a)vger.kernel.org> # 5.19
Fixes: 03c0bb8ec983 ("bus: mhi: ep: Add support for processing channel rings")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/bus/mhi/ep/main.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index 0bce6610ebf1..2362fcc8b32c 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -730,24 +730,37 @@ static void mhi_ep_ch_ring_worker(struct work_struct *work)
list_del(&itr->node);
ring = itr->ring;
+ chan = &mhi_cntrl->mhi_chan[ring->ch_id];
+ mutex_lock(&chan->lock);
+
+ /*
+ * The ring could've stopped while we waited to grab the (chan->lock), so do
+ * a sanity check before going further.
+ */
+ if (!ring->started) {
+ mutex_unlock(&chan->lock);
+ kfree(itr);
+ continue;
+ }
+
/* Update the write offset for the ring */
ret = mhi_ep_update_wr_offset(ring);
if (ret) {
dev_err(dev, "Error updating write offset for ring\n");
+ mutex_unlock(&chan->lock);
kfree(itr);
continue;
}
/* Sanity check to make sure there are elements in the ring */
if (ring->rd_offset == ring->wr_offset) {
+ mutex_unlock(&chan->lock);
kfree(itr);
continue;
}
el = &ring->ring_cache[ring->rd_offset];
- chan = &mhi_cntrl->mhi_chan[ring->ch_id];
- mutex_lock(&chan->lock);
dev_dbg(dev, "Processing the ring for channel (%u)\n", ring->ch_id);
ret = mhi_ep_process_ch_ring(ring, el);
if (ret) {
--
2.25.1
> On Jan 5, 2023, at 6:43 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
>
> On Wed, Jan 04, 2023 at 04:56:31PM -0500, Joel Fernandes wrote:
>>
>>
>>>> On Jan 4, 2023, at 12:29 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
>>>
>>> On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
>>>>> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.10.162 release.
>>>>> There are 63 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Thu, 05 Jan 2023 08:12:47 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.162-r…
>>>>> or in the git tree and branch at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>
>>>> Testing fails. Could you please pick these 2 up?
>>>> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
>>>> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
>>>
>>> That is not a regression from 5.10.161, right?
>>
>> Yes it is not.
>>
>>> This release is only for
>>> the io_uring stuff to make sure that backport was done correctly.
>>>
>>> The current "to apply" queue for the stable trees is very large right
>>> now due to everyone waiting to get tiny things into -rc1 instead of
>>> before then, so the above two are still not yet queued up, sorry.
>>
>> Sure not a problem, I can resend again later if it is still not queued.
>
> You should have already received the email notices saying they were
> queued :)
I happen to take messages from Skynet with a grain of salt ;-).
But thank you for the automated notification!
- Joel
From: Francesco Dolcini <francesco.dolcini(a)toradex.com>
Add a fallback mechanism to handle the case in which #size-cells is set
to <0>. According to the DT binding the nand controller node should have
set it to 0 and this is not compatible with the legacy way of
specifying partitions directly as child nodes of the nand-controller node.
This fixes a boot failure on colibri-imx7 and potentially other boards.
Cc: stable(a)vger.kernel.org
Fixes: 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells")
Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/
Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com>
---
drivers/mtd/parsers/ofpart_core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/parsers/ofpart_core.c b/drivers/mtd/parsers/ofpart_core.c
index 192190c42fc8..aa3b7fa61e50 100644
--- a/drivers/mtd/parsers/ofpart_core.c
+++ b/drivers/mtd/parsers/ofpart_core.c
@@ -122,6 +122,17 @@ static int parse_fixed_partitions(struct mtd_info *master,
a_cells = of_n_addr_cells(pp);
s_cells = of_n_size_cells(pp);
+ if (s_cells == 0) {
+ /*
+ * Use #size-cells = <1> for backward compatibility
+ * in case #size-cells is set to <0> and firmware adds
+ * OF partitions without setting it.
+ */
+ pr_warn_once("%s: ofpart partition %pOF (%pOF) #size-cells is <0>, using <1> for backward compatibility.\n",
+ master->name, pp,
+ mtd_node);
+ s_cells = 1;
+ }
if (len / 4 != a_cells + s_cells) {
pr_debug("%s: ofpart partition %pOF (%pOF) error parsing reg property.\n",
master->name, pp,
--
2.25.1
Saludo de la Sra. Angela Larsson,
Mi amado, Dios me ha tocado entregarte este dinero considerando mi
último deseo, y también debes saber que mi contacto contigo es por
gracia especial de Dios, por favor, comprende que no me estás ayudando
a mí, sino que estás trabajando para Dios. creador del cielo y de la
tierra. Y de nuevo viuda sufriendo de una larga enfermedad.
Actualmente estoy ingresado en un hospital de ligustro en el país,
tengo algunos fondos que heredé de mi difunto y amado esposo, el Sr.
Larsson Wisdom, la suma de ($ 5,500,000.00USD) que depositó en el
banco aquí y necesito un muy honesto y temeroso de Dios cristiano que
puede usar estos fondos para la obra de Dios. Quiero que tú y la
iglesia siempre oren por mí porque el señor es mi pastor. Mi felicidad
es que viví una vida de cristiano digno y quien quiera servir al Señor
debe servirlo en espíritu y Verdad.
Por favor, si pudiera utilizar estos fondos para la obra del Señor,
tenga la amabilidad de responderme. No olvide orar siempre por mí
porque toda mi esperanza de sobrevivir está en Dios, el creador, que
tiene la muerte y la vida.
Espero recibir tu respuesta.
Sra. Ángela Larsson.
From: Jan Kara <jack(a)suse.cz>
commit a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd upstream.
When manipulating xattr blocks, we can deadlock infinitely looping
inside ext4_xattr_block_set() where we constantly keep finding xattr
block for reuse in mbcache but we are unable to reuse it because its
reference count is too big. This happens because cache entry for the
xattr block is marked as reusable (e_reusable set) although its
reference count is too big. When this inconsistency happens, this
inconsistent state is kept indefinitely and so ext4_xattr_block_set()
keeps retrying indefinitely.
The inconsistent state is caused by non-atomic update of e_reusable bit.
e_reusable is part of a bitfield and e_reusable update can race with
update of e_referenced bit in the same bitfield resulting in loss of one
of the updates. Fix the problem by using atomic bitops instead.
This bug has been around for many years, but it became *much* easier
to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr
blocks").
A special backport to 5.15 was necessary due to changes to reference counting.
Cc: stable(a)vger.kernel.org # 5.15
Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
Reported-and-tested-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
Reported-by: Thilo Fromm <t-lo(a)linux.microsoft.com>
Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.micros…
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
---
fs/ext4/xattr.c | 4 ++--
fs/mbcache.c | 14 ++++++++------
include/linux/mbcache.h | 9 +++++++--
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 533216e80fa2..22700812a4d3 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1281,7 +1281,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
ce = mb_cache_entry_get(ea_block_cache, hash,
bh->b_blocknr);
if (ce) {
- ce->e_reusable = 1;
+ set_bit(MBE_REUSABLE_B, &ce->e_flags);
mb_cache_entry_put(ea_block_cache, ce);
}
}
@@ -2042,7 +2042,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
}
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
if (ref == EXT4_XATTR_REFCOUNT_MAX)
- ce->e_reusable = 0;
+ clear_bit(MBE_REUSABLE_B, &ce->e_flags);
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
ext4_xattr_block_csum_set(inode, new_bh);
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 2010bc80a3f2..ac07b50ea3df 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -94,8 +94,9 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
atomic_set(&entry->e_refcnt, 1);
entry->e_key = key;
entry->e_value = value;
- entry->e_reusable = reusable;
- entry->e_referenced = 0;
+ entry->e_flags = 0;
+ if (reusable)
+ set_bit(MBE_REUSABLE_B, &entry->e_flags);
head = mb_cache_entry_head(cache, key);
hlist_bl_lock(head);
hlist_bl_for_each_entry(dup, dup_node, head, e_hash_list) {
@@ -155,7 +156,8 @@ static struct mb_cache_entry *__entry_find(struct mb_cache *cache,
while (node) {
entry = hlist_bl_entry(node, struct mb_cache_entry,
e_hash_list);
- if (entry->e_key == key && entry->e_reusable) {
+ if (entry->e_key == key &&
+ test_bit(MBE_REUSABLE_B, &entry->e_flags)) {
atomic_inc(&entry->e_refcnt);
goto out;
}
@@ -325,7 +327,7 @@ EXPORT_SYMBOL(mb_cache_entry_delete_or_get);
void mb_cache_entry_touch(struct mb_cache *cache,
struct mb_cache_entry *entry)
{
- entry->e_referenced = 1;
+ set_bit(MBE_REFERENCED_B, &entry->e_flags);
}
EXPORT_SYMBOL(mb_cache_entry_touch);
@@ -350,8 +352,8 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
while (nr_to_scan-- && !list_empty(&cache->c_list)) {
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
- if (entry->e_referenced || atomic_read(&entry->e_refcnt) > 2) {
- entry->e_referenced = 0;
+ if (test_bit(MBE_REFERENCED_B, &entry->e_flags) || atomic_read(&entry->e_refcnt) > 2) {
+ clear_bit(MBE_REFERENCED_B, &entry->e_flags);
list_move_tail(&entry->e_list, &cache->c_list);
continue;
}
diff --git a/include/linux/mbcache.h b/include/linux/mbcache.h
index 8eca7f25c432..62927f7e2588 100644
--- a/include/linux/mbcache.h
+++ b/include/linux/mbcache.h
@@ -10,6 +10,12 @@
struct mb_cache;
+/* Cache entry flags */
+enum {
+ MBE_REFERENCED_B = 0,
+ MBE_REUSABLE_B
+};
+
struct mb_cache_entry {
/* List of entries in cache - protected by cache->c_list_lock */
struct list_head e_list;
@@ -18,8 +24,7 @@ struct mb_cache_entry {
atomic_t e_refcnt;
/* Key in hash - stable during lifetime of the entry */
u32 e_key;
- u32 e_referenced:1;
- u32 e_reusable:1;
+ unsigned long e_flags;
/* User provided value - stable during lifetime of the entry */
u64 e_value;
};
--
2.25.1
The patch below does not apply to the 5.15-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>.
Possible dependencies:
a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
307af6c87937 ("mbcache: automatically delete entries from cache on freeing")
65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
fd48e9acdf26 ("ext4: unindent codeblock in ext4_xattr_block_set()")
6bc0d63dad7f ("ext4: remove EA inode entry from mbcache on inode eviction")
3dc96bba65f5 ("mbcache: add functions to delete entry if unused")
58318914186c ("mbcache: don't reclaim used entries")
4efd9f0d120c ("ext4: use kmemdup() to replace kmalloc + memcpy")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd Mon Sep 17 00:00:00 2001
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 23 Nov 2022 20:39:50 +0100
Subject: [PATCH] ext4: fix deadlock due to mbcache entry corruption
When manipulating xattr blocks, we can deadlock infinitely looping
inside ext4_xattr_block_set() where we constantly keep finding xattr
block for reuse in mbcache but we are unable to reuse it because its
reference count is too big. This happens because cache entry for the
xattr block is marked as reusable (e_reusable set) although its
reference count is too big. When this inconsistency happens, this
inconsistent state is kept indefinitely and so ext4_xattr_block_set()
keeps retrying indefinitely.
The inconsistent state is caused by non-atomic update of e_reusable bit.
e_reusable is part of a bitfield and e_reusable update can race with
update of e_referenced bit in the same bitfield resulting in loss of one
of the updates. Fix the problem by using atomic bitops instead.
This bug has been around for many years, but it became *much* easier
to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr
blocks").
Cc: stable(a)vger.kernel.org
Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
Reported-and-tested-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
Reported-by: Thilo Fromm <t-lo(a)linux.microsoft.com>
Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.micros…
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 4d1c701f0eec..6bdd502527f8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1281,7 +1281,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
ce = mb_cache_entry_get(ea_block_cache, hash,
bh->b_blocknr);
if (ce) {
- ce->e_reusable = 1;
+ set_bit(MBE_REUSABLE_B, &ce->e_flags);
mb_cache_entry_put(ea_block_cache, ce);
}
}
@@ -2043,7 +2043,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
}
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
if (ref == EXT4_XATTR_REFCOUNT_MAX)
- ce->e_reusable = 0;
+ clear_bit(MBE_REUSABLE_B, &ce->e_flags);
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
ext4_xattr_block_csum_set(inode, new_bh);
diff --git a/fs/mbcache.c b/fs/mbcache.c
index e272ad738faf..2a4b8b549e93 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -100,8 +100,9 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
atomic_set(&entry->e_refcnt, 2);
entry->e_key = key;
entry->e_value = value;
- entry->e_reusable = reusable;
- entry->e_referenced = 0;
+ entry->e_flags = 0;
+ if (reusable)
+ set_bit(MBE_REUSABLE_B, &entry->e_flags);
head = mb_cache_entry_head(cache, key);
hlist_bl_lock(head);
hlist_bl_for_each_entry(dup, dup_node, head, e_hash_list) {
@@ -165,7 +166,8 @@ static struct mb_cache_entry *__entry_find(struct mb_cache *cache,
while (node) {
entry = hlist_bl_entry(node, struct mb_cache_entry,
e_hash_list);
- if (entry->e_key == key && entry->e_reusable &&
+ if (entry->e_key == key &&
+ test_bit(MBE_REUSABLE_B, &entry->e_flags) &&
atomic_inc_not_zero(&entry->e_refcnt))
goto out;
node = node->next;
@@ -284,7 +286,7 @@ EXPORT_SYMBOL(mb_cache_entry_delete_or_get);
void mb_cache_entry_touch(struct mb_cache *cache,
struct mb_cache_entry *entry)
{
- entry->e_referenced = 1;
+ set_bit(MBE_REFERENCED_B, &entry->e_flags);
}
EXPORT_SYMBOL(mb_cache_entry_touch);
@@ -309,9 +311,9 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
/* Drop initial hash reference if there is no user */
- if (entry->e_referenced ||
+ if (test_bit(MBE_REFERENCED_B, &entry->e_flags) ||
atomic_cmpxchg(&entry->e_refcnt, 1, 0) != 1) {
- entry->e_referenced = 0;
+ clear_bit(MBE_REFERENCED_B, &entry->e_flags);
list_move_tail(&entry->e_list, &cache->c_list);
continue;
}
diff --git a/include/linux/mbcache.h b/include/linux/mbcache.h
index 2da63fd7b98f..97e64184767d 100644
--- a/include/linux/mbcache.h
+++ b/include/linux/mbcache.h
@@ -10,6 +10,12 @@
struct mb_cache;
+/* Cache entry flags */
+enum {
+ MBE_REFERENCED_B = 0,
+ MBE_REUSABLE_B
+};
+
struct mb_cache_entry {
/* List of entries in cache - protected by cache->c_list_lock */
struct list_head e_list;
@@ -26,8 +32,7 @@ struct mb_cache_entry {
atomic_t e_refcnt;
/* Key in hash - stable during lifetime of the entry */
u32 e_key;
- u32 e_referenced:1;
- u32 e_reusable:1;
+ unsigned long e_flags;
/* User provided value - stable during lifetime of the entry */
u64 e_value;
};
When wait_event_interruptible() has been interrupted by a signal the
tx.state value might not be ISOTP_IDLE. Force the state machines
into idle state to inhibit the timer handlers to continue working.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Cc: stable(a)vger.kernel.org
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
---
V2: fixed checkpatch warnings m(
V3: added 'Fixes:' tag
net/can/isotp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index 0476a506d4a4..fc81d77724a1 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -1150,10 +1150,14 @@ static int isotp_release(struct socket *sock)
net = sock_net(sk);
/* wait for complete transmission of current pdu */
wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
+ /* force state machines to be idle also when a signal occurred */
+ so->tx.state = ISOTP_IDLE;
+ so->rx.state = ISOTP_IDLE;
+
spin_lock(&isotp_notifier_lock);
while (isotp_busy_notifier == so) {
spin_unlock(&isotp_notifier_lock);
schedule_timeout_uninterruptible(1);
spin_lock(&isotp_notifier_lock);
--
2.30.2
The patch below does not apply to the 5.15-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>.
Possible dependencies:
ff4837f7fe59 ("tracing: Fix issue of missing one synthetic field")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ff4837f7fe59ff018eca4705a70eca5e0b486b97 Mon Sep 17 00:00:00 2001
From: Zheng Yejian <zhengyejian1(a)huawei.com>
Date: Wed, 7 Dec 2022 17:15:57 +0800
Subject: [PATCH] tracing: Fix issue of missing one synthetic field
The maximum number of synthetic fields supported is defined as
SYNTH_FIELDS_MAX which value currently is 64, but it actually fails
when try to generate a synthetic event with 64 fields by executing like:
# echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
int v63; int v64" >> /sys/kernel/tracing/synthetic_events
Correct the field counting to fix it.
Link: https://lore.kernel.org/linux-trace-kernel/20221207091557.3137904-1-zhengye…
Cc: <mhiramat(a)kernel.org>
Cc: <zanussi(a)kernel.org>
Cc: stable(a)vger.kernel.org
Fixes: c9e759b1e845 ("tracing: Rework synthetic event command parsing")
Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com>
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
index c3b582d19b62..67592eed0be8 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -1282,12 +1282,12 @@ static int __create_synth_event(const char *name, const char *raw_fields)
goto err_free_arg;
}
- fields[n_fields++] = field;
if (n_fields == SYNTH_FIELDS_MAX) {
synth_err(SYNTH_ERR_TOO_MANY_FIELDS, 0);
ret = -EINVAL;
goto err_free_arg;
}
+ fields[n_fields++] = field;
n_fields_this_loop++;
}
The patch below does not apply to the 5.15-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>.
Possible dependencies:
2820e5d0820a ("block: mq-deadline: Fix dd_finish_request() for zoned devices")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2820e5d0820ac4daedff1272616a53d9c7682fd2 Mon Sep 17 00:00:00 2001
From: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Date: Thu, 24 Nov 2022 11:12:07 +0900
Subject: [PATCH] block: mq-deadline: Fix dd_finish_request() for zoned devices
dd_finish_request() tests if the per prio fifo_list is not empty to
determine if request dispatching must be restarted for handling blocked
write requests to zoned devices with a call to
blk_mq_sched_mark_restart_hctx(). While simple, this implementation has
2 problems:
1) Only the priority level of the completed request is considered.
However, writes to a zone may be blocked due to other writes to the
same zone using a different priority level. While this is unlikely to
happen in practice, as writing a zone with different IO priorirites
does not make sense, nothing in the code prevents this from
happening.
2) The use of list_empty() is dangerous as dd_finish_request() does not
take dd->lock and may run concurrently with the insert and dispatch
code.
Fix these 2 problems by testing the write fifo list of all priority
levels using the new helper dd_has_write_work(), and by testing each
fifo list using list_empty_careful().
Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com>
Link: https://lore.kernel.org/r/20221124021208.242541-2-damien.lemoal@opensource.…
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/mq-deadline.c b/block/mq-deadline.c
index 5639921dfa92..36374481cb87 100644
--- a/block/mq-deadline.c
+++ b/block/mq-deadline.c
@@ -789,6 +789,18 @@ static void dd_prepare_request(struct request *rq)
rq->elv.priv[0] = NULL;
}
+static bool dd_has_write_work(struct blk_mq_hw_ctx *hctx)
+{
+ struct deadline_data *dd = hctx->queue->elevator->elevator_data;
+ enum dd_prio p;
+
+ for (p = 0; p <= DD_PRIO_MAX; p++)
+ if (!list_empty_careful(&dd->per_prio[p].fifo_list[DD_WRITE]))
+ return true;
+
+ return false;
+}
+
/*
* Callback from inside blk_mq_free_request().
*
@@ -828,9 +840,10 @@ static void dd_finish_request(struct request *rq)
spin_lock_irqsave(&dd->zone_lock, flags);
blk_req_zone_write_unlock(rq);
- if (!list_empty(&per_prio->fifo_list[DD_WRITE]))
- blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
spin_unlock_irqrestore(&dd->zone_lock, flags);
+
+ if (dd_has_write_work(rq->mq_hctx))
+ blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
}
}
Following kernel BUG noticed on qemu_arm and BeagleBoard x15 while running
selftests: netfilter: nft_fib.sh test case.
This is always reproducible on stable-rc 6.1 and 6.0 [1].
Build, config, vmlinux and System.map links provided.
unwind: Unknown symbol address bf02e1c8
BUG: spinlock recursion on CPU#0, modprobe/762
lock: unwind_lock+0x0/0x24, .magic: dead4ead, .owner:
modprobe/762, .owner_cpu: 0
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
[ 49.898742] kselftest: Running tests in netfilter
TAP version 13
1..14
# selftests: netfilter: nft_fib.sh
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"nsrouter-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"ns1-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"ns2-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
[ 55.484253] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 55.569226] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 55.670281] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 55.674377] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
# PASS: fib expression did not cause unwanted packet drops
# Error: Could not process rule: No such file or directory
# flush table inet filter
# ^^^^^^
# /dev/stdin:4:20-38: Error: Could not process rule: No such file or directory
# ip daddr 1.1.1.1 fib saddr . iif oif missing counter drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:5:23-41: Error: Could not process rule: No such file or directory
# ip6 daddr 1c3::c01d fib saddr . iif oif missing counter drop
# ^^^^^^^^^^^^^^^^^^^
# Error: No such file or directory
# list table inet filter
# ^^^^^^
# Netns nsrouter-L7wUUW2r fib counter doesn't match expected packet
count of 0 for 1.1.1.1
# Error: No such file or directory
# list table inet filter
# ^^^^^^
not ok 1 selftests: netfilter: nft_fib.sh # exit=1
# selftests: netfilter: nft_nat.sh
[ 70.428411] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 70.961660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 70.965547] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[ 71.027372] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:6:34-42: Error: Could not process rule: No such file or directory
# ip saddr 10.0.2.2 counter name \"ns0insl\"
# ^^^^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_counters 3
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns1-0Hc1Kf82 has unexpected value
(expected packets 1 bytes 104) at check_counters 4
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns0-0Hc1Kf82 has unexpected value
(expected packets 0 bytes 0) at check_ns0_counters3
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1in
# ^^^^^^
# ERROR: ns1in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns1in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1in6
# ^^^^^^
# ERROR: ns1 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns1
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1out
# ^^^^^^
# ERROR: ns1out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns1out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1out6
# ^^^^^^
# ERROR: ns1 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns1
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_counters 3
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns2-0Hc1Kf82 has unexpected value
(expected packets 1 bytes 104) at check_counters 4
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns0-0Hc1Kf82 has unexpected value
(expected packets 0 bytes 0) at check_ns0_counters3
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2in
# ^^^^^^
# ERROR: ns2in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns2in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2in6
# ^^^^^^
# ERROR: ns2 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns2
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2out
# ^^^^^^
# ERROR: ns2out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns2out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2out6
# ^^^^^^
# ERROR: ns2 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns2
# ^^^^^^
[ 92.417219] unwind: Unknown symbol address bf02e1c8
[ 92.417611] BUG: spinlock recursion on CPU#0, modprobe/762
[ 92.417622] lock: unwind_lock+0x0/0x24, .magic: dead4ead, .owner:
modprobe/762, .owner_cpu: 0
[ 92.417649] CPU: 0 PID: 762 Comm: modprobe Not tainted 6.1.4-rc1 #1
[ 92.417657] Hardware name: Generic DT based system
[ 92.417662] unwind_backtrace from show_stack+0x18/0x1c
[ 92.417682] show_stack from dump_stack_lvl+0x58/0x70
[ 92.417703] dump_stack_lvl from do_raw_spin_lock+0xcc/0xf0
[ 92.417719] do_raw_spin_lock from _raw_spin_lock_irqsave+0x60/0x74
[ 92.417740] _raw_spin_lock_irqsave from unwind_frame+0x470/0x840
[ 92.417760] unwind_frame from __save_stack_trace+0xa4/0xe0
[ 92.417775] __save_stack_trace from stack_trace_save+0x40/0x60
[ 92.417792] stack_trace_save from save_trace+0x50/0x410
[ 92.417805] save_trace from __lock_acquire+0x16dc/0x2a8c
[ 92.417815] __lock_acquire from lock_acquire+0x110/0x364
[ 92.417826] lock_acquire from _raw_spin_lock_irqsave+0x58/0x74
[ 92.417847] _raw_spin_lock_irqsave from down_trylock+0x14/0x34
[ 92.417872] down_trylock from __down_trylock_console_sem+0x30/0x98
[ 92.417894] __down_trylock_console_sem from vprintk_emit+0x98/0x35c
[ 92.417914] vprintk_emit from vprintk_default+0x28/0x30
[ 92.417933] vprintk_default from _printk+0x30/0x54
[ 92.417954] _printk from search_index+0xcc/0xd8
[ 92.417974] search_index from unwind_frame+0x630/0x840
[ 92.417989] unwind_frame from __save_stack_trace+0xa4/0xe0
[ 92.417999] __save_stack_trace from stack_trace_save+0x40/0x60
[ 92.418021] stack_trace_save from set_track_prepare+0x2c/0x58
[ 92.418044] set_track_prepare from free_debug_processing+0x380/0x61c
[ 92.418063] free_debug_processing from kmem_cache_free+0x270/0x45c
[ 92.418077] kmem_cache_free from rcu_core+0x3c8/0x1140
[ 92.418093] rcu_core from __do_softirq+0x130/0x538
[ 92.418109] __do_softirq from __irq_exit_rcu+0x14c/0x170
[ 92.418122] __irq_exit_rcu from irq_exit+0x10/0x30
[ 92.418132] irq_exit from call_with_stack+0x18/0x20
[ 92.418146] call_with_stack from __irq_svc+0x9c/0xb8
[ 92.418160] Exception stack(0xf8f59cc0 to 0xf8f59d08)
[ 92.418171] 9cc0: c634b108 f8f9e940 0000021c 00034068 00000028
c634b100 00000d01 f8fa7040
[ 92.418180] 9ce0: c634b108 c634b100 c25e54d0 ffffffbf bf02e020
f8f59d10 bf02e304 bf02e1c8
[ 92.418187] 9d00: 200d0113 ffffffff
[ 92.418191] __irq_svc from sha1_ce_transform+0x188/0x1bc [sha1_arm_ce]
[ 118.427094] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 118.430231] (detected by 1, t=2602 jiffies, g=13749, q=213 ncpus=2)
[ 118.433459] rcu: All QSes seen, last rcu_sched kthread activity
2602 (-18164--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 118.438830] rcu: rcu_sched kthread timer wakeup didn't happen for
2601 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 118.444321] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 118.447958] rcu: rcu_sched kthread starved for 2602 jiffies! g13749
f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 118.453202] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 118.457584] rcu: RCU grace-period kthread stack dump:
[ 118.460282] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 118.464277] __schedule from schedule+0x60/0x100
[ 118.466571] schedule from schedule_timeout+0xbc/0x20c
[ 118.469192] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 118.472165] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 118.475096] rcu_gp_kthread from kthread+0xfc/0x11c
[ 118.477675] kthread from ret_from_fork+0x14/0x2c
[ 118.479938] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 118.482620] 1fa0: 00000000
00000000 00000000 00000000
[ 118.486777] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 118.490778] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 118.494227] rcu: Stack dump where RCU GP kthread last ran:
[ 118.496920] Sending NMI from CPU 1 to CPUs 0:
[ 196.487089] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 196.490069] (detected by 1, t=10408 jiffies, g=13749, q=291 ncpus=2)
[ 196.493125] rcu: All QSes seen, last rcu_sched kthread activity
10408 (-10358--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 196.498543] rcu: rcu_sched kthread timer wakeup didn't happen for
10407 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 196.503820] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 196.507068] rcu: rcu_sched kthread starved for 10408 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 196.511845] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 196.515998] rcu: RCU grace-period kthread stack dump:
[ 196.518341] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 196.522212] __schedule from schedule+0x60/0x100
[ 196.524392] schedule from schedule_timeout+0xbc/0x20c
[ 196.526793] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 196.529554] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 196.532231] rcu_gp_kthread from kthread+0xfc/0x11c
[ 196.534515] kthread from ret_from_fork+0x14/0x2c
[ 196.536814] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 196.539163] 1fa0: 00000000
00000000 00000000 00000000
[ 196.542933] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 196.546718] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 196.549759] rcu: Stack dump where RCU GP kthread last ran:
[ 196.552305] Sending NMI from CPU 1 to CPUs 0:
[ 274.537090] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 274.539913] (detected by 1, t=18213 jiffies, g=13749, q=294 ncpus=2)
[ 274.542844] rcu: All QSes seen, last rcu_sched kthread activity
18213 (-2553--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 274.548052] rcu: rcu_sched kthread timer wakeup didn't happen for
18212 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 274.553130] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 274.556276] rcu: rcu_sched kthread starved for 18213 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 274.560932] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 274.564906] rcu: RCU grace-period kthread stack dump:
[ 274.567183] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 274.570945] __schedule from schedule+0x60/0x100
[ 274.573114] schedule from schedule_timeout+0xbc/0x20c
[ 274.575482] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 274.578110] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 274.580685] rcu_gp_kthread from kthread+0xfc/0x11c
[ 274.582907] kthread from ret_from_fork+0x14/0x2c
[ 274.585072] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 274.587375] 1fa0: 00000000
00000000 00000000 00000000
[ 274.591035] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 274.594733] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 274.597716] rcu: Stack dump where RCU GP kthread last ran:
[ 274.600211] Sending NMI from CPU 1 to CPUs 0:
[ 352.587095] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 352.589951] (detected by 1, t=26018 jiffies, g=13749, q=302 ncpus=2)
[ 352.592812] rcu: All QSes seen, last rcu_sched kthread activity
26018 (5252--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 352.597854] rcu: rcu_sched kthread timer wakeup didn't happen for
26017 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 352.603086] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 352.606120] rcu: rcu_sched kthread starved for 26018 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 352.610625] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 352.614522] rcu: RCU grace-period kthread stack dump:
[ 352.616787] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 352.620470] __schedule from schedule+0x60/0x100
[ 352.622642] schedule from schedule_timeout+0xbc/0x20c
[ 352.625133] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 352.627944] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 352.630522] rcu_gp_kthread from kthread+0xfc/0x11c
[ 352.632711] kthread from ret_from_fork+0x14/0x2c
[ 352.634870] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 352.637127] 1fa0: 00000000
00000000 00000000 00000000
[ 352.640687] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 352.644262] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 352.647148] rcu: Stack dump where RCU GP kthread last ran:
[ 352.649559] Sending NMI from CPU 1 to CPUs 0:
[ 430.637222] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 430.640203] (detected by 1, t=33823 jiffies, g=13749, q=314 ncpus=2)
[ 430.643245] rcu: All QSes seen, last rcu_sched kthread activity
33823 (13057--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 430.648624] rcu: rcu_sched kthread timer wakeup didn't happen for
33822 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 430.653861] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 430.657085] rcu: rcu_sched kthread starved for 33823 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 430.661780] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 430.665876] rcu: RCU grace-period kthread stack dump:
[ 430.668225] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 430.672089] __schedule from schedule+0x60/0x100
[ 430.674294] schedule from schedule_timeout+0xbc/0x20c
[ 430.676805] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 430.679569] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 430.682281] rcu_gp_kthread from kthread+0xfc/0x11c
[ 430.684608] kthread from ret_from_fork+0x14/0x2c
[ 430.686809] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 430.689211] 1fa0: 00000000
00000000 00000000 00000000
[ 430.692951] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 430.696735] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 430.699829] rcu: Stack dump where RCU GP kthread last ran:
[ 430.702415] Sending NMI from CPU 1 to CPUs 0:
[1]
https://lkft.validation.linaro.org/scheduler/job/6022385#L1224https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3…https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3…
metadata:
git_ref: linux-6.1.y
git_repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git_sha: a31425cbf493ef8bc7f7ce775a1028b1e0612f32
git_describe: v6.1.3-208-ga31425cbf493
kernel_version: 6.1.4-rc1
kernel-config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
build-url: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/pipelines/7…
artifact-location:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
toolchain: gcc-10
vmlinux.xz: https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
System.map: https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
--
Linaro LKFT
https://lkft.linaro.org
Backports the following three patches to fix the issue of IMA mishandling
LSM based rule during LSM policy update, causing a file to match an
unexpected rule.
v5:
goes back to ima_lsm_free_rule() instead to avoid freeing
rule->fsname.
v4:
Make use of the exisiting ima_free_rule() instead of backported
ima_lsm_free_rule(). Which resolves additional memory leak issues.
v3:
Backport "LSM: switch to blocking policy update notifiers" as well, as
the prerequsite of "ima: use the lsm policy update notifier".
v2:
Re-adjust the bacported logic.
GUO Zihua (1):
ima: Handle -ESTALE returned by ima_filter_rule_match()
Janne Karhunen (2):
LSM: switch to blocking policy update notifiers
ima: use the lsm policy update notifier
drivers/infiniband/core/device.c | 4 +-
include/linux/security.h | 12 +--
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_main.c | 8 ++
security/integrity/ima/ima_policy.c | 151 ++++++++++++++++++++++------
security/security.c | 23 +++--
security/selinux/hooks.c | 2 +-
security/selinux/selinuxfs.c | 2 +-
8 files changed, 156 insertions(+), 48 deletions(-)
--
2.17.1
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer.
Cc: stable(a)vger.kernel.org
Suggested-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ------
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9a1a5c2864a0..cdb681398a99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
#include <linux/pci-p2pdma.h>
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_aperture.h>
#include <drm/drm_probe_helper.h>
#include <drm/amdgpu_drm.h>
#include <linux/vgaarb.h>
@@ -89,6 +90,8 @@ MODULE_FIRMWARE("amdgpu/navi12_gpu_info.bin");
#define AMDGPU_MAX_RETRY_LIMIT 2
#define AMDGPU_RETRY_SRIOV_RESET(r) ((r) == -EBUSY || (r) == -ETIMEDOUT || (r) == -EINVAL)
+static const struct drm_driver amdgpu_kms_driver;
+
const char *amdgpu_asic_name[] = {
"TAHITI",
"PITCAIRN",
@@ -3685,6 +3688,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r)
return r;
+ /* Get rid of things like offb */
+ r = drm_aperture_remove_conflicting_pci_framebuffers(adev->pdev, &amdgpu_kms_driver);
+ if (r)
+ return r;
+
/* Enable TMZ based on IP_VERSION */
amdgpu_gmc_tmz_set(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index db7e34eacc35..b9f14ec9edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,7 +23,6 @@
*/
#include <drm/amdgpu_drm.h>
-#include <drm/drm_aperture.h>
#include <drm/drm_drv.h>
#include <drm/drm_gem.h>
#include <drm/drm_vblank.h>
@@ -2096,11 +2095,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
}
#endif
- /* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver);
- if (ret)
- return ret;
-
adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver, typeof(*adev), ddev);
if (IS_ERR(adev))
return PTR_ERR(adev);
--
2.34.1
Backports the following three patches to fix the issue of IMA mishandling
LSM based rule during LSM policy update, causing a file to match an
unexpected rule.
v4:
Make use of the exisiting ima_free_rule() instead of backported
ima_lsm_free_rule(). Which resolves additional memory leak issues.
v3:
Backport "LSM: switch to blocking policy update notifiers" as well, as
the prerequsite of "ima: use the lsm policy update notifier".
v2:
Re-adjust the bacported logic.
GUO Zihua (1):
ima: Handle -ESTALE returned by ima_filter_rule_match()
Janne Karhunen (2):
LSM: switch to blocking policy update notifiers
ima: use the lsm policy update notifier
drivers/infiniband/core/device.c | 4 +-
include/linux/security.h | 12 +--
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_main.c | 8 ++
security/integrity/ima/ima_policy.c | 136 ++++++++++++++++++++++------
security/security.c | 23 +++--
security/selinux/hooks.c | 2 +-
security/selinux/selinuxfs.c | 2 +-
8 files changed, 143 insertions(+), 46 deletions(-)
--
2.17.1
The patch titled
Subject: mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Peter Xu <peterx(a)redhat.com>
Subject: mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects
Date: Wed, 4 Jan 2023 17:52:05 -0500
Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
was overlooked.
Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
find the huge ptep. It's possible that huge_pte_alloc() can fail with
high memory pressure, in that case stop the loop immediately and fail
silently. This is not the most ideal solution but it matches with what we
do with shmem meanwhile it avoids the splat in dmesg.
Link: https://lkml.kernel.org/r/20230104225207.1066932-2-peterx@redhat.com
Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
Signed-off-by: Peter Xu <peterx(a)redhat.com>
Reported-by: James Houghton <jthoughton(a)google.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Axel Rasmussen <axelrasmussen(a)google.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [5.19+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c~mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects
+++ a/mm/hugetlb.c
@@ -6660,8 +6660,17 @@ unsigned long hugetlb_change_protection(
spinlock_t *ptl;
ptep = huge_pte_offset(mm, address, psize);
if (!ptep) {
- address |= last_addr_mask;
- continue;
+ if (!uffd_wp) {
+ address |= last_addr_mask;
+ continue;
+ }
+ /*
+ * Userfaultfd wr-protect requires pgtable
+ * pre-allocations to install pte markers.
+ */
+ ptep = huge_pte_alloc(mm, vma, address, psize);
+ if (!ptep)
+ break;
}
ptl = huge_pte_lock(h, mm, ptep);
if (huge_pmd_unshare(mm, vma, address, ptep)) {
_
Patches currently in -mm which might be from peterx(a)redhat.com are
mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects.patch
mm-uffd-fix-pte-marker-when-fork-without-fork-event.patch
mm-fix-a-few-rare-cases-of-using-swapin-error-pte-marker.patch
mm-uffd-always-wr-protect-pte-in-ptepmd_mkuffd_wp.patch
mm-hugetlb-let-vma_offset_start-to-return-start.patch
mm-hugetlb-dont-wait-for-migration-entry-during-follow-page.patch
mm-hugetlb-document-huge_pte_offset-usage.patch
mm-hugetlb-move-swap-entry-handling-into-vma-lock-when-faulted.patch
mm-hugetlb-make-userfaultfd_huge_must_wait-safe-to-pmd-unshare.patch
mm-hugetlb-make-hugetlb_follow_page_mask-safe-to-pmd-unshare.patch
mm-hugetlb-make-follow_hugetlb_page-safe-to-pmd-unshare.patch
mm-hugetlb-make-walk_hugetlb_range-safe-to-pmd-unshare.patch
mm-hugetlb-introduce-hugetlb_walk.patch
mm-mprotect-use-long-for-page-accountings-and-retval.patch
mm-uffd-detect-pgtable-allocation-failures.patch
The patch titled
Subject: mm: fix vma->anon_name memory leak for anonymous shmem VMAs
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Suren Baghdasaryan <surenb(a)google.com>
Subject: mm: fix vma->anon_name memory leak for anonymous shmem VMAs
Date: Wed, 4 Jan 2023 16:02:40 -0800
free_anon_vma_name() is missing a check for anonymous shmem VMA which
leads to a memory leak due to refcount not being dropped. Fix this by
calling anon_vma_name_put() unconditionally. It will free vma->anon_name
whenever it's non-NULL.
Link: https://lkml.kernel.org/r/20230105000241.1450843-1-surenb@google.com
Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
Signed-off-by: Suren Baghdasaryan <surenb(a)google.com>
Suggested-by: David Hildenbrand <david(a)redhat.com>
Reported-by: syzbot+91edf9178386a07d06a7(a)syzkaller.appspotmail.com
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mm_inline.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/include/linux/mm_inline.h~mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas
+++ a/include/linux/mm_inline.h
@@ -413,8 +413,7 @@ static inline void free_anon_vma_name(st
* Not using anon_vma_name because it generates a warning if mmap_lock
* is not held, which might be the case here.
*/
- if (!vma->vm_file)
- anon_vma_name_put(vma->anon_name);
+ anon_vma_name_put(vma->anon_name);
}
static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,
_
Patches currently in -mm which might be from surenb(a)google.com are
mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas.patch
These fixes have been in next, though not as these commits.
I'd like to apologize again to contributors for missing the merge
window with new features. These by necessity have been pushed out
to the next merge window. This pull only has bugfixes.
I put automation in place to help prevent missing merge window
in the future.
The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2:
Linux 6.2-rc1 (2022-12-25 13:41:39 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to a26116c1e74028914f281851488546c91cbae57d:
virtio_blk: Fix signedness bug in virtblk_prep_rq() (2022-12-28 05:28:11 -0500)
----------------------------------------------------------------
virtio,vhost,vdpa: fixes, cleanups
mostly fixes all over the place, a couple of cleanups.
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
----------------------------------------------------------------
Angus Chen (2):
virtio_pci: modify ENOENT to EINVAL
virtio_blk: use UINT_MAX instead of -1U
Cindy Lu (2):
vhost_vdpa: fix the crash in unmap a large memory
vdpa_sim_net: should not drop the multicast/broadcast packet
Colin Ian King (1):
RDMA/mlx5: remove variable i
Davidlohr Bueso (2):
tools/virtio: remove stray characters
tools/virtio: remove smp_read_barrier_depends()
Dawei Li (1):
virtio: Implementing attribute show with sysfs_emit
Dmitry Fomichev (1):
virtio-blk: use a helper to handle request queuing errors
Eli Cohen (5):
vdpa/mlx5: Fix rule forwarding VLAN to TIR
vdpa/mlx5: Return error on vlan ctrl commands if not supported
vdpa/mlx5: Fix wrong mac address deletion
vdpa/mlx5: Avoid using reslock in event_handler
vdpa/mlx5: Avoid overwriting CVQ iotlb
Harshit Mogalapalli (1):
vduse: Validate vq_num in vduse_validate_config()
Jason Wang (2):
vdpa: conditionally fill max max queue pair for stats
vdpasim: fix memory leak when freeing IOTLBs
Rafael Mendonca (1):
virtio_blk: Fix signedness bug in virtblk_prep_rq()
Ricardo Cañuelo (1):
tools/virtio: initialize spinlocks in vring_test.c
Rong Wang (1):
vdpa/vp_vdpa: fix kfree a wrong pointer in vp_vdpa_remove
Shaomin Deng (1):
tools: Delete the unneeded semicolon after curly braces
Shaoqin Huang (2):
virtio_pci: use helper function is_power_of_2()
virtio_ring: use helper function is_power_of_2()
Si-Wei Liu (1):
vdpa: merge functionally duplicated dev_features attributes
Stefano Garzarella (4):
vringh: fix range used in iotlb_translate()
vhost: fix range used in translate_desc()
vhost-vdpa: fix an iotlb memory leak
vdpa_sim: fix vringh initialization in vdpasim_queue_ready()
Wei Yongjun (1):
virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()
Yuan Can (1):
vhost/vsock: Fix error handling in vhost_vsock_init()
ruanjinjie (1):
vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()
wangjianli (1):
tools/virtio: Variable type completion
drivers/block/virtio_blk.c | 35 +++++-----
.../crypto/virtio/virtio_crypto_skcipher_algs.c | 3 +-
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 5 +-
drivers/vdpa/mlx5/core/mr.c | 46 +++++++------
drivers/vdpa/mlx5/net/mlx5_vnet.c | 78 +++++++---------------
drivers/vdpa/vdpa.c | 11 ++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +-
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 4 +-
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 7 +-
drivers/vdpa/vdpa_user/vduse_dev.c | 3 +
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/vdpa.c | 52 +++++++++------
drivers/vhost/vhost.c | 4 +-
drivers/vhost/vringh.c | 5 +-
drivers/vhost/vsock.c | 9 ++-
drivers/virtio/virtio.c | 12 ++--
drivers/virtio/virtio_pci_modern.c | 4 +-
drivers/virtio/virtio_ring.c | 2 +-
include/uapi/linux/vdpa.h | 4 +-
tools/virtio/ringtest/main.h | 37 +++++-----
tools/virtio/virtio-trace/trace-agent-ctl.c | 2 +-
tools/virtio/virtio_test.c | 2 +-
tools/virtio/vringh_test.c | 2 +
23 files changed, 173 insertions(+), 163 deletions(-)
From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org>
During rcutorture shutdown, the rcu_torture_cleanup() function calls
torture_cleanup_begin(), which sets the fullstop global variable to
FULLSTOP_RMMOD. This causes the rcutorture threads for readers and
fakewriters to exit all of their "while" loops and start shutting down.
They then call torture_kthread_stopping(), which in turn waits for
kthread_stop() to be called. However, rcu_torture_cleanup() has
not yet called kthread_stop() on those threads, and before it gets a
chance to do so, multiple instances of torture_kthread_stopping() invoke
schedule_timeout_interruptible(1) in a tight loop. Tracing confirms that
TIMER_SOFTIRQ can then continuously execute timer callbacks. If that
TIMER_SOFTIRQ preempts the task executing rcu_torture_cleanup(), that
task might never invoke kthread_stop().
This commit improves this situation by increasing the timeout passed to
schedule_timeout_interruptible() from one jiffy to 1/20th of a second.
This change prevents TIMER_SOFTIRQ from monopolizing its CPU, thus
allowing rcu_torture_cleanup() to carry out the needed kthread_stop()
invocations. Testing has shown 100 runs of TREE07 passing reliably,
as oppose to the tens-of-percent failure rates seen beforehand.
Cc: Paul McKenney <paulmck(a)kernel.org>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Zhouyi Zhou <zhouzhouyi(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # 6.0.x
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Tested-by: Zhouyi Zhou <zhouzhouyi(a)gmail.com>
Reviewed-by: Davidlohr Bueso <dave(a)stgolabs.net>
Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org>
---
kernel/torture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/torture.c b/kernel/torture.c
index 29afc62f2bfec..1a0519b836ac9 100644
--- a/kernel/torture.c
+++ b/kernel/torture.c
@@ -915,7 +915,7 @@ void torture_kthread_stopping(char *title)
VERBOSE_TOROUT_STRING(buf);
while (!kthread_should_stop()) {
torture_shutdown_absorb(title);
- schedule_timeout_uninterruptible(1);
+ schedule_timeout_uninterruptible(HZ / 20);
}
}
EXPORT_SYMBOL_GPL(torture_kthread_stopping);
--
2.31.1.189.g2e36527f23
Hello,
I am running Manjaro, after upgrading from kernel 6.0.15 to 6.1.1
(https://gitlab.manjaro.org/packages/core/linux61) I have noticed that
suspend stopped working, what I can see in the logs is the following
issue which IMO points to cs35l41
Machine:
Type: Laptop System: LENOVO product: 82N6 v: Legion 7 16ACHg6
journalctl output below:
Jan 02 21:52:54 legion16 systemd[1]: Starting System Suspend...
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: wlp4s0:
CTRL-EVENT-DSCP-POLICY clear_all
Jan 02 21:52:54 legion16 systemd-sleep[2912]: Entering sleep state
'suspend'...
Jan 02 21:52:54 legion16 kernel: PM: suspend entry (deep)
Jan 02 21:52:54 legion16 kernel: Filesystems sync: 0.008 seconds
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: wlp4s0:
CTRL-EVENT-DSCP-POLICY clear_all
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: nl80211: deinit
ifname=wlp4s0 disabled_11b_rates=0
Jan 02 21:52:54 legion16 plasmashell[1770]: qml: [DEBUG] - onNewData
Jan 02 21:52:54 legion16 kernel: Freezing user space processes ...
(elapsed 0.002 seconds) done.
Jan 02 21:52:54 legion16 kernel: OOM killer disabled.
Jan 02 21:52:54 legion16 kernel: Freezing remaining freezable tasks ...
(elapsed 0.001 seconds) done.
Jan 02 21:52:54 legion16 kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: System Suspend not supported
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: System Suspend not supported
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: failed to suspend async: error -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: PM: failed to suspend async: error -22
Jan 02 21:52:54 legion16 kernel: PM: Some devices failed to suspend, or
early wake event detected
Jan 02 21:52:54 legion16 kernel: OOM killer enabled.
Jan 02 21:52:54 legion16 kernel: Restarting tasks ... done.
Jan 02 21:52:54 legion16 kernel: random: crng reseeded on system resumption
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: could not
find a connectable relay
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) starting
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: Get
"https://relays.syncthing.net/endpoint": dial tcp: lookup
relays.syncthing.net on [::1]:53: read udp [::1]:58193->[::1]:53: read:
connection refused
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) starting
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: Get
"https://relays.syncthing.net/endpoint": dial tcp: lookup
relays.syncthing.net on [::1]:53: read udp [::1]:35430->[::1]:53: read:
connection refused
Jan 02 21:52:55 legion16 bluetoothd[942]: Controller resume with wake
event 0x0
Jan 02 21:52:55 legion16 kernel: PM: suspend exit
Jan 02 21:52:55 legion16 kernel: PM: suspend entry (s2idle)
Jan 02 21:52:55 legion16 kernel: Filesystems sync: 0.004 seconds
Jan 02 21:52:55 legion16 kernel: Freezing user space processes ...
(elapsed 0.001 seconds) done.
Jan 02 21:52:55 legion16 kernel: OOM killer disabled.
Jan 02 21:52:55 legion16 kernel: Freezing remaining freezable tasks ...
(elapsed 0.216 seconds) done.
Jan 02 21:52:55 legion16 kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: System Suspend not supported
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: failed to suspend async: error -22
Jan 02 21:52:55 legion16 kernel: PM: Some devices failed to suspend, or
early wake event detected
Jan 02 21:52:55 legion16 kernel: OOM killer enabled.
Jan 02 21:52:55 legion16 plasmashell[1770]: qml: [DEBUG] - onNewData
Jan 02 21:52:55 legion16 kernel: Restarting tasks ... done.
Jan 02 21:52:55 legion16 kernel: random: crng reseeded on system resumption
Jan 02 21:52:55 legion16 systemd-sleep[2912]: Failed to put system to
sleep. System resumed again: Invalid argument
Jan 02 21:52:55 legion16 kernel: PM: suspend exit
Jan 02 21:52:55 legion16 bluetoothd[942]: Controller resume with wake
event 0x0
Jan 02 21:52:55 legion16 systemd[1]: systemd-suspend.service: Main
process exited, code=exited, status=1/FAILURE
Jan 02 21:52:55 legion16 systemd[1]: systemd-suspend.service: Failed
with result 'exit-code'.
Jan 02 21:52:55 legion16 systemd[1]: Failed to start System Suspend.
Jan 02 21:52:55 legion16 systemd[1]: Dependency failed for Suspend.
I have to admit I have not tried 6.1.2 yet but I could not find any
changes related to this module (opposite to 6.1 where there was quite a
few including suspend - commit dca45efbe3c870a4ad2107fe625109b3765c0fea).
I can provide any additional information or logs if necessary.
Best Regards,
Waldek
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer.
Cc: stable(a)vger.kernel.org
Suggested-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
v4->v5:
* no changes
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ------
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9a1a5c2864a0..cdb681398a99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
#include <linux/pci-p2pdma.h>
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_aperture.h>
#include <drm/drm_probe_helper.h>
#include <drm/amdgpu_drm.h>
#include <linux/vgaarb.h>
@@ -89,6 +90,8 @@ MODULE_FIRMWARE("amdgpu/navi12_gpu_info.bin");
#define AMDGPU_MAX_RETRY_LIMIT 2
#define AMDGPU_RETRY_SRIOV_RESET(r) ((r) == -EBUSY || (r) == -ETIMEDOUT || (r) == -EINVAL)
+static const struct drm_driver amdgpu_kms_driver;
+
const char *amdgpu_asic_name[] = {
"TAHITI",
"PITCAIRN",
@@ -3685,6 +3688,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r)
return r;
+ /* Get rid of things like offb */
+ r = drm_aperture_remove_conflicting_pci_framebuffers(adev->pdev, &amdgpu_kms_driver);
+ if (r)
+ return r;
+
/* Enable TMZ based on IP_VERSION */
amdgpu_gmc_tmz_set(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index db7e34eacc35..b9f14ec9edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,7 +23,6 @@
*/
#include <drm/amdgpu_drm.h>
-#include <drm/drm_aperture.h>
#include <drm/drm_drv.h>
#include <drm/drm_gem.h>
#include <drm/drm_vblank.h>
@@ -2096,11 +2095,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
}
#endif
- /* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver);
- if (ret)
- return ret;
-
adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver, typeof(*adev), ddev);
if (IS_ERR(adev))
return PTR_ERR(adev);
--
2.34.1
When wait_event_interruptible() has been interrupted by a signal the
tx.state value might not be ISOTP_IDLE. Force the state machines
into idle state to inhibit the timer handlers to continue working.
Cc: stable(a)vger.kernel.org # >= v5.15
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
---
net/can/isotp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index 0476a506d4a4..d3b39a5b7e74 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -1150,10 +1150,13 @@ static int isotp_release(struct socket *sock)
net = sock_net(sk);
/* wait for complete transmission of current pdu */
wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
+ /* force state machines to be idle also when a signal occured */
+ so->tx.state = so->rx.state = ISOTP_IDLE;
+
spin_lock(&isotp_notifier_lock);
while (isotp_busy_notifier == so) {
spin_unlock(&isotp_notifier_lock);
schedule_timeout_uninterruptible(1);
spin_lock(&isotp_notifier_lock);
--
2.30.2
The patch below does not apply to the 5.10-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>.
Possible dependencies:
35aba5f51a39 ("drm/i915: Never return 0 if not all requests retired")
b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC")
f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer")
e0717063ccb4 ("drm/i915/guc: Defer context unpin until scheduling is disabled")
3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new inteface")
925dc1cf58ed ("drm/i915/guc: Implement GuC submission tasklet")
27213d79b384 ("drm/i915/guc: Add LRC descriptor context lookup array")
7518d9b67cf5 ("drm/i915/guc: Remove GuC stage descriptor, add LRC descriptor")
56bc88745e73 ("drm/i915/guc: Add new GuC interface defines and structures")
75452167a279 ("drm/i915/guc: Optimize CTB writes and reads")
b43b9950486e ("drm/i915/guc: Add stall timer to non blocking CTB send function")
1681924d8bde ("drm/i915/guc: Add non blocking CTB send function")
c26e289f1d8d ("drm/i915/guc: Increase size of CTB buffers")
572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
22916bad07a5 ("drm/i915: Move submission tasklet to i915_sched_engine")
d2a31d026492 ("drm/i915: Update i915_scheduler to operate on i915_sched_engine")
71ed60112d5d ("drm/i915: Add kick_backend function to i915_sched_engine")
3f623e06cd56 ("drm/i915: Move engine->schedule to i915_sched_engine")
349a2bc5aae4 ("drm/i915: Move active tracking to i915_sched_engine")
c4fd7d8cc3ca ("drm/i915: Reset sched_engine.no_priolist immediately after dequeue")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 35aba5f51a39fb95351844ffb14ec02b8970e19f Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik <janusz.krzysztofik(a)linux.intel.com>
Date: Mon, 21 Nov 2022 15:56:55 +0100
Subject: [PATCH] drm/i915: Never return 0 if not all requests retired
Users of intel_gt_retire_requests_timeout() expect 0 return value on
success. However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.
Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.
v3: Use conditional expression, more compact but also better reflecting
intention standing behind the change.
v2: Move the added lines down so flush_submission() is not affected.
Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik(a)linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com>
Cc: stable(a)vger.kernel.org # v5.5+
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221121145655.75141-3-janusz…
(cherry picked from commit f301a29f143760ce8d3d6b6a8436d45d3448cde6)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d75630..1dfd01668c79 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,7 +199,7 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;
- return active_count ? timeout : 0;
+ return active_count ? timeout ?: -ETIME : 0;
}
static void retire_work_handler(struct work_struct *work)
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>.
Possible dependencies:
62b9f835a6c6 ("drm/amd/pm: enable GPO dynamic control support for SMU13.0.7")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 62b9f835a6c60171845642afec4ce4b44865f10f Mon Sep 17 00:00:00 2001
From: Evan Quan <evan.quan(a)amd.com>
Date: Fri, 2 Dec 2022 14:03:45 +0800
Subject: [PATCH] drm/amd/pm: enable GPO dynamic control support for SMU13.0.7
To better support UMD pstate profilings, the GPO feature needs
to be switched on/off accordingly.
Signed-off-by: Evan Quan <evan.quan(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0.x
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index c270f94a1b86..ab1c004606be 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -123,6 +123,7 @@ static struct cmn2asic_msg_mapping smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(SetMGpuFanBoostLimitRpm, PPSMC_MSG_SetMGpuFanBoostLimitRpm, 0),
MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0),
MSG_MAP(ArmD3, PPSMC_MSG_ArmD3, 0),
+ MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow, 0),
};
static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -1690,6 +1691,7 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.mode1_reset = smu_v13_0_mode1_reset,
.set_mp1_state = smu_v13_0_7_set_mp1_state,
.set_df_cstate = smu_v13_0_7_set_df_cstate,
+ .gpo_control = smu_v13_0_gpo_control,
};
void smu_v13_0_7_set_ppt_funcs(struct smu_context *smu)
The patch below does not apply to the 6.0-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>.
Possible dependencies:
62b9f835a6c6 ("drm/amd/pm: enable GPO dynamic control support for SMU13.0.7")
a60254d25e48 ("drm/amd/pm: enable runpm support over BACO for SMU13.0.7")
ba2f09960e75 ("drm/amd/pm: fulfill SMU13.0.7 cstate control interface")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 62b9f835a6c60171845642afec4ce4b44865f10f Mon Sep 17 00:00:00 2001
From: Evan Quan <evan.quan(a)amd.com>
Date: Fri, 2 Dec 2022 14:03:45 +0800
Subject: [PATCH] drm/amd/pm: enable GPO dynamic control support for SMU13.0.7
To better support UMD pstate profilings, the GPO feature needs
to be switched on/off accordingly.
Signed-off-by: Evan Quan <evan.quan(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0.x
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index c270f94a1b86..ab1c004606be 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -123,6 +123,7 @@ static struct cmn2asic_msg_mapping smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(SetMGpuFanBoostLimitRpm, PPSMC_MSG_SetMGpuFanBoostLimitRpm, 0),
MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0),
MSG_MAP(ArmD3, PPSMC_MSG_ArmD3, 0),
+ MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow, 0),
};
static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -1690,6 +1691,7 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.mode1_reset = smu_v13_0_mode1_reset,
.set_mp1_state = smu_v13_0_7_set_mp1_state,
.set_df_cstate = smu_v13_0_7_set_df_cstate,
+ .gpo_control = smu_v13_0_gpo_control,
};
void smu_v13_0_7_set_ppt_funcs(struct smu_context *smu)
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>.
Possible dependencies:
6217e9f05a74 ("drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index")
963bbdb32b47 ("drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence")
8cee664d3eb6 ("drm/i915: use proper helper for register updates")
e58c2cac2c21 ("drm/i915/display: Use intel_uncore alias if defined")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 6217e9f05a74df48c77ee68993d587cdfdb1feb7 Mon Sep 17 00:00:00 2001
From: Jani Nikula <jani.nikula(a)intel.com>
Date: Tue, 20 Dec 2022 16:01:05 +0200
Subject: [PATCH] drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Due to copy-paste fail, MIPI_BKLT_EN_1 would always use PPS index 1,
never 0. Fix the sloppiest commit in recent memory.
Fixes: 963bbdb32b47 ("drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence")
Reported-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221220140105.313333-1-jani.…
(cherry picked from commit a561933c571798868b5fa42198427a7e6df56c09)
Cc: stable(a)vger.kernel.org # 6.1
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 41f025f089d9..2cbc1292ab38 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -430,7 +430,7 @@ static void icl_native_gpio_set_value(struct drm_i915_private *dev_priv,
break;
case MIPI_BKLT_EN_1:
case MIPI_BKLT_EN_2:
- index = gpio == MIPI_AVDD_EN_1 ? 0 : 1;
+ index = gpio == MIPI_BKLT_EN_1 ? 0 : 1;
intel_de_rmw(dev_priv, PP_CONTROL(index), EDP_BLC_ENABLE,
value ? EDP_BLC_ENABLE : 0);
The patch below does not apply to the 5.15-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>.
Possible dependencies:
31a2e6cbe8a4 ("drm/i915/migrate: Account for the reserved_space")
00e27ad85bc9 ("drm/i915/migrate: add acceleration support for DG2")
31d70749bfe1 ("drm/i915/migrate: fix length calculation")
08c7c122ad90 ("drm/i915/migrate: fix offset calculation")
8eb7fcce34d1 ("drm/i915/migrate: don't check the scratch page")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 31a2e6cbe8a4eb0d1650fff4b77872b744e14a62 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris.p.wilson(a)intel.com>
Date: Fri, 2 Dec 2022 12:28:42 +0000
Subject: [PATCH] drm/i915/migrate: Account for the reserved_space
If the ring is nearly full when calling into emit_pte(), we might
incorrectly trample the reserved_space when constructing the packet to
emit the PTEs. This then triggers the GEM_BUG_ON(rq->reserved_space >
ring->space) when later submitting the request, since the request itself
doesn't have enough space left in the ring to emit things like
workarounds, breadcrumbs etc.
v2: Fix the whitespace errors
Testcase: igt@i915_selftests@live_emit_pte_full_ring
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7535
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Fixes: cf586021642d ("drm/i915/gt: Pipelined page migration")
Signed-off-by: Chris Wilson <chris.p.wilson(a)intel.com>
Signed-off-by: Matthew Auld <matthew.auld(a)intel.com>
Cc: Andrzej Hajda <andrzej.hajda(a)intel.com>
Cc: Andi Shyti <andi.shyti(a)linux.intel.com>
Cc: Nirmoy Das <nirmoy.das(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v5.15+
Tested-by: Nirmoy Das <nirmoy.das(a)intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com>
Reviewed-by: Andi Shyti <andi.shyti(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202122844.428006-1-matth…
(cherry picked from commit 35168a6c4ed53db4f786858bac23b1474fd7d0dc)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c
index b405a04135ca..b783f6f740c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -342,6 +342,16 @@ static int emit_no_arbitration(struct i915_request *rq)
return 0;
}
+static int max_pte_pkt_size(struct i915_request *rq, int pkt)
+{
+ struct intel_ring *ring = rq->ring;
+
+ pkt = min_t(int, pkt, (ring->space - rq->reserved_space) / sizeof(u32) + 5);
+ pkt = min_t(int, pkt, (ring->size - ring->emit) / sizeof(u32) + 5);
+
+ return pkt;
+}
+
static int emit_pte(struct i915_request *rq,
struct sgt_dma *it,
enum i915_cache_level cache_level,
@@ -388,8 +398,7 @@ static int emit_pte(struct i915_request *rq,
return PTR_ERR(cs);
/* Pack as many PTE updates as possible into a single MI command */
- pkt = min_t(int, dword_length, ring->space / sizeof(u32) + 5);
- pkt = min_t(int, pkt, (ring->size - ring->emit) / sizeof(u32) + 5);
+ pkt = max_pte_pkt_size(rq, dword_length);
hdr = cs;
*cs++ = MI_STORE_DATA_IMM | REG_BIT(21); /* as qword elements */
@@ -422,8 +431,7 @@ static int emit_pte(struct i915_request *rq,
}
}
- pkt = min_t(int, dword_rem, ring->space / sizeof(u32) + 5);
- pkt = min_t(int, pkt, (ring->size - ring->emit) / sizeof(u32) + 5);
+ pkt = max_pte_pkt_size(rq, dword_rem);
hdr = cs;
*cs++ = MI_STORE_DATA_IMM | REG_BIT(21);
The patch below does not apply to the 6.0-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>.
Possible dependencies:
e1d900df63ad ("drm/amdgpu: enable VCN DPG for GC IP v11.0.4")
2a0fe2ca6e9c ("drm/amdgpu: Enable pg/cg flags on GC11_0_4 for VCN")
311d52367d0a ("drm/amdgpu: add soc21 common ip block support for GC 11.0.4")
6b46251c5067 ("drm/amdgpu: initialize common sw config for v11_0_3")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e1d900df63adcb748905131dd6258e570e11aed1 Mon Sep 17 00:00:00 2001
From: Saleemkhan Jamadar <saleemkhan.jamadar(a)amd.com>
Date: Tue, 20 Dec 2022 13:21:44 +0530
Subject: [PATCH] drm/amdgpu: enable VCN DPG for GC IP v11.0.4
Enable VCN Dynamic Power Gating control for GC IP v11.0.4.
Signed-off-by: Saleemkhan Jamadar <saleemkhan.jamadar(a)amd.com>
Reviewed-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0, 6.1
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 7d5fdf450d0c..5562670b7b52 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc21.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc21.c
@@ -666,6 +666,7 @@ static int soc21_common_early_init(void *handle)
AMD_CG_SUPPORT_VCN_MGCG |
AMD_CG_SUPPORT_JPEG_MGCG;
adev->pg_flags = AMD_PG_SUPPORT_VCN |
+ AMD_PG_SUPPORT_VCN_DPG |
AMD_PG_SUPPORT_GFX_PG |
AMD_PG_SUPPORT_JPEG;
adev->external_rev_id = adev->rev_id + 0x1;
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>.
Possible dependencies:
e1d900df63ad ("drm/amdgpu: enable VCN DPG for GC IP v11.0.4")
2a0fe2ca6e9c ("drm/amdgpu: Enable pg/cg flags on GC11_0_4 for VCN")
311d52367d0a ("drm/amdgpu: add soc21 common ip block support for GC 11.0.4")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e1d900df63adcb748905131dd6258e570e11aed1 Mon Sep 17 00:00:00 2001
From: Saleemkhan Jamadar <saleemkhan.jamadar(a)amd.com>
Date: Tue, 20 Dec 2022 13:21:44 +0530
Subject: [PATCH] drm/amdgpu: enable VCN DPG for GC IP v11.0.4
Enable VCN Dynamic Power Gating control for GC IP v11.0.4.
Signed-off-by: Saleemkhan Jamadar <saleemkhan.jamadar(a)amd.com>
Reviewed-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0, 6.1
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 7d5fdf450d0c..5562670b7b52 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc21.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc21.c
@@ -666,6 +666,7 @@ static int soc21_common_early_init(void *handle)
AMD_CG_SUPPORT_VCN_MGCG |
AMD_CG_SUPPORT_JPEG_MGCG;
adev->pg_flags = AMD_PG_SUPPORT_VCN |
+ AMD_PG_SUPPORT_VCN_DPG |
AMD_PG_SUPPORT_GFX_PG |
AMD_PG_SUPPORT_JPEG;
adev->external_rev_id = adev->rev_id + 0x1;
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>.
Possible dependencies:
45ae272a948a ("clocksource/drivers/arm_arch_timer: Fix XGene-1 TVAL register math error")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 45ae272a948a03a7d55748bf52d2f47d3b4e1d5a Mon Sep 17 00:00:00 2001
From: Joe Korty <joe.korty(a)concurrent-rt.com>
Date: Mon, 21 Nov 2022 14:53:43 +0000
Subject: [PATCH] clocksource/drivers/arm_arch_timer: Fix XGene-1 TVAL register
math error
The TVAL register is 32 bit signed. Thus only the lower 31 bits are
available to specify when an interrupt is to occur at some time in the
near future. Attempting to specify a larger interval with TVAL results
in a negative time delta which means the timer fires immediately upon
being programmed, rather than firing at that expected future time.
The solution is for Linux to declare that TVAL is a 31 bit register rather
than give its true size of 32 bits. This prevents Linux from programming
TVAL with a too-large value. Note that, prior to 5.16, this little trick
was the standard way to handle TVAL in Linux, so there is nothing new
happening here on that front.
The softlockup detector hides the issue, because it keeps generating
short timer deadlines that are within the scope of the broken timer.
Disable it, and you start using NO_HZ with much longer timer deadlines,
which turns into an interrupt flood:
11: 1124855130 949168462 758009394 76417474 104782230 30210281
310890 1734323687 GICv2 29 Level arch_timer
And "much longer" isn't that long: it takes less than 43s to underflow
TVAL at 50MHz (the frequency of the counter on XGene-1).
Some comments on the v1 version of this patch by Marc Zyngier:
XGene implements CVAL (a 64bit comparator) in terms of TVAL (a countdown
register) instead of the other way around. TVAL being a 32bit register,
the width of the counter should equally be 32. However, TVAL is a
*signed* value, and keeps counting down in the negative range once the
timer fires.
It means that any TVAL value with bit 31 set will fire immediately,
as it cannot be distinguished from an already expired timer. Reducing
the timer range back to a paltry 31 bits papers over the issue.
Another problem cannot be fixed though, which is that the timer interrupt
*must* be handled within the negative countdown period, or the interrupt
will be lost (TVAL will rollover to a positive value, indicative of a
new timer deadline).
Cc: stable(a)vger.kernel.org # 5.16+
Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations")
Signed-off-by: Joe Korty <joe.korty(a)concurrent-rt.com>
Reviewed-by: Marc Zyngier <maz(a)kernel.org>
[maz: revamped the commit message]
Signed-off-by: Marc Zyngier <maz(a)kernel.org>
Link: https://lore.kernel.org/r/20221024165422.GA51107@zipoli.concurrent-rt.com
Link: https://lore.kernel.org/r/20221121145343.896018-1-maz@kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)kernel.org>
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 9c3420a0d19d..e2920da18ea1 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -806,6 +806,9 @@ static u64 __arch_timer_check_delta(void)
/*
* XGene-1 implements CVAL in terms of TVAL, meaning
* that the maximum timer range is 32bit. Shame on them.
+ *
+ * Note that TVAL is signed, thus has only 31 of its
+ * 32 bits to express magnitude.
*/
MIDR_ALL_VERSIONS(MIDR_CPU_MODEL(ARM_CPU_IMP_APM,
APM_CPU_PART_POTENZA)),
@@ -813,8 +816,8 @@ static u64 __arch_timer_check_delta(void)
};
if (is_midr_in_range_list(read_cpuid_id(), broken_cval_midrs)) {
- pr_warn_once("Broken CNTx_CVAL_EL1, limiting width to 32bits");
- return CLOCKSOURCE_MASK(32);
+ pr_warn_once("Broken CNTx_CVAL_EL1, using 32 bit TVAL instead.\n");
+ return CLOCKSOURCE_MASK(31);
}
#endif
return CLOCKSOURCE_MASK(arch_counter_get_width());
I'm currently experiencing a regression with the audio on my Behringer
U-Phoria UMC404HD.
Alsa info is at:
http://alsa-project.org/db/?f=f453b8cd0248fb5fdfa38e1b770e774102f66135
I get no audio in or out for this device with kernel versions 6.1.1 and 6.1.2.
The versions I have tried that work correctly include 5.15.86 LTS,
5.19.12, and 6.0.13–16.
When I run this on 6.1.1, it will just hang until I ctrl+c:
aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Center.wav
I've run strace on that command, and its output is at:
https://pastebin.com/WaxJpTMe
Nothing out of the ordinary occurs when aplay is run, according to the
kernel logs.
Please let me know how I can provide additional debugging information
if necessary.
Thanks
Michael
The patch below does not apply to the 4.9-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>.
Possible dependencies:
e4db04f7d3db ("ext4: fix inode leak in ext4_xattr_inode_create() on an error path")
bd3b963b273e ("ext4: attach jinode after creation of xattr inode")
e50e5129f384 ("ext4: xattr-in-inode support")
b8cb5a545c3d ("ext4: fix quota charging for shared xattr blocks")
c755e251357a ("ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea()")
d7614cc16146 ("ext4: correctly detect when an xattr value has an invalid size")
2f8f5e76c7da ("ext4: avoid lockdep warning when inheriting encryption context")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e4db04f7d3dbbe16680e0ded27ea2a65b10f766a Mon Sep 17 00:00:00 2001
From: Ye Bin <yebin10(a)huawei.com>
Date: Thu, 8 Dec 2022 10:32:33 +0800
Subject: [PATCH] ext4: fix inode leak in ext4_xattr_inode_create() on an error
path
There is issue as follows when do setxattr with inject fault:
[localhost]# fsck.ext4 -fn /dev/sda
e2fsck 1.46.6-rc1 (12-Sep-2022)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached zero-length inode 15. Clear? no
Unattached inode 15
Connect to /lost+found? no
Pass 5: Checking group summary information
/dev/sda: ********** WARNING: Filesystem still has errors **********
/dev/sda: 15/655360 files (0.0% non-contiguous), 66755/2621440 blocks
This occurs in 'ext4_xattr_inode_create()'. If 'ext4_mark_inode_dirty()'
fails, dropping i_nlink of the inode is needed. Or will lead to inode leak.
Signed-off-by: Ye Bin <yebin10(a)huawei.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Link: https://lore.kernel.org/r/20221208023233.1231330-5-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index b666d3bf8b38..7decaaf27e82 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1441,6 +1441,9 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle,
if (!err)
err = ext4_inode_attach_jinode(ea_inode);
if (err) {
+ if (ext4_xattr_inode_dec_ref(handle, ea_inode))
+ ext4_warning_inode(ea_inode,
+ "cleanup dec ref error %d", err);
iput(ea_inode);
return ERR_PTR(err);
}
The patch below does not apply to the 4.9-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>.
Possible dependencies:
5c099c4fdc43 ("ext4: fix kernel BUG in 'ext4_write_inline_data_end()'")
6984aef59814 ("ext4: factor out write end code of inline file")
55ce2f649b9e ("ext4: correct the error path of ext4_write_inline_data_end()")
4df031ff5876 ("ext4: check and update i_disksize properly")
4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors")
4337ecd1fe99 ("ext4: remove EXT4_EOFBLOCKS_FL and associated code")
43f816772ff3 ("ext4: make some functions static in extents.c")
9b02e4987ab0 ("ext4: clean up len and offset checks in ext4_fallocate()")
c7df4a1ecb85 ("ext4: work around deleting a file with i_nlink == 0 safely")
8d0d47ea1640 ("Merge branch 'mb/dio' into master")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5c099c4fdc438014d5893629e70a8ba934433ee8 Mon Sep 17 00:00:00 2001
From: Ye Bin <yebin10(a)huawei.com>
Date: Tue, 6 Dec 2022 22:41:34 +0800
Subject: [PATCH] ext4: fix kernel BUG in 'ext4_write_inline_data_end()'
Syzbot report follow issue:
------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:227!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227
RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000
RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006
RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199
R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b
R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82
FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768
ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313
ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063
generic_perform_write+0x316/0x570 mm/filemap.c:3764
ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285
ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700
call_write_iter include/linux/fs.h:2191 [inline]
do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735
do_iter_write+0x182/0x700 fs/read_write.c:861
vfs_iter_write+0x74/0xa0 fs/read_write.c:902
iter_file_splice_write+0x745/0xc90 fs/splice.c:686
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x114/0x180 fs/splice.c:931
splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886
do_splice_direct+0x1ab/0x280 fs/splice.c:974
do_sendfile+0xb19/0x1270 fs/read_write.c:1255
__do_sys_sendfile64 fs/read_write.c:1323 [inline]
__se_sys_sendfile64 fs/read_write.c:1309 [inline]
__x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
---[ end trace 0000000000000000 ]---
Above issue may happens as follows:
ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_da_convert_inline_data_to_extent
ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
ext4_da_write_end
ext4_run_li_request
ext4_mb_prefetch
ext4_read_block_bitmap_nowait
ext4_validate_block_bitmap
ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT)
percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free);
-> sbi->s_freeclusters_counter become zero
ext4_da_write_begin
if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true
*fsdata = (void *)FALL_BACK_TO_NONDELALLOC;
ext4_write_begin
ext4_da_write_end
if (write_mode == FALL_BACK_TO_NONDELALLOC)
ext4_write_end
if (inline_data)
ext4_write_inline_data_end
ext4_write_inline_data
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
-> As inode is already convert to extent, so 'pos + len' > inline_size
-> then trigger BUG.
To solve this issue, instead of checking ext4_has_inline_data() which
is only cleared after data has been written back, check the
EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end().
Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
Reported-by: syzbot+4faa160fa96bfba639f8(a)syzkaller.appspotmail.com
Reported-by: Jun Nie <jun.nie(a)linaro.org>
Signed-off-by: Ye Bin <yebin10(a)huawei.com>
Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 181bc161b1ac..a0f4d4197a0b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1315,7 +1315,8 @@ static int ext4_write_end(struct file *file,
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_has_inline_data(inode))
+ if (ext4_has_inline_data(inode) &&
+ ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
return ext4_write_inline_data_end(inode, pos, len, copied, page);
copied = block_write_end(file, mapping, pos, len, copied, page, fsdata);
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>.
Possible dependencies:
5c099c4fdc43 ("ext4: fix kernel BUG in 'ext4_write_inline_data_end()'")
6984aef59814 ("ext4: factor out write end code of inline file")
55ce2f649b9e ("ext4: correct the error path of ext4_write_inline_data_end()")
4df031ff5876 ("ext4: check and update i_disksize properly")
4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors")
4337ecd1fe99 ("ext4: remove EXT4_EOFBLOCKS_FL and associated code")
43f816772ff3 ("ext4: make some functions static in extents.c")
9b02e4987ab0 ("ext4: clean up len and offset checks in ext4_fallocate()")
c7df4a1ecb85 ("ext4: work around deleting a file with i_nlink == 0 safely")
8d0d47ea1640 ("Merge branch 'mb/dio' into master")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5c099c4fdc438014d5893629e70a8ba934433ee8 Mon Sep 17 00:00:00 2001
From: Ye Bin <yebin10(a)huawei.com>
Date: Tue, 6 Dec 2022 22:41:34 +0800
Subject: [PATCH] ext4: fix kernel BUG in 'ext4_write_inline_data_end()'
Syzbot report follow issue:
------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:227!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227
RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000
RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006
RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199
R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b
R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82
FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768
ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313
ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063
generic_perform_write+0x316/0x570 mm/filemap.c:3764
ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285
ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700
call_write_iter include/linux/fs.h:2191 [inline]
do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735
do_iter_write+0x182/0x700 fs/read_write.c:861
vfs_iter_write+0x74/0xa0 fs/read_write.c:902
iter_file_splice_write+0x745/0xc90 fs/splice.c:686
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x114/0x180 fs/splice.c:931
splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886
do_splice_direct+0x1ab/0x280 fs/splice.c:974
do_sendfile+0xb19/0x1270 fs/read_write.c:1255
__do_sys_sendfile64 fs/read_write.c:1323 [inline]
__se_sys_sendfile64 fs/read_write.c:1309 [inline]
__x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
---[ end trace 0000000000000000 ]---
Above issue may happens as follows:
ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_da_convert_inline_data_to_extent
ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
ext4_da_write_end
ext4_run_li_request
ext4_mb_prefetch
ext4_read_block_bitmap_nowait
ext4_validate_block_bitmap
ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT)
percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free);
-> sbi->s_freeclusters_counter become zero
ext4_da_write_begin
if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true
*fsdata = (void *)FALL_BACK_TO_NONDELALLOC;
ext4_write_begin
ext4_da_write_end
if (write_mode == FALL_BACK_TO_NONDELALLOC)
ext4_write_end
if (inline_data)
ext4_write_inline_data_end
ext4_write_inline_data
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
-> As inode is already convert to extent, so 'pos + len' > inline_size
-> then trigger BUG.
To solve this issue, instead of checking ext4_has_inline_data() which
is only cleared after data has been written back, check the
EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end().
Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
Reported-by: syzbot+4faa160fa96bfba639f8(a)syzkaller.appspotmail.com
Reported-by: Jun Nie <jun.nie(a)linaro.org>
Signed-off-by: Ye Bin <yebin10(a)huawei.com>
Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 181bc161b1ac..a0f4d4197a0b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1315,7 +1315,8 @@ static int ext4_write_end(struct file *file,
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_has_inline_data(inode))
+ if (ext4_has_inline_data(inode) &&
+ ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
return ext4_write_inline_data_end(inode, pos, len, copied, page);
copied = block_write_end(file, mapping, pos, len, copied, page, fsdata);
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>.
Possible dependencies:
5c099c4fdc43 ("ext4: fix kernel BUG in 'ext4_write_inline_data_end()'")
6984aef59814 ("ext4: factor out write end code of inline file")
55ce2f649b9e ("ext4: correct the error path of ext4_write_inline_data_end()")
4df031ff5876 ("ext4: check and update i_disksize properly")
4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors")
4337ecd1fe99 ("ext4: remove EXT4_EOFBLOCKS_FL and associated code")
43f816772ff3 ("ext4: make some functions static in extents.c")
9b02e4987ab0 ("ext4: clean up len and offset checks in ext4_fallocate()")
c7df4a1ecb85 ("ext4: work around deleting a file with i_nlink == 0 safely")
8d0d47ea1640 ("Merge branch 'mb/dio' into master")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5c099c4fdc438014d5893629e70a8ba934433ee8 Mon Sep 17 00:00:00 2001
From: Ye Bin <yebin10(a)huawei.com>
Date: Tue, 6 Dec 2022 22:41:34 +0800
Subject: [PATCH] ext4: fix kernel BUG in 'ext4_write_inline_data_end()'
Syzbot report follow issue:
------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:227!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227
RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000
RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006
RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199
R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b
R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82
FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768
ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313
ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063
generic_perform_write+0x316/0x570 mm/filemap.c:3764
ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285
ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700
call_write_iter include/linux/fs.h:2191 [inline]
do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735
do_iter_write+0x182/0x700 fs/read_write.c:861
vfs_iter_write+0x74/0xa0 fs/read_write.c:902
iter_file_splice_write+0x745/0xc90 fs/splice.c:686
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x114/0x180 fs/splice.c:931
splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886
do_splice_direct+0x1ab/0x280 fs/splice.c:974
do_sendfile+0xb19/0x1270 fs/read_write.c:1255
__do_sys_sendfile64 fs/read_write.c:1323 [inline]
__se_sys_sendfile64 fs/read_write.c:1309 [inline]
__x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
---[ end trace 0000000000000000 ]---
Above issue may happens as follows:
ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_da_convert_inline_data_to_extent
ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
ext4_da_write_end
ext4_run_li_request
ext4_mb_prefetch
ext4_read_block_bitmap_nowait
ext4_validate_block_bitmap
ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT)
percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free);
-> sbi->s_freeclusters_counter become zero
ext4_da_write_begin
if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true
*fsdata = (void *)FALL_BACK_TO_NONDELALLOC;
ext4_write_begin
ext4_da_write_end
if (write_mode == FALL_BACK_TO_NONDELALLOC)
ext4_write_end
if (inline_data)
ext4_write_inline_data_end
ext4_write_inline_data
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
-> As inode is already convert to extent, so 'pos + len' > inline_size
-> then trigger BUG.
To solve this issue, instead of checking ext4_has_inline_data() which
is only cleared after data has been written back, check the
EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end().
Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
Reported-by: syzbot+4faa160fa96bfba639f8(a)syzkaller.appspotmail.com
Reported-by: Jun Nie <jun.nie(a)linaro.org>
Signed-off-by: Ye Bin <yebin10(a)huawei.com>
Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 181bc161b1ac..a0f4d4197a0b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1315,7 +1315,8 @@ static int ext4_write_end(struct file *file,
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_has_inline_data(inode))
+ if (ext4_has_inline_data(inode) &&
+ ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
return ext4_write_inline_data_end(inode, pos, len, copied, page);
copied = block_write_end(file, mapping, pos, len, copied, page, fsdata);
The patch below does not apply to the 5.4-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>.
Possible dependencies:
5c099c4fdc43 ("ext4: fix kernel BUG in 'ext4_write_inline_data_end()'")
6984aef59814 ("ext4: factor out write end code of inline file")
55ce2f649b9e ("ext4: correct the error path of ext4_write_inline_data_end()")
4df031ff5876 ("ext4: check and update i_disksize properly")
4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors")
4337ecd1fe99 ("ext4: remove EXT4_EOFBLOCKS_FL and associated code")
43f816772ff3 ("ext4: make some functions static in extents.c")
9b02e4987ab0 ("ext4: clean up len and offset checks in ext4_fallocate()")
c7df4a1ecb85 ("ext4: work around deleting a file with i_nlink == 0 safely")
8d0d47ea1640 ("Merge branch 'mb/dio' into master")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5c099c4fdc438014d5893629e70a8ba934433ee8 Mon Sep 17 00:00:00 2001
From: Ye Bin <yebin10(a)huawei.com>
Date: Tue, 6 Dec 2022 22:41:34 +0800
Subject: [PATCH] ext4: fix kernel BUG in 'ext4_write_inline_data_end()'
Syzbot report follow issue:
------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:227!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227
RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000
RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006
RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199
R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b
R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82
FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768
ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313
ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063
generic_perform_write+0x316/0x570 mm/filemap.c:3764
ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285
ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700
call_write_iter include/linux/fs.h:2191 [inline]
do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735
do_iter_write+0x182/0x700 fs/read_write.c:861
vfs_iter_write+0x74/0xa0 fs/read_write.c:902
iter_file_splice_write+0x745/0xc90 fs/splice.c:686
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x114/0x180 fs/splice.c:931
splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886
do_splice_direct+0x1ab/0x280 fs/splice.c:974
do_sendfile+0xb19/0x1270 fs/read_write.c:1255
__do_sys_sendfile64 fs/read_write.c:1323 [inline]
__se_sys_sendfile64 fs/read_write.c:1309 [inline]
__x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
---[ end trace 0000000000000000 ]---
Above issue may happens as follows:
ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_da_convert_inline_data_to_extent
ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
ext4_da_write_end
ext4_run_li_request
ext4_mb_prefetch
ext4_read_block_bitmap_nowait
ext4_validate_block_bitmap
ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT)
percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free);
-> sbi->s_freeclusters_counter become zero
ext4_da_write_begin
if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true
*fsdata = (void *)FALL_BACK_TO_NONDELALLOC;
ext4_write_begin
ext4_da_write_end
if (write_mode == FALL_BACK_TO_NONDELALLOC)
ext4_write_end
if (inline_data)
ext4_write_inline_data_end
ext4_write_inline_data
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
-> As inode is already convert to extent, so 'pos + len' > inline_size
-> then trigger BUG.
To solve this issue, instead of checking ext4_has_inline_data() which
is only cleared after data has been written back, check the
EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end().
Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
Reported-by: syzbot+4faa160fa96bfba639f8(a)syzkaller.appspotmail.com
Reported-by: Jun Nie <jun.nie(a)linaro.org>
Signed-off-by: Ye Bin <yebin10(a)huawei.com>
Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 181bc161b1ac..a0f4d4197a0b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1315,7 +1315,8 @@ static int ext4_write_end(struct file *file,
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_has_inline_data(inode))
+ if (ext4_has_inline_data(inode) &&
+ ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
return ext4_write_inline_data_end(inode, pos, len, copied, page);
copied = block_write_end(file, mapping, pos, len, copied, page, fsdata);
The patch below does not apply to the 4.9-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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
351a0a3fbc35 ("ext4: add ioctl EXT4_IOC_CHECKPOINT")
4db5c2e6236f ("ext4: convert to fileattr")
7d6beb71da3c ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)
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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
351a0a3fbc35 ("ext4: add ioctl EXT4_IOC_CHECKPOINT")
4db5c2e6236f ("ext4: convert to fileattr")
7d6beb71da3c ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)
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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
351a0a3fbc35 ("ext4: add ioctl EXT4_IOC_CHECKPOINT")
4db5c2e6236f ("ext4: convert to fileattr")
7d6beb71da3c ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)
The patch below does not apply to the 5.4-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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
351a0a3fbc35 ("ext4: add ioctl EXT4_IOC_CHECKPOINT")
4db5c2e6236f ("ext4: convert to fileattr")
7d6beb71da3c ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)
The patch below does not apply to the 5.10-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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
351a0a3fbc35 ("ext4: add ioctl EXT4_IOC_CHECKPOINT")
4db5c2e6236f ("ext4: convert to fileattr")
7d6beb71da3c ("Merge tag 'idmapped-mounts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)
The patch below does not apply to the 5.15-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>.
Possible dependencies:
b76abb515746 ("ext4: dont return EINVAL from GETFSUUID when reporting UUID length")
d95efb14c0b8 ("ext4: add ioctls to get/set the ext4 superblock uuid")
bbc605cdb1e1 ("ext4: implement support for get/set fs label")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b76abb5157468756163fe7e3431c9fe32cba57ca Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <djwong(a)kernel.org>
Date: Thu, 10 Nov 2022 12:16:29 -0800
Subject: [PATCH] ext4: dont return EINVAL from GETFSUUID when reporting UUID
length
If userspace calls this ioctl with fsu_length (the length of the
fsuuid.fsu_uuid array) set to zero, ext4 copies the desired uuid length
out to userspace. The kernel call returned a result from a valid input,
so the return value here should be zero, not EINVAL.
While we're at it, fix the copy_to_user call to make it clear that we're
only copying out fsu_len.
Signed-off-by: Darrick J. Wong <djwong(a)kernel.org>
Reviewed-by: Catherine Hoang <catherine.hoang(a)oracle.com>
Link: https://lore.kernel.org/r/166811138914.327006.9241306894437166566.stgit@mag…
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e5f60057db5b..beedaebab21c 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1154,9 +1154,10 @@ static int ext4_ioctl_getuuid(struct ext4_sb_info *sbi,
if (fsuuid.fsu_len == 0) {
fsuuid.fsu_len = UUID_SIZE;
- if (copy_to_user(ufsuuid, &fsuuid, sizeof(fsuuid.fsu_len)))
+ if (copy_to_user(&ufsuuid->fsu_len, &fsuuid.fsu_len,
+ sizeof(fsuuid.fsu_len)))
return -EFAULT;
- return -EINVAL;
+ return 0;
}
if (fsuuid.fsu_len != UUID_SIZE || fsuuid.fsu_flags != 0)