* Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper
From: Linus Torvalds @ 2021-05-14 19:22 UTC (permalink / raw)
To: Vineet Gupta
Cc: Rich Felker, Linux-sh list, Richard Russon (FlatCap),
Amitkumar Karwar, Russell King, Eric Dumazet, Paul Mackerras,
H. Peter Anvin, linux-sparc, Thomas Gleixner, linux-arch,
Florian Fainelli, Yoshinori Sato, the arch/x86 maintainers,
James Morris, Ingo Molnar, Geert Uytterhoeven, Linux ARM,
Jakub Kicinski, Serge E. Hallyn, Jonas Bonn, Arnd Bergmann,
Ganapathi Bhat, Stefan Kristiansson, linux-block, linux-m68k,
openrisc@lists.librecores.org, Borislav Petkov, Stafford Horne,
Kalle Valo, Jens Axboe, Arnd Bergmann, John Johansen, Xinming Hu,
Netdev, linux-wireless, Linux Kernel Mailing List,
Vladimir Oltean, linux-ntfs-dev@lists.sourceforge.net, LSM List,
Linux Crypto Mailing List, linuxppc-dev, Sharvari Harisangam
In-Reply-To: <2408c893-4ae7-4f53-f58c-497c91f5b034@synopsys.com>
On Fri, May 14, 2021 at 11:52 AM Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
>
> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet
You're right, I never actually committed it, since it was specific to
ARC and -O3 and I wasn't entirely happy with the amount of testing it
got (with Heiko pointing out that the s390 stuff needed more fixes for
the change).
So in fact it's not even queued up for 5.14 due to this all, I just dropped it.
> > and the biggy
> > case didn't even use "get_unaligned()").
>
> Indeed this series is sort of orthogonal to that bug, but IMO that bug
> still exists in 5.13 for -O3 build, granted that is not enabled for !ARC.
Right, the zlib bug is still there.
But Arnd's series wouldn't even fix it: right now inffast has its own
- ugly and slow - special 2-byte-only version of "get_unaligned()",
called "get_unaligned16()".
And because it's ugly and slow, it's not actually used for
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
Vineet - maybe the fix is to not take my patch to update to a newer
zlib, but to just fix inffast to use the proper get_unaligned(). Then
Arnd's series _would_ actually fix all this..
Linus
^ permalink raw reply
* Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper
From: Arnd Bergmann @ 2021-05-14 19:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Linux-sh list, Richard Russon (FlatCap),
Amitkumar Karwar, Russell King, Eric Dumazet, Paul Mackerras,
H. Peter Anvin, linux-sparc, Thomas Gleixner, linux-arch,
Florian Fainelli, Yoshinori Sato, the arch/x86 maintainers,
James Morris, Ingo Molnar, Geert Uytterhoeven, Linux ARM,
Jakub Kicinski, Serge E. Hallyn, Jonas Bonn, Ganapathi Bhat,
Stefan Kristiansson, linux-block, linux-m68k, Openrisc,
Borislav Petkov, Stafford Horne, Kalle Valo, Jens Axboe,
John Johansen, Xinming Hu, Vineet Gupta, linux-wireless,
Linux Kernel Mailing List, Vladimir Oltean, linux-ntfs-dev,
LSM List, Linux Crypto Mailing List, Netdev, linuxppc-dev,
Sharvari Harisangam
In-Reply-To: <CAHk-=whGObOKruA_bU3aPGZfoDqZM1_9wBkwREp0H0FgR-90uQ@mail.gmail.com>
On Fri, May 14, 2021 at 7:32 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > I've included this version in the asm-generic tree for 5.14 already,
> > addressing the few issues that were pointed out in the RFC. If there
> > are any remaining problems, I hope those can be addressed as follow-up
> > patches.
>
> This continues to look great to me, and now has the even simpler
> remaining implementation.
>
> I'd be tempted to just pull it in for 5.13, but I guess we don't
> actually have any _outstanding_ bug in this area (the bug was in our
> zlib code, required -O3 to trigger, has been fixed now, and the biggy
> case didn't even use "get_unaligned()").
>
> So I guess your 5.14 timing is the right thing to do.
Yes, I think that's best, just in case something does come up. While all the
object code I looked at does appear better, this is one of those areas that
can be hard to pinpoint if we hit a regression in a particular combination of
architecture+compiler+source file.
I have pushed a signed tag to
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
asm-generic-unaligned-5.14
and plan to send that in the 5.14 merge window unless you decide to
take it now after all.
Arnd
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Michal Suchánek @ 2021-05-14 19:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andreas Schwab, Nicholas Piggin
In-Reply-To: <87tunh8jum.fsf@mpe.ellerman.id.au>
On Wed, May 05, 2021 at 10:07:29PM +1000, Michael Ellerman wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
> > On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
> >> Should this add a tag to the module vermagic?
> >
> > Would the modues link even if the vermagic was not changed?
>
> Most modules will require some symbols from the kernel, and those will
> be dot symbols, which won't resolve.
>
> But there are a few small modules that don't rely on any kernel symbols,
> which can load.
>
> > I suppose something like this might do it.
>
> It would, but I feel like we should be handling this at the ELF level.
> ie. we don't allow loading modules with a different ELF machine type, so
> neither should we allow loading a module with the wrong ELF ABI.
>
> And you can build the kernel without MODVERSIONS, so relying on
> MODVERSIONS still leaves a small exposure (same kernel version
> with/without ELFv2).
>
> I don't see an existing hook that would do what we want. There's
> elf_check_arch(), but that also applies to userspace binaries, which is
> not what we want.
>
> Maybe something like below.
The below patch works for me.
Tested-by: Michal Suchánek <msuchanek@suse.de>
Built a Hello World module for both v1 and v2 ABI, and kernels built
with v1 and v2 ABI rejected module with the other ABI.
[ 100.602943] Module has invalid ELF structures
insmod: ERROR: could not insert module moin_v1.ko: Invalid module format
Thanks
Michal
>
> cheers
>
>
> diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
> index 857d9ff24295..d0e9368982d8 100644
> --- a/arch/powerpc/include/asm/module.h
> +++ b/arch/powerpc/include/asm/module.h
> @@ -83,5 +83,28 @@ static inline int module_finalize_ftrace(struct module *mod, const Elf_Shdr *sec
> }
> #endif
>
> +#ifdef CONFIG_PPC64
> +static inline bool elf_check_module_arch(Elf_Ehdr *hdr)
> +{
> + unsigned long flags;
> +
> + if (!elf_check_arch(hdr))
> + return false;
> +
> + flags = hdr->e_flags & 0x3;
> +
> +#ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> + if (flags == 2)
> + return true;
> +#else
> + if (flags < 2)
> + return true;
> +#endif
> + return false;
> +}
> +
> +#define elf_check_module_arch elf_check_module_arch
> +#endif /* CONFIG_PPC64 */
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_MODULE_H */
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 9e09d11ffe5b..fdc042a84562 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -13,6 +13,11 @@
> * must be implemented by each architecture.
> */
>
> +// Allow arch to optionally do additional checking of module ELF header
> +#ifndef elf_check_module_arch
> +#define elf_check_module_arch elf_check_arch
> +#endif
> +
> /* Adjust arch-specific sections. Return 0 on success. */
> int module_frob_arch_sections(Elf_Ehdr *hdr,
> Elf_Shdr *sechdrs,
> diff --git a/kernel/module.c b/kernel/module.c
> index b5dd92e35b02..c71889107226 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2941,7 +2941,7 @@ static int elf_validity_check(struct load_info *info)
>
> if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
> || info->hdr->e_type != ET_REL
> - || !elf_check_arch(info->hdr)
> + || !elf_check_module_arch(info->hdr)
> || info->hdr->e_shentsize != sizeof(Elf_Shdr))
> return -ENOEXEC;
>
^ permalink raw reply
* Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper
From: Vineet Gupta @ 2021-05-14 19:45 UTC (permalink / raw)
To: Linus Torvalds, Vineet Gupta
Cc: Rich Felker, Linux-sh list, Richard Russon (FlatCap),
Amitkumar Karwar, Russell King, Eric Dumazet, Paul Mackerras,
H. Peter Anvin, linux-sparc, Thomas Gleixner, linux-arch,
Florian Fainelli, Yoshinori Sato, the arch/x86 maintainers,
James Morris, Ingo Molnar, Geert Uytterhoeven, Linux ARM,
Jakub Kicinski, Serge E. Hallyn, Jonas Bonn, Arnd Bergmann,
Ganapathi Bhat, Stefan Kristiansson, linux-block, linux-m68k,
openrisc@lists.librecores.org, Borislav Petkov, Stafford Horne,
Kalle Valo, Jens Axboe, Arnd Bergmann, John Johansen, Xinming Hu,
Netdev, linux-wireless, Linux Kernel Mailing List,
Vladimir Oltean, linux-ntfs-dev@lists.sourceforge.net, LSM List,
Linux Crypto Mailing List, linuxppc-dev, Sharvari Harisangam
In-Reply-To: <CAHk-=wih8UHDwJ8x6m-p0PQ7o4S4gOBwGNs=w=q10GNY7A-70w@mail.gmail.com>
On 5/14/21 12:22 PM, Linus Torvalds wrote:
> On Fri, May 14, 2021 at 11:52 AM Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
>> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet
> You're right, I never actually committed it, since it was specific to
> ARC and -O3
Well, not really, the issue manifested in ARC O3 testing, but I showed
the problem existed for arm64 gcc too.
> and I wasn't entirely happy with the amount of testing it
> got (with Heiko pointing out that the s390 stuff needed more fixes for
> the change).
With his addon patch everything seemed hunky dory.
> The patch below is required on top of your patch to make it compile
> for s390 as well.
> Tested with kernel image decompression, and also btrfs with file
> compression; both software and hardware compression.
> Everything seems to work.
> So in fact it's not even queued up for 5.14 due to this all, I just dropped it.
But Why. Can't we throw it in linux-next for 5.14. I promise to test it
- and will likely hit any corner cases. Also for the time being we could
force just that file/files to build for -O3 to stress test the aspects
that were fragile.
>>> and the biggy
>>> case didn't even use "get_unaligned()").
>> Indeed this series is sort of orthogonal to that bug, but IMO that bug
>> still exists in 5.13 for -O3 build, granted that is not enabled for !ARC.
> Right, the zlib bug is still there.
>
> But Arnd's series wouldn't even fix it: right now inffast has its own
> - ugly and slow - special 2-byte-only version of "get_unaligned()",
> called "get_unaligned16()".
I know that's why said they are orthogonal.
> And because it's ugly and slow, it's not actually used for
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
>
> Vineet - maybe the fix is to not take my patch to update to a newer
> zlib, but to just fix inffast to use the proper get_unaligned(). Then
> Arnd's series _would_ actually fix all this..
OK if you say so.
-Vineet
^ permalink raw reply
* Re: [PATCH v2 00/13] Unify asm/unaligned.h around struct helper
From: Linus Torvalds @ 2021-05-14 20:19 UTC (permalink / raw)
To: Vineet Gupta
Cc: Rich Felker, Linux-sh list, Richard Russon (FlatCap),
Amitkumar Karwar, Russell King, Eric Dumazet, Paul Mackerras,
H. Peter Anvin, linux-sparc, Thomas Gleixner, linux-arch,
Florian Fainelli, Yoshinori Sato, the arch/x86 maintainers,
James Morris, Ingo Molnar, Geert Uytterhoeven, Linux ARM,
Jakub Kicinski, Serge E. Hallyn, Jonas Bonn, Arnd Bergmann,
Ganapathi Bhat, Stefan Kristiansson, linux-block, linux-m68k,
openrisc@lists.librecores.org, Borislav Petkov, Stafford Horne,
Kalle Valo, Jens Axboe, Arnd Bergmann, John Johansen, Xinming Hu,
Netdev, linux-wireless, Linux Kernel Mailing List,
Vladimir Oltean, linux-ntfs-dev@lists.sourceforge.net, LSM List,
Linux Crypto Mailing List, linuxppc-dev, Sharvari Harisangam
In-Reply-To: <14016937-b9c3-c131-db18-f97081806c7f@synopsys.com>
On Fri, May 14, 2021 at 12:45 PM Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
>
> Well, not really, the issue manifested in ARC O3 testing, but I showed
> the problem existed for arm64 gcc too.
.. but not with a supported kernel configuration.
> > So in fact it's not even queued up for 5.14 due to this all, I just dropped it.
>
> But Why.
I just didn't have time to deal with it during the merge window. If
you keep it alive, that's all fine and good.
Linus
^ permalink raw reply
* Re: [PATCH 07/31] powerpc/xive: Fix xive_irq_set_affinity for MSI
From: Thomas Gleixner @ 2021-05-14 20:48 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: Cédric Le Goater
In-Reply-To: <20210430080407.4030767-8-clg@kaod.org>
On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
> The MSI affinity is automanaged and it can be set before starting the
> associated IRQ.
>
> ( Should we simply remove the irqd_is_started() test ? )
If the hardware can handle it properly.
But see:
cffb717ceb8e ("powerpc/xive: Ensure active irqd when setting affinity")
which introduced that condition. It mutters something about migration of
shutdown interrupts:
[ 123.053037264,3] XIVE[ IC 00 ] ISN 2 lead to invalid IVE !
[ 77.885859] xive: Error -6 reconfiguring irq 17
[ 77.885862] IRQ17: set affinity failed(-6).
Not that I can decode that :)
Non-managed interrupts have the sequence:
startup()
set_affinity()
which is historical and an earlier attempt to flip it caused havoc in
some places.
With managed we needed to make sure that the affinity is set correctly
right at start. So it needs to be done the other way round and it turned
out that for MSI this works.
I have no idea, whether that might make the above issue reappear or
not. If so, then we need some extra state to make it work.
The root cause which triggered the problem got fixed, so there should be
no issue _if_ this was specifically related to that CPU unplug case.
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 96737938e8e3..3485baf9ec8c 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -710,7 +710,7 @@ static int xive_irq_set_affinity(struct irq_data *d,
> return -EINVAL;
>
> /* Don't do anything if the interrupt isn't started */
> - if (!irqd_is_started(d))
> + if (!irqd_is_started(d) && !irqd_affinity_is_managed(d))
> return IRQ_SET_MASK_OK;
>
> /*
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 31/31] genirq: Improve "hwirq" output in /proc and /sys/
From: Thomas Gleixner @ 2021-05-14 20:49 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: Cédric Le Goater
In-Reply-To: <20210430080407.4030767-32-clg@kaod.org>
On Fri, Apr 30 2021 at 10:04, Cédric Le Goater wrote:
> The HW IRQ numbers generated by the PCI MSI layer can be quite large
> on a pSeries machine when running under the IBM Hypervisor and they
> appear as negative. Use '%u' to show them correctly.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> kernel/irq/irqdesc.c | 2 +-
> kernel/irq/proc.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
> index cc1a09406c6e..85054eb2ae51 100644
> --- a/kernel/irq/irqdesc.c
> +++ b/kernel/irq/irqdesc.c
> @@ -188,7 +188,7 @@ static ssize_t hwirq_show(struct kobject *kobj,
>
> raw_spin_lock_irq(&desc->lock);
> if (desc->irq_data.domain)
> - ret = sprintf(buf, "%d\n", (int)desc->irq_data.hwirq);
> + ret = sprintf(buf, "%u\n", (int)desc->irq_data.hwirq);
Which makes the (int) cast pointless, right?
> raw_spin_unlock_irq(&desc->lock);
>
> return ret;
> diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
> index 98138788cb04..e2392f05da04 100644
> --- a/kernel/irq/proc.c
> +++ b/kernel/irq/proc.c
> @@ -513,7 +513,7 @@ int show_interrupts(struct seq_file *p, void *v)
> seq_printf(p, " %8s", "None");
> }
> if (desc->irq_data.domain)
> - seq_printf(p, " %*d", prec, (int) desc->irq_data.hwirq);
> + seq_printf(p, " %*u", prec, (int)desc->irq_data.hwirq);
ditto.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 15/31] KVM: PPC: Book3S HV: XIVE: Fix mapping of passthrough interrupts
From: Thomas Gleixner @ 2021-05-14 20:51 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: Cédric Le Goater, Marc Zyngier
In-Reply-To: <20210430080407.4030767-16-clg@kaod.org>
On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
CC: +Marc
> PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
> underlying calls handling the passthrough of the interrupt in the
> guest need a number in the XIVE IRQ domain.
>
> Use the IRQ data mapped in the XIVE IRQ domain and not the one in the
> PCI-MSI domain.
>
> Exporting irq_get_default_host() might not be the best solution.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/kvm/book3s_xive.c | 3 ++-
> kernel/irq/irqdomain.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 3a7da42bed57..81b9f4fc3978 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -861,7 +861,8 @@ int kvmppc_xive_set_mapped(struct kvm *kvm, unsigned long guest_irq,
> struct kvmppc_xive *xive = kvm->arch.xive;
> struct kvmppc_xive_src_block *sb;
> struct kvmppc_xive_irq_state *state;
> - struct irq_data *host_data = irq_get_irq_data(host_irq);
> + struct irq_data *host_data =
> + irq_domain_get_irq_data(irq_get_default_host(), host_irq);
> unsigned int hw_irq = (unsigned int)irqd_to_hwirq(host_data);
> u16 idx;
> u8 prio;
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index d10ab1d689d5..8a073d1ce611 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -481,6 +481,7 @@ struct irq_domain *irq_get_default_host(void)
> {
> return irq_default_domain;
> }
> +EXPORT_SYMBOL_GPL(irq_get_default_host);
>
> static void irq_domain_clear_mapping(struct irq_domain *domain,
> irq_hw_number_t hwirq)
^ permalink raw reply
* Re: [PATCH -next] powerpc/pseries/memhotplug: Remove unused inline function dlpar_memory_remove()
From: Daniel Henrique Barboza @ 2021-05-14 20:54 UTC (permalink / raw)
To: YueHaibing, mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20210514071041.17432-1-yuehaibing@huawei.com>
On 5/14/21 4:10 AM, YueHaibing wrote:
> dlpar_memory_remove() is never used, so can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> arch/powerpc/platforms/pseries/hotplug-memory.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 8377f1f7c78e..3d93f1c48e23 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -585,10 +585,6 @@ static inline int pseries_remove_mem_node(struct device_node *np)
> {
> return 0;
> }
> -static inline int dlpar_memory_remove(struct pseries_hp_errorlog *hp_elog)
> -{
> - return -EOPNOTSUPP;
> -}
> static int dlpar_remove_lmb(struct drmem_lmb *lmb)
> {
> return -EOPNOTSUPP;
>
^ permalink raw reply
* Re: [PATCH] arm64: Define only {pud/pmd}_{set/clear}_huge when usefull
From: Andrew Morton @ 2021-05-14 21:42 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, naresh.kamboju, linux-kernel, Nicholas Piggin,
linux-mm, linux-arm-kernel, sparclinux, linuxppc-dev,
Mike Rapoport, Mike Kravetz
In-Reply-To: <73ec95f40cafbbb69bdfb43a7f53876fd845b0ce.1620990479.git.christophe.leroy@csgroup.eu>
On Fri, 14 May 2021 11:08:53 +0000 (UTC) Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> When PUD and/or PMD are folded, those functions are useless
> and we now have a stub in linux/pgtable.h
OK, help me out here please. What patch does this fix?
^ permalink raw reply
* [PATCH] powerpc/udbg_hvc: retry putc on -EAGAIN
From: Nathan Lynch @ 2021-05-14 21:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jirislaby, linux-kernel, gregkh
hvterm_raw_put_chars() calls hvc_put_chars(), which may return -EAGAIN
when the underlying hcall returns a "busy" status, but udbg_hvc_putc()
doesn't handle this. When using xmon on a PowerVM guest, this can
result in incomplete or garbled output when printing relatively large
amounts of data quickly, such as when dumping the kernel log buffer.
Call again on -EAGAIN.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
drivers/tty/hvc/hvc_vio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index 798f27f40cc2..76d2a7038095 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -249,7 +249,7 @@ static void udbg_hvc_putc(char c)
count = hvterm_hvsi_put_chars(0, &c, 1);
break;
}
- } while(count == 0);
+ } while(count == 0 || count == -EAGAIN);
}
static int udbg_hvc_getc_poll(void)
--
2.30.2
^ permalink raw reply related
* [Bug 213069] New: kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147! Oops: Exception in kernel mode, sig: 5 [#1]
From: bugzilla-daemon @ 2021-05-14 23:44 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=213069
Bug ID: 213069
Summary: kernel BUG at
arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
Oops: Exception in kernel mode, sig: 5 [#1]
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.13-rc1
Hardware: PPC-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-64
Assignee: platform_ppc-64@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: No
Created attachment 296753
--> https://bugzilla.kernel.org/attachment.cgi?id=296753&action=edit
kernel .config (5.13-rc1, PowerMac G5 11,2)
Got this on my PowerMac G5 11,2 with v5.13-rc1 + few debug options on. The bug
was too early for netconsole to kick in so I took a photo and transcribed it.
[...]
kmemleak: Kernel memory leak detector initialized (mem pool available: 15805)
kmemleak: Automatic memory scanning thread started
debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page
table helpers
------------[ cut here ]------------
kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=4 NUMA PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.13.0-rc1-PowerMacG5
#2
NIP: c00000000003d6fc LR: c000000001024bc8 CTR: c0000000000f778c
REGS: c0000000025f7840 TRAP: 0700 Tainted: G W
(5.13.0-rc1-PowerMacG5)
MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 44002448 XER: 00000000
IRQMASK: 0
GPR00: c000000001024a5c c0000000025f7ae0 c00000000129f800 c0000000025f7b58
GPR04: 0000000000001000 8000000000000108 0000000000000000 0000000000000001
GPR08: 0000000000000000 0000000000000000 0000000000000008 0000000000000200
GPR12: 0000000024002440 c000000002366000 c00000000001003c 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: c0000000011b3388 c000000000b013e8 c0000000011b3108 4000000000000006
GPR24: 4000000000000280 00000000011b3000 0000000000000000 8000000000000105
GPR28: 0000000000001000 ffffffffffffff7f c000000000b01460 80000000011b3108
NIP [c00000000003d6fc] .pfn_pmd+x0x/0x4
LR [c000000001024bc8] .debug_vm_pgtable+0x3f4/0x51c
Call Trace:
[c0000000025f7ae0] [c000000001024a5c] .debug_vm_pgtable+0x288/0x51c
(unreliable)
[c0000000025f7bd0] [c00000000000fa58] .do_one_initcall+0x104/0x2c4
[c0000000025f7cb0] [c000000001003dec] .kernel_init_freeable+0x3d4/0x410
[c0000000025f7da0] [c00000000001004c] .kernel_init+0x10/0x15c
[c0000000025f7e10] [c00000000000bbf4] .ret_from_kernel_thread+0x58/0x64
Instruction dump:
4bffcd05 60000000 e9210078 e94d0370 7d295279 39400000 4182000c 487d3829
60000000 38210090 7fe3fb78 487dacf4 <0fe00000> 7c0802a6 f8010010 f821ff71
---[ end trace 21fc0fb84dac9a9b ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000005
Rebooting in 120 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] lockdown,selinux: fix bogus SELinux lockdown permission checks
From: Casey Schaufler @ 2021-05-15 0:57 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: SElinux list, network dev, Stephen Smalley, James Morris,
Steven Rostedt, Linux kernel mailing list, Casey Schaufler,
Linux Security Module list, Ingo Molnar, Linux FS Devel, bpf,
linuxppc-dev
In-Reply-To: <CAFqZXNu_DW1FgnVvtA+CnBMtdRDrzYo5B3_=SzKV7-o1CaV0RA@mail.gmail.com>
On 5/14/2021 8:12 AM, Ondrej Mosnacek wrote:
> On Wed, May 12, 2021 at 7:12 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 5/12/2021 9:44 AM, Ondrej Mosnacek wrote:
>>> On Wed, May 12, 2021 at 6:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 5/12/2021 6:21 AM, Ondrej Mosnacek wrote:
>>>>> On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote:
>>>>>>> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
>>>>>>> lockdown") added an implementation of the locked_down LSM hook to
>>>>>>> SELinux, with the aim to restrict which domains are allowed to perform
>>>>>>> operations that would breach lockdown.
>>>>>>>
>>>>>>> However, in several places the security_locked_down() hook is called in
>>>>>>> situations where the current task isn't doing any action that would
>>>>>>> directly breach lockdown, leading to SELinux checks that are basically
>>>>>>> bogus.
>>>>>>>
>>>>>>> Since in most of these situations converting the callers such that
>>>>>>> security_locked_down() is called in a context where the current task
>>>>>>> would be meaningful for SELinux is impossible or very non-trivial (and
>>>>>>> could lead to TOCTOU issues for the classic Lockdown LSM
>>>>>>> implementation), fix this by adding a separate hook
>>>>>>> security_locked_down_globally()
>>>>>> This is a poor solution to the stated problem. Rather than adding
>>>>>> a new hook you should add the task as a parameter to the existing hook
>>>>>> and let the security modules do as they will based on its value.
>>>>>> If the caller does not have an appropriate task it should pass NULL.
>>>>>> The lockdown LSM can ignore the task value and SELinux can make its
>>>>>> own decision based on the task value passed.
>>>>> The problem with that approach is that all callers would then need to
>>>>> be updated and I intended to keep the patch small as I'd like it to go
>>>>> to stable kernels as well.
>>>>>
>>>>> But it does seem to be a better long-term solution - would it work for
>>>>> you (and whichever maintainer would be taking the patch(es)) if I just
>>>>> added another patch that refactors it to use the task parameter?
>>>> I can't figure out what you're suggesting. Are you saying that you
>>>> want to add a new hook *and* add the task parameter?
>>> No, just to keep this patch as-is (and let it go to stable in this
>>> form) and post another (non-stable) patch on top of it that undoes the
>>> new hook and re-implements the fix using your suggestion. (Yeah, it'll
>>> look weird, but I'm not sure how better to handle such situation - I'm
>>> open to doing it whatever different way the maintainers prefer.)
>> James gets to make the call on this one. If it was my call I would
>> tell you to make the task parameter change and accept the backport
>> pain. I think that as a security developer community we spend way too
>> much time and effort trying to avoid being noticed in source trees.
> Hm... actually, what about this attached patch? It switches to a
> single hook with a cred argument (I figured cred makes more sense than
> task_struct, since the rest of task_struct should be irrelevant for
> the LSM, anyway...) right from the start and keeps the original
> security_locked_down() function only as a simple wrapper around the
> main hook.
>
> At that point I think converting the other callers to call
> security_cred_locked_down() directly isn't really worth it, since the
> resulting calls would just be more verbose without much benefit. So
> I'm tempted to just leave the security_locked_down() helper as is, so
> that the more common pattern can be still achieved with a simpler
> call.
>
> What do you think?
It's still a bit kludgy, but a big improvement over the previous version.
I wouldn't object to this approach.
>
> --
> Ondrej Mosnacek
> Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS c6ac667b07996929835b512de0e9a988977e6abc
From: kernel test robot @ 2021-05-15 2:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: c6ac667b07996929835b512de0e9a988977e6abc powerpc/64e/interrupt: Fix nvgprs being clobbered
elapsed time: 726m
configs tested: 114
configs skipped: 31
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 allyesconfig
arm allmodconfig
mips rm200_defconfig
arm pxa255-idp_defconfig
arm mini2440_defconfig
powerpc eiger_defconfig
xtensa cadence_csp_defconfig
powerpc ps3_defconfig
m68k m5307c3_defconfig
m68k m5275evb_defconfig
arm iop32x_defconfig
powerpc mpc8315_rdb_defconfig
sh landisk_defconfig
m68k amcore_defconfig
sh apsh4ad0a_defconfig
arm keystone_defconfig
um alldefconfig
sh edosk7705_defconfig
arm davinci_all_defconfig
mips tb0219_defconfig
sh sh2007_defconfig
m68k m5272c3_defconfig
powerpc mpc836x_mds_defconfig
arm imx_v4_v5_defconfig
powerpc tqm5200_defconfig
sh sh7770_generic_defconfig
h8300 defconfig
sh sh7785lcr_defconfig
arc defconfig
m68k m5249evb_defconfig
m68k sun3_defconfig
powerpc mpc512x_defconfig
openrisc simple_smp_defconfig
mips ip22_defconfig
arc axs101_defconfig
m68k hp300_defconfig
powerpc wii_defconfig
riscv rv32_defconfig
xtensa nommu_kc705_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210514
i386 randconfig-a001-20210514
i386 randconfig-a004-20210514
i386 randconfig-a005-20210514
i386 randconfig-a002-20210514
i386 randconfig-a006-20210514
x86_64 randconfig-a004-20210514
x86_64 randconfig-a003-20210514
x86_64 randconfig-a001-20210514
x86_64 randconfig-a005-20210514
x86_64 randconfig-a002-20210514
x86_64 randconfig-a006-20210514
i386 randconfig-a016-20210514
i386 randconfig-a014-20210514
i386 randconfig-a011-20210514
i386 randconfig-a012-20210514
i386 randconfig-a015-20210514
i386 randconfig-a013-20210514
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210514
x86_64 randconfig-a012-20210514
x86_64 randconfig-a011-20210514
x86_64 randconfig-a013-20210514
x86_64 randconfig-a016-20210514
x86_64 randconfig-a014-20210514
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS b68d19e1abdbafef9481c7c0b0bcaff34d7af17d
From: kernel test robot @ 2021-05-15 2:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: b68d19e1abdbafef9481c7c0b0bcaff34d7af17d Automatic merge of 'master' into merge (2021-05-10 08:23)
elapsed time: 723m
configs tested: 109
configs skipped: 3
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 allyesconfig
arm allmodconfig
mips rm200_defconfig
arm pxa255-idp_defconfig
arm mini2440_defconfig
powerpc eiger_defconfig
xtensa cadence_csp_defconfig
powerpc ps3_defconfig
m68k m5307c3_defconfig
m68k m5275evb_defconfig
arm iop32x_defconfig
powerpc mpc8315_rdb_defconfig
sh landisk_defconfig
m68k amcore_defconfig
sh apsh4ad0a_defconfig
arm keystone_defconfig
um alldefconfig
sh edosk7705_defconfig
arm imx_v4_v5_defconfig
powerpc tqm5200_defconfig
sh sh7770_generic_defconfig
h8300 defconfig
sh sh7785lcr_defconfig
arc defconfig
m68k m5249evb_defconfig
m68k sun3_defconfig
powerpc mpc512x_defconfig
openrisc simple_smp_defconfig
mips ip22_defconfig
arc axs101_defconfig
m68k hp300_defconfig
powerpc wii_defconfig
riscv rv32_defconfig
xtensa nommu_kc705_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210514
x86_64 randconfig-a003-20210514
x86_64 randconfig-a001-20210514
x86_64 randconfig-a005-20210514
x86_64 randconfig-a002-20210514
x86_64 randconfig-a006-20210514
i386 randconfig-a003-20210514
i386 randconfig-a001-20210514
i386 randconfig-a004-20210514
i386 randconfig-a005-20210514
i386 randconfig-a002-20210514
i386 randconfig-a006-20210514
i386 randconfig-a016-20210514
i386 randconfig-a014-20210514
i386 randconfig-a011-20210514
i386 randconfig-a012-20210514
i386 randconfig-a015-20210514
i386 randconfig-a013-20210514
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210514
x86_64 randconfig-a012-20210514
x86_64 randconfig-a011-20210514
x86_64 randconfig-a013-20210514
x86_64 randconfig-a016-20210514
x86_64 randconfig-a014-20210514
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 4572be3694e6e0f9ee6b669df8e4b5bbc040791e
From: kernel test robot @ 2021-05-15 2:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 4572be3694e6e0f9ee6b669df8e4b5bbc040791e selftests/powerpc: Add test of mitigation patching
elapsed time: 723m
configs tested: 165
configs skipped: 3
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 allyesconfig
arm allmodconfig
mips mtx1_defconfig
arm stm32_defconfig
mips ip32_defconfig
arm sunxi_defconfig
mips bcm63xx_defconfig
powerpc mpc836x_rdk_defconfig
sh rsk7264_defconfig
arm lpc32xx_defconfig
powerpc mpc834x_mds_defconfig
sh ecovec24_defconfig
xtensa cadence_csp_defconfig
mips rm200_defconfig
arm pxa255-idp_defconfig
arm mini2440_defconfig
powerpc eiger_defconfig
powerpc mpc832x_rdb_defconfig
powerpc ppc64_defconfig
arm milbeaut_m10v_defconfig
mips rb532_defconfig
arm ixp4xx_defconfig
um defconfig
powerpc ps3_defconfig
m68k m5307c3_defconfig
m68k m5275evb_defconfig
arm iop32x_defconfig
powerpc mpc8315_rdb_defconfig
sh landisk_defconfig
m68k amcore_defconfig
sh apsh4ad0a_defconfig
arm keystone_defconfig
um alldefconfig
sh edosk7705_defconfig
openrisc or1klitex_defconfig
powerpc amigaone_defconfig
sh sdk7786_defconfig
powerpc mpc832x_mds_defconfig
sh se7206_defconfig
m68k mvme16x_defconfig
mips pistachio_defconfig
arm oxnas_v6_defconfig
arm jornada720_defconfig
nios2 3c120_defconfig
openrisc alldefconfig
ia64 defconfig
powerpc mpc5200_defconfig
parisc generic-64bit_defconfig
arm mps2_defconfig
powerpc chrp32_defconfig
ia64 tiger_defconfig
powerpc currituck_defconfig
riscv defconfig
arm imx_v4_v5_defconfig
powerpc tqm5200_defconfig
sh sh7770_generic_defconfig
h8300 defconfig
sh sh7785lcr_defconfig
arc defconfig
m68k m5249evb_defconfig
m68k sun3_defconfig
powerpc mpc512x_defconfig
openrisc simple_smp_defconfig
mips ip22_defconfig
arc axs101_defconfig
m68k hp300_defconfig
powerpc wii_defconfig
riscv rv32_defconfig
xtensa nommu_kc705_defconfig
arm mainstone_defconfig
openrisc defconfig
arm mvebu_v5_defconfig
arc tb10x_defconfig
sparc64 alldefconfig
openrisc or1ksim_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210514
x86_64 randconfig-a003-20210514
x86_64 randconfig-a001-20210514
x86_64 randconfig-a005-20210514
x86_64 randconfig-a002-20210514
x86_64 randconfig-a006-20210514
i386 randconfig-a003-20210514
i386 randconfig-a001-20210514
i386 randconfig-a004-20210514
i386 randconfig-a005-20210514
i386 randconfig-a002-20210514
i386 randconfig-a006-20210514
x86_64 randconfig-a012-20210515
x86_64 randconfig-a015-20210515
x86_64 randconfig-a011-20210515
x86_64 randconfig-a013-20210515
x86_64 randconfig-a016-20210515
x86_64 randconfig-a014-20210515
i386 randconfig-a016-20210515
i386 randconfig-a014-20210515
i386 randconfig-a011-20210515
i386 randconfig-a012-20210515
i386 randconfig-a015-20210515
i386 randconfig-a013-20210515
i386 randconfig-a016-20210514
i386 randconfig-a014-20210514
i386 randconfig-a011-20210514
i386 randconfig-a012-20210514
i386 randconfig-a015-20210514
i386 randconfig-a013-20210514
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210515
x86_64 randconfig-a003-20210515
x86_64 randconfig-a001-20210515
x86_64 randconfig-a005-20210515
x86_64 randconfig-a002-20210515
x86_64 randconfig-a006-20210515
x86_64 randconfig-a015-20210514
x86_64 randconfig-a012-20210514
x86_64 randconfig-a011-20210514
x86_64 randconfig-a013-20210514
x86_64 randconfig-a016-20210514
x86_64 randconfig-a014-20210514
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] arm64: Define only {pud/pmd}_{set/clear}_huge when usefull
From: Nathan Chancellor @ 2021-05-15 3:58 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-arm-kernel, naresh.kamboju, linux-kernel,
Nicholas Piggin, linux-mm, sparclinux, linuxppc-dev,
Mike Rapoport, Mike Kravetz
In-Reply-To: <20210514144200.b49ee77c9b2a7f9998ffbf22@linux-foundation.org>
On Fri, May 14, 2021 at 02:42:00PM -0700, Andrew Morton wrote:
> On Fri, 14 May 2021 11:08:53 +0000 (UTC) Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
> > When PUD and/or PMD are folded, those functions are useless
> > and we now have a stub in linux/pgtable.h
>
> OK, help me out here please. What patch does this fix?
>
Naresh's original report is here it seems:
https://lore.kernel.org/r/CA+G9fYv79t0+2W4Rt3wDkBShc4eY3M3utC5BHqUgGDwMYExYMw@mail.gmail.com/
I can reproduce the failure that he reported with
ARCH=arm64 allmodconfig and this patch resolves it for me.
Cheers,
Nathan
^ permalink raw reply
* [PATCH v2 01/14] PCI: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b717680377a9..5ed316ea5831 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6439,7 +6439,7 @@ static ssize_t resource_alignment_show(struct bus_type *bus, char *buf)
spin_lock(&resource_alignment_lock);
if (resource_alignment_param)
- count = scnprintf(buf, PAGE_SIZE, "%s", resource_alignment_param);
+ count = sysfs_emit(buf, "%s", resource_alignment_param);
spin_unlock(&resource_alignment_lock);
/*
--
2.31.1
^ permalink raw reply related
* [PATCH v2 02/14] PCI/AER: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/pcie/aer.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ec943cee5ecc..40ef7bed7a77 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -529,21 +529,23 @@ static const char *aer_agent_string[] = {
char *buf) \
{ \
unsigned int i; \
- char *str = buf; \
struct pci_dev *pdev = to_pci_dev(dev); \
u64 *stats = pdev->aer_stats->stats_array; \
+ size_t len = 0; \
\
for (i = 0; i < ARRAY_SIZE(strings_array); i++) { \
if (strings_array[i]) \
- str += sprintf(str, "%s %llu\n", \
- strings_array[i], stats[i]); \
+ len += sysfs_emit_at(buf, len, "%s %llu\n", \
+ strings_array[i], \
+ stats[i]); \
else if (stats[i]) \
- str += sprintf(str, #stats_array "_bit[%d] %llu\n",\
- i, stats[i]); \
+ len += sysfs_emit_at(buf, len, \
+ #stats_array "_bit[%d] %llu\n",\
+ i, stats[i]); \
} \
- str += sprintf(str, "TOTAL_%s %llu\n", total_string, \
- pdev->aer_stats->total_field); \
- return str-buf; \
+ len += sysfs_emit_at(buf, len, "TOTAL_%s %llu\n", total_string, \
+ pdev->aer_stats->total_field); \
+ return len; \
} \
static DEVICE_ATTR_RO(name)
@@ -563,7 +565,7 @@ aer_stats_dev_attr(aer_dev_nonfatal, dev_nonfatal_errs,
char *buf) \
{ \
struct pci_dev *pdev = to_pci_dev(dev); \
- return sprintf(buf, "%llu\n", pdev->aer_stats->field); \
+ return sysfs_emit(buf, "%llu\n", pdev->aer_stats->field); \
} \
static DEVICE_ATTR_RO(name)
--
2.31.1
^ permalink raw reply related
* [PATCH v2 03/14] PCI: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
Modify the function dsm_label_utf16s_to_utf8s() to directly return the
number of bytes written into the buffer so that the strlen() used later
to calculate the length of the buffer can be removed as it would no
longer be needed.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/pci-label.c | 18 ++++++++++--------
drivers/pci/slot.c | 16 ++++++++--------
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index c32f3b7540e8..000e169c7197 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -139,14 +139,17 @@ enum acpi_attr_enum {
ACPI_ATTR_INDEX_SHOW,
};
-static void dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
+static int dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
{
int len;
+
len = utf16s_to_utf8s((const wchar_t *)obj->buffer.pointer,
obj->buffer.length,
UTF16_LITTLE_ENDIAN,
buf, PAGE_SIZE);
buf[len] = '\n';
+
+ return len;
}
static int dsm_get_label(struct device *dev, char *buf,
@@ -154,7 +157,7 @@ static int dsm_get_label(struct device *dev, char *buf,
{
acpi_handle handle = ACPI_HANDLE(dev);
union acpi_object *obj, *tmp;
- int len = -1;
+ int len = 0;
if (!handle)
return -1;
@@ -175,20 +178,19 @@ static int dsm_get_label(struct device *dev, char *buf,
* this entry must return a null string.
*/
if (attr == ACPI_ATTR_INDEX_SHOW) {
- scnprintf(buf, PAGE_SIZE, "%llu\n", tmp->integer.value);
+ len = sysfs_emit(buf, "%llu\n", tmp->integer.value);
} else if (attr == ACPI_ATTR_LABEL_SHOW) {
if (tmp[1].type == ACPI_TYPE_STRING)
- scnprintf(buf, PAGE_SIZE, "%s\n",
- tmp[1].string.pointer);
+ len = sysfs_emit(buf, "%s\n",
+ tmp[1].string.pointer);
else if (tmp[1].type == ACPI_TYPE_BUFFER)
- dsm_label_utf16s_to_utf8s(tmp + 1, buf);
+ len = dsm_label_utf16s_to_utf8s(tmp + 1, buf);
}
- len = strlen(buf) > 0 ? strlen(buf) : -1;
}
ACPI_FREE(obj);
- return len;
+ return len > 0 ? len : -1;
}
static ssize_t label_show(struct device *dev, struct device_attribute *attr,
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index d627dd9179b4..7487e8f8f13f 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -39,19 +39,19 @@ static const struct sysfs_ops pci_slot_sysfs_ops = {
static ssize_t address_read_file(struct pci_slot *slot, char *buf)
{
if (slot->number == 0xff)
- return sprintf(buf, "%04x:%02x\n",
- pci_domain_nr(slot->bus),
- slot->bus->number);
+ return sysfs_emit(buf, "%04x:%02x\n",
+ pci_domain_nr(slot->bus),
+ slot->bus->number);
else
- return sprintf(buf, "%04x:%02x:%02x\n",
- pci_domain_nr(slot->bus),
- slot->bus->number,
- slot->number);
+ return sysfs_emit(buf, "%04x:%02x:%02x\n",
+ pci_domain_nr(slot->bus),
+ slot->bus->number,
+ slot->number);
}
static ssize_t bus_speed_read(enum pci_bus_speed speed, char *buf)
{
- return sprintf(buf, "%s\n", pci_speed_string(speed));
+ return sysfs_emit(buf, "%s\n", pci_speed_string(speed));
}
static ssize_t max_speed_read_file(struct pci_slot *slot, char *buf)
--
2.31.1
^ permalink raw reply related
* [PATCH v2 04/14] PCI/MSI: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/msi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 217dc9f0231f..dbfec59dfe41 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -465,8 +465,8 @@ static ssize_t msi_mode_show(struct device *dev, struct device_attribute *attr,
entry = irq_get_msi_desc(irq);
if (entry)
- return sprintf(buf, "%s\n",
- entry->msi_attrib.is_msix ? "msix" : "msi");
+ return sysfs_emit(buf, "%s\n",
+ entry->msi_attrib.is_msix ? "msix" : "msi");
return -ENODEV;
}
--
2.31.1
^ permalink raw reply related
* [PATCH v2 05/14] PCI/IOV: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/iov.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index afc06e6ce115..a71258347323 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -346,7 +346,7 @@ static ssize_t sriov_totalvfs_show(struct device *dev,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return sprintf(buf, "%u\n", pci_sriov_get_totalvfs(pdev));
+ return sysfs_emit(buf, "%u\n", pci_sriov_get_totalvfs(pdev));
}
static ssize_t sriov_numvfs_show(struct device *dev,
@@ -361,7 +361,7 @@ static ssize_t sriov_numvfs_show(struct device *dev,
num_vfs = pdev->sriov->num_VFs;
device_unlock(&pdev->dev);
- return sprintf(buf, "%u\n", num_vfs);
+ return sysfs_emit(buf, "%u\n", num_vfs);
}
/*
@@ -435,7 +435,7 @@ static ssize_t sriov_offset_show(struct device *dev,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return sprintf(buf, "%u\n", pdev->sriov->offset);
+ return sysfs_emit(buf, "%u\n", pdev->sriov->offset);
}
static ssize_t sriov_stride_show(struct device *dev,
@@ -444,7 +444,7 @@ static ssize_t sriov_stride_show(struct device *dev,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return sprintf(buf, "%u\n", pdev->sriov->stride);
+ return sysfs_emit(buf, "%u\n", pdev->sriov->stride);
}
static ssize_t sriov_vf_device_show(struct device *dev,
@@ -453,7 +453,7 @@ static ssize_t sriov_vf_device_show(struct device *dev,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return sprintf(buf, "%x\n", pdev->sriov->vf_device);
+ return sysfs_emit(buf, "%x\n", pdev->sriov->vf_device);
}
static ssize_t sriov_drivers_autoprobe_show(struct device *dev,
@@ -462,7 +462,7 @@ static ssize_t sriov_drivers_autoprobe_show(struct device *dev,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return sprintf(buf, "%u\n", pdev->sriov->drivers_autoprobe);
+ return sysfs_emit(buf, "%u\n", pdev->sriov->drivers_autoprobe);
}
static ssize_t sriov_drivers_autoprobe_store(struct device *dev,
--
2.31.1
^ permalink raw reply related
* [PATCH v2 06/14] PCI/P2PDMA: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/p2pdma.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 196382630363..a1351b3e2c4c 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -53,7 +53,7 @@ static ssize_t size_show(struct device *dev, struct device_attribute *attr,
if (pdev->p2pdma->pool)
size = gen_pool_size(pdev->p2pdma->pool);
- return scnprintf(buf, PAGE_SIZE, "%zd\n", size);
+ return sysfs_emit(buf, "%zd\n", size);
}
static DEVICE_ATTR_RO(size);
@@ -66,7 +66,7 @@ static ssize_t available_show(struct device *dev, struct device_attribute *attr,
if (pdev->p2pdma->pool)
avail = gen_pool_avail(pdev->p2pdma->pool);
- return scnprintf(buf, PAGE_SIZE, "%zd\n", avail);
+ return sysfs_emit(buf, "%zd\n", avail);
}
static DEVICE_ATTR_RO(available);
@@ -75,8 +75,7 @@ static ssize_t published_show(struct device *dev, struct device_attribute *attr,
{
struct pci_dev *pdev = to_pci_dev(dev);
- return scnprintf(buf, PAGE_SIZE, "%d\n",
- pdev->p2pdma->p2pmem_published);
+ return sysfs_emit(buf, "%d\n", pdev->p2pdma->p2pmem_published);
}
static DEVICE_ATTR_RO(published);
--
2.31.1
^ permalink raw reply related
* [PATCH v2 07/14] PCI/ASPM: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/pcie/aspm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index ac0557a305af..013a47f587ce 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -1208,7 +1208,7 @@ static ssize_t aspm_attr_show_common(struct device *dev,
struct pci_dev *pdev = to_pci_dev(dev);
struct pcie_link_state *link = pcie_aspm_get_link(pdev);
- return sprintf(buf, "%d\n", (link->aspm_enabled & state) ? 1 : 0);
+ return sysfs_emit(buf, "%d\n", (link->aspm_enabled & state) ? 1 : 0);
}
static ssize_t aspm_attr_store_common(struct device *dev,
@@ -1265,7 +1265,7 @@ static ssize_t clkpm_show(struct device *dev,
struct pci_dev *pdev = to_pci_dev(dev);
struct pcie_link_state *link = pcie_aspm_get_link(pdev);
- return sprintf(buf, "%d\n", link->clkpm_enabled);
+ return sysfs_emit(buf, "%d\n", link->clkpm_enabled);
}
static ssize_t clkpm_store(struct device *dev,
--
2.31.1
^ permalink raw reply related
* [PATCH v2 08/14] PCI: switchtec: Use sysfs_emit() and sysfs_emit_at() in "show" functions
From: Krzysztof Wilczyński @ 2021-05-15 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, linuxppc-dev, Vidya Sagar,
Oliver O'Halloran, Joe Perches, Paul Mackerras,
Kurt Schwemmer, Logan Gunthorpe, Xiongfeng Wang
In-Reply-To: <20210515052434.1413236-1-kw@linux.com>
The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Related to:
commit ad025f8e46f3 ("PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
drivers/pci/switch/switchtec.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index ba52459928f7..0b301f8be9ed 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -280,7 +280,7 @@ static ssize_t device_version_show(struct device *dev,
ver = ioread32(&stdev->mmio_sys_info->device_version);
- return sprintf(buf, "%x\n", ver);
+ return sysfs_emit(buf, "%x\n", ver);
}
static DEVICE_ATTR_RO(device_version);
@@ -292,7 +292,7 @@ static ssize_t fw_version_show(struct device *dev,
ver = ioread32(&stdev->mmio_sys_info->firmware_version);
- return sprintf(buf, "%08x\n", ver);
+ return sysfs_emit(buf, "%08x\n", ver);
}
static DEVICE_ATTR_RO(fw_version);
@@ -344,7 +344,7 @@ static ssize_t component_vendor_show(struct device *dev,
/* component_vendor field not supported after gen3 */
if (stdev->gen != SWITCHTEC_GEN3)
- return sprintf(buf, "none\n");
+ return sysfs_emit(buf, "none\n");
return io_string_show(buf, &si->gen3.component_vendor,
sizeof(si->gen3.component_vendor));
@@ -359,9 +359,9 @@ static ssize_t component_id_show(struct device *dev,
/* component_id field not supported after gen3 */
if (stdev->gen != SWITCHTEC_GEN3)
- return sprintf(buf, "none\n");
+ return sysfs_emit(buf, "none\n");
- return sprintf(buf, "PM%04X\n", id);
+ return sysfs_emit(buf, "PM%04X\n", id);
}
static DEVICE_ATTR_RO(component_id);
@@ -373,9 +373,9 @@ static ssize_t component_revision_show(struct device *dev,
/* component_revision field not supported after gen3 */
if (stdev->gen != SWITCHTEC_GEN3)
- return sprintf(buf, "255\n");
+ return sysfs_emit(buf, "255\n");
- return sprintf(buf, "%d\n", rev);
+ return sysfs_emit(buf, "%d\n", rev);
}
static DEVICE_ATTR_RO(component_revision);
@@ -384,7 +384,7 @@ static ssize_t partition_show(struct device *dev,
{
struct switchtec_dev *stdev = to_stdev(dev);
- return sprintf(buf, "%d\n", stdev->partition);
+ return sysfs_emit(buf, "%d\n", stdev->partition);
}
static DEVICE_ATTR_RO(partition);
@@ -393,7 +393,7 @@ static ssize_t partition_count_show(struct device *dev,
{
struct switchtec_dev *stdev = to_stdev(dev);
- return sprintf(buf, "%d\n", stdev->partition_count);
+ return sysfs_emit(buf, "%d\n", stdev->partition_count);
}
static DEVICE_ATTR_RO(partition_count);
--
2.31.1
^ 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