Hi,
The following two commits help with initialization of DPIA which is used
for DP tunneling over USB4 within amdgpu.
Needed for both 6.1.y and 6.2.y:
ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer")
0cf8307adbc6 ("drm/amd/display: Properly reuse completion structure")
Needed just for 6.2:
0cf8307adbc6 ("drm/amd/display: Properly reuse completion structure")
0cf8307adbc6 was actually already tagged to go stable but it doesn’t
apply cleanly to 6.1.y
because of the above mentioned dependency so it didn’t come back.
Can you please bring them back as requested above?
Thanks,
From: David Sloan <david.sloan(a)eideticom.com>
commit 5e8daf906f890560df430d30617c692a794acb73 upstream.
A race condition still exists when removing and re-creating md devices
in test cases. However, it is only seen on some setups.
The race condition was tracked down to a reference still being held
to the kobject by the rdev in the md_rdev_misc_wq which will be released
in rdev_delayed_delete().
md_alloc() waits for previous deletions by waiting on the md_misc_wq,
but the md_rdev_misc_wq may still be holding a reference to a recently
removed device.
To fix this, also flush the md_rdev_misc_wq in md_alloc().
Signed-off-by: David Sloan <david.sloan(a)eideticom.com>
[logang(a)deltatee.com: rewrote commit message]
Signed-off-by: Logan Gunthorpe <logang(a)deltatee.com>
Signed-off-by: Song Liu <song(a)kernel.org>
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
---
Hi Greg,
We found the problem also exists on v5.10, so could you please pick it up
for v5.10 ?
Thanks.
drivers/md/md.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3038e7ecb7e1..c0b34637bd66 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5683,6 +5683,7 @@ static int md_alloc(dev_t dev, char *name)
* completely removed (mddev_delayed_delete).
*/
flush_workqueue(md_misc_wq);
+ flush_workqueue(md_rdev_misc_wq);
mutex_lock(&disks_mutex);
error = -EEXIST;
--
2.29.2
Hi,
please backport the following commit[0] to all stable releases that
contain the commit
226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Commit 46d733d0efc7 ("vc_screen: modify vcs_size() handling in vcs_read()") [1]
also tries to fix this commit but should not actually be necessary for a
proper fix. It may make sense to also backport for consistency.
commit ae3419fbac845b4d3f3a9fae4cc80c68d82cdf6e
Author: Thomas Weißschuh <linux(a)weissschuh.net>
Date: Mon Feb 20 06:46:12 2023 +0000
vc_screen: don't clobber return value in vcs_read
Commit 226fae124b2d ("vc_screen: move load of struct vc_data pointer in
vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of
ret = -ENXIO;
This unconditional assignment was valid outside the loop but within it
it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
[ Also, the 'goto unlock_out" needs to be just a "break", so that it
does the right thing when it exits on later iterations when partial
success has happened - Linus ]
Reported-by: Storm Dragon <stormdragon2976(a)gmail.com>
Link: https://lore.kernel.org/lkml/Y%2FKS6vdql2pIsCiI@hotmail.com/
Fixes: 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net>
Link: https://lore.kernel.org/lkml/64981d94-d00c-4b31-9063-43ad0a384bde@t-8ch.de/
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Thanks,
Thomas
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
commit efbc7bd90f60c71b8e786ee767952bc22fc3666d upstream.
Please apply ("staging: mt7621-dts: change palmbus address to lower
case") to 5.15. It solves the duplicate label error caused by the node
name being uppercase on gbpc1.dts, but lowercase on mt7621.dtsi.
drivers/staging/mt7621-dts/gbpc1.dts:22.28-26.4: ERROR
(duplicate_label): /palmbus@1E000000: Duplicate label 'palmbus' on
/palmbus@1E000000 and /palmbus@1e000000
ERROR: Input tree has errors, aborting (use -f to force output)
Arınç
commit 943f4e64ee177cf44d7f2c235281fcda7c32bb28 upstream
Please backport to 6.2.
This fixes an API break between the cs_dsp driver and the cs35l41 HDA
driver that broke the cs35l41 driver.
The original chain of patches that made the cs_dsp change missed out the
corresponding change to the HDA code. These changes went into the first
6.2 release.
Reported-by: Martin Wolf <info(a)martinwolf.pub>
drahý příteli
Jak se dneska máš? Myslím, že už je to dlouho, co jsme spolu mluvili
naposledy. V každém případě Vás budu znovu kontaktovat ohledně naší
předchozí transakce, která u Vás nebyla úspěšná. Vaše spolupráce se
mnou bohužel nemůže dokončit převod finančních prostředků. Nevím,
možná proto, že se musím smířit se svým zájmem o případ.
V každém případě jsem rád, že mohu oznámit úspěch při přijímání
finančních prostředků převedených novým partnerem z Venezuely.
Momentálně jsem ve Venezuele kvůli investici. Nezapomněl jsem však na
své předchozí snažení a snažil jsem se mi s převodem fondu pomoci, i
když jsme nemohli dojít ke konkrétnímu závěru. Díky mé snaze pomoci
mně jsme se s mým novým partnerem rozhodli vrátit vám 850 000 $,
abyste si s námi mohli užívat radosti a štěstí.
Nechal jsem vaše kompenzační vízum pro svou sekretářku, aby mi pomohla
podat žádost. Nyní kontaktujte mou sekretářku v Togu, jmenuje se paní
Silverly Rojas a její e-mailová adresa je
(silverlynrojas94(a)gmail.com). Řekněte jí, aby vám poslala kartu Visa v
hodnotě 850 000 USD. V současné době jsem velmi zaneprázdněn ve
Venezuele kvůli investičním projektům, které mám se svým novým
partnerem. Rychle kontaktujte paní Silverly Rojasovou a dejte jí
vědět, kam má poslat čekající vízum. Karta vám bude obratem zaslána.
Přeji vám vše nejlepší ve všech vašich snahách.
S pozdravem
Robert G Mohammed
When ucsi_init() fails, ucsi->connector is NULL, yet in case of
ucsi_acpi we may still get events which cause the ucs_acpi code to call
ucsi_connector_change(), which then derefs the NULL ucsi->connector
pointer.
Fix this by adding a check for ucsi->connector being NULL, as is
already done in ucsi_resume() for similar reasons.
Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/usb/typec/ucsi/ucsi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 1cf8947c6d66..e762897cb25a 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -842,7 +842,13 @@ static void ucsi_handle_connector_change(struct work_struct *work)
*/
void ucsi_connector_change(struct ucsi *ucsi, u8 num)
{
- struct ucsi_connector *con = &ucsi->connector[num - 1];
+ struct ucsi_connector *con;
+
+ /* Check for ucsi_init() failure */
+ if (!ucsi->connector)
+ return;
+
+ con = &ucsi->connector[num - 1];
if (!(ucsi->ntfy & UCSI_ENABLE_NTFY_CONNECTOR_CHANGE)) {
dev_dbg(ucsi->dev, "Bogus connector change event\n");
--
2.39.1
Patch 1 fixes a possible deadlock in subflow_error_report() reported by
lockdep. The report was in fact a false positive but the modification
makes sense and silences lockdep to allow syzkaller to find real issues.
The regression has been introduced in v5.12.
Patch 2 is a refactoring needed to be able to fix the two next issues.
It improves the situation and can be backported up to v6.0.
Patches 3 and 4 fix UaF reported by KASAN. It fixes issues potentially
visible since v5.7 and v5.19 but only reproducible until recently
(v6.0). These two patches depend on patch 2/7.
Patch 5 fixes the order of the printed values: expected vs seen values.
The regression has been introduced recently: present in Linus' tree but
not in a tagged version yet.
Patch 6 adds missing ro_after_init flags. A previous patch added them
for other functions but these two have been missed. This previous patch
has been backported to stable versions (up to v5.12) so probably better
to do the same here.
Patch 7 fixes tcp_set_state() being called twice in a row since v5.10.
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Geliang Tang (1):
mptcp: add ro_after_init for tcp{,v6}_prot_override
Matthieu Baerts (2):
selftests: mptcp: userspace pm: fix printed values
mptcp: avoid setting TCP_CLOSE state twice
Paolo Abeni (4):
mptcp: fix possible deadlock in subflow_error_report
mptcp: refactor passive socket initialization
mptcp: use the workqueue to destroy unaccepted sockets
mptcp: fix UaF in listener shutdown
net/mptcp/protocol.c | 44 +++-----
net/mptcp/protocol.h | 4 +-
net/mptcp/subflow.c | 122 +++++++---------------
tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +-
4 files changed, 59 insertions(+), 113 deletions(-)
---
base-commit: aaa3c08ee0653beaa649d4adfb27ad562641cfd8
change-id: 20230227-upstream-net-20230227-mptcp-fixes-cc78f3a2f5b2
Best regards,
--
Matthieu Baerts <matthieu.baerts(a)tessares.net>
Hi all,
I'm facing the same issue as https://lore.kernel.org/stable/CAFsF8vL4CGFzWMb38_XviiEgxoKX0GYup=JiUFXUOma…, but on 5.15. I've bisected it across releases to 5.15.88, and can reproduce on 5.15.93.
However, I cannot seem to find the identified problematic commit in the 5.15 branch, so I'm unsure if this is a different issue or not.
There's a few ways to reproduce this issue, but the one I've been using is running libuv's (https://github.com/libuv/libuv) tests, specifically tests 271 and 277.
#regzbot introduced v5.15.88..
Thanks,
Winter
Please, I have an investment Project transaction of US$27.500.000.00.
that involves transfer and I would like to have your advice on which
Investment / Industry that you think that can bring us profit.
If you're interested, kindly reply for more specific information on
this project.
Mr. Aisha Al-Gaddafi
drahý příteli
Jak se dneska máš? Myslím, že už je to dlouho, co jsme spolu mluvili
naposledy. V každém případě Vás budu znovu kontaktovat ohledně naší
předchozí transakce, která u Vás nebyla úspěšná. Vaše spolupráce se
mnou bohužel nemůže dokončit převod finančních prostředků. Nevím,
možná proto, že se musím smířit se svým zájmem o případ.
V každém případě jsem rád, že mohu oznámit úspěch při přijímání
finančních prostředků převedených novým partnerem z Venezuely.
Momentálně jsem ve Venezuele kvůli investici. Nezapomněl jsem však na
své předchozí snažení a snažil jsem se mi s převodem fondu pomoci, i
když jsme nemohli dojít ke konkrétnímu závěru. Díky mé snaze pomoci
mně jsme se s mým novým partnerem rozhodli vrátit vám 850 000 $,
abyste si s námi mohli užívat radosti a štěstí.
Nechal jsem vaše kompenzační vízum pro svou sekretářku, aby mi pomohla
podat žádost. Nyní kontaktujte mou sekretářku v Togu, jmenuje se paní
Silverly Rojas a její e-mailová adresa je
(silverlynrojas94(a)gmail.com). Řekněte jí, aby vám poslala kartu Visa v
hodnotě 850 000 USD. V současné době jsem velmi zaneprázdněn ve
Venezuele kvůli investičním projektům, které mám se svým novým
partnerem. Rychle kontaktujte paní Silverly Rojasovou a dejte jí
vědět, kam má poslat čekající vízum. Karta vám bude obratem zaslána.
Přeji vám vše nejlepší ve všech vašich snahách.
S pozdravem
Robert G Mohammed
Olá,
Sou Leigh Himsworth, de Massachusetts, estou procurando investir um
ativo avaliado em US $ 350 milhões, no Astronaut Asteroid e em
qualquer outro projeto comercial lucrativo em seu país que possa gerar
nosso retorno esperado sobre o investimento.
Por favor, deixe-me saber se você está interessado para que possamos
falar sobre isso com mais detalhes.
Cumprimentos.
Leigh Himsworth
This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a.
The should_skip_kasan_poison() function reads the PG_skip_kasan_poison
flag from page->flags. However, this line of code in free_pages_prepare():
page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
clears most of page->flags, including PG_skip_kasan_poison, before calling
should_skip_kasan_poison(), which meant that it would never return true
as a result of the page flag being set. Therefore, fix the code to call
should_skip_kasan_poison() before clearing the flags, as we were doing
before the reverted patch.
Signed-off-by: Peter Collingbourne <pcc(a)google.com>
Fixes: 487a32ec24be ("kasan: drop skip_kasan_poison variable in free_pages_prepare")
Cc: <stable(a)vger.kernel.org> # 6.1
Link: https://linux-review.googlesource.com/id/Ic4f13affeebd20548758438bb9ed9ca40…
Reviewed-by: Andrey Konovalov <andreyknvl(a)gmail.com>
---
mm/page_alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ac1fc986af44..7136c36c5d01 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1398,6 +1398,7 @@ static __always_inline bool free_pages_prepare(struct page *page,
unsigned int order, bool check_free, fpi_t fpi_flags)
{
int bad = 0;
+ bool skip_kasan_poison = should_skip_kasan_poison(page, fpi_flags);
bool init = want_init_on_free();
VM_BUG_ON_PAGE(PageTail(page), page);
@@ -1470,7 +1471,7 @@ static __always_inline bool free_pages_prepare(struct page *page,
* With hardware tag-based KASAN, memory tags must be set before the
* page becomes unavailable via debug_pagealloc or arch_free_page.
*/
- if (!should_skip_kasan_poison(page, fpi_flags)) {
+ if (!skip_kasan_poison) {
kasan_poison_pages(page, order, init);
/* Memory is already initialized if KASAN did it internally. */
--
2.39.2.722.g9855ee24e9-goog
Hello
I need your urgent response to a transaction request attached to your name/email stable(a)vger.kernel.org I would like to discuss with you now.
Thank You
Mahmut Akten
Vice Chairman
Garanti BBVA Bank (Turkey)
www.garantibbva.com.tr
The 8250 handle_irq callback is not just called from the interrupt
handler but also from a timer callback when polling (e.g. for ports
without an interrupt line). Consequently the callback must explicitly
disable interrupts to avoid a potential deadlock with another interrupt
in polled mode.
Fix up the two paths in the freescale callback that failed to re-enable
interrupts when polling.
Fixes: 853a9ae29e97 ("serial: 8250: fix handle_irq locking")
Cc: stable(a)vger.kernel.org # 5.13
Reported-by: Dan Carpenter <error27(a)gmail.com>
Link: https://lore.kernel.org/r/Y/xYzqp4ogmOF5t0@kili
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/tty/serial/8250/8250_fsl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
index 8aad15622a2e..8adfaa183f77 100644
--- a/drivers/tty/serial/8250/8250_fsl.c
+++ b/drivers/tty/serial/8250/8250_fsl.c
@@ -34,7 +34,7 @@ int fsl8250_handle_irq(struct uart_port *port)
iir = port->serial_in(port, UART_IIR);
if (iir & UART_IIR_NO_INT) {
- spin_unlock(&up->port.lock);
+ spin_unlock_irqrestore(&up->port.lock, flags);
return 0;
}
@@ -42,7 +42,7 @@ int fsl8250_handle_irq(struct uart_port *port)
if (unlikely(up->lsr_saved_flags & UART_LSR_BI)) {
up->lsr_saved_flags &= ~UART_LSR_BI;
port->serial_in(port, UART_RX);
- spin_unlock(&up->port.lock);
+ spin_unlock_irqrestore(&up->port.lock, flags);
return 1;
}
--
2.39.2
The quilt patch titled
Subject: ocfs2: fix non-auto defrag path not working issue
has been removed from the -mm tree. Its filename was
ocfs2-fix-non-auto-defrag-path-not-working-issue.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Heming Zhao via Ocfs2-devel <ocfs2-devel(a)oss.oracle.com>
Subject: ocfs2: fix non-auto defrag path not working issue
Date: Mon, 20 Feb 2023 13:05:26 +0800
This fixes three issues on move extents ioctl without auto defrag:
a) In ocfs2_find_victim_alloc_group(), we have to convert bits to block
first in case of global bitmap.
b) In ocfs2_probe_alloc_group(), when finding enough bits in block
group bitmap, we have to back off move_len to start pos as well,
otherwise it may corrupt filesystem.
c) In ocfs2_ioctl_move_extents(), set me_threshold both for non-auto
and auto defrag paths. Otherwise it will set move_max_hop to 0 and
finally cause unexpectedly ENOSPC error.
Currently there are no tools triggering the above issues since
defragfs.ocfs2 enables auto defrag by default. Tested with manually
changing defragfs.ocfs2 to run non auto defrag path.
Link: https://lkml.kernel.org/r/20230220050526.22020-1-heming.zhao@suse.com
Signed-off-by: Heming Zhao <heming.zhao(a)suse.com>
Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com>
Cc: Mark Fasheh <mark(a)fasheh.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Changwei Ge <gechangwei(a)live.cn>
Cc: Gang He <ghe(a)suse.com>
Cc: Jun Piao <piaojun(a)huawei.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/ocfs2/move_extents.c~ocfs2-fix-non-auto-defrag-path-not-working-issue
+++ a/fs/ocfs2/move_extents.c
@@ -434,7 +434,7 @@ static int ocfs2_find_victim_alloc_group
bg = (struct ocfs2_group_desc *)gd_bh->b_data;
if (vict_blkno < (le64_to_cpu(bg->bg_blkno) +
- le16_to_cpu(bg->bg_bits))) {
+ (le16_to_cpu(bg->bg_bits) << bits_per_unit))) {
*ret_bh = gd_bh;
*vict_bit = (vict_blkno - blkno) >>
@@ -549,6 +549,7 @@ static void ocfs2_probe_alloc_group(stru
last_free_bits++;
if (last_free_bits == move_len) {
+ i -= move_len;
*goal_bit = i;
*phys_cpos = base_cpos + i;
break;
@@ -1020,18 +1021,19 @@ int ocfs2_ioctl_move_extents(struct file
context->range = ⦥
+ /*
+ * ok, the default theshold for the defragmentation
+ * is 1M, since our maximum clustersize was 1M also.
+ * any thought?
+ */
+ if (!range.me_threshold)
+ range.me_threshold = 1024 * 1024;
+
+ if (range.me_threshold > i_size_read(inode))
+ range.me_threshold = i_size_read(inode);
+
if (range.me_flags & OCFS2_MOVE_EXT_FL_AUTO_DEFRAG) {
context->auto_defrag = 1;
- /*
- * ok, the default theshold for the defragmentation
- * is 1M, since our maximum clustersize was 1M also.
- * any thought?
- */
- if (!range.me_threshold)
- range.me_threshold = 1024 * 1024;
-
- if (range.me_threshold > i_size_read(inode))
- range.me_threshold = i_size_read(inode);
if (range.me_flags & OCFS2_MOVE_EXT_FL_PART_DEFRAG)
context->partial = 1;
_
Patches currently in -mm which might be from ocfs2-devel(a)oss.oracle.com are
The quilt patch titled
Subject: ocfs2: fix defrag path triggering jbd2 ASSERT
has been removed from the -mm tree. Its filename was
ocfs2-fix-defrag-path-triggering-jbd2-assert.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Heming Zhao via Ocfs2-devel <ocfs2-devel(a)oss.oracle.com>
Subject: ocfs2: fix defrag path triggering jbd2 ASSERT
Date: Fri, 17 Feb 2023 08:37:17 +0800
code path:
ocfs2_ioctl_move_extents
ocfs2_move_extents
ocfs2_defrag_extent
__ocfs2_move_extent
+ ocfs2_journal_access_di
+ ocfs2_split_extent //sub-paths call jbd2_journal_restart
+ ocfs2_journal_dirty //crash by jbs2 ASSERT
crash stacks:
PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"
#0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
#1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
#2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
#3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
#4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
#5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
#6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
[exception RIP: jbd2_journal_dirty_metadata+0x2ba]
RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250
RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000
R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28
R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
#8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
#9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]
Analysis
This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call
ocfs2_journal_access_di() before ocfs2_journal_dirty() in
ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is
called by ocfs2_split_extent() during defragmenting.
How to fix
For ocfs2_split_extent() can handle journal operations totally by itself.
Caller doesn't need to call journal access/dirty pair, and caller only
needs to call journal start/stop pair. The fix method is to remove
journal access/dirty from __ocfs2_move_extent().
The discussion for this patch:
https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
Link: https://lkml.kernel.org/r/20230217003717.32469-1-heming.zhao@suse.com
Signed-off-by: Heming Zhao <heming.zhao(a)suse.com>
Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com>
Cc: Mark Fasheh <mark(a)fasheh.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Changwei Ge <gechangwei(a)live.cn>
Cc: Gang He <ghe(a)suse.com>
Cc: Jun Piao <piaojun(a)huawei.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/ocfs2/move_extents.c~ocfs2-fix-defrag-path-triggering-jbd2-assert
+++ a/fs/ocfs2/move_extents.c
@@ -105,14 +105,6 @@ static int __ocfs2_move_extent(handle_t
*/
replace_rec.e_flags = ext_flags & ~OCFS2_EXT_REFCOUNTED;
- ret = ocfs2_journal_access_di(handle, INODE_CACHE(inode),
- context->et.et_root_bh,
- OCFS2_JOURNAL_ACCESS_WRITE);
- if (ret) {
- mlog_errno(ret);
- goto out;
- }
-
ret = ocfs2_split_extent(handle, &context->et, path, index,
&replace_rec, context->meta_ac,
&context->dealloc);
@@ -121,8 +113,6 @@ static int __ocfs2_move_extent(handle_t
goto out;
}
- ocfs2_journal_dirty(handle, context->et.et_root_bh);
-
context->new_phys_cpos = new_p_cpos;
/*
_
Patches currently in -mm which might be from ocfs2-devel(a)oss.oracle.com are
The quilt patch titled
Subject: mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON
has been removed from the -mm tree. Its filename was
mm-hwpoison-convert-ttu_ignore_hwpoison-to-ttu_hwpoison.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Subject: mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON
Date: Tue, 21 Feb 2023 17:59:05 +0900
After a memory error happens on a clean folio, a process unexpectedly
receives SIGBUS when it accesses the error page. This SIGBUS killing is
pointless and simply degrades the level of RAS of the system, because the
clean folio can be dropped without any data lost on memory error handling
as we do for a clean pagecache.
When memory_failure() is called on a clean folio, try_to_unmap() is called
twice (one from split_huge_page() and one from hwpoison_user_mappings()).
The root cause of the issue is that pte conversion to hwpoisoned entry is
now done in the first call of try_to_unmap() because PageHWPoison is
already set at this point, while it's actually expected to be done in the
second call. This behavior disturbs the error handling operation like
removing pagecache, which results in the malfunction described above.
So convert TTU_IGNORE_HWPOISON into TTU_HWPOISON and set TTU_HWPOISON only
when we really intend to convert pte to hwpoison entry. This can prevent
other callers of try_to_unmap() from accidentally converting to hwpoison
entries.
Link: https://lkml.kernel.org/r/20230221085905.1465385-1-naoya.horiguchi@linux.dev
Fixes: a42634a6c07d ("readahead: Use a folio in read_pages()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/include/linux/rmap.h~mm-hwpoison-convert-ttu_ignore_hwpoison-to-ttu_hwpoison
+++ a/include/linux/rmap.h
@@ -94,7 +94,7 @@ enum ttu_flags {
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK = 0x8, /* ignore mlock */
TTU_SYNC = 0x10, /* avoid racy checks with PVMW_SYNC */
- TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
+ TTU_HWPOISON = 0x20, /* do convert pte to hwpoison entry */
TTU_BATCH_FLUSH = 0x40, /* Batch TLB flushes where possible
* and caller guarantees they will
* do a final flush if necessary */
--- a/mm/memory-failure.c~mm-hwpoison-convert-ttu_ignore_hwpoison-to-ttu_hwpoison
+++ a/mm/memory-failure.c
@@ -1069,7 +1069,7 @@ static int me_pagecache_dirty(struct pag
* cache and swap cache(ie. page is freshly swapped in). So it could be
* referenced concurrently by 2 types of PTEs:
* normal PTEs and swap PTEs. We try to handle them consistently by calling
- * try_to_unmap(TTU_IGNORE_HWPOISON) to convert the normal PTEs to swap PTEs,
+ * try_to_unmap(!TTU_HWPOISON) to convert the normal PTEs to swap PTEs,
* and then
* - clear dirty bit to prevent IO
* - remove from LRU
@@ -1486,7 +1486,7 @@ static bool hwpoison_user_mappings(struc
int flags, struct page *hpage)
{
struct folio *folio = page_folio(hpage);
- enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_SYNC;
+ enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_SYNC | TTU_HWPOISON;
struct address_space *mapping;
LIST_HEAD(tokill);
bool unmap_success;
@@ -1516,7 +1516,7 @@ static bool hwpoison_user_mappings(struc
if (PageSwapCache(p)) {
pr_err("%#lx: keeping poisoned page in swap cache\n", pfn);
- ttu |= TTU_IGNORE_HWPOISON;
+ ttu &= ~TTU_HWPOISON;
}
/*
@@ -1531,7 +1531,7 @@ static bool hwpoison_user_mappings(struc
if (page_mkclean(hpage)) {
SetPageDirty(hpage);
} else {
- ttu |= TTU_IGNORE_HWPOISON;
+ ttu &= ~TTU_HWPOISON;
pr_info("%#lx: corrupted page was clean: dropped without side effects\n",
pfn);
}
--- a/mm/rmap.c~mm-hwpoison-convert-ttu_ignore_hwpoison-to-ttu_hwpoison
+++ a/mm/rmap.c
@@ -1602,7 +1602,7 @@ static bool try_to_unmap_one(struct foli
/* Update high watermark before we lower rss */
update_hiwater_rss(mm);
- if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) {
+ if (PageHWPoison(subpage) && (flags & TTU_HWPOISON)) {
pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));
if (folio_test_hugetlb(folio)) {
hugetlb_count_sub(folio_nr_pages(folio), mm);
_
Patches currently in -mm which might be from naoya.horiguchi(a)nec.com are
The quilt patch titled
Subject: mm/damon/paddr: fix missing folio_put()
has been removed from the -mm tree. Its filename was
mm-damon-paddr-fix-missing-folio_put.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: "andrew.yang" <andrew.yang(a)mediatek.com>
Subject: mm/damon/paddr: fix missing folio_put()
Date: Wed, 22 Feb 2023 14:42:20 +0800
damon_get_folio() would always increase folio _refcount and
folio_isolate_lru() would increase folio _refcount if the folio's lru flag
is set.
If an unevictable folio isolated successfully, there will be two more
_refcount. The one from folio_isolate_lru() will be decreased in
folio_puback_lru(), but the other one from damon_get_folio() will be left
behind. This causes a pin page.
Whatever the case, the _refcount from damon_get_folio() should be
decreased.
Link: https://lkml.kernel.org/r/20230222064223.6735-1-andrew.yang@mediatek.com
Fixes: 57223ac29584 ("mm/damon/paddr: support the pageout scheme")
Signed-off-by: andrew.yang <andrew.yang(a)mediatek.com>
Reviewed-by: SeongJae Park <sj(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [5.16.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/damon/paddr.c~mm-damon-paddr-fix-missing-folio_put
+++ a/mm/damon/paddr.c
@@ -250,12 +250,11 @@ static unsigned long damon_pa_pageout(st
folio_put(folio);
continue;
}
- if (folio_test_unevictable(folio)) {
+ if (folio_test_unevictable(folio))
folio_putback_lru(folio);
- } else {
+ else
list_add(&folio->lru, &folio_list);
- folio_put(folio);
- }
+ folio_put(folio);
}
applied = reclaim_pages(&folio_list);
cond_resched();
_
Patches currently in -mm which might be from andrew.yang(a)mediatek.com are
Hi,
This series of two patches fixes the issue introduced in
cf586021642d80 ("drm/i915/gt: Pipelined page migration") where,
as reported by Matt, in a chain of requests an error is reported
only if happens in the last request.
However Chris noticed that without ensuring exclusivity in the
locking we might end up in some deadlock. That's why patch 1
throttles for the ringspace in order to make sure that no one is
holding it.
Version 1 of this patch has been reviewed by matt and this
version is adding Chris exclusive locking.
Thanks Chris for this work.
Andi
Changelog
=========
v1 -> v2
- Add patch 1 for ensuring exclusive locking of the timeline
- Reword git commit of patch 2.
Andi Shyti (1):
drm/i915/gt: Make sure that errors are propagated through request
chains
Chris Wilson (1):
drm/i915: Throttle for ringspace prior to taking the timeline mutex
drivers/gpu/drm/i915/gt/intel_context.c | 41 +++++++++++++++++++++++++
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/gt/intel_migrate.c | 31 +++++++++++++------
drivers/gpu/drm/i915/i915_request.c | 3 ++
4 files changed, 67 insertions(+), 10 deletions(-)
--
2.39.1
Hi,
I have received two reports [0][1] about WARN_ON_ONCE() in
sk_stream_kill_queues().
This is because the stable tree backported ca43ccf41224 ("dccp/tcp:
Avoid negative sk_forward_alloc by ipv6_pinfo.pktoptions.") without
62ec33b44e0f ("net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from
sk_stream_kill_queues().").
The reports are about 6.1.14 and 5.15.95 though, 62ec33b44e0f can be
applied cleanly on 6.1.y only, and 4.14 ~ 5.10 will have the same
issue.
So, please backport 62ec33b44e0f to 6.1.y. I will post patches for
other trees later.
[0]: https://lore.kernel.org/netdev/eb5ad452-0abe-8ea6-7e9e-1dd16852e8db@hauke-m…
[1]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-3b67299c42
Thanks,
Kuniyuki
With the introduction of KERNEL_IBRS, STIBP is no longer needed
to prevent cross thread training in the kernel space. When KERNEL_IBRS
was added, it also disabled the user-mode protections for spectre_v2.
KERNEL_IBRS does not mitigate cross thread training in the userspace.
In order to demonstrate the issue, one needs to avoid syscalls in the
victim as syscalls can shorten the window size due to
a user -> kernel -> user transition which sets the
IBRS bit when entering kernel space and clearing any training the
attacker may have done.
Allow users to select a spectre_v2_user mitigation (STIBP always on,
opt-in via prctl) when KERNEL_IBRS is enabled.
Reported-by: José Oliveira <joseloliveira11(a)gmail.com>
Reported-by: Rodrigo Branco <rodrigo(a)kernelhacking.com>
Reviewed-by: Alexandra Sandulescu <aesa(a)google.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
Cc: stable(a)vger.kernel.org
Signed-off-by: KP Singh <kpsingh(a)kernel.org>
---
arch/x86/kernel/cpu/bugs.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index bca0bd8f4846..b05ca1575d81 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1132,6 +1132,19 @@ static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
mode == SPECTRE_V2_EIBRS_LFENCE;
}
+static inline bool spectre_v2_user_no_stibp(enum spectre_v2_mitigation mode)
+{
+ /* When IBRS or enhanced IBRS is enabled, STIBP is not needed.
+ *
+ * However, With KERNEL_IBRS, the IBRS bit is cleared on return
+ * to user and the user-mode code needs to be able to enable protection
+ * from cross-thread training, either by always enabling STIBP or
+ * by enabling it via prctl.
+ */
+ return (spectre_v2_in_ibrs_mode(mode) &&
+ !cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS));
+}
+
static void __init
spectre_v2_user_select_mitigation(void)
{
@@ -1193,13 +1206,8 @@ spectre_v2_user_select_mitigation(void)
"always-on" : "conditional");
}
- /*
- * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossible,
- * STIBP is not required.
- */
- if (!boot_cpu_has(X86_FEATURE_STIBP) ||
- !smt_possible ||
- spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible ||
+ spectre_v2_user_no_stibp(spectre_v2_enabled))
return;
/*
@@ -1496,6 +1504,7 @@ static void __init spectre_v2_select_mitigation(void)
break;
case SPECTRE_V2_IBRS:
+ pr_err("enabling KERNEL_IBRS");
setup_force_cpu_cap(X86_FEATURE_KERNEL_IBRS);
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED))
pr_warn(SPECTRE_V2_IBRS_PERF_MSG);
@@ -2327,7 +2336,7 @@ static ssize_t mmio_stale_data_show_state(char *buf)
static char *stibp_state(void)
{
- if (spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ if (spectre_v2_user_no_stibp(spectre_v2_enabled))
return "";
switch (spectre_v2_user_stibp) {
--
2.39.2.637.g21b0678d19-goog
--
A mail was sent to you sometime last week with the expectation of
having a return mail from you but to my surprise you never bothered to replied.
Kindly reply for further explanations.
Respectfully yours,
Barrister. Douglas Felix.
This is an alrady known issue that dm-thin volume cannot be used as
swap, otherwise a deadlock may happen when dm-thin internal memory
demond triggers swap I/O on the dm-thin volume itself.
Thanks to Mikulas Patocka for commit a666e5c05e7c ("dm: fix deadlock
when swapping to encrypted device"), this method can also be used for
dm-thin to avoid the recursive I/O when it is used as swap.
This patch just simply sets ti->limit_swap_bios by tree in pool_ctr()
and thin_ctr(), other important stuffs are already done by Patocka in
the above mentioned commit.
In my test, I create a dm-thin volume /dev/vg/swap and use it as swap
device. Then I run fio on another dm-thin volume /dev/vg/main and use
large --blocksize to trigger swap I/O onto /dev/vg/swap.
The following fio command line is used in my test,
fio --name recursive-swap-io --lockmem 1 --iodepth 128 \
--ioengine libaio --filename /dev/vg/main --rw randrw \
--blocksize 1M --numjobs 32 --time_based --runtime=12h
Without the patch, the whole system can be locked up within 15 seconds.
With this patch, there is no any deadlock or hang task observed after
2 hours fio running.
Further more, I change --blocksize from 1M to 128M, around 30 seconds
after fio running, no I/O rate displayed by fio, and the out-of-memory
killer message shows up in kernel message. After around 20 minutes all
fio processes are killed and the whole system backs to be alive.
This is exactly what is expected when recursive I/O happens on dm-thin
volume when it is used as swap.
Note: this change depends on commit a666e5c05e7c ("dm: fix deadlock when
swapping to encrypted device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Mike Snitzer <snitzer(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
Changelog,
v2: fix typo in commit log.
v1: initial version.
drivers/md/dm-thin.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -3355,6 +3355,7 @@ static int pool_ctr(struct dm_target *ti
pt->low_water_blocks = low_water_blocks;
pt->adjusted_pf = pt->requested_pf = pf;
ti->num_flush_bios = 1;
+ ti->limit_swap_bios = true;
/*
* Only need to enable discards if the pool should pass
@@ -4233,6 +4234,7 @@ static int thin_ctr(struct dm_target *ti
goto bad;
ti->num_flush_bios = 1;
+ ti->limit_swap_bios = true;
ti->flush_supported = true;
ti->accounts_remapped_io = true;
ti->per_io_data_size = sizeof(struct dm_thin_endio_hook);
Dear Linux folks,
It’d be great if you could apply the commit below [1], present in Linux
since 6.2-rc1, to at least the Linux 6.1 LTS series.
commit a449dfbfc0894676ad0aa1873383265047529e3a
Author: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Date: Thu Dec 1 19:33:09 2022 +0100
PM: sleep: Avoid using pr_cont() in the tasks freezing code
Using pr_cont() in the tasks freezing code related to system-wide
suspend and hibernation is problematic, because the continuation
messages printed there are susceptible to interspersing with other
unrelated messages which results in output that is hard to
understand.
Address this issue by modifying try_to_freeze_tasks() to print
messages that don't require continuations and adjusting its
callers accordingly.
Reported-by: Thomas Weißschuh <linux(a)weissschuh.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Reviewed-by: Petr Mladek <pmladek(a)suse.com>
On a Dell Precision 3540, Linux 6.1.12 from Debian sid/unstable logs the
stray warning below:
$ sudo dmesg --level=warn | grep elapsed
[ 3063.289579] (elapsed 0.047 seconds) done.
It’s due to `pr_cont` usage, and the another (DRM) log message adds the
unexpected newline character, splitting the message:
[ 0.000000] Linux version 6.1.0-5-amd64
(debian-kernel(a)lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU
ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian
6.1.12-1 (2023-02-15)
[…]
[ 0.000000] DMI: Dell Inc. Precision 3540/0M14W7, BIOS 1.23.0
12/19/2022
[…]
[ 3063.241846] Freezing user space processes ...
[ 3063.281999] [drm] VCE initialized successfully.
[ 3063.289579] (elapsed 0.047 seconds) done.
Backporting the patch would change the log messages a little though. No
idea, if that is acceptable for commit for stable series.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
This is an alrady known issue that dm-thin volume cannot be used as
swap, otherwise a deadlock may happen when dm-thin internal memory
demond triggers swap I/O on the dm-thin volume itself.
Thanks to Mikulas Patocka for commit a666e5c05e7c ("dm: fix deadlock
when swapping to encrypted device"), this method can also be used for
dm-thin to avoid the recursive I/O when it is used as swap.
This patch just simply sets ti->limit_swap_bios by tree in pool_ctr()
and thin_ctr(), other important stuffs are already done by Patocka in
the above mentioned commit.
In my test, I create a dm-thin volume /dev/vg/swap and use it as swap
device. Then I run fio on another dm-thin volume /dev/vg/main and use
large --blocksize to trigger swap I/O onto /dev/vg/swap.
The following fio command line is used in my test,
fio --name recursive-swap-io --lockmem 1 --iodepth 128 \
--ioengine libaio --filename /dev/vg/main --rw randrw \
--blocksize 1M --numjobs 32 --time_based --runtime=12h
Without the patch, the whole system can be locked up within 15 seconds.
With this patch, there is no any deadlock or hang task observed after
2 hours fio running.
Further more, I change --blocksize from 1M to 128M, around 30 seconds
after fio running, no I/O rate displayed by fio, and the out-of-memory
killer message shows up in kernel message. After around 20 minutes all
fio processes are killed and the whole system backs to be alive.
This is exactly what is expected when recursive I/O happens on dm-thin
volume when it is used as swap.
NOTE: this change depends on commit a666e5c05e7c ("dm: fix deadlock when
swapping to encrypted device")
Signed-off-by: Coly Li <colyli(a)suse.de>
Cc: Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Mike Snitzer <snitzer(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/md/dm-thin.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 6cd105c1cef3..13d4677baafd 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -3369,6 +3369,7 @@ static int pool_ctr(struct dm_target *ti, unsigned int argc, char **argv)
pt->low_water_blocks = low_water_blocks;
pt->adjusted_pf = pt->requested_pf = pf;
ti->num_flush_bios = 1;
+ ti->limit_swap_bios = true;
/*
* Only need to enable discards if the pool should pass
@@ -4249,6 +4250,7 @@ static int thin_ctr(struct dm_target *ti, unsigned int argc, char **argv)
goto bad;
ti->num_flush_bios = 1;
+ ti->limit_swap_bios = true;
ti->flush_supported = true;
ti->accounts_remapped_io = true;
ti->per_io_data_size = sizeof(struct dm_thin_endio_hook);
--
2.39.2
As per HW manual for EMEV2 "R19UH0040EJ0400 Rev.4.00", the UART
IP found on EMMA mobile SoC is Register-compatible with the
general-purpose 16750 UART chip. Fix UART port type as 16750 and
enable 64-bytes fifo support.
Fixes: 22886ee96895 ("serial8250-em: Emma Mobile UART driver V2")
Cc: stable(a)vger.kernel.org
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
v4->v5:
* Added fixes tag
* Updated commit header and description
* Removed UPF_BOOT_AUTOCONF from flags.
* Reordered the patch (from patch#4 to patch#1) to make it easier
for applying it to stable branches.
v3->v4:
* Both {RZ/V2M, EMMA mobile} SoC is Register-compatible
with the general-purpose 16750 UART chip. So started using
generic compatible and removed struct serial8250_em_hw_info.
* Removed Rb tag from Ilpo as it is new change.
v2->v3:
* Replaced of_device_get_match_data()->device_get_match_data().
* Replaced of_device.h->property.h
* Dropped struct serial8250_em_hw_info *info from priv and started
using a local variable info in probe().
* Retained Rb tag from Ilpo as changes are trivial.
v2:
* New patch
---
drivers/tty/serial/8250/8250_em.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_em.c b/drivers/tty/serial/8250/8250_em.c
index f8e99995eee9..d94c3811a8f7 100644
--- a/drivers/tty/serial/8250/8250_em.c
+++ b/drivers/tty/serial/8250/8250_em.c
@@ -106,8 +106,8 @@ static int serial8250_em_probe(struct platform_device *pdev)
memset(&up, 0, sizeof(up));
up.port.mapbase = regs->start;
up.port.irq = irq;
- up.port.type = PORT_UNKNOWN;
- up.port.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_PORT | UPF_IOREMAP;
+ up.port.type = PORT_16750;
+ up.port.flags = UPF_FIXED_PORT | UPF_IOREMAP | UPF_FIXED_TYPE;
up.port.dev = &pdev->dev;
up.port.private_data = priv;
--
2.25.1
This bug is marked as fixed by commit:
net: core: netlink: add helper refcount dec and lock function
net: sched: add helper function to take reference to Qdisc
net: sched: extend Qdisc with rcu
net: sched: rename qdisc_destroy() to qdisc_put()
net: sched: use Qdisc rcu API instead of relying on rtnl lock
But I can't find it in the tested trees[1] for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and new crashes with
the same signature are ignored.
Kernel: Linux 4.19
Dashboard link: https://syzkaller.appspot.com/bug?extid=5f229e48cccc804062c0
---
[1] I expect the commit to be present in:
1. linux-4.19.y branch of
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Hello, good day,
Please don't be offended by my unsolicited email. First of all, I
would like to briefly introduce myself. My name is kateryna mudrik, I
come from Mariupol in the Donetsk oblast in northern Ukraine. We may
have been humiliated by the Russian invasion of Ukraine, but I still
believe that we Ukrainians can be friends with good people like you.
Now, time won't allow me to say much, but I will tell you the main
reason I contacted you when I get your response.
Thank you and waiting for your response.
When plain IBRS is enabled (not enhanced IBRS), the logic in
spectre_v2_user_select_mitigation() determines that STIBP is not needed.
The IBRS bit implicitly protects against cross-thread branch target
injection. However, with legacy IBRS, the IBRS bit is cleared on
returning to userspace for performance reasons which leaves userspace
threads vulnerable to cross-thread branch target injection against which
STIBP protects.
Exclude IBRS from the spectre_v2_in_ibrs_mode() check to allow for
enabling STIBP (through seccomp/prctl() by default or always-on, if
selected by spectre_v2_user kernel cmdline parameter).
Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
Reported-by: José Oliveira <joseloliveira11(a)gmail.com>
Reported-by: Rodrigo Branco <rodrigo(a)kernelhacking.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: KP Singh <kpsingh(a)kernel.org>
---
arch/x86/kernel/cpu/bugs.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index cf81848b72f4..44e22cda7fb3 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1133,14 +1133,18 @@ spectre_v2_parse_user_cmdline(void)
return SPECTRE_V2_USER_CMD_AUTO;
}
-static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
+static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation mode)
{
- return mode == SPECTRE_V2_IBRS ||
- mode == SPECTRE_V2_EIBRS ||
+ return mode == SPECTRE_V2_EIBRS ||
mode == SPECTRE_V2_EIBRS_RETPOLINE ||
mode == SPECTRE_V2_EIBRS_LFENCE;
}
+static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
+{
+ return spectre_v2_in_eibrs_mode(mode) || mode == SPECTRE_V2_IBRS;
+}
+
static void __init
spectre_v2_user_select_mitigation(void)
{
@@ -1203,12 +1207,20 @@ spectre_v2_user_select_mitigation(void)
}
/*
- * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossible,
- * STIBP is not required.
+ * If no STIBP, enhanced IBRS is enabled, or SMT impossible, STIBP
+ * is not required.
+ *
+ * Enhanced IBRS also protects against cross-thread branch target
+ * injection in user-mode as the IBRS bit remains always set which
+ * implicitly enables cross-thread protections. However, in legacy IBRS
+ * mode, the IBRS bit is set only on kernel entry and cleared on return
+ * to userspace. This disables the implicit
+ * cross-thread protection, so allow for STIBP to be selected in that
+ * case.
*/
if (!boot_cpu_has(X86_FEATURE_STIBP) ||
!smt_possible ||
- spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ spectre_v2_in_eibrs_mode(spectre_v2_enabled))
return;
/*
@@ -2340,7 +2352,7 @@ static ssize_t mmio_stale_data_show_state(char *buf)
static char *stibp_state(void)
{
- if (spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ if (spectre_v2_in_eibrs_mode(spectre_v2_enabled))
return "";
switch (spectre_v2_user_stibp) {
--
2.39.2.637.g21b0678d19-goog
From: Roman Li <roman.li(a)amd.com>
[ Upstream commit 7a7175a2cd84b7874bebbf8e59f134557a34161b ]
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Wayne Lin <Wayne.Lin(a)amd.com>
Acked-by: Jasdeep Dhillon <jdhillon(a)amd.com>
Signed-off-by: Roman Li <roman.li(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 57678e6dcdc4c..98d51bc204172 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -773,12 +773,14 @@ static int dm_resume(void *handle)
list_for_each_entry(connector, &ddev->mode_config.connector_list, head) {
aconnector = to_amdgpu_dm_connector(connector);
+ if (!aconnector->dc_link)
+ continue;
+
/*
* this is the case when traversing through already created
* MST connectors, should be skipped
*/
- if (aconnector->dc_link &&
- aconnector->dc_link->type == dc_connection_mst_branch)
+ if (aconnector->dc_link->type == dc_connection_mst_branch)
continue;
mutex_lock(&aconnector->hpd_lock);
--
2.39.0
From: Roman Li <roman.li(a)amd.com>
[ Upstream commit 7a7175a2cd84b7874bebbf8e59f134557a34161b ]
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Wayne Lin <Wayne.Lin(a)amd.com>
Acked-by: Jasdeep Dhillon <jdhillon(a)amd.com>
Signed-off-by: Roman Li <roman.li(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 9fd711005c1f5..1e7083bc8a527 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1206,12 +1206,14 @@ static int dm_resume(void *handle)
list_for_each_entry(connector, &ddev->mode_config.connector_list, head) {
aconnector = to_amdgpu_dm_connector(connector);
+ if (!aconnector->dc_link)
+ continue;
+
/*
* this is the case when traversing through already created
* MST connectors, should be skipped
*/
- if (aconnector->dc_link &&
- aconnector->dc_link->type == dc_connection_mst_branch)
+ if (aconnector->dc_link->type == dc_connection_mst_branch)
continue;
mutex_lock(&aconnector->hpd_lock);
--
2.39.0
From: Roman Li <roman.li(a)amd.com>
[ Upstream commit 7a7175a2cd84b7874bebbf8e59f134557a34161b ]
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Wayne Lin <Wayne.Lin(a)amd.com>
Acked-by: Jasdeep Dhillon <jdhillon(a)amd.com>
Signed-off-by: Roman Li <roman.li(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fbe15f4b75fd5..dbdf0e210522c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2051,12 +2051,14 @@ static int dm_resume(void *handle)
drm_for_each_connector_iter(connector, &iter) {
aconnector = to_amdgpu_dm_connector(connector);
+ if (!aconnector->dc_link)
+ continue;
+
/*
* this is the case when traversing through already created
* MST connectors, should be skipped
*/
- if (aconnector->dc_link &&
- aconnector->dc_link->type == dc_connection_mst_branch)
+ if (aconnector->dc_link->type == dc_connection_mst_branch)
continue;
mutex_lock(&aconnector->hpd_lock);
--
2.39.0
Attention: Sir
Our Company is willing, ready to help you grow your network and offer
you Loan funds to complete and fund your existing Projects. We can
send you our Company Terms and Condition after review of your project
plan and executive summary of your project, if you are serious and
Interested contact us for further Information:
Best regards,
Adel Aldoseri
Attention: Sir
Our Company is willing, ready to help you grow your network and offer
you Loan funds to complete and fund your existing Projects. We can
send you our Company Terms and Condition after review of your project
plan and executive summary of your project, if you are serious and
Interested contact us for further Information
Best regards,
Donald Anderson
This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a.
The should_skip_kasan_poison() function reads the PG_skip_kasan_poison
flag from page->flags. However, this line of code in free_pages_prepare():
page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
clears most of page->flags, including PG_skip_kasan_poison, before calling
should_skip_kasan_poison(), which meant that it would never return true
as a result of the page flag being set. Therefore, fix the code to call
should_skip_kasan_poison() before clearing the flags, as we were doing
before the reverted patch.
Signed-off-by: Peter Collingbourne <pcc(a)google.com>
Fixes: 487a32ec24be ("kasan: drop skip_kasan_poison variable in free_pages_prepare")
Cc: <stable(a)vger.kernel.org> # 6.1
Link: https://linux-review.googlesource.com/id/Ic4f13affeebd20548758438bb9ed9ca40…
---
mm/page_alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ac1fc986af44..7136c36c5d01 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1398,6 +1398,7 @@ static __always_inline bool free_pages_prepare(struct page *page,
unsigned int order, bool check_free, fpi_t fpi_flags)
{
int bad = 0;
+ bool skip_kasan_poison = should_skip_kasan_poison(page, fpi_flags);
bool init = want_init_on_free();
VM_BUG_ON_PAGE(PageTail(page), page);
@@ -1470,7 +1471,7 @@ static __always_inline bool free_pages_prepare(struct page *page,
* With hardware tag-based KASAN, memory tags must be set before the
* page becomes unavailable via debug_pagealloc or arch_free_page.
*/
- if (!should_skip_kasan_poison(page, fpi_flags)) {
+ if (!skip_kasan_poison) {
kasan_poison_pages(page, order, init);
/* Memory is already initialized if KASAN did it internally. */
--
2.39.2.637.g21b0678d19-goog
The patch titled
Subject: fs/cramfs/inode.c: initialize file_ra_state
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
fs-cramfs-inodec-initialize-file_ra_state.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: Andrew Morton <akpm(a)linux-foundation.org>
Subject: fs/cramfs/inode.c: initialize file_ra_state
Date: Sun Feb 26 12:31:11 PM PST 2023
file_ra_state_init() assumes that the file_ra_state has been zeroed out.
Fixes a KMSAN used-unintialized issue (at least).
Fixes: cf948cbc35e80 ("cramfs: read_mapping_page() is synchronous")
Reported-by: syzbot <syzbot+8ce7f8308d91e6b8bbe2(a)syzkaller.appspotmail.com>
Link: https://lkml.kernel.org/r/0000000000008f74e905f56df987@google.com
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Nicolas Pitre <nico(a)fluxnic.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/cramfs/inode.c~fs-cramfs-inodec-initialize-file_ra_state
+++ b/fs/cramfs/inode.c
@@ -183,7 +183,7 @@ static void *cramfs_blkdev_read(struct super_block *sb, unsigned int offset,
unsigned int len)
{
struct address_space *mapping = sb->s_bdev->bd_inode->i_mapping;
- struct file_ra_state ra;
+ struct file_ra_state ra = {};
struct page *pages[BLKS_PER_BUF];
unsigned i, blocknr, buffer;
unsigned long devsize;
_
Patches currently in -mm which might be from akpm(a)linux-foundation.org are
fs-cramfs-inodec-initialize-file_ra_state.patch
mm-page_alloc-reduce-page-alloc-free-sanity-checks-checkpatch-fixes.patch
mm-page_alloc-reduce-page-alloc-free-sanity-checks-fix.patch
mm-userfaultfd-support-wp-on-multiple-vmas-fix.patch
The patch titled
Subject: fs: hfsplus: fix UAF issue in hfsplus_put_super
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
fs-hfsplus-fix-uaf-issue-in-hfsplus_put_super.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: Dongliang Mu <mudongliangabcd(a)gmail.com>
Subject: fs: hfsplus: fix UAF issue in hfsplus_put_super
Date: Sun, 26 Feb 2023 20:49:47 +0800
The current hfsplus_put_super first calls hfs_btree_close on
sbi->ext_tree, then invokes iput on sbi->hidden_dir, resulting in an
use-after-free issue in hfsplus_release_folio.
As shown in hfsplus_fill_super, the error handling code also calls iput
before hfs_btree_close.
To fix this error, we move all iput calls before hfsplus_btree_close.
Note that this patch is tested on Syzbot.
Link: https://lkml.kernel.org/r/20230226124948.3175736-1-mudongliangabcd@gmail.com
Reported-by: syzbot+57e3e98f7e3b80f64d56(a)syzkaller.appspotmail.com
Tested-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com>
Cc: Bart Van Assche <bvanassche(a)acm.org>
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Roman Gushchin <roman.gushchin(a)linux.dev>
Cc: "Theodore Ts'o" <tytso(a)mit.edu>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/hfsplus/super.c~fs-hfsplus-fix-uaf-issue-in-hfsplus_put_super
+++ b/fs/hfsplus/super.c
@@ -295,11 +295,11 @@ static void hfsplus_put_super(struct super_block *sb)
hfsplus_sync_fs(sb, 1);
}
+ iput(sbi->alloc_file);
+ iput(sbi->hidden_dir);
hfs_btree_close(sbi->attr_tree);
hfs_btree_close(sbi->cat_tree);
hfs_btree_close(sbi->ext_tree);
- iput(sbi->alloc_file);
- iput(sbi->hidden_dir);
kfree(sbi->s_vhdr_buf);
kfree(sbi->s_backup_vhdr_buf);
unload_nls(sbi->nls);
_
Patches currently in -mm which might be from mudongliangabcd(a)gmail.com are
fs-hfsplus-fix-uaf-issue-in-hfsplus_put_super.patch
The patch titled
Subject: panic: fix the panic_print NMI backtrace setting
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
panic-fixes-the-panic_print-nmi-backtrace-setting.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: "Guilherme G. Piccoli" <gpiccoli(a)igalia.com>
Subject: panic: fix the panic_print NMI backtrace setting
Date: Sun, 26 Feb 2023 13:08:38 -0300
Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in
panic_print") introduced a setting for the "panic_print" kernel parameter
to allow users to request a NMI backtrace on panic. Problem is that the
panic_print handling happens after the secondary CPUs are already
disabled, hence this option ended-up being kind of a no-op - kernel skips
the NMI trace in idling CPUs, which is the case of offline CPUs.
Fix it by checking the NMI backtrace bit in the panic_print prior to the
CPU disabling function.
Link: https://lkml.kernel.org/r/20230226160838.414257-1-gpiccoli@igalia.com
Fixes: 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in panic_print")
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com>
Cc: <stable(a)vger.kernel.org>
Cc: Baoquan He <bhe(a)redhat.com>
Cc: Dave Young <dyoung(a)redhat.com>
Cc: Feng Tang <feng.tang(a)intel.com>
Cc: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez(a)hitachi.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Michael Kelley <mikelley(a)microsoft.com>
Cc: Petr Mladek <pmladek(a)suse.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/kernel/panic.c~panic-fixes-the-panic_print-nmi-backtrace-setting
+++ b/kernel/panic.c
@@ -212,9 +212,6 @@ static void panic_print_sys_info(bool console_flush)
return;
}
- if (panic_print & PANIC_PRINT_ALL_CPU_BT)
- trigger_all_cpu_backtrace();
-
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
@@ -244,6 +241,30 @@ void check_panic_on_warn(const char *origin)
origin, limit);
}
+/*
+ * Helper that triggers the NMI backtrace (if set in panic_print)
+ * and then performs the secondary CPUs shutdown - we cannot have
+ * the NMI backtrace after the CPUs are off!
+ */
+static void panic_other_cpus_shutdown(bool crash_kexec)
+{
+ if (panic_print & PANIC_PRINT_ALL_CPU_BT)
+ trigger_all_cpu_backtrace();
+
+ /*
+ * Note that smp_send_stop() is the usual SMP shutdown function,
+ * which unfortunately may not be hardened to work in a panic
+ * situation. If we want to do crash dump after notifier calls
+ * and kmsg_dump, we will need architecture dependent extra
+ * bits in addition to stopping other CPUs, hence we rely on
+ * crash_smp_send_stop() for that.
+ */
+ if (!crash_kexec)
+ smp_send_stop();
+ else
+ crash_smp_send_stop();
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -334,23 +355,10 @@ void panic(const char *fmt, ...)
*
* Bypass the panic_cpu check and call __crash_kexec directly.
*/
- if (!_crash_kexec_post_notifiers) {
+ if (!_crash_kexec_post_notifiers)
__crash_kexec(NULL);
- /*
- * Note smp_send_stop is the usual smp shutdown function, which
- * unfortunately means it may not be hardened to work in a
- * panic situation.
- */
- smp_send_stop();
- } else {
- /*
- * If we want to do crash dump after notifier calls and
- * kmsg_dump, we will need architecture dependent extra
- * works in addition to stopping other CPUs.
- */
- crash_smp_send_stop();
- }
+ panic_other_cpus_shutdown(_crash_kexec_post_notifiers);
/*
* Run any panic handlers, including those that might need to
_
Patches currently in -mm which might be from gpiccoli(a)igalia.com are
panic-fixes-the-panic_print-nmi-backtrace-setting.patch
I trust you are staying safe and well, I am Franklin C. James QC. from Glasgow, Scotland. I have an investment proposition for your consideration and more details will be revealed once your interest is indicated.
Yours in service,
Franklin C. James QC.
____________________
Secretary: Phillip Hernandez
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
From: Guo Ren <guoren(a)linux.alibaba.com>
After use_asid_allocator is enabled, the userspace application will
crash by stale TLB entries. Because only using cpumask_clear_cpu without
local_flush_tlb_all couldn't guarantee CPU's TLB entries were fresh.
Then set_mm_asid would cause the user space application to get a stale
value by stale TLB entry, but set_mm_noasid is okay.
Here is the symptom of the bug:
unhandled signal 11 code 0x1 (coredump)
0x0000003fd6d22524 <+4>: auipc s0,0x70
0x0000003fd6d22528 <+8>: ld s0,-148(s0) # 0x3fd6d92490
=> 0x0000003fd6d2252c <+12>: ld a5,0(s0)
(gdb) i r s0
s0 0x8082ed1cc3198b21 0x8082ed1cc3198b21
(gdb) x /2x 0x3fd6d92490
0x3fd6d92490: 0xd80ac8a8 0x0000003f
The core dump file shows that register s0 is wrong, but the value in
memory is correct. Because 'ld s0, -148(s0)' used a stale mapping entry
in TLB and got a wrong result from an incorrect physical address.
When the task ran on CPU0, which loaded/speculative-loaded the value of
address(0x3fd6d92490), then the first version of the mapping entry was
PTWed into CPU0's TLB.
When the task switched from CPU0 to CPU1 (No local_tlb_flush_all here by
asid), it happened to write a value on the address (0x3fd6d92490). It
caused do_page_fault -> wp_page_copy -> ptep_clear_flush ->
ptep_get_and_clear & flush_tlb_page.
The flush_tlb_page used mm_cpumask(mm) to determine which CPUs need TLB
flush, but CPU0 had cleared the CPU0's mm_cpumask in the previous
switch_mm. So we only flushed the CPU1 TLB and set the second version
mapping of the PTE. When the task switched from CPU1 to CPU0 again, CPU0
still used a stale TLB mapping entry which contained a wrong target
physical address. It raised a bug when the task happened to read that
value.
CPU0 CPU1
- switch 'task' in
- read addr (Fill stale mapping
entry into TLB)
- switch 'task' out (no tlb_flush)
- switch 'task' in (no tlb_flush)
- write addr cause pagefault
do_page_fault() (change to
new addr mapping)
wp_page_copy()
ptep_clear_flush()
ptep_get_and_clear()
& flush_tlb_page()
write new value into addr
- switch 'task' out (no tlb_flush)
- switch 'task' in (no tlb_flush)
- read addr again (Use stale
mapping entry in TLB)
get wrong value from old phyical
addr, BUG!
The solution is to keep all CPUs' footmarks of cpumask(mm) in switch_mm,
which could guarantee to invalidate all stale TLB entries during TLB
flush.
Fixes: 65d4b9c53017 ("RISC-V: Implement ASID allocator")
Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com>
Signed-off-by: Guo Ren <guoren(a)kernel.org>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com>
Tested-by: Zong Li <zong.li(a)sifive.com>
Tested-by: Sergey Matyukevich <sergey.matyukevich(a)syntacore.com>
Cc: Anup Patel <apatel(a)ventanamicro.com>
Cc: Palmer Dabbelt <palmer(a)rivosinc.com>
Cc: stable(a)vger.kernel.org
---
arch/riscv/mm/context.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/mm/context.c b/arch/riscv/mm/context.c
index 7acbfbd14557..0f784e3d307b 100644
--- a/arch/riscv/mm/context.c
+++ b/arch/riscv/mm/context.c
@@ -205,12 +205,24 @@ static void set_mm_noasid(struct mm_struct *mm)
local_flush_tlb_all();
}
-static inline void set_mm(struct mm_struct *mm, unsigned int cpu)
+static inline void set_mm(struct mm_struct *prev,
+ struct mm_struct *next, unsigned int cpu)
{
- if (static_branch_unlikely(&use_asid_allocator))
- set_mm_asid(mm, cpu);
- else
- set_mm_noasid(mm);
+ /*
+ * The mm_cpumask indicates which harts' TLBs contain the virtual
+ * address mapping of the mm. Compared to noasid, using asid
+ * can't guarantee that stale TLB entries are invalidated because
+ * the asid mechanism wouldn't flush TLB for every switch_mm for
+ * performance. So when using asid, keep all CPUs footmarks in
+ * cpumask() until mm reset.
+ */
+ cpumask_set_cpu(cpu, mm_cpumask(next));
+ if (static_branch_unlikely(&use_asid_allocator)) {
+ set_mm_asid(next, cpu);
+ } else {
+ cpumask_clear_cpu(cpu, mm_cpumask(prev));
+ set_mm_noasid(next);
+ }
}
static int __init asids_init(void)
@@ -264,7 +276,8 @@ static int __init asids_init(void)
}
early_initcall(asids_init);
#else
-static inline void set_mm(struct mm_struct *mm, unsigned int cpu)
+static inline void set_mm(struct mm_struct *prev,
+ struct mm_struct *next, unsigned int cpu)
{
/* Nothing to do here when there is no MMU */
}
@@ -317,10 +330,7 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next,
*/
cpu = smp_processor_id();
- cpumask_clear_cpu(cpu, mm_cpumask(prev));
- cpumask_set_cpu(cpu, mm_cpumask(next));
-
- set_mm(next, cpu);
+ set_mm(prev, next, cpu);
flush_icache_deferred(next, cpu);
}
--
2.39.2
Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in panic_print")
introduced a setting for the "panic_print" kernel parameter to allow
users to request a NMI backtrace on panic. Problem is that the panic_print
handling happens after the secondary CPUs are already disabled, hence
this option ended-up being kind of a no-op - kernel skips the NMI trace
in idling CPUs, which is the case of offline CPUs.
Fix it by checking the NMI backtrace bit in the panic_print prior to
the CPU disabling function.
Fixes: 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in panic_print")
Cc: stable(a)vger.kernel.org
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com>
---
V4:
- Sent as standalone patch, rebased against v6.2-rc7.
V2 / V3:
- New patch, there was no V1 of this one.
Link for V3: https://lore.kernel.org/lkml/20220819221731.480795-12-gpiccoli@igalia.com/
Hi folks, thanks in advance for reviews/comments.
Notice that while at it, I got rid of the "crash_kexec_post_notifiers"
local copy in panic(). This was introduced by commit b26e27ddfd2a
("kexec: use core_param for crash_kexec_post_notifiers boot option"),
but it is not clear from comments or commit message why this local copy
is required.
My understanding is that it's a mechanism to prevent some concurrency,
in case some other CPU modify this variable while panic() is running.
I find it very unlikely, hence I removed it - but if people consider
this copy needed, I can respin this patch and keep it, even providing a
comment about that, in order to be explict about its need.
Let me know your thoughts!
Cheers,
Guilherme
kernel/panic.c | 47 +++++++++++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 463c9295bc28..f45ee88be8a2 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -211,9 +211,6 @@ static void panic_print_sys_info(bool console_flush)
return;
}
- if (panic_print & PANIC_PRINT_ALL_CPU_BT)
- trigger_all_cpu_backtrace();
-
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
@@ -243,6 +240,30 @@ void check_panic_on_warn(const char *origin)
origin, limit);
}
+/*
+ * Helper that triggers the NMI backtrace (if set in panic_print)
+ * and then performs the secondary CPUs shutdown - we cannot have
+ * the NMI backtrace after the CPUs are off!
+ */
+static void panic_other_cpus_shutdown(void)
+{
+ if (panic_print & PANIC_PRINT_ALL_CPU_BT)
+ trigger_all_cpu_backtrace();
+
+ /*
+ * Note that smp_send_stop() is the usual SMP shutdown function,
+ * which unfortunately may not be hardened to work in a panic
+ * situation. If we want to do crash dump after notifier calls
+ * and kmsg_dump, we will need architecture dependent extra
+ * bits in addition to stopping other CPUs, hence we rely on
+ * crash_smp_send_stop() for that.
+ */
+ if (!crash_kexec_post_notifiers)
+ smp_send_stop();
+ else
+ crash_smp_send_stop();
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -258,7 +279,6 @@ void panic(const char *fmt, ...)
long i, i_next = 0, len;
int state = 0;
int old_cpu, this_cpu;
- bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;
if (panic_on_warn) {
/*
@@ -333,23 +353,10 @@ void panic(const char *fmt, ...)
*
* Bypass the panic_cpu check and call __crash_kexec directly.
*/
- if (!_crash_kexec_post_notifiers) {
+ if (!crash_kexec_post_notifiers)
__crash_kexec(NULL);
- /*
- * Note smp_send_stop is the usual smp shutdown function, which
- * unfortunately means it may not be hardened to work in a
- * panic situation.
- */
- smp_send_stop();
- } else {
- /*
- * If we want to do crash dump after notifier calls and
- * kmsg_dump, we will need architecture dependent extra
- * works in addition to stopping other CPUs.
- */
- crash_smp_send_stop();
- }
+ panic_other_cpus_shutdown();
/*
* Run any panic handlers, including those that might need to
@@ -370,7 +377,7 @@ void panic(const char *fmt, ...)
*
* Bypass the panic_cpu check and call __crash_kexec directly.
*/
- if (_crash_kexec_post_notifiers)
+ if (crash_kexec_post_notifiers)
__crash_kexec(NULL);
console_unblank();
--
2.39.1
Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in panic_print")
introduced a setting for the "panic_print" kernel parameter to allow
users to request a NMI backtrace on panic. Problem is that the panic_print
handling happens after the secondary CPUs are already disabled, hence
this option ended-up being kind of a no-op - kernel skips the NMI trace
in idling CPUs, which is the case of offline CPUs.
Fix it by checking the NMI backtrace bit in the panic_print prior to
the CPU disabling function.
Fixes: 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in panic_print")
Cc: stable(a)vger.kernel.org
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com>
---
V5:
- Kept the local version of "crash_kexec_post_notifiers", since
this is standalone fix that should be backported to stable. Hence,
it's not a good idea to mess with it in this patch (thanks Andrew!).
V4:
- Sent as standalone patch, rebased against v6.2-rc7.
- Link: https://lore.kernel.org/lkml/20230210203510.1734835-1-gpiccoli@igalia.com/
kernel/panic.c | 44 ++++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 463c9295bc28..e026191a0a07 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -211,9 +211,6 @@ static void panic_print_sys_info(bool console_flush)
return;
}
- if (panic_print & PANIC_PRINT_ALL_CPU_BT)
- trigger_all_cpu_backtrace();
-
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
@@ -243,6 +240,30 @@ void check_panic_on_warn(const char *origin)
origin, limit);
}
+/*
+ * Helper that triggers the NMI backtrace (if set in panic_print)
+ * and then performs the secondary CPUs shutdown - we cannot have
+ * the NMI backtrace after the CPUs are off!
+ */
+static void panic_other_cpus_shutdown(bool crash_kexec)
+{
+ if (panic_print & PANIC_PRINT_ALL_CPU_BT)
+ trigger_all_cpu_backtrace();
+
+ /*
+ * Note that smp_send_stop() is the usual SMP shutdown function,
+ * which unfortunately may not be hardened to work in a panic
+ * situation. If we want to do crash dump after notifier calls
+ * and kmsg_dump, we will need architecture dependent extra
+ * bits in addition to stopping other CPUs, hence we rely on
+ * crash_smp_send_stop() for that.
+ */
+ if (!crash_kexec)
+ smp_send_stop();
+ else
+ crash_smp_send_stop();
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -333,23 +354,10 @@ void panic(const char *fmt, ...)
*
* Bypass the panic_cpu check and call __crash_kexec directly.
*/
- if (!_crash_kexec_post_notifiers) {
+ if (!_crash_kexec_post_notifiers)
__crash_kexec(NULL);
- /*
- * Note smp_send_stop is the usual smp shutdown function, which
- * unfortunately means it may not be hardened to work in a
- * panic situation.
- */
- smp_send_stop();
- } else {
- /*
- * If we want to do crash dump after notifier calls and
- * kmsg_dump, we will need architecture dependent extra
- * works in addition to stopping other CPUs.
- */
- crash_smp_send_stop();
- }
+ panic_other_cpus_shutdown(_crash_kexec_post_notifiers);
/*
* Run any panic handlers, including those that might need to
--
2.39.1
I trust you are staying safe and well, I am Franklin C. James QC. from Glasgow, Scotland. I have an investment proposition for your consideration and more details will be revealed once your interest is indicated.
Yours in service,
Franklin C. James QC.
____________________
Secretary: Phillip Hernandez
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Setting the IBRS bit implicitly enables STIBP to protect against
cross-thread branch target injection. With enhanced IBRS, the bit it set
once and is not cleared again. However, on CPUs with just legacy IBRS,
IBRS bit set on user -> kernel and cleared on kernel -> user (a.k.a
KERNEL_IBRS). Clearing this bit also disables the implicitly enabled
STIBP, thus requiring some form of cross-thread protection in userspace.
Enable STIBP, either opt-in via prctl or seccomp, or always on depending
on the choice of mitigation selected via spectre_v2_user.
Reported-by: José Oliveira <joseloliveira11(a)gmail.com>
Reported-by: Rodrigo Branco <rodrigo(a)kernelhacking.com>
Reviewed-by: Alexandra Sandulescu <aesa(a)google.com>
Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
Cc: stable(a)vger.kernel.org
Signed-off-by: KP Singh <kpsingh(a)kernel.org>
---
arch/x86/kernel/cpu/bugs.c | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 85168740f76a..5be6075d8e36 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1124,14 +1124,30 @@ spectre_v2_parse_user_cmdline(void)
return SPECTRE_V2_USER_CMD_AUTO;
}
-static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
+static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation mode)
{
- return mode == SPECTRE_V2_IBRS ||
- mode == SPECTRE_V2_EIBRS ||
+ return mode == SPECTRE_V2_EIBRS ||
mode == SPECTRE_V2_EIBRS_RETPOLINE ||
mode == SPECTRE_V2_EIBRS_LFENCE;
}
+static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
+{
+ return spectre_v2_in_eibrs_mode(mode) || mode == SPECTRE_V2_IBRS;
+}
+
+static inline bool spectre_v2_user_needs_stibp(enum spectre_v2_mitigation mode)
+{
+ /*
+ * enhanced IBRS also protects against user-mode attacks as the IBRS bit
+ * remains always set which implicitly enables cross-thread protections.
+ * However, In legacy IBRS mode, the IBRS bit is set only in kernel
+ * and cleared on return to userspace. This disables the implicit
+ * cross-thread protections and STIBP is needed.
+ */
+ return !spectre_v2_in_eibrs_mode(mode);
+}
+
static void __init
spectre_v2_user_select_mitigation(void)
{
@@ -1193,13 +1209,8 @@ spectre_v2_user_select_mitigation(void)
"always-on" : "conditional");
}
- /*
- * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossible,
- * STIBP is not required.
- */
- if (!boot_cpu_has(X86_FEATURE_STIBP) ||
- !smt_possible ||
- spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible ||
+ !spectre_v2_user_needs_stibp(spectre_v2_enabled))
return;
/*
@@ -2327,7 +2338,7 @@ static ssize_t mmio_stale_data_show_state(char *buf)
static char *stibp_state(void)
{
- if (spectre_v2_in_ibrs_mode(spectre_v2_enabled))
+ if (!spectre_v2_user_needs_stibp(spectre_v2_enabled))
return "";
switch (spectre_v2_user_stibp) {
--
2.39.2.637.g21b0678d19-goog
The following changes since commit ceaa837f96adb69c0df0397937cd74991d5d821a:
Linux 6.2-rc8 (2023-02-12 14:10:17 -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 deeacf35c922da579637f5db625af20baafc66ed:
vdpa/mlx5: support device features provisioning (2023-02-20 19:27:00 -0500)
Note: dropped a patch close to the bottom of the stack at the last
minute so the commits differ but all of these have been in next already.
The dropped patch just added a new query ioctl so not interacting with
anything else in the pull.
----------------------------------------------------------------
virtio,vhost,vdpa: features, fixes
device feature provisioning in ifcvf, mlx5
new SolidNET driver
support for zoned block device in virtio blk
numa support in virtio pmem
VIRTIO_F_RING_RESET support in vhost-net
more debugfs entries in mlx5
resume support in vdpa
completion batching in virtio blk
cleanup of dma api use in vdpa
now simulating more features in vdpa-sim
documentation, features, fixes all over the place
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
----------------------------------------------------------------
Alvaro Karsz (4):
PCI: Add SolidRun vendor ID
PCI: Avoid FLR for SolidRun SNET DPU rev 1
virtio: vdpa: new SolidNET DPU driver.
vhost-vdpa: print warning when vhost_vdpa_alloc_domain fails
Bagas Sanjaya (3):
docs: driver-api: virtio: parenthesize external reference targets
docs: driver-api: virtio: slightly reword virtqueues allocation paragraph
docs: driver-api: virtio: commentize spec version checking
Bo Liu (1):
vhost-scsi: convert sysfs snprintf and sprintf to sysfs_emit
Colin Ian King (1):
vdpa: Fix a couple of spelling mistakes in some messages
Dmitry Fomichev (1):
virtio-blk: add support for zoned block devices
Eli Cohen (6):
vdpa/mlx5: Move some definitions to a new header file
vdpa/mlx5: Add debugfs subtree
vdpa/mlx5: Add RX counters to debugfs
vdpa/mlx5: Directly assign memory key
vdpa/mlx5: Don't clear mr struct on destroy MR
vdpa/mlx5: Initialize CVQ iotlb spinlock
Eugenio Pérez (2):
vdpa_sim: not reset state in vdpasim_queue_ready
vdpa_sim_net: Offer VIRTIO_NET_F_STATUS
Jason Wang (11):
vdpa_sim: use weak barriers
vdpa_sim: switch to use __vdpa_alloc_device()
vdpasim: customize allocation size
vdpa_sim: support vendor statistics
vdpa_sim_net: vendor satistics
vdpa_sim: get rid of DMA ops
virtio_ring: per virtqueue dma device
vdpa: introduce get_vq_dma_device()
virtio-vdpa: support per vq dma device
vdpa: set dma mask for vDPA device
vdpa: mlx5: support per virtqueue dma device
Kangjie Xu (1):
vhost-net: support VIRTIO_F_RING_RESET
Liming Wu (2):
vhost-test: remove meaningless debug info
vhost: remove unused paramete
Michael S. Tsirkin (3):
virtio_blk: temporary variable type tweak
virtio_blk: zone append in header type tweak
virtio_blk: mark all zone fields LE
Michael Sammler (1):
virtio_pmem: populate numa information
Ricardo Cañuelo (1):
docs: driver-api: virtio: virtio on Linux
Sebastien Boeuf (4):
vdpa: Add resume operation
vhost-vdpa: Introduce RESUME backend feature bit
vhost-vdpa: uAPI to resume the device
vdpa_sim: Implement resume vdpa op
Shunsuke Mie (2):
vringh: fix a typo in comments for vringh_kiov
tools/virtio: enable to build with retpoline
Si-Wei Liu (6):
vdpa: fix improper error message when adding vdpa dev
vdpa: conditionally read STATUS in config space
vdpa: validate provisioned device features against specified attribute
vdpa: validate device feature provisioning against supported class
vdpa/mlx5: make MTU/STATUS presence conditional on feature bits
vdpa/mlx5: support device features provisioning
Suwan Kim (2):
virtio-blk: set req->state to MQ_RQ_COMPLETE after polling I/O is finished
virtio-blk: support completion batching for the IRQ path
Zheng Wang (1):
scsi: virtio_scsi: fix handling of kmalloc failure
Zhu Lingshan (12):
vDPA/ifcvf: decouple hw features manipulators from the adapter
vDPA/ifcvf: decouple config space ops from the adapter
vDPA/ifcvf: alloc the mgmt_dev before the adapter
vDPA/ifcvf: decouple vq IRQ releasers from the adapter
vDPA/ifcvf: decouple config IRQ releaser from the adapter
vDPA/ifcvf: decouple vq irq requester from the adapter
vDPA/ifcvf: decouple config/dev IRQ requester and vectors allocator from the adapter
vDPA/ifcvf: ifcvf_request_irq works on ifcvf_hw
vDPA/ifcvf: manage ifcvf_hw in the mgmt_dev
vDPA/ifcvf: allocate the adapter in dev_add()
vDPA/ifcvf: retire ifcvf_private_to_vf
vDPA/ifcvf: implement features provisioning
Documentation/driver-api/index.rst | 1 +
Documentation/driver-api/virtio/index.rst | 11 +
Documentation/driver-api/virtio/virtio.rst | 145 +++
.../driver-api/virtio/writing_virtio_drivers.rst | 197 ++++
MAINTAINERS | 5 +
drivers/block/virtio_blk.c | 468 ++++++++-
drivers/nvdimm/virtio_pmem.c | 11 +-
drivers/pci/quirks.c | 8 +
drivers/scsi/virtio_scsi.c | 14 +-
drivers/vdpa/Kconfig | 30 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/ifcvf/ifcvf_base.c | 32 +-
drivers/vdpa/ifcvf/ifcvf_base.h | 10 +-
drivers/vdpa/ifcvf/ifcvf_main.c | 162 ++-
drivers/vdpa/mlx5/Makefile | 2 +-
drivers/vdpa/mlx5/core/mr.c | 1 -
drivers/vdpa/mlx5/core/resources.c | 3 +-
drivers/vdpa/mlx5/net/debug.c | 152 +++
drivers/vdpa/mlx5/net/mlx5_vnet.c | 261 +++--
drivers/vdpa/mlx5/net/mlx5_vnet.h | 94 ++
drivers/vdpa/solidrun/Makefile | 6 +
drivers/vdpa/solidrun/snet_hwmon.c | 188 ++++
drivers/vdpa/solidrun/snet_main.c | 1111 ++++++++++++++++++++
drivers/vdpa/solidrun/snet_vdpa.h | 194 ++++
drivers/vdpa/vdpa.c | 110 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 233 ++--
drivers/vdpa/vdpa_sim/vdpa_sim.h | 7 +-
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 1 +
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 219 +++-
drivers/vhost/net.c | 5 +-
drivers/vhost/scsi.c | 6 +-
drivers/vhost/test.c | 3 -
drivers/vhost/vdpa.c | 39 +-
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 2 +-
drivers/vhost/vsock.c | 2 +-
drivers/virtio/virtio_ring.c | 133 ++-
drivers/virtio/virtio_vdpa.c | 13 +-
include/linux/pci_ids.h | 2 +
include/linux/vdpa.h | 12 +-
include/linux/virtio_config.h | 8 +-
include/linux/virtio_ring.h | 16 +
include/linux/vringh.h | 2 +-
include/uapi/linux/vhost.h | 8 +
include/uapi/linux/vhost_types.h | 2 +
include/uapi/linux/virtio_blk.h | 105 ++
tools/virtio/Makefile | 2 +-
47 files changed, 3536 insertions(+), 503 deletions(-)
create mode 100644 Documentation/driver-api/virtio/index.rst
create mode 100644 Documentation/driver-api/virtio/virtio.rst
create mode 100644 Documentation/driver-api/virtio/writing_virtio_drivers.rst
create mode 100644 drivers/vdpa/mlx5/net/debug.c
create mode 100644 drivers/vdpa/mlx5/net/mlx5_vnet.h
create mode 100644 drivers/vdpa/solidrun/Makefile
create mode 100644 drivers/vdpa/solidrun/snet_hwmon.c
create mode 100644 drivers/vdpa/solidrun/snet_main.c
create mode 100644 drivers/vdpa/solidrun/snet_vdpa.h