* [PATCH v2] drivers: scsi: replace snprintf in show functions with sysfs_emit
From: cgel.zte @ 2021-11-02 6:59 UTC (permalink / raw)
To: tyreld
Cc: Jing Yao, martin.petersen, linux-scsi, jejb, linux-kernel, paulus,
linuxppc-dev, Zeal Robot
From: Jing Yao <yao.jing2@zte.com.cn>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yao <yao.jing2@zte.com.cn>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index d0eab5700dc5..69bf55c037a5 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -3403,7 +3403,7 @@ static ssize_t ibmvfc_show_host_partition_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.partition_name);
}
@@ -3413,7 +3413,7 @@ static ssize_t ibmvfc_show_host_device_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.device_name);
}
@@ -3423,7 +3423,7 @@ static ssize_t ibmvfc_show_host_loc_code(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.port_loc_code);
}
@@ -3433,7 +3433,7 @@ static ssize_t ibmvfc_show_host_drc_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.drc_name);
}
@@ -3442,7 +3442,7 @@ static ssize_t ibmvfc_show_host_npiv_version(struct device *dev,
{
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%d\n", be32_to_cpu(vhost->login_buf->resp.version));
+ return sysfs_emit(buf, "%d\n", be32_to_cpu(vhost->login_buf->resp.version));
}
static ssize_t ibmvfc_show_host_capabilities(struct device *dev,
@@ -3450,7 +3450,7 @@ static ssize_t ibmvfc_show_host_capabilities(struct device *dev,
{
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%llx\n", be64_to_cpu(vhost->login_buf->resp.capabilities));
+ return sysfs_emit(buf, "%llx\n", be64_to_cpu(vhost->login_buf->resp.capabilities));
}
/**
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v12 1/2] tty: hvc: pass DMA capable memory to put_chars()
From: Jiri Slaby @ 2021-11-02 6:33 UTC (permalink / raw)
To: Xianting Tian, gregkh, amit, arnd, osandov
Cc: sfr, shile.zhang, linuxppc-dev, linux-kernel, virtualization
In-Reply-To: <20211028150954.1356334-2-xianting.tian@linux.alibaba.com>
On 28. 10. 21, 17:09, Xianting Tian wrote:
> As well known, hvc backend can register its opertions to hvc backend.
> the operations contain put_chars(), get_chars() and so on.
>
> Some hvc backend may do dma in its operations. eg, put_chars() of
> virtio-console. But in the code of hvc framework, it may pass DMA
> incapable memory to put_chars() under a specific configuration, which
> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
> 1, c[] is on stack,
> hvc_console_print():
> char c[N_OUTBUF] __ALIGNED__;
> cons_ops[index]->put_chars(vtermnos[index], c, i);
> 2, ch is on stack,
> static void hvc_poll_put_char(,,char ch)
> {
> struct tty_struct *tty = driver->ttys[0];
> struct hvc_struct *hp = tty->driver_data;
> int n;
>
> do {
> n = hp->ops->put_chars(hp->vtermno, &ch, 1);
> } while (n <= 0);
> }
>
> Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
> is passed to virtio-console by hvc framework in above code. But I think
> the fix is aggressive, it directly uses kmemdup() to alloc new buffer
> from kmalloc area and do memcpy no matter the memory is in kmalloc area
> or not. But most importantly, it should better be fixed in the hvc
> framework, by changing it to never pass stack memory to the put_chars()
> function in the first place. Otherwise, we still face the same issue if
> a new hvc backend using dma added in the furture.
>
> In this patch, add 'char cons_outbuf[]' as part of 'struct hvc_struct',
> so hp->cons_outbuf is no longer the stack memory, we can use it in above
> cases safely. We also add lock to protect cons_outbuf instead of using
> the global lock of hvc.
>
> Introduce array cons_hvcs[] for hvc pointers next to the cons_ops[] and
> vtermnos[] arrays. With the array, we can easily find hvc's cons_outbuf
> and its lock.
Hi,
this is still overly complicated IMO. As I already noted in:
https://lore.kernel.org/all/5b728c71-a754-b3ef-4ad3-6e33db1b7647@kernel.org/
this:
=============
In fact, you need only a single char for the poll case
(hvc_poll_put_char), so hvc_struct needs to contain only c, not an array.
OTOH, you need c[N_OUTBUF] in the console case (hvc_console_print), but
not whole hvc_struct. So cons_hvcs should be an array of structs
composed of only the lock and the buffer.
=============
And I would do it even simpler now. One c[N_OUTBUF] buffer for all
consoles and a single lock.
And "char c" in struct hvc_struct.
No need for the complex logic in hvc_console_print.
> Introduce array cons_early_outbuf[] to ensure the mechanism of early
> console still work normally.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH kernel 0/4] Fixes for powerpc/pseries/iommu: Make use of DDW for indirect mapping
From: Michael Ellerman @ 2021-11-02 2:43 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Frederic Barrat, Leonardo Bras, Brian King
In-Reply-To: <20211020132315.2287178-1-aik@ozlabs.ru>
On Thu, 21 Oct 2021 00:23:11 +1100, Alexey Kardashevskiy wrote:
> Found some issues on SRIOV enabled PHYP.
> It probably should be one patch, or not?
>
> Please comment. Thanks.
>
>
>
> [...]
Patches 2-4 applied to powerpc/fixes.
[2/4] powerpc/pseries/iommu: Use correct vfree for it_map
https://git.kernel.org/powerpc/c/41ee7232fa5f3c034f22baa52bc287e494e2129a
[3/4] powerpc/pseries/iommu: Check if the default window in use before removing it
https://git.kernel.org/powerpc/c/92fe01b7c655b9767724e7d62bdded0761d232ff
[4/4] powerpc/pseries/iommu: Create huge DMA window if no MMIO32 is present
https://git.kernel.org/powerpc/c/d853adc7adf601d7d6823afe3ed396065a3e08d1
cheers
^ permalink raw reply
* Re: Fwd: Fwd: X stopped working with 5.14 on iBook
From: Finn Thain @ 2021-11-02 2:20 UTC (permalink / raw)
To: Christopher M. Riedl; +Cc: Stan Johnson, linuxppc-dev, Riccardo Mottola
In-Reply-To: <d5d0b396-7408-bdae-cf50-4b5f4e7b3184@csgroup.eu>
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is not
present there. Thus far, only PowerMac G4 systems are known to be affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using bisection.
So I've addressed this message to you. Can you help fix this regression?
Regards,
Finn
On Fri, 22 Oct 2021, Christophe Leroy wrote:
> ...
> >
> > -------- Forwarded Message --------
> > Subject: Fwd: X stopped working with 5.14 on iBook
> > Date: Fri, 22 Oct 2021 11:35:21 -0600
> > From: Stan Johnson
> > To: Christopher M. Riedl <cmr@codefail.de>
> > CC: Finn Thain <fthain@fastmail.com.au>
> >
> > Hello Christopher Riedl,
> >
> > Please see the message below, in which a git bisect identifies a commit
> > which may have stopped X from working on some PowerPC G4 systems
> > (specifically the G4 PowerBook and Cube, possibly others).
> >
> > I'm not sure how to proceed with further tests. If the identified commit
> > could not have caused the problem, then further testing may be needed.
> > Please let me know if you need any additional information.
> >
> > Hopefully your e-mail filter will allow messages from yahoo.com addresses.
> >
> > thanks for your help
> >
> > -Stan Johnson
> >
> > -------- Forwarded Message --------
> > Subject: Re: X stopped working with 5.14 on iBook
> > Date: Fri, 22 Oct 2021 11:25:14 -0600
> > From: Stan Johnson
> > To: debian-powerpc@lists.debian.org
> > CC: Riccardo Mottola <riccardo.mottola@libero.it>
> >
> > On 10/14/21 9:21 PM, Stan Johnson wrote:
> > > ...
> > > Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
> > > kernel source.
> > > ...
> > > X works with 5.14 using a tuned config file derived from 5.13 testing.
> > > ...
> >
> > Update:
> >
> > The issue originally reported by Riccardo Mottola was that X wasn't
> > working on a PowerBook G4 using Debian's default
> > vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
> > failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
> > sysvinit-core, Xfce and wdm installed. To test whether X works, I
> > disabled wdm, then I log in at the text console and run "startx". When X
> > fails, the screen goes blank and the backlight stays on; when X works,
> > the normal desktop comes up.
> >
> > X works in mainline v5.12 built using a config file based on Debian's
> > config-5.10.0-8-powerpc.
> >
> > X fails in mainline v5.13 built using a config file based on Debian's
> > config-5.10.0-8-powerpc.
> >
> > With much help and advice from Finn Thain, I was able to run a bisect
> > using a config file based on Debian's config-5.10.0-8-powerpc, with
> > v5.12 "good" and v5.13 "bad".
> >
> > $ git reset --hard
> > HEAD is now at 62fb9874f5da Linux 5.13
> > $ git bisect start v5.13
> > Updating files: 100% (12992/12992), done.
> > Previous HEAD position was 62fb9874f5da Linux 5.13
> > HEAD is now at 9f4ad9e425a1 Linux 5.12
> > $ git bisect bad v5.13
> > $ git bisect good v5.12
> > Bisecting: 8739 revisions left to test after this (roughly 13 steps)
> > > 85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
> > https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
> >
> > After the bisect, git reports this:
> >
> > ----------
> >
> > d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
> > commit d3ccc9781560af051554017c702631560bdc0811
> > Author: Christopher M. Riedl <cmr@codefail.de>
> > Date: Fri Feb 26 19:12:59 2021 -0600
> >
> > powerpc/signal: Use __get_user() to copy sigset_t
> >
> > Usually sigset_t is exactly 8B which is a "trivial" size and does not
> > warrant using __copy_from_user(). Use __get_user() directly in
> > anticipation of future work to remove the trivial size optimizations
> > from __copy_from_user().
> >
> > The ppc32 implementation of get_sigset_t() previously called
> > copy_from_user() which, unlike __copy_from_user(), calls access_ok().
> > Replacing this w/ __get_user() (no access_ok()) is fine here since both
> > callsites in signal_32.c are preceded by an earlier access_ok().
> >
> > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
> >
> > arch/powerpc/kernel/signal.h | 7 +++++++
> > arch/powerpc/kernel/signal_32.c | 2 +-
> > arch/powerpc/kernel/signal_64.c | 4 ++--
> > 3 files changed, 10 insertions(+), 3 deletions(-)
> >
>
^ permalink raw reply
* [PATCH] powerpc: Fix reference leak of node np in opal_lpc_init
From: He Ying @ 2021-11-02 1:59 UTC (permalink / raw)
To: mpe, benh, paulus, akpm, npiggin, aneesh.kumar; +Cc: linuxppc-dev, linux-kernel
When breaking from for_each_compatible_node body, we increase the
reference of node np. Then calling isa_bridge_init_non_pci()
will assign np to isa_bridge_devnode. It looks good. However,
other error paths in the code should put the node np back to avoid
the reference leak. Fix the problem by adding missing
of_node_put().
Signed-off-by: He Ying <heying24@huawei.com>
---
arch/powerpc/kernel/isa-bridge.c | 10 +++++++++-
arch/powerpc/platforms/powernv/opal-lpc.c | 6 +++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index 39c625737c09..bcf1d6024f9e 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -192,14 +192,17 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
u64 cbase, pbase, size = 0;
/* If we already have an ISA bridge, bail off */
- if (isa_bridge_devnode != NULL)
+ if (isa_bridge_devnode != NULL) {
+ of_node_put(np);
return;
+ }
pna = of_n_addr_cells(np);
if (of_property_read_u32(np, "#address-cells", &na) ||
of_property_read_u32(np, "#size-cells", &ns)) {
pr_warn("ISA: Non-PCI bridge %pOF is missing address format\n",
np);
+ of_node_put(np);
return;
}
@@ -207,6 +210,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
if (na != 2 || ns != 1) {
pr_warn("ISA: Non-PCI bridge %pOF has unsupported address format\n",
np);
+ of_node_put(np);
return;
}
rs = na + ns + pna;
@@ -216,6 +220,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
if (ranges == NULL || rlen < rs) {
pr_warn("ISA: Non-PCI bridge %pOF has absent or invalid ranges\n",
np);
+ of_node_put(np);
return;
}
@@ -233,6 +238,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
if (!size || !pbasep) {
pr_warn("ISA: Non-PCI bridge %pOF has no usable IO range\n",
np);
+ of_node_put(np);
return;
}
@@ -246,6 +252,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
if (pbase == OF_BAD_ADDR) {
pr_warn("ISA: Non-PCI bridge %pOF failed to translate IO base\n",
np);
+ of_node_put(np);
return;
}
@@ -253,6 +260,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)
if ((cbase & ~PAGE_MASK) || (pbase & ~PAGE_MASK)) {
pr_warn("ISA: Non-PCI bridge %pOF has non aligned IO range\n",
np);
+ of_node_put(np);
return;
}
diff --git a/arch/powerpc/platforms/powernv/opal-lpc.c b/arch/powerpc/platforms/powernv/opal-lpc.c
index 1e5d51db40f8..5647752b2d6a 100644
--- a/arch/powerpc/platforms/powernv/opal-lpc.c
+++ b/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -398,8 +398,11 @@ void __init opal_lpc_init(void)
opal_lpc_chip_id = of_get_ibm_chip_id(np);
break;
}
- if (opal_lpc_chip_id < 0)
+ if (opal_lpc_chip_id < 0) {
+ if (np)
+ of_node_put(np);
return;
+ }
/* Does it support direct mapping ? */
if (of_get_property(np, "ranges", NULL)) {
@@ -407,6 +410,7 @@ void __init opal_lpc_init(void)
opal_lpc_chip_id);
isa_bridge_init_non_pci(np);
} else {
+ of_node_put(np);
pr_info("OPAL: Found non-mapped LPC bus on chip %d\n",
opal_lpc_chip_id);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 11/45] arm64: Use do_kernel_power_off()
From: Catalin Marinas @ 2021-11-01 13:28 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Tomer Maimon,
Santosh Shilimkar, Rafael J . Wysocki, Boris Ostrovsky,
Linus Walleij, Dave Hansen, x86, Tali Perry, James E.J. Bottomley,
Thierry Reding, Guo Ren, Pavel Machek, H. Peter Anvin,
linux-riscv, Vincent Chen, Will Deacon, Greg Ungerer,
Stefano Stabellini, Benjamin Fair, Yoshinori Sato,
Krzysztof Kozlowski, linux-sh, Lee Jones, Helge Deller,
Daniel Lezcano, Russell King, linux-csky, Jonathan Hunter,
Tony Lindgren, Chen-Yu Tsai, Ingo Molnar, Geert Uytterhoeven,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
linux-omap, Jonathan Neuschäfer, Vladimir Zapolskiy,
linux-acpi, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
Nancy Yuen, linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
linux-parisc, Nick Hu, Avi Fishman, Patrick Venture, linux-pm,
Liam Girdwood, linux-kernel, Palmer Dabbelt, Philipp Zabel,
Paul Mackerras, Andrew Morton, linuxppc-dev, openbmc,
Joshua Thompson
In-Reply-To: <20211027211715.12671-12-digetx@gmail.com>
On Thu, Oct 28, 2021 at 12:16:41AM +0300, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: Michal Suchánek @ 2021-11-01 17:43 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: debian-powerpc@lists.debian.org, linuxppc-dev, Nicholas Piggin
In-Reply-To: <1d02b53d-cb39-38bb-8ce2-9a92cc97e729@physik.fu-berlin.de>
On Fri, Oct 29, 2021 at 02:33:12PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Nicholas!
>
> On 10/29/21 02:41, Nicholas Piggin wrote:
> > Soft lockup should mean it's taking timer interrupts still, just not
> > scheduling. Do you have the hard lockup detector enabled as well? Is
> > there anything stuck spinning on another CPU?
>
>
> > Could you try a sysrq+w to get a trace of blocked tasks?
>
> Not sure how to send a magic sysrequest over the IPMI serial console. Any idea?
As on any serial console sending break should be equivalent to the magic
sysrq key combo.
https://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html
With ipmitool break is sent by typing ~B
https://linux.die.net/man/1/ipmitool
Thanks
Michal
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: Michal Suchánek @ 2021-11-01 17:36 UTC (permalink / raw)
To: John Paul Adrian Glaubitz; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <8123f71a-3db3-0a5d-c1b0-59dce2df154c@physik.fu-berlin.de>
Hello,
On Thu, Oct 28, 2021 at 04:15:19PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 10/28/21 16:05, John Paul Adrian Glaubitz wrote:
> > The following packages were being built at the same time:
> >
> > - guest 1: virtuoso-opensource and openturns
> > - guest 2: llvm-toolchain-13
> >
> > I really did a lot of testing today with no issues and just after I sent my report
> > to oss-security that the machine seems to be stable again, the issue showed up :(.
>
> Do you know whether IPMI features any sort of monitoring for capturing the output
> of the serial console non-interactively? This way I would be able to capture the
> crash besides what I have seen above.
I am pretty sure you can run something like
script ipmitool
to capture output indefinitely, and the same inside screen on a remote
machine.
Thanks
Michal
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: John Paul Adrian Glaubitz @ 2021-11-01 17:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <8759057e-170c-3972-997f-a63d88b0e94c@physik.fu-berlin.de>
Hi Michael!
On 11/1/21 08:37, John Paul Adrian Glaubitz wrote:
> I made another experiment and upgraded the host to 5.15-rc7 which contains your
> fixes and made the guests build gcc-10. Interestingly, this time, the gcc-10
> build crashed the guest but didn't manage to crash the host. I will update the
> guest to 5.15-rc7 now as well and see how that goes.
OK, so I'm definitely able to crash the 5.15 kernel as well:
[57031.404944] watchdog: BUG: soft lockup - CPU#24 stuck for 14957s! [migration/24:14]
[57035.420898] watchdog: BUG: soft lockup - CPU#48 stuck for 14961s! [CPU 17/KVM:1815]
[57047.456761] watchdog: BUG: soft lockup - CPU#152 stuck for 14841s! [CPU 13/KVM:1811]
[57055.404670] watchdog: BUG: soft lockup - CPU#24 stuck for 14979s! [migration/24:14]
[57059.420624] watchdog: BUG: soft lockup - CPU#48 stuck for 14983s! [CPU 17/KVM:1815]
[57064.064573] rcu: INFO: rcu_sched self-detected stall on CPU
[57064.064584] rcu: 48-....: (3338577 ticks this GP) idle=9f3/1/0x4000000000000002 softirq=77540/77540 fqs=15421
[57064.064598] rcu: rcu_sched kthread timer wakeup didn't happen for 3988041 jiffies! g125265 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[57064.064606] rcu: Possible timer handling issue on cpu=136 timer-softirq=313650
[57064.064611] rcu: rcu_sched kthread starved for 3988042 jiffies! g125265 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=136
[57064.064618] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[57064.064624] rcu: RCU grace-period kthread stack dump:
[57064.064665] rcu: Stack dump where RCU GP kthread last ran:
[57071.456487] watchdog: BUG: soft lockup - CPU#152 stuck for 14863s! [CPU 13/KVM:1811]
[57079.404396] watchdog: BUG: soft lockup - CPU#24 stuck for 15002s! [migration/24:14]
And the gcc-10 testsuite is able to trigger the crash very reliably.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v1 0/5] Implement livepatch on PPC32
From: Miroslav Benes @ 2021-11-01 14:50 UTC (permalink / raw)
To: Christophe Leroy
Cc: Petr Mladek, Joe Lawrence, Jiri Kosina, linux-kernel,
Steven Rostedt, Ingo Molnar, Josh Poimboeuf, live-patching,
Naveen N . Rao, linuxppc-dev
In-Reply-To: <cover.1635423081.git.christophe.leroy@csgroup.eu>
Hi,
On Thu, 28 Oct 2021, Christophe Leroy wrote:
> This series implements livepatch on PPC32.
>
> This is largely copied from what's done on PPC64.
>
> Christophe Leroy (5):
> livepatch: Fix build failure on 32 bits processors
> powerpc/ftrace: No need to read LR from stack in _mcount()
> powerpc/ftrace: Add module_trampoline_target() for PPC32
> powerpc/ftrace: Activate HAVE_DYNAMIC_FTRACE_WITH_REGS on PPC32
> powerpc/ftrace: Add support for livepatch to PPC32
>
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/livepatch.h | 4 +-
> arch/powerpc/kernel/module_32.c | 33 +++++
> arch/powerpc/kernel/trace/ftrace.c | 53 +++-----
> arch/powerpc/kernel/trace/ftrace_32.S | 187 ++++++++++++++++++++++++--
> kernel/livepatch/core.c | 4 +-
> 6 files changed, 230 insertions(+), 53 deletions(-)
thanks for the patch set!
I wondered whether the reliability of stack traces also applies to PPC32.
This was obviously resolved by accdd093f260 ("powerpc: Activate
HAVE_RELIABLE_STACKTRACE for all").
Did the patch set pass the selftests in
tools/testing/selftests/livepatch/ ?
Regards
Miroslav
^ permalink raw reply
* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Joe Lawrence @ 2021-11-01 13:48 UTC (permalink / raw)
To: Russell Currey, live-patching, linuxppc-dev
Cc: Peter Zijlstra, Jordan Niethe, Jessica Yu, Josh Poimboeuf
In-Reply-To: <7ee0c84650617e6307b29674dd0a12c7258417cf.camel@russell.cc>
On 11/1/21 5:20 AM, Russell Currey wrote:
> I'm looking into this now, will update when there's progress. I
> personally wasn't aware but Jordan flagged this as an issue back in
> August [0]. Are the selftests in the klp-convert tree sufficient for
> testing? I'm not especially familiar with livepatching & haven't used
> the userspace tools.
>
Hi Russell, thanks for taking a look.
Testing with that klp-convert tree is probably the quickest and easiest
way to verify the late relocations.
I'm happy to setup and test additional tools (ie, kpatch-build) with any
potential changes as I know they take longer to config and run.
Thanks,
--
Joe
^ permalink raw reply
* [PATCH] powerpc/44x/fsp2: Add missing of_node_put in node_irq_request
From: He Ying @ 2021-11-01 9:44 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
Early exits from for_each_compatible_node() should decrement the
node reference counter.
Signed-off-by: He Ying <heying24@huawei.com>
---
arch/powerpc/platforms/44x/fsp2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/44x/fsp2.c b/arch/powerpc/platforms/44x/fsp2.c
index b299e43f5ef9..823397c802de 100644
--- a/arch/powerpc/platforms/44x/fsp2.c
+++ b/arch/powerpc/platforms/44x/fsp2.c
@@ -208,6 +208,7 @@ static void node_irq_request(const char *compat, irq_handler_t errirq_handler)
if (irq == NO_IRQ) {
pr_err("device tree node %pOFn is missing a interrupt",
np);
+ of_node_put(np);
return;
}
@@ -215,6 +216,7 @@ static void node_irq_request(const char *compat, irq_handler_t errirq_handler)
if (rc) {
pr_err("fsp_of_probe: request_irq failed: np=%pOF rc=%d",
np, rc);
+ of_node_put(np);
return;
}
}
--
2.17.1
^ permalink raw reply related
* Re: ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Russell Currey @ 2021-11-01 9:20 UTC (permalink / raw)
To: Joe Lawrence, live-patching, linuxppc-dev
Cc: Peter Zijlstra, Jordan Niethe, Jessica Yu, Josh Poimboeuf
In-Reply-To: <YX9UUBeudSUuJs01@redhat.com>
On Sun, 2021-10-31 at 22:43 -0400, Joe Lawrence wrote:
> Starting with 5.14 kernels, I can reliably reproduce a crash [1] on
> ppc64le when loading livepatches containing late klp-relocations [2].
> These are relocations, specific to livepatching, that are resolved not
> when a livepatch module is loaded, but only when a livepatch-target
> module is loaded.
Hey Joe, thanks for the report.
> I haven't started looking at a fix yet, but in the case of the x86 code
> update, its apply_relocate_add() implementation was modified to use a
> common text_poke() function to allowed us to drop
> module_{en,dis}ble_ro() games by the livepatching code.
It should be a similar fix for Power, our patch_instruction() uses a
text poke area but apply_relocate_add() doesn't use it and does its own
raw patching instead.
> I can take a closer look this week, but thought I'd send out a report
> in case this may be a known todo for STRICT_MODULE_RWX on Power.
I'm looking into this now, will update when there's progress. I
personally wasn't aware but Jordan flagged this as an issue back in
August [0]. Are the selftests in the klp-convert tree sufficient for
testing? I'm not especially familiar with livepatching & haven't used
the userspace tools.
- Russell
[0] https://github.com/linuxppc/issues/issues/375
>
> -- Joe
^ permalink raw reply
* [PATCH] powerpc/xmon: replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
From: cgel.zte @ 2021-11-01 8:43 UTC (permalink / raw)
To: mpe
Cc: pmladek, arnd, john.ogness, sxwjean, Zeal Robot, linux-kernel,
npiggin, Changcheng Deng, paulus, naveen.n.rao, linuxppc-dev, clg
From: Changcheng Deng <deng.changcheng@zte.com.cn>
Fix the following coccicheck warning:
./arch/powerpc/xmon/xmon.c: 4064: 0-23: WARNING: xmon_dbgfs_ops should
be defined with DEFINE_DEBUGFS_ATTRIBUTE
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
---
arch/powerpc/xmon/xmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index dd8241c009e5..875241bd216b 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -4062,7 +4062,7 @@ static int xmon_dbgfs_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(xmon_dbgfs_ops, xmon_dbgfs_get,
+DEFINE_DEBUGFS_ATTRIBUTE(xmon_dbgfs_ops, xmon_dbgfs_get,
xmon_dbgfs_set, "%llu\n");
static int __init setup_xmon_dbgfs(void)
--
2.25.1
^ permalink raw reply related
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: John Paul Adrian Glaubitz @ 2021-11-01 7:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <87k0hs8iyq.fsf@mpe.ellerman.id.au>
Hi Michael!
On 11/1/21 07:53, Michael Ellerman wrote:
> Sure, will give that a try.
>
> I was able to crash my machine over the weekend, building openjdk, but I
> haven't been able to reproduce it for ~24 hours now (I didn't change
> anything).
I made another experiment and upgraded the host to 5.15-rc7 which contains your
fixes and made the guests build gcc-10. Interestingly, this time, the gcc-10
build crashed the guest but didn't manage to crash the host. I will update the
guest to 5.15-rc7 now as well and see how that goes.
> Can you try running your guests with no SMT threads?
>
> I think one of your guests was using:
>
> -smp 32,sockets=1,dies=1,cores=8,threads=4
>
> Can you change that to:
>
> -smp 8,sockets=1,dies=1,cores=8,threads=1
>
>
> And something similar for the other guest(s).
Sure. I will try that later. But first I want to switch the guests to 5.15-rc7 as well.
> If the system is stable with those settings that would be useful
> information, and would also mean you could use the system without it
> crashing semi regularly.
Gotcha.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: Michael Ellerman @ 2021-11-01 6:53 UTC (permalink / raw)
To: John Paul Adrian Glaubitz; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <73c55cc9-369e-8989-4f6c-6801ce6a4d64@physik.fu-berlin.de>
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:
> Hi Michael!
>
> On 10/28/21 08:39, Michael Ellerman wrote:
>> That completed fine on my BE VM here.
>>
>> I ran these in two tmux windows:
>> $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc
>> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10.dsc
>
> Could you try gcc-10 instead? It's testsuite has crashed the host for me
> with a patched kernel twice now.
>
> $ dget -u https://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.3.0-12.dsc
> $ sbuild -d sid --arch=powerpc --no-arch-all gcc-10_10.3.0-12.dsc
> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-10_10.3.0-12.dsc
Sure, will give that a try.
I was able to crash my machine over the weekend, building openjdk, but I
haven't been able to reproduce it for ~24 hours now (I didn't change
anything).
Can you try running your guests with no SMT threads?
I think one of your guests was using:
-smp 32,sockets=1,dies=1,cores=8,threads=4
Can you change that to:
-smp 8,sockets=1,dies=1,cores=8,threads=1
And something similar for the other guest(s).
If the system is stable with those settings that would be useful
information, and would also mean you could use the system without it
crashing semi regularly.
cheers
^ permalink raw reply
* Re: [PATCH v2 12/45] csky: Use do_kernel_power_off()
From: Guo Ren @ 2021-11-01 1:57 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Tomer Maimon,
Santosh Shilimkar, Rafael J . Wysocki, Boris Ostrovsky,
Catalin Marinas, Linus Walleij, Dave Hansen, x86, Tali Perry,
James E.J. Bottomley, Thierry Reding, Paul Mackerras,
Pavel Machek, H. Peter Anvin, linux-riscv, Vincent Chen,
Will Deacon, Greg Ungerer, Stefano Stabellini, Benjamin Fair,
Yoshinori Sato, Krzysztof Kozlowski, linux-sh, Lee Jones,
Helge Deller, Daniel Lezcano, Russell King, linux-csky,
Jonathan Hunter, Tony Lindgren, Chen-Yu Tsai, Ingo Molnar,
Geert Uytterhoeven, xen-devel, linux-mips, Guenter Roeck,
Len Brown, Albert Ou, linux-omap, Jonathan Neuschäfer,
Vladimir Zapolskiy, linux-acpi, linux-m68k, Mark Brown,
Borislav Petkov, Greentime Hu, Paul Walmsley, linux-tegra,
Thomas Gleixner, Andy Shevchenko, Nancy Yuen, Linux ARM,
Juergen Gross, Thomas Bogendoerfer, linux-parisc, Nick Hu,
Avi Fishman, Patrick Venture, linux-pm, Liam Girdwood,
Linux Kernel Mailing List, Palmer Dabbelt, Philipp Zabel,
Andrew Morton, linuxppc-dev, openbmc, Joshua Thompson
In-Reply-To: <20211027211715.12671-13-digetx@gmail.com>
Only for this patch, Acked-by: Guo Ren <guoren@kernel.org>
On Thu, Oct 28, 2021 at 5:18 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> arch/csky/kernel/power.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
> index 923ee4e381b8..86ee202906f8 100644
> --- a/arch/csky/kernel/power.c
> +++ b/arch/csky/kernel/power.c
> @@ -9,16 +9,14 @@ EXPORT_SYMBOL(pm_power_off);
> void machine_power_off(void)
> {
> local_irq_disable();
> - if (pm_power_off)
> - pm_power_off();
> + do_kernel_power_off();
> asm volatile ("bkpt");
> }
>
> void machine_halt(void)
> {
> local_irq_disable();
> - if (pm_power_off)
> - pm_power_off();
> + do_kernel_power_off();
> asm volatile ("bkpt");
> }
>
> --
> 2.33.1
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* ppc64le STRICT_MODULE_RWX and livepatch apply_relocate_add() crashes
From: Joe Lawrence @ 2021-11-01 2:43 UTC (permalink / raw)
To: live-patching, linuxppc-dev
Cc: Josh Poimboeuf, Peter Zijlstra, Jordan Niethe, Jessica Yu
Starting with 5.14 kernels, I can reliably reproduce a crash [1] on
ppc64le when loading livepatches containing late klp-relocations [2].
These are relocations, specific to livepatching, that are resolved not
when a livepatch module is loaded, but only when a livepatch-target
module is loaded.
There was previously related work by Josh and Peter [3] to simplify a
lot of x86 and s390x code (at the time, the only two arches to
HAVE_LIVEPATCH and STRICT_MODULE_RWX) as part of disallowing writable
executable mappings.
Now that Power has STRICT_MODULE_RWX, I think we will need to consider
this architecture as well.
The crash was originally spotted by the external kpatch-build tool [4]
when building its integration tests on rhel-9-beta. It can also be
reproduced by the endless-WIP klp-convert patchset [5], which brings
klp-relocation creation from kpatch-build to the upstream build.
I further verified:
- turning STRICT_MODULE_RWX off resulted in no crash
- alternatively, reverting the following commits resulted in no crash:
d556e1be3332 ("livepatch: Remove module_disable_ro() usage")
0d9fbf78fefb ("module: Remove module_disable_ro()")
I haven't started looking at a fix yet, but in the case of the x86 code
update, its apply_relocate_add() implementation was modified to use a
common text_poke() function to allowed us to drop
module_{en,dis}ble_ro() games by the livepatching code.
I can take a closer look this week, but thought I'd send out a report
in case this may be a known todo for STRICT_MODULE_RWX on Power.
-- Joe
[1] crashing kernel log
[ 84.837986] ===== TEST: klp-convert symbols =====
[ 84.858937] % modprobe test_klp_convert_mod
[ 84.879040] % modprobe test_klp_convert1
[ 84.908056] BUG: Unable to handle kernel data access on write at 0xc0080000018402f0
[ 84.908067] Faulting instruction address: 0xc000000000056b58
[ 84.908072] Oops: Kernel access of bad area, sig: 11 [#1]
[ 84.908077] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 84.908082] Modules linked in: test_klp_convert1(K+) test_klp_convert_mod bonding tls rfkill pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto dm_mirror dm_region_hash dm_log dm_mod [last unloaded: test_klp_atomic_replace]
[ 84.908114] CPU: 1 PID: 4205 Comm: modprobe Kdump: loaded Tainted: G K 5.14.0+ #2
[ 84.908121] NIP: c000000000056b58 LR: c000000000056b1c CTR: 0000000000000009
[ 84.908127] REGS: c00000005dce3480 TRAP: 0300 Tainted: G K (5.14.0+)
[ 84.908132] MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24224484 XER: 00000000
[ 84.908147] CFAR: c000000000056a68 DAR: c0080000018402f0 DSISR: 0a000000 IRQMASK: 0
GPR00: c000000000056b1c c00000005dce3720 c000000002a2af00 0000000000000000
GPR04: c0080000018402f0 396b00003d620000 e98b0020f8410018 00000000ffffffff
GPR08: 4e8004207d8903a6 0000000080000000 c0080000018382f0 000000000000000d
GPR12: 0000000000004000 c000000007fcf480 c00000004d7e2000 c0080000018706d8
GPR16: c008000001850228 c00000004d7e2c00 00000000ffffffff c0000000010d6248
GPR20: c00000000298c1c8 c008000001860380 c0080000018706f0 aaaaaaaaaaaaaaab
GPR24: c00000004d7e2b40 c008000001870000 c00800000184005c 000000000000008c
GPR28: c008000001860380 c008000000770008 c00000004d7e2000 c0080000018402f0
[ 84.908209] NIP [c000000000056b58] create_stub+0x78/0x240
[ 84.908217] LR [c000000000056b1c] create_stub+0x3c/0x240
[ 84.908223] Call Trace:
[ 84.908225] [c00000005dce3720] [c00000004d7e2b40] 0xc00000004d7e2b40 (unreliable)
[ 84.908232] [c00000005dce37a0] [c000000000056e0c] stub_for_addr+0xec/0x120
[ 84.908240] [c00000005dce37d0] [c000000000057f14] apply_relocate_add+0x814/0x9a0
[ 84.908247] [c00000005dce38d0] [c00000000021ca38] klp_apply_section_relocs+0x208/0x2d0
[ 84.908255] [c00000005dce39c0] [c00000000021cb90] klp_init_object_loaded+0x90/0x1d0
[ 84.908262] [c00000005dce3a50] [c00000000021d2dc] klp_enable_patch+0x32c/0x540
[ 84.908269] [c00000005dce3b10] [c008000001840030] test_klp_convert_init+0x28/0x48 [test_klp_convert1]
[ 84.908277] [c00000005dce3b30] [c000000000012230] do_one_initcall+0x60/0x2c0
[ 84.908284] [c00000005dce3c00] [c00000000026012c] do_init_module+0x7c/0x3b0
[ 84.908290] [c00000005dce3c90] [c000000000262b74] __do_sys_finit_module+0xd4/0x160
[ 84.908296] [c00000005dce3db0] [c000000000030664] system_call_exception+0x144/0x280
[ 84.908303] [c00000005dce3e10] [c00000000000bff0] system_call_vectored_common+0xf0/0x280
[ 84.908310] --- interrupt: 3000 at 0x7fffa06d6b9c
[ 84.908315] NIP: 00007fffa06d6b9c LR: 0000000000000000 CTR: 0000000000000000
[ 84.908320] REGS: c00000005dce3e80 TRAP: 3000 Tainted: G K (5.14.0+)
[ 84.908325] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28224244 XER: 00000000
[ 84.908340] IRQMASK: 0
GPR00: 0000000000000161 00007fffc4f74ad0 00007fffa07d7100 0000000000000005
GPR04: 000000012a926ca0 0000000000000000 0000000000000005 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00007fffa0f9c380 0000000000000020 0000000000000000
GPR16: 00000100010a1de0 0000000000000000 000000012a927d50 00000100010a02f8
GPR20: 0000000000000001 0000000000000908 00000100010a2020 00000100010a19b0
GPR24: 0000000000000000 0000000000000000 00000100010a2040 00000100010a03f0
GPR28: 00000100010a1e00 000000012a926ca0 0000000000040000 00000100010a19b0
[ 84.908399] NIP [00007fffa06d6b9c] 0x7fffa06d6b9c
[ 84.908403] LR [0000000000000000] 0x0
[ 84.908406] --- interrupt: 3000
[ 84.908410] Instruction dump:
[ 84.908413] 3d02ffb2 395f8000 3d208000 3ce0ffff 38c68d70 39088d84 79290020 60e7ffff
[ 84.908423] e8a60014 e8c80008 e9080010 78e70020 <f8bf0000> f8df0008 f91f0010 811c0224
[ 84.908435] ---[ end trace 961b4b817da4a53b ]---
[2] https://www.kernel.org/doc/html/latest/livepatch/module-elf-format.html
[3] https://lore.kernel.org/lkml/cover.1588173720.git.jpoimboe@redhat.com/
[4] https://github.com/dynup/kpatch/issues/1228
[5] https://github.com/joe-lawrence/linux/tree/klp-convert-v5-expanded-v5.14-rebase1
^ permalink raw reply
* Re: [PATCH 04/13] nvdimm/btt: use goto error labels on btt_blk_init()
From: Dan Williams @ 2021-10-31 17:51 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <20211015235219.2191207-5-mcgrof@kernel.org>
On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> This will make it easier to share common error paths.
>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
> drivers/nvdimm/btt.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
> index 29cc7325e890..23ee8c005db5 100644
> --- a/drivers/nvdimm/btt.c
> +++ b/drivers/nvdimm/btt.c
> @@ -1520,10 +1520,11 @@ static int btt_blk_init(struct btt *btt)
> {
> struct nd_btt *nd_btt = btt->nd_btt;
> struct nd_namespace_common *ndns = nd_btt->ndns;
> + int rc = -ENOMEM;
>
> btt->btt_disk = blk_alloc_disk(NUMA_NO_NODE);
> if (!btt->btt_disk)
> - return -ENOMEM;
> + goto out;
I tend to not use a goto when there is nothing to unwind.
The rest looks good to me. After dropping "goto out;" you can add:
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* Re: [PATCH 03/13] nvdimm/btt: do not call del_gendisk() if not needed
From: Dan Williams @ 2021-10-31 17:47 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <20211015235219.2191207-4-mcgrof@kernel.org>
On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> We know we don't need del_gendisk() if we haven't added
> the disk, so just skip it. This should fix a bug on older
> kernels, as del_gendisk() became able to deal with
> disks not added only recently, after the patch titled
> "block: add flag for add_disk() completion notation".
Perhaps put this in:
commit $abbrev_commit ("block: add flag for add_disk() completion notation")
...format, but I can't seem to find that commit?
If you're touching the changelog how about one that clarifies the
impact and drops "we"?
"del_gendisk() is not required if the disk has not been added. On
kernels prior to commit $abbrev_commit ("block: add flag for
add_disk() completion notation")
it is mandatory to not call del_gendisk() if the underlying device has
not been through device_add()."
Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity")
With that you can add:
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 81291383ffde08b23bce75e7d6b2575ce9d3475c
From: kernel test robot @ 2021-10-31 14:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 81291383ffde08b23bce75e7d6b2575ce9d3475c powerpc/32e: Ignore ESR in instruction storage interrupt handler
elapsed time: 2268m
configs tested: 279
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allmodconfig
arm allyesconfig
i386 randconfig-c001-20211028
powerpc randconfig-c003-20211028
sh landisk_defconfig
um x86_64_defconfig
sh se7751_defconfig
arm exynos_defconfig
m68k multi_defconfig
mips tb0287_defconfig
powerpc mpc8540_ads_defconfig
m68k m5407c3_defconfig
arc nsimosci_defconfig
sh se7721_defconfig
arm corgi_defconfig
arm am200epdkit_defconfig
powerpc mpc83xx_defconfig
xtensa cadence_csp_defconfig
powerpc mpc834x_itxgp_defconfig
m68k amcore_defconfig
sh apsh4ad0a_defconfig
arm magician_defconfig
mips sb1250_swarm_defconfig
arm vf610m4_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
mips maltasmvp_defconfig
h8300 alldefconfig
arm imx_v4_v5_defconfig
mips workpad_defconfig
x86_64 allyesconfig
arc haps_hs_defconfig
mips ip32_defconfig
arm badge4_defconfig
sh rts7751r2d1_defconfig
sh se7206_defconfig
powerpc mpc512x_defconfig
sh se7780_defconfig
arm vt8500_v6_v7_defconfig
openrisc alldefconfig
arm bcm2835_defconfig
sh kfr2r09_defconfig
parisc generic-32bit_defconfig
sh shx3_defconfig
powerpc pasemi_defconfig
powerpc arches_defconfig
arm sama7_defconfig
sparc sparc64_defconfig
arc nsimosci_hs_defconfig
xtensa generic_kc705_defconfig
sh rsk7269_defconfig
m68k m5208evb_defconfig
sh edosk7760_defconfig
s390 alldefconfig
arm pxa_defconfig
powerpc klondike_defconfig
arm netwinder_defconfig
powerpc microwatt_defconfig
powerpc canyonlands_defconfig
powerpc cell_defconfig
riscv nommu_k210_defconfig
m68k m5475evb_defconfig
sh se7724_defconfig
arm h3600_defconfig
powerpc mvme5100_defconfig
m68k mvme147_defconfig
h8300 edosk2674_defconfig
powerpc lite5200b_defconfig
riscv nommu_virt_defconfig
xtensa defconfig
arm pxa168_defconfig
riscv rv32_defconfig
sh kfr2r09-romimage_defconfig
sh apsh4a3a_defconfig
powerpc mpc7448_hpc2_defconfig
mips vocore2_defconfig
sh lboxre2_defconfig
arm imx_v6_v7_defconfig
powerpc g5_defconfig
ia64 zx1_defconfig
xtensa nommu_kc705_defconfig
powerpc maple_defconfig
m68k m5249evb_defconfig
arm dove_defconfig
arm pxa910_defconfig
sh polaris_defconfig
mips rm200_defconfig
mips malta_qemu_32r6_defconfig
powerpc socrates_defconfig
powerpc rainier_defconfig
csky defconfig
sh se7619_defconfig
mips ci20_defconfig
powerpc mpc8313_rdb_defconfig
mips omega2p_defconfig
arm pcm027_defconfig
arm realview_defconfig
sh ecovec24_defconfig
arm shannon_defconfig
powerpc tqm8541_defconfig
sh j2_defconfig
arm multi_v5_defconfig
mips allyesconfig
powerpc powernv_defconfig
powerpc mpc8560_ads_defconfig
arm stm32_defconfig
microblaze mmu_defconfig
openrisc or1klitex_defconfig
sh sh2007_defconfig
arm ixp4xx_defconfig
powerpc iss476-smp_defconfig
xtensa smp_lx200_defconfig
arm omap1_defconfig
powerpc katmai_defconfig
powerpc warp_defconfig
arm oxnas_v6_defconfig
powerpc mpc885_ads_defconfig
powerpc ppc64e_defconfig
microblaze defconfig
sh edosk7705_defconfig
powerpc mpc837x_rdb_defconfig
mips db1xxx_defconfig
sh r7785rp_defconfig
ia64 alldefconfig
sh urquell_defconfig
arm h5000_defconfig
mips gpr_defconfig
powerpc ge_imp3a_defconfig
arm64 alldefconfig
powerpc tqm8548_defconfig
s390 debug_defconfig
m68k amiga_defconfig
sh sh7763rdp_defconfig
powerpc tqm8560_defconfig
mips lemote2f_defconfig
arm eseries_pxa_defconfig
arm footbridge_defconfig
arm randconfig-c002-20211031
arm randconfig-c002-20211028
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
arc allyesconfig
nds32 defconfig
alpha defconfig
alpha allyesconfig
nios2 allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
xtensa allyesconfig
parisc defconfig
s390 defconfig
parisc allyesconfig
s390 allyesconfig
s390 allmodconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
mips allmodconfig
powerpc allnoconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a002-20211028
x86_64 randconfig-a004-20211028
x86_64 randconfig-a005-20211028
x86_64 randconfig-a001-20211028
x86_64 randconfig-a006-20211028
x86_64 randconfig-a003-20211028
i386 randconfig-a004-20211028
i386 randconfig-a003-20211028
i386 randconfig-a002-20211028
i386 randconfig-a006-20211028
i386 randconfig-a001-20211028
i386 randconfig-a005-20211028
i386 randconfig-a003-20211031
i386 randconfig-a006-20211031
i386 randconfig-a002-20211031
i386 randconfig-a005-20211031
i386 randconfig-a001-20211031
i386 randconfig-a004-20211031
x86_64 randconfig-a015-20211029
x86_64 randconfig-a013-20211029
x86_64 randconfig-a011-20211029
x86_64 randconfig-a014-20211029
x86_64 randconfig-a012-20211029
x86_64 randconfig-a016-20211029
i386 randconfig-a012-20211029
i386 randconfig-a013-20211029
i386 randconfig-a011-20211029
i386 randconfig-a015-20211029
i386 randconfig-a016-20211029
i386 randconfig-a014-20211029
x86_64 randconfig-a005-20211031
x86_64 randconfig-a004-20211031
x86_64 randconfig-a002-20211031
x86_64 randconfig-a003-20211031
x86_64 randconfig-a001-20211031
x86_64 randconfig-a006-20211031
arc randconfig-r043-20211031
riscv allnoconfig
riscv defconfig
riscv allmodconfig
riscv allyesconfig
x86_64 rhel-8.3-kselftests
um i386_defconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
arm randconfig-c002-20211028
powerpc randconfig-c003-20211028
riscv randconfig-c006-20211028
x86_64 randconfig-c007-20211028
mips randconfig-c004-20211028
s390 randconfig-c005-20211028
i386 randconfig-c001-20211028
powerpc randconfig-c003-20211031
riscv randconfig-c006-20211031
x86_64 randconfig-c007-20211031
mips randconfig-c004-20211031
s390 randconfig-c005-20211031
arm randconfig-c002-20211031
i386 randconfig-c001-20211031
arm randconfig-c002-20211029
powerpc randconfig-c003-20211029
riscv randconfig-c006-20211029
x86_64 randconfig-c007-20211029
mips randconfig-c004-20211029
s390 randconfig-c005-20211029
i386 randconfig-c001-20211029
x86_64 randconfig-a002-20211029
x86_64 randconfig-a004-20211029
x86_64 randconfig-a005-20211029
x86_64 randconfig-a001-20211029
x86_64 randconfig-a006-20211029
x86_64 randconfig-a003-20211029
i386 randconfig-a004-20211029
i386 randconfig-a003-20211029
i386 randconfig-a002-20211029
i386 randconfig-a001-20211029
i386 randconfig-a006-20211029
i386 randconfig-a005-20211029
x86_64 randconfig-a013-20211031
x86_64 randconfig-a015-20211031
x86_64 randconfig-a014-20211031
x86_64 randconfig-a011-20211031
x86_64 randconfig-a016-20211031
x86_64 randconfig-a012-20211031
x86_64 randconfig-a015-20211028
x86_64 randconfig-a013-20211028
x86_64 randconfig-a011-20211028
x86_64 randconfig-a014-20211028
x86_64 randconfig-a012-20211028
x86_64 randconfig-a016-20211028
i386 randconfig-a013-20211031
i386 randconfig-a012-20211031
i386 randconfig-a014-20211031
i386 randconfig-a015-20211031
i386 randconfig-a011-20211031
i386 randconfig-a016-20211031
i386 randconfig-a012-20211028
i386 randconfig-a013-20211028
i386 randconfig-a011-20211028
i386 randconfig-a015-20211028
i386 randconfig-a016-20211028
i386 randconfig-a014-20211028
hexagon randconfig-r045-20211028
riscv randconfig-r042-20211028
s390 randconfig-r044-20211028
hexagon randconfig-r041-20211028
hexagon randconfig-r045-20211029
hexagon randconfig-r041-20211029
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: (subset) [PATCH 00/13] block: add_disk() error handling stragglers
From: Jens Axboe @ 2021-10-30 17:07 UTC (permalink / raw)
To: vigneshr, richard, geoff, vishal.l.verma, kbusch, sagi, minchan,
mpe, ira.weiny, hch, senozhatsky, dave.jiang, miquel.raynal,
paulus, dan.j.williams, benh, jim, ngupta, Luis Chamberlain
Cc: nvdimm, linux-kernel, linux-nvme, linux-block, linux-mtd,
linuxppc-dev
In-Reply-To: <20211015235219.2191207-1-mcgrof@kernel.org>
On Fri, 15 Oct 2021 16:52:06 -0700, Luis Chamberlain wrote:
> This patch set consists of al the straggler drivers for which we have
> have no patch reviews done for yet. I'd like to ask for folks to please
> consider chiming in, specially if you're the maintainer for the driver.
> Additionally if you can specify if you'll take the patch in yourself or
> if you want Jens to take it, that'd be great too.
>
> Luis Chamberlain (13):
> block/brd: add error handling support for add_disk()
> nvme-multipath: add error handling support for add_disk()
> nvdimm/btt: do not call del_gendisk() if not needed
> nvdimm/btt: use goto error labels on btt_blk_init()
> nvdimm/btt: add error handling support for add_disk()
> nvdimm/blk: avoid calling del_gendisk() on early failures
> nvdimm/blk: add error handling support for add_disk()
> zram: add error handling support for add_disk()
> z2ram: add error handling support for add_disk()
> ps3disk: add error handling support for add_disk()
> ps3vram: add error handling support for add_disk()
> block/sunvdc: add error handling support for add_disk()
> mtd/ubi/block: add error handling support for add_disk()
>
> [...]
Applied, thanks!
[01/13] block/brd: add error handling support for add_disk()
commit: e1528830bd4ebf435d91c154e309e6e028336210
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: (subset) [PATCH 00/13] block: add_disk() error handling stragglers
From: Jens Axboe @ 2021-10-30 17:03 UTC (permalink / raw)
To: kbusch, dan.j.williams, richard, jim, vishal.l.verma, dave.jiang,
miquel.raynal, vigneshr, ngupta, ira.weiny, senozhatsky, hch,
paulus, Luis Chamberlain, sagi, mpe, minchan, geoff, benh
Cc: nvdimm, linux-kernel, linux-nvme, linux-block, linux-mtd,
linuxppc-dev
In-Reply-To: <20211015235219.2191207-1-mcgrof@kernel.org>
On Fri, 15 Oct 2021 16:52:06 -0700, Luis Chamberlain wrote:
> This patch set consists of al the straggler drivers for which we have
> have no patch reviews done for yet. I'd like to ask for folks to please
> consider chiming in, specially if you're the maintainer for the driver.
> Additionally if you can specify if you'll take the patch in yourself or
> if you want Jens to take it, that'd be great too.
>
> Luis Chamberlain (13):
> block/brd: add error handling support for add_disk()
> nvme-multipath: add error handling support for add_disk()
> nvdimm/btt: do not call del_gendisk() if not needed
> nvdimm/btt: use goto error labels on btt_blk_init()
> nvdimm/btt: add error handling support for add_disk()
> nvdimm/blk: avoid calling del_gendisk() on early failures
> nvdimm/blk: add error handling support for add_disk()
> zram: add error handling support for add_disk()
> z2ram: add error handling support for add_disk()
> ps3disk: add error handling support for add_disk()
> ps3vram: add error handling support for add_disk()
> block/sunvdc: add error handling support for add_disk()
> mtd/ubi/block: add error handling support for add_disk()
>
> [...]
Applied, thanks!
[08/13] zram: add error handling support for add_disk()
commit: 5e2e1cc4131cf4d21629c94331f2351b7dc8b87c
[10/13] ps3disk: add error handling support for add_disk()
commit: ff4cbe0fcf5d749f76040f782f0618656cd23e33
[11/13] ps3vram: add error handling support for add_disk()
commit: 3c30883acab1d20ecbd3c48dc12b147b51548742
Best regards,
--
Jens Axboe
^ permalink raw reply
* [powerpc:next-test 31/71] arch/powerpc/mm/nohash/fsl_book3e.c:126:40: error: '_PAGE_BAP_SX' undeclared
From: kernel test robot @ 2021-10-30 16:40 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 5312 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 81291383ffde08b23bce75e7d6b2575ce9d3475c
commit: 01116e6e98b08ab0641fa516ddafb1b1b2088e64 [31/71] powerpc/fsl_booke: Take exec flag into account when setting TLBCAMs
config: powerpc-ge_imp3a_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=01116e6e98b08ab0641fa516ddafb1b1b2088e64
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 01116e6e98b08ab0641fa516ddafb1b1b2088e64
# save the attached .config to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Note: the powerpc/next-test HEAD 81291383ffde08b23bce75e7d6b2575ce9d3475c builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
arch/powerpc/mm/nohash/fsl_book3e.c:63:15: error: no previous prototype for 'tlbcam_sz' [-Werror=missing-prototypes]
63 | unsigned long tlbcam_sz(int idx)
| ^~~~~~~~~
arch/powerpc/mm/nohash/fsl_book3e.c: In function 'settlbcam':
>> arch/powerpc/mm/nohash/fsl_book3e.c:126:40: error: '_PAGE_BAP_SX' undeclared (first use in this function)
126 | TLBCAM[index].MAS3 |= (flags & _PAGE_BAP_SX) ? MAS3_SX : 0;
| ^~~~~~~~~~~~
arch/powerpc/mm/nohash/fsl_book3e.c:126:40: note: each undeclared identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
vim +/_PAGE_BAP_SX +126 arch/powerpc/mm/nohash/fsl_book3e.c
62
> 63 unsigned long tlbcam_sz(int idx)
64 {
65 return tlbcam_addrs[idx].limit - tlbcam_addrs[idx].start + 1;
66 }
67
68 #ifdef CONFIG_FSL_BOOKE
69 /*
70 * Return PA for this VA if it is mapped by a CAM, or 0
71 */
72 phys_addr_t v_block_mapped(unsigned long va)
73 {
74 int b;
75 for (b = 0; b < tlbcam_index; ++b)
76 if (va >= tlbcam_addrs[b].start && va < tlbcam_addrs[b].limit)
77 return tlbcam_addrs[b].phys + (va - tlbcam_addrs[b].start);
78 return 0;
79 }
80
81 /*
82 * Return VA for a given PA or 0 if not mapped
83 */
84 unsigned long p_block_mapped(phys_addr_t pa)
85 {
86 int b;
87 for (b = 0; b < tlbcam_index; ++b)
88 if (pa >= tlbcam_addrs[b].phys
89 && pa < (tlbcam_addrs[b].limit-tlbcam_addrs[b].start)
90 +tlbcam_addrs[b].phys)
91 return tlbcam_addrs[b].start+(pa-tlbcam_addrs[b].phys);
92 return 0;
93 }
94 #endif
95
96 /*
97 * Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
98 * in particular size must be a power of 4 between 4k and the max supported by
99 * an implementation; max may further be limited by what can be represented in
100 * an unsigned long (for example, 32-bit implementations cannot support a 4GB
101 * size).
102 */
103 static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
104 unsigned long size, unsigned long flags, unsigned int pid)
105 {
106 unsigned int tsize;
107
108 tsize = __ilog2(size) - 10;
109
110 #if defined(CONFIG_SMP) || defined(CONFIG_PPC_E500MC)
111 if ((flags & _PAGE_NO_CACHE) == 0)
112 flags |= _PAGE_COHERENT;
113 #endif
114
115 TLBCAM[index].MAS0 = MAS0_TLBSEL(1) | MAS0_ESEL(index) | MAS0_NV(index+1);
116 TLBCAM[index].MAS1 = MAS1_VALID | MAS1_IPROT | MAS1_TSIZE(tsize) | MAS1_TID(pid);
117 TLBCAM[index].MAS2 = virt & PAGE_MASK;
118
119 TLBCAM[index].MAS2 |= (flags & _PAGE_WRITETHRU) ? MAS2_W : 0;
120 TLBCAM[index].MAS2 |= (flags & _PAGE_NO_CACHE) ? MAS2_I : 0;
121 TLBCAM[index].MAS2 |= (flags & _PAGE_COHERENT) ? MAS2_M : 0;
122 TLBCAM[index].MAS2 |= (flags & _PAGE_GUARDED) ? MAS2_G : 0;
123 TLBCAM[index].MAS2 |= (flags & _PAGE_ENDIAN) ? MAS2_E : 0;
124
125 TLBCAM[index].MAS3 = (phys & MAS3_RPN) | MAS3_SR;
> 126 TLBCAM[index].MAS3 |= (flags & _PAGE_BAP_SX) ? MAS3_SX : 0;
127 TLBCAM[index].MAS3 |= (flags & _PAGE_RW) ? MAS3_SW : 0;
128 if (mmu_has_feature(MMU_FTR_BIG_PHYS))
129 TLBCAM[index].MAS7 = (u64)phys >> 32;
130
131 /* Below is unlikely -- only for large user pages or similar */
132 if (pte_user(__pte(flags))) {
133 TLBCAM[index].MAS3 |= MAS3_UR;
134 TLBCAM[index].MAS3 |= (flags & _PAGE_EXEC) ? MAS3_UX : 0;
135 TLBCAM[index].MAS3 |= (flags & _PAGE_RW) ? MAS3_UW : 0;
136 }
137
138 tlbcam_addrs[index].start = virt;
139 tlbcam_addrs[index].limit = virt + size - 1;
140 tlbcam_addrs[index].phys = phys;
141 }
142
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21066 bytes --]
^ permalink raw reply
* Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Joakim Tjernlund @ 2021-10-30 14:20 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, Eugene_Bordenkircher@selinc.com,
linux-usb@vger.kernel.org
Cc: gregkh@linuxfoundataion.org, balbi@kernel.org, leoyang.li@nxp.com
In-Reply-To: <MWHPR2201MB152074F47BF142189365627B91879@MWHPR2201MB1520.namprd22.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]
On Fri, 2021-10-29 at 17:14 +0000, Eugene Bordenkircher wrote:
> Hello all,
>
> We've discovered a situation where the FSL udc driver (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the request queue, but the queue has been corrupted at some point so it loops infinitely. I believe we have narrowed into the offending code, but we are in need of assistance trying to find an appropriate fix for the problem. The identified code appears to be in all versions of the Linux kernel the driver exists in.
>
> The problem appears to be when handling a USB_REQ_GET_STATUS request. The driver gets this request and then calls the ch9getstatus() function. In this function, it starts a request by "borrowing" the per device status_req, filling it in, and then queuing it with a call to list_add_tail() to add the request to the endpoint queue. Right before it exits the function however, it's calling ep0_prime_status(), which is filling out that same status_req structure and then queuing it with another call to list_add_tail() to add the request to the endpoint queue. This adds two instances of the exact same LIST_HEAD to the endpoint queue, which breaks the list since the prev and next pointers end up pointing to the wrong things. This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ.
>
> I'm not sure what the appropriate fix to this problem is, mostly due to my lack of expertise in USB and this driver stack. The code has been this way in the kernel for a very long time, which suggests that it has been working, unless USB_REQ_GET_STATUS requests are never made. This further suggests that there is something else going on that I don't understand. Deleting the call to ep0_prime_status() and the following ep0stall() call appears, on the surface, to get the device working again, but may have side effects that I'm not seeing.
>
> I'm hopeful someone in the community can help provide some information on what I may be missing or help come up with a solution to the problem. A big thank you to anyone who would like to help out.
>
> Eugene
Run into this to a while ago. Found the bug and a few more fixes.
This is against 4.19 so you may have to tweak them a bit.
Feel free to upstream them.
Jocke
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0005-fsl_udc_core-Init-max_pipes-for-reset_queues.patch --]
[-- Type: text/x-patch; name="0005-fsl_udc_core-Init-max_pipes-for-reset_queues.patch", Size: 989 bytes --]
From a7ed9cffbfc90371b570ebef698d96c39adbaf77 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Mon, 11 May 2020 11:18:14 +0200
Subject: [PATCH 5/5] fsl_udc_core: Init max_pipes for reset_queues()
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index bd3825d9f1d2..92136dff8373 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2441,6 +2441,7 @@ static int fsl_udc_probe(struct platform_device *pdev)
/* Get max device endpoints */
/* DEN is bidirectional ep number, max_ep doubles the number */
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
+ udc_controller->max_pipes = udc_controller->max_ep;
udc_controller->irq = platform_get_irq(pdev, 0);
if (!udc_controller->irq) {
--
2.32.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0004-fsl_udc_stop-Use-list_for_each_entry_safe-when-delet.patch --]
[-- Type: text/x-patch; name="0004-fsl_udc_stop-Use-list_for_each_entry_safe-when-delet.patch", Size: 1422 bytes --]
From b98fa0dd384f17fee0c1283b91f855b97d1976f4 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Mon, 11 May 2020 10:38:07 +0200
Subject: [PATCH 4/5] fsl_udc_stop: Use list_for_each_entry_safe() when
deleting
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index 4f835332af45..bd3825d9f1d2 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1984,7 +1984,7 @@ static int fsl_udc_start(struct usb_gadget *g,
/* Disconnect from gadget driver */
static int fsl_udc_stop(struct usb_gadget *g)
{
- struct fsl_ep *loop_ep;
+ struct fsl_ep *loop_ep, *tmp_loop;
unsigned long flags;
if (!IS_ERR_OR_NULL(udc_controller->transceiver))
@@ -2002,8 +2002,8 @@ static int fsl_udc_stop(struct usb_gadget *g)
spin_lock_irqsave(&udc_controller->lock, flags);
udc_controller->gadget.speed = USB_SPEED_UNKNOWN;
nuke(&udc_controller->eps[0], -ESHUTDOWN);
- list_for_each_entry(loop_ep, &udc_controller->gadget.ep_list,
- ep.ep_list)
+ list_for_each_entry_safe(loop_ep, tmp_loop, &udc_controller->gadget.ep_list,
+ ep.ep_list)
nuke(loop_ep, -ESHUTDOWN);
spin_unlock_irqrestore(&udc_controller->lock, flags);
--
2.32.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-fsl_ep_dequeue.patch --]
[-- Type: text/x-patch; name="0003-fsl_ep_dequeue.patch", Size: 1007 bytes --]
From a90a89d06bd008f606404ec613b4f2343b9dda1a Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Thu, 7 May 2020 22:35:14 +0200
Subject: [PATCH 3/5] fsl_ep_dequeue
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index 4b1591fa2e1c..4f835332af45 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -977,7 +977,13 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
/* prime with dTD of next request */
fsl_prime_ep(ep, next_req->head);
- }
+ } else {
+ struct ep_queue_head *qh;
+
+ qh = ep->qh;
+ qh->next_dtd_ptr = 1;
+ qh->size_ioc_int_sts = 0;
+ }
/* The request hasn't been processed, patch up the TD chain */
} else {
struct fsl_req *prev_req;
--
2.32.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0002-fsl_udc-import-build_dtd-fixes.patch --]
[-- Type: text/x-patch; name="0002-fsl_udc-import-build_dtd-fixes.patch", Size: 2239 bytes --]
From b3f09747be2007be3a372fe80635b51df6ba71bd Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Thu, 7 May 2020 22:32:26 +0200
Subject: [PATCH 2/5] fsl_udc: import build_dtd fixes
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index 2546bc28f42a..4b1591fa2e1c 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -774,12 +774,20 @@ static void fsl_queue_td(struct fsl_ep *ep, struct fsl_req *req)
static struct ep_td_struct *fsl_build_dtd(struct fsl_req *req, unsigned *length,
dma_addr_t *dma, int *is_last, gfp_t gfp_flags)
{
- u32 swap_temp;
+ u32 swap_temp, mult = 0;
struct ep_td_struct *dtd;
+ struct ep_queue_head *dqh;
/* how big will this transfer be? */
- *length = min(req->req.length - req->req.actual,
- (unsigned)EP_MAX_LENGTH_TRANSFER);
+ if (usb_endpoint_xfer_isoc(req->ep->ep.desc)) {
+ dqh = req->ep->qh;
+ mult = (dqh->max_pkt_length >> EP_QUEUE_HEAD_MULT_POS)
+ & 0x3;
+ *length = min(req->req.length - req->req.actual,
+ (unsigned)(mult * req->ep->ep.maxpacket));
+ } else
+ *length = min(req->req.length - req->req.actual,
+ (unsigned)EP_MAX_LENGTH_TRANSFER);
dtd = dma_pool_alloc(udc_controller->td_pool, gfp_flags, dma);
if (dtd == NULL)
@@ -794,6 +802,7 @@ static struct ep_td_struct *fsl_build_dtd(struct fsl_req *req, unsigned *length,
/* Init all of buffer page pointers */
swap_temp = (u32) (req->req.dma + req->req.actual);
dtd->buff_ptr0 = cpu_to_hc32(swap_temp);
+ swap_temp &= ~0xFFF;
dtd->buff_ptr1 = cpu_to_hc32(swap_temp + 0x1000);
dtd->buff_ptr2 = cpu_to_hc32(swap_temp + 0x2000);
dtd->buff_ptr3 = cpu_to_hc32(swap_temp + 0x3000);
@@ -820,6 +829,7 @@ static struct ep_td_struct *fsl_build_dtd(struct fsl_req *req, unsigned *length,
/* Enable interrupt for the last dtd of a request */
if (*is_last && !req->req.no_interrupt)
swap_temp |= DTD_IOC;
+ swap_temp |= mult << 10;
dtd->size_ioc_sts = cpu_to_hc32(swap_temp);
--
2.32.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0001-ch9getstatus-ep0_prime_status-fixes-RND-28770.patch --]
[-- Type: text/x-patch; name="0001-ch9getstatus-ep0_prime_status-fixes-RND-28770.patch", Size: 4367 bytes --]
From 17c684fdcd6152b7e504656b1711e24508c32f6e Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Fri, 8 May 2020 17:12:53 +0200
Subject: [PATCH 1/5] ch9getstatus/ep0_prime_status, fixes RND-28770
USB driver added the same req twice to the same list.
This cause a endless loop while in IRQ context.
Fix by importing code from mv_udc_core.c, its sister driver.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 56 ++++++++++-----------------
1 file changed, 21 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index 367697144cda..2546bc28f42a 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1266,7 +1266,7 @@ static void ep0stall(struct fsl_udc *udc)
}
/* Prime a status phase for ep0 */
-static int ep0_prime_status(struct fsl_udc *udc, int direction)
+static int ep0_prime_status(struct fsl_udc *udc, int direction, u16 status, bool empty)
{
struct fsl_req *req = udc->status_req;
struct fsl_ep *ep;
@@ -1281,8 +1281,14 @@ static int ep0_prime_status(struct fsl_udc *udc, int direction)
if (udc->ep0_state != DATA_STATE_XMIT)
udc->ep0_state = WAIT_FOR_OUT_STATUS;
+ /* fill in the reqest structure */
+ if (empty == false) {
+ *((u16 *) req->req.buf) = cpu_to_le16(status);
+ req->req.length = 2;
+ } else
+ req->req.length = 0;
+
req->ep = ep;
- req->req.length = 0;
req->req.status = -EINPROGRESS;
req->req.actual = 0;
req->req.complete = fsl_noop_complete;
@@ -1292,14 +1298,19 @@ static int ep0_prime_status(struct fsl_udc *udc, int direction)
if (ret)
return ret;
+ ret = -ENOMEM;
if (fsl_req_to_dtd(req, GFP_ATOMIC) == 0)
fsl_queue_td(ep, req);
else
- return -ENOMEM;
+ goto out;
list_add_tail(&req->queue, &ep->queue);
return 0;
+out:
+ usb_gadget_unmap_request(&udc->gadget, &req->req, ep_is_in(ep));
+
+ return ret;
}
static void udc_reset_ep_queue(struct fsl_udc *udc, u8 pipe)
@@ -1320,7 +1331,7 @@ static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16 length)
/* Update usb state */
udc->usb_state = USB_STATE_ADDRESS;
/* Status phase */
- if (ep0_prime_status(udc, EP_DIR_IN))
+ if (ep0_prime_status(udc, EP_DIR_IN, 0, true))
ep0stall(udc);
}
@@ -1331,9 +1342,7 @@ static void ch9getstatus(struct fsl_udc *udc, u8 request_type, u16 value,
u16 index, u16 length)
{
u16 tmp = 0; /* Status, cpu endian */
- struct fsl_req *req;
struct fsl_ep *ep;
- int ret;
ep = &udc->eps[0];
@@ -1358,33 +1367,10 @@ static void ch9getstatus(struct fsl_udc *udc, u8 request_type, u16 value,
<< USB_ENDPOINT_HALT;
}
- udc->ep0_dir = USB_DIR_IN;
- /* Borrow the per device status_req */
- req = udc->status_req;
- /* Fill in the reqest structure */
- *((u16 *) req->req.buf) = cpu_to_le16(tmp);
-
- req->ep = ep;
- req->req.length = 2;
- req->req.status = -EINPROGRESS;
- req->req.actual = 0;
- req->req.complete = fsl_noop_complete;
- req->dtd_count = 0;
-
- ret = usb_gadget_map_request(&ep->udc->gadget, &req->req, ep_is_in(ep));
- if (ret)
- goto stall;
-
- /* prime the data phase */
- if ((fsl_req_to_dtd(req, GFP_ATOMIC) == 0))
- fsl_queue_td(ep, req);
- else /* no mem */
- goto stall;
-
- list_add_tail(&req->queue, &ep->queue);
- udc->ep0_state = DATA_STATE_XMIT;
- if (ep0_prime_status(udc, EP_DIR_OUT))
+ if (ep0_prime_status(udc, EP_DIR_OUT, tmp, false))
ep0stall(udc);
+ else
+ udc->ep0_state = DATA_STATE_XMIT;
return;
stall:
@@ -1465,7 +1451,7 @@ __acquires(udc->lock)
break;
if (rc == 0) {
- if (ep0_prime_status(udc, EP_DIR_IN))
+ if (ep0_prime_status(udc, EP_DIR_IN, 0, true))
ep0stall(udc);
}
if (ptc) {
@@ -1501,7 +1487,7 @@ __acquires(udc->lock)
* See 2.0 Spec chapter 8.5.3.3 for detail.
*/
if (udc->ep0_state == DATA_STATE_XMIT)
- if (ep0_prime_status(udc, EP_DIR_OUT))
+ if (ep0_prime_status(udc, EP_DIR_OUT, 0, true))
ep0stall(udc);
} else {
@@ -1537,7 +1523,7 @@ static void ep0_req_complete(struct fsl_udc *udc, struct fsl_ep *ep0,
break;
case DATA_STATE_RECV:
/* send status phase */
- if (ep0_prime_status(udc, EP_DIR_IN))
+ if (ep0_prime_status(udc, EP_DIR_IN, 0, true))
ep0stall(udc);
break;
case WAIT_FOR_OUT_STATUS:
--
2.32.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox