* Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Andrew Morton @ 2020-06-16 18:09 UTC (permalink / raw)
To: Waiman Long
Cc: Jason A . Donenfeld, Michal Hocko, Jarkko Sakkinen,
virtualization, David Howells, linux-mm, linux-sctp, keyrings,
kasan-dev, linux-stm32, devel, linux-cifs, linux-scsi,
James Morris, Matthew Wilcox, linux-wpan, David Rientjes,
Dan Carpenter, Serge E. Hallyn, linux-pm, ecryptfs, linux-fscrypt,
linux-mediatek, linux-amlogic, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, linux-integrity,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200616154311.12314-3-longman@redhat.com>
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long <longman@redhat.com> wrote:
> As said by Linus:
>
> A symmetric naming is only helpful if it implies symmetries in use.
> Otherwise it's actively misleading.
>
> In "kzalloc()", the z is meaningful and an important part of what the
> caller wants.
>
> In "kzfree()", the z is actively detrimental, because maybe in the
> future we really _might_ want to use that "memfill(0xdeadbeef)" or
> something. The "zero" part of the interface isn't even _relevant_.
>
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
>
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.
>
> The renaming is done by using the command sequence:
>
> git grep -w --name-only kzfree |\
> xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
>
> followed by some editing of the kfree_sensitive() kerneldoc and adding
> a kzfree backward compatibility macro in slab.h.
>
> ...
>
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, struct mem_cgroup *);
> */
> void * __must_check krealloc(const void *, size_t, gfp_t);
> void kfree(const void *);
> -void kzfree(const void *);
> +void kfree_sensitive(const void *);
> size_t __ksize(const void *);
> size_t ksize(const void *);
>
> +#define kzfree(x) kfree_sensitive(x) /* For backward compatibility */
> +
What was the thinking here? Is this really necessary?
I suppose we could keep this around for a while to ease migration. But
not for too long, please.
^ permalink raw reply
* Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
From: Nathan Chancellor @ 2020-06-16 18:16 UTC (permalink / raw)
To: Michal Simek
Cc: arnd, linux-kernel, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <68503e5e-7456-b81c-e43d-27cb331a4b72@xilinx.com>
Hi Michal,
On Tue, Jun 16, 2020 at 04:45:20PM +0200, Michal Simek wrote:
>
>
> On 16. 06. 20 2:27, Nathan Chancellor wrote:
> > On Thu, May 21, 2020 at 04:55:52PM +0000, Christophe Leroy wrote:
> >> From: Michal Simek <michal.simek@xilinx.com>
> >>
> >> The latest Xilinx design tools called ISE and EDK has been released in
> >> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> >> These platforms are no longer supported and tested.
> >>
> >> PowerPC 405/440 port is orphan from 2013 by
> >> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> >> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and maintainership")
> >> that's why it is time to remove the support fot these platforms.
> >>
> >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >
> > This patch causes qemu-system-ppc to fail to load ppc44x_defconfig:
> >
> > $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc distclean ppc44x_defconfig zImage
> >
> > $ timeout --foreground 30s unbuffer \
> > qemu-system-ppc \
> > -machine bamboo \
>
> Did you bisect it that you found that this patch is causing problem for
> you on any bamboo machine?
>
> Or this was caused by the whole series?
>
> Thanks,
> Michal
Yes, this conclusion was the result of the following bisect:
$ cat test.sh
#!/usr/bin/env bash
cd "${HOME}"/src/linux || exit 125
set -x
PATH=${HOME}/toolchains/gcc/10.1.0/bin:${PATH} \
make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc32 distclean ppc44x_defconfig zImage || exit 125
"${HOME}"/cbl/github/boot-utils/boot-qemu.sh -a ppc32 -k out/ppc32 -t 30s
$ git bisect start v5.8-rc1 v5.7
...
$ git bisect run test.sh
...
$ git bisect log
# bad: [b3a9e3b9622ae10064826dccb4f7a52bd88c7407] Linux 5.8-rc1
# good: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7
git bisect start 'v5.8-rc1' 'v5.7'
# good: [ee01c4d72adffb7d424535adf630f2955748fa8b] Merge branch 'akpm' (patches from Andrew)
git bisect good ee01c4d72adffb7d424535adf630f2955748fa8b
# bad: [6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7] Merge tag 'dma-mapping-5.8-2' of git://git.infradead.org/users/hch/dma-mapping
git bisect bad 6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7
# skip: [828f3e18e1cb98c68fc6db4d5113513d4a267775] Merge tag 'arm-drivers-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect skip 828f3e18e1cb98c68fc6db4d5113513d4a267775
# good: [c46241a370a61f0f264791abb9fc869016e749ce] powerpc/pkeys: Check vma before returning key fault error to the user
git bisect good c46241a370a61f0f264791abb9fc869016e749ce
# good: [3f0be4df50a7854a831c80a74d7cf2cfd61f2fde] Merge tag 'versatile-dts-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into arm/dt
git bisect good 3f0be4df50a7854a831c80a74d7cf2cfd61f2fde
# bad: [bd55e792de0844631d34487d43eaf3f13294ebfe] powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
git bisect bad bd55e792de0844631d34487d43eaf3f13294ebfe
# good: [303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3] powerpc/watchpoint: Convert thread_struct->hw_brk to an array
git bisect good 303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3
# good: [0755e85570a4615ca674ad6489d44d63916f1f3e] powerpc/xive: Do not expose a debugfs file when XIVE is disabled
git bisect good 0755e85570a4615ca674ad6489d44d63916f1f3e
# bad: [b4ac18eead28611ff470d0f47a35c4e0ac080d9c] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
git bisect bad b4ac18eead28611ff470d0f47a35c4e0ac080d9c
# bad: [3aacaa719b7bf135551cabde2480e8f7bfdf7c7d] powerpc/40x: Don't save CR in SPRN_SPRG_SCRATCH6
git bisect bad 3aacaa719b7bf135551cabde2480e8f7bfdf7c7d
# bad: [1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0] powerpc/40x: Remove support for IBM 403GCX
git bisect bad 1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0
# good: [0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978] powerpc/64: Refactor interrupt exit irq disabling sequence
git bisect good 0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978
# bad: [2c74e2586bb96012ffc05f1c819b05d9cad86d6e] powerpc/40x: Rework 40x PTE access and TLB miss
git bisect bad 2c74e2586bb96012ffc05f1c819b05d9cad86d6e
# bad: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove Xilinx PPC405/PPC440 support
git bisect bad 7ade8495dcfd788a76e6877c9ea86f5207369ea4
# first bad commit: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove Xilinx PPC405/PPC440 support
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Johannes Thumshirn @ 2020-06-16 14:13 UTC (permalink / raw)
To: Bart Van Assche, Finn Thain, Chris Boot
Cc: Martin K . Petersen, linux-scsi@vger.kernel.org, Chuhong Yuan,
linux-kernel@vger.kernel.org, Nicholas Bellinger,
target-devel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Stefan Richter
In-Reply-To: <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org>
On 16/06/2020 16:09, Bart Van Assche wrote:
> On 2020-06-16 02:42, Finn Thain wrote:
>> Martin said, "I'd appreciate a patch to remove it"
>>
>> And Bart said, "do you want to keep this driver in the kernel tree?"
>>
>> AFAICT both comments are quite ambiguous. I don't see an actionable
>> request, just an expression of interest from people doing their jobs.
>>
>> Note well: there is no pay check associated with having a MAINTAINERS file
>> entry.
>
> Hi Finn,
>
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver. So why to keep it in the kernel tree?
> Restoring a kernel driver can be easy - the first step is a "git revert".
Why not move the driver to drivers/staging for 2 or 3 kernel releases and if
noone steps up, delete it?
Just my 2 Cents,
Johannes
^ permalink raw reply
* Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 18:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Jason A . Donenfeld, Michal Hocko, Jarkko Sakkinen,
virtualization, David Howells, linux-mm, linux-sctp, keyrings,
kasan-dev, linux-stm32, devel, linux-cifs, linux-scsi,
James Morris, Matthew Wilcox, linux-wpan, David Rientjes,
Dan Carpenter, Serge E. Hallyn, linux-pm, ecryptfs, linux-fscrypt,
linux-mediatek, linux-amlogic, linux-nfs, Linus Torvalds,
linux-wireless, linux-kernel, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
linux-crypto, Johannes Weiner, Joe Perches, linux-integrity,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <20200616110944.c13f221e5c3f54e775190afe@linux-foundation.org>
On 6/16/20 2:09 PM, Andrew Morton wrote:
> On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long <longman@redhat.com> wrote:
>
>> As said by Linus:
>>
>> A symmetric naming is only helpful if it implies symmetries in use.
>> Otherwise it's actively misleading.
>>
>> In "kzalloc()", the z is meaningful and an important part of what the
>> caller wants.
>>
>> In "kzfree()", the z is actively detrimental, because maybe in the
>> future we really _might_ want to use that "memfill(0xdeadbeef)" or
>> something. The "zero" part of the interface isn't even _relevant_.
>>
>> The main reason that kzfree() exists is to clear sensitive information
>> that should not be leaked to other future users of the same memory
>> objects.
>>
>> Rename kzfree() to kfree_sensitive() to follow the example of the
>> recently added kvfree_sensitive() and make the intention of the API
>> more explicit. In addition, memzero_explicit() is used to clear the
>> memory to make sure that it won't get optimized away by the compiler.
>>
>> The renaming is done by using the command sequence:
>>
>> git grep -w --name-only kzfree |\
>> xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
>>
>> followed by some editing of the kfree_sensitive() kerneldoc and adding
>> a kzfree backward compatibility macro in slab.h.
>>
>> ...
>>
>> --- a/include/linux/slab.h
>> +++ b/include/linux/slab.h
>> @@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, struct mem_cgroup *);
>> */
>> void * __must_check krealloc(const void *, size_t, gfp_t);
>> void kfree(const void *);
>> -void kzfree(const void *);
>> +void kfree_sensitive(const void *);
>> size_t __ksize(const void *);
>> size_t ksize(const void *);
>>
>> +#define kzfree(x) kfree_sensitive(x) /* For backward compatibility */
>> +
> What was the thinking here? Is this really necessary?
>
> I suppose we could keep this around for a while to ease migration. But
> not for too long, please.
>
It should be there just for 1 release cycle. I have broken out the btrfs
patch to the btrfs list and I didn't make the kzfree to kfree_sensitive
conversion there as that patch was in front in my patch list. So
depending on which one lands first, there can be a window where the
compilation may fail without this workaround. I am going to send out
another patch in the next release cycle to remove it.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Joe Perches @ 2020-06-16 18:53 UTC (permalink / raw)
To: Waiman Long, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <20200616015718.7812-1-longman@redhat.com>
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> v4:
> - Break out the memzero_explicit() change as suggested by Dan Carpenter
> so that it can be backported to stable.
> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> now as there can be a bit more discussion on what is best. It will be
> introduced as a separate patch later on after this one is merged.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
Are there _any_ fastpath uses of kfree or vfree?
Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.
To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?
Something like the below:
void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;
if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}
#define kvfree kfree
#define vfree kfree
#define kfree_const kfree
^ permalink raw reply
* Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
From: Bhupesh Sharma @ 2020-06-16 19:24 UTC (permalink / raw)
To: Bharat Gooty
Cc: Mark Rutland, Ard Biesheuvel, Linux Doc Mailing List,
Catalin Marinas, x86, kexec mailing list,
Linux Kernel Mailing List, Ray Jui, linuxppc-dev, Kazuhito Hagio,
James Morse, linux-arm-kernel, Amit Kachhap, Dave Anderson,
bhupesh linux, Will Deacon, Scott Branden, Steve Capper
In-Reply-To: <f644ddb6fdb926606bb376a9f491ee79@mail.gmail.com>
Hello Bharat,
On Wed, Jun 10, 2020 at 10:17 PM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>
> Hello Bhupesh,
> V6 patch set on Linux 5.7, did not help.
> I have applied makedump file
> http://lists.infradead.org/pipermail/kexec/2019-November/023963.html changes
> also (makedump-1.6.6). Tried to apply it on makedumpfile 1.6.7. Patch set_2
> failed. Would like to know, if you have V5 patch set for makedump file
> changes. With makedump 1.6.6, able to collect the vmore file.
> I used latest crash utility
> (https://www.redhat.com/archives/crash-utility/2019-November/msg00014.html
> changes are present)
> When I used crash utility, following is the error:
>
> Thanks,
> -Bharat
>
>
> -----Original Message-----
> From: Scott Branden [mailto:scott.branden@broadcom.com]
> Sent: Thursday, April 30, 2020 4:34 AM
> To: Bhupesh Sharma; Amit Kachhap
> Cc: Mark Rutland; x86@kernel.org; Will Deacon; Linux Doc Mailing List;
> Catalin Marinas; Ard Biesheuvel; kexec mailing list; Linux Kernel Mailing
> List; Kazuhito Hagio; James Morse; Dave Anderson; bhupesh linux;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel; Steve Capper; Ray Jui;
> Bharat Gooty
> Subject: Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ
> in vmcoreinfo
>
> Hi Bhupesh,
>
> On 2020-02-23 10:25 p.m., Bhupesh Sharma wrote:
> > Hi Amit,
> >
> > On Fri, Feb 21, 2020 at 2:36 PM Amit Kachhap <amit.kachhap@arm.com> wrote:
> >> Hi Bhupesh,
> >>
> >> On 1/13/20 5:44 PM, Bhupesh Sharma wrote:
> >>> Hi James,
> >>>
> >>> On 01/11/2020 12:30 AM, Dave Anderson wrote:
> >>>> ----- Original Message -----
> >>>>> Hi Bhupesh,
> >>>>>
> >>>>> On 25/12/2019 19:01, Bhupesh Sharma wrote:
> >>>>>> On 12/12/2019 04:02 PM, James Morse wrote:
> >>>>>>> On 29/11/2019 19:59, Bhupesh Sharma wrote:
> >>>>>>>> vabits_actual variable on arm64 indicates the actual VA space size,
> >>>>>>>> and allows a single binary to support both 48-bit and 52-bit VA
> >>>>>>>> spaces.
> >>>>>>>>
> >>>>>>>> If the ARMv8.2-LVA optional feature is present, and we are running
> >>>>>>>> with a 64KB page size; then it is possible to use 52-bits of
> >>>>>>>> address
> >>>>>>>> space for both userspace and kernel addresses. However, any kernel
> >>>>>>>> binary that supports 52-bit must also be able to fall back to
> >>>>>>>> 48-bit
> >>>>>>>> at early boot time if the hardware feature is not present.
> >>>>>>>>
> >>>>>>>> Since TCR_EL1.T1SZ indicates the size offset of the memory region
> >>>>>>>> addressed by TTBR1_EL1 (and hence can be used for determining the
> >>>>>>>> vabits_actual value) it makes more sense to export the same in
> >>>>>>>> vmcoreinfo rather than vabits_actual variable, as the name of the
> >>>>>>>> variable can change in future kernel versions, but the
> >>>>>>>> architectural
> >>>>>>>> constructs like TCR_EL1.T1SZ can be used better to indicate
> >>>>>>>> intended
> >>>>>>>> specific fields to user-space.
> >>>>>>>>
> >>>>>>>> User-space utilities like makedumpfile and crash-utility, need to
> >>>>>>>> read/write this value from/to vmcoreinfo
> >>>>>>> (write?)
> >>>>>> Yes, also write so that the vmcoreinfo from an (crashing) arm64
> >>>>>> system can
> >>>>>> be used for
> >>>>>> analysis of the root-cause of panic/crash on say an x86_64 host using
> >>>>>> utilities like
> >>>>>> crash-utility/gdb.
> >>>>> I read this as as "User-space [...] needs to write to vmcoreinfo".
> >>> That's correct. But for writing to vmcore dump in the kdump kernel, we
> >>> need to read the symbols from the vmcoreinfo in the primary kernel.
> >>>
> >>>>>>>> for determining if a virtual address lies in the linear map range.
> >>>>>>> I think this is a fragile example. The debugger shouldn't need to
> >>>>>>> know
> >>>>>>> this.
> >>>>>> Well that the current user-space utility design, so I am not sure we
> >>>>>> can
> >>>>>> tweak that too much.
> >>>>>>
> >>>>>>>> The user-space computation for determining whether an address lies
> >>>>>>>> in
> >>>>>>>> the linear map range is the same as we have in kernel-space:
> >>>>>>>>
> >>>>>>>> #define __is_lm_address(addr) (!(((u64)addr) &
> >>>>>>>> BIT(vabits_actual -
> >>>>>>>> 1)))
> >>>>>>> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA
> >>>>>>> space"). If
> >>>>>>> user-space
> >>>>>>> tools rely on 'knowing' the kernel memory layout, they must have to
> >>>>>>> constantly be fixed
> >>>>>>> and updated. This is a poor argument for adding this to something
> >>>>>>> that
> >>>>>>> ends up as ABI.
> >>>>>> See above. The user-space has to rely on some ABI/guaranteed
> >>>>>> hardware-symbols which can be
> >>>>>> used for 'determining' the kernel memory layout.
> >>>>> I disagree. Everything and anything in the kernel will change. The
> >>>>> ABI rules apply to
> >>>>> stuff exposed via syscalls and kernel filesystems. It does not apply
> >>>>> to kernel internals,
> >>>>> like the memory layout we used yesterday. 14c127c957c1 is a case in
> >>>>> point.
> >>>>>
> >>>>> A debugger trying to rely on this sort of thing would have to play
> >>>>> catchup whenever it
> >>>>> changes.
> >>>> Exactly. That's the whole point.
> >>>>
> >>>> The crash utility and makedumpfile are not in the same league as other
> >>>> user-space tools.
> >>>> They have always had to "play catchup" precisely because they depend
> >>>> upon kernel internals,
> >>>> which constantly change.
> >>> I agree with you and DaveA here. Software user-space debuggers are
> >>> dependent on kernel internals (which can change from time-to-time) and
> >>> will have to play catch-up (which has been the case since the very
> >>> start).
> >>>
> >>> Unfortunately we don't have any clear ABI for software debugging tools -
> >>> may be something to look for in future.
> >>>
> >>> A case in point is gdb/kgdb, which still needs to run with KASLR
> >>> turned-off (nokaslr) for debugging, as it confuses gdb which resolve
> >>> kernel symbol address from symbol table of vmlinux. But we can
> >>> work-around the same in makedumpfile/crash by reading the 'kaslr_offset'
> >>> value. And I have several users telling me now they cannot use gdb on
> >>> KASLR enabled kernel to debug panics, but can makedumpfile + crash
> >>> combination to achieve the same.
> >>>
> >>> So, we should be looking to fix these utilities which are broken since
> >>> the 52-bit changes for arm64. Accordingly, I will try to send the v6
> >>> soon while incorporating the comments posted on the v5.
> >> Any update on the next v6 version. Since this patch series is fixing the
> >> current broken kdump so need this series to add some more fields in
> >> vmcoreinfo for Pointer Authentication work.
> > Sorry for the delay. I was caught up in some other urgent arm64
> > user-space issues.
> > I am preparing the v6 now and hopefully will be able to post it out
> > for review later today.
>
> Did v6 get sent out?
Like I mentioned in a different thread reply, I did not put out the
user-space changes just yet, since we are waiting for the kernel
patches to be accepted first.
In the last review cycle (v5) we had inconsistencies between the
user-space and kernel as user-space utilities like crash accepted the
v5 patches while we had to respin the v6 for the kernel side.
But since a few other Red Hat arm partners have asked for the same,
please find below my public github trees (with prescribed branches),
which you can use for testing the v6 kernel patchset:
1. makedumpfile:
<https://github.com/bhupesh-sharma/makedumpfile/tree/52-bit-va-support-via-vmcore-upstream-v6-rebase>
2. crash-utility:
<https://github.com/bhupesh-sharma/crash/tree/52-bit-va-support-via-vmcore-upstream-v6-rebase>
Hope this helps.
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
From: Andrew Morton @ 2020-06-16 19:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Christophe Leroy, linux-kernel, Mike Rapoport, linux-mm,
linuxppc-dev
In-Reply-To: <20200615092229.23142-1-rppt@kernel.org>
On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport <rppt@kernel.org> wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> level to access a PMD entry. Since 8xx has only 2-level page table this can
> be simplified with pmd_off() shortcut.
>
> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
> and pgd_offset() that are no longer needed.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> I think it's powerpc material, but I won't mind if Andrew picks it up :)
Via the powerpc tree would be better, please.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 19:43 UTC (permalink / raw)
To: Joe Perches, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On 6/16/20 2:53 PM, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>> v4:
>> - Break out the memzero_explicit() change as suggested by Dan Carpenter
>> so that it can be backported to stable.
>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
>> now as there can be a bit more discussion on what is best. It will be
>> introduced as a separate patch later on after this one is merged.
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I am not sure about that, but both of them can be slow.
>
> Many patches have been posted recently to fix mispairings
> of specific types of alloc and free functions.
>
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
>
> Something like the below:
>
> void kfree(const void *addr)
> {
> if (is_kernel_rodata((unsigned long)addr))
> return;
>
> if (is_vmalloc_addr(addr))
> _vfree(addr);
> else
> _kfree(addr);
> }
>
is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the
overhead can be a bit bigger.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Jason A. Donenfeld @ 2020-06-16 19:46 UTC (permalink / raw)
To: Joe Perches
Cc: Michal Hocko, linux-btrfs, Jarkko Sakkinen, David Sterba,
David Howells, Linux-MM, linux-sctp, keyrings, kasan-dev,
linux-stm32, devel, linux-cifs, linux-scsi, James Morris,
Matthew Wilcox, linux-wpan, David Rientjes, Waiman Long,
Dan Carpenter, Serge E. Hallyn, Steffen Klassert, linux-pm,
ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, LKML, David Miller, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
Linux Crypto Mailing List, Johannes Weiner, Andrew Morton,
linuxppc-dev, Netdev, WireGuard mailing list, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches <joe@perches.com> wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
The networking stack has various places where there will be a quick
kmalloc followed by a kfree for an incoming or outgoing packet. One
place that comes to mind would be esp_alloc_tmp, which does a quick
allocation of some temporary kmalloc memory, processes some packet
things inside of that, and then frees it, sometimes in the same
function, and sometimes later in an async callback. I don't know how
"fastpath" you consider this, but usually packet processing is
something people want to do with minimal overhead, considering how
fast NICs are these days.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 20:01 UTC (permalink / raw)
To: Joe Perches, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On 6/16/20 2:53 PM, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>> v4:
>> - Break out the memzero_explicit() change as suggested by Dan Carpenter
>> so that it can be backported to stable.
>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
>> now as there can be a bit more discussion on what is best. It will be
>> introduced as a separate patch later on after this one is merged.
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
>
> Many patches have been posted recently to fix mispairings
> of specific types of alloc and free functions.
>
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
>
> Something like the below:
>
> void kfree(const void *addr)
> {
> if (is_kernel_rodata((unsigned long)addr))
> return;
>
> if (is_vmalloc_addr(addr))
> _vfree(addr);
> else
> _kfree(addr);
> }
>
> #define kvfree kfree
> #define vfree kfree
> #define kfree_const kfree
>
>
How about adding CONFIG_DEBUG_VM code to check for invalid address
ranges in kfree() and vfree()? By doing this, we can catch unmatched
pairing in debug mode, but won't have the overhead when debug mode is off.
Thought?
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: James Bottomley @ 2020-06-16 15:34 UTC (permalink / raw)
To: Johannes Thumshirn, Bart Van Assche, Finn Thain, Chris Boot
Cc: Martin K . Petersen, linux-scsi@vger.kernel.org, Chuhong Yuan,
linux-kernel@vger.kernel.org, Nicholas Bellinger,
target-devel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Stefan Richter
In-Reply-To: <SN4PR0401MB35982D889857E3C03E96E49D9B9D0@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > >
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> > >
> > > AFAICT both comments are quite ambiguous. I don't see an
> > > actionable request, just an expression of interest from people
> > > doing their jobs.
> > >
> > > Note well: there is no pay check associated with having a
> > > MAINTAINERS file
> > > entry.
> >
> > Hi Finn,
> >
> > As far as I know the sbp driver only has had one user ever and that
> > user is no longer user the sbp driver. So why to keep it in the
> > kernel tree? Restoring a kernel driver can be easy - the first step
> > is a "git revert".
>
> Why not move the driver to drivers/staging for 2 or 3 kernel releases
> and if noone steps up, delete it?
Because that's pretty much the worst of all worlds: If the driver is
simply going orphaned it can stay where it is to avoid confusion. If
it's being removed, it's better to remove it from where it is because
that makes the patch to restore it easy to find.
Chris, the thing is this: if this driver has just one user on a stable
distro who complains about its removal six months to two years from
now, Linus will descend on us from a great height (which won't matter
to you, since you'll be long gone). This makes everyone very wary of
outright removal. If you're really, really sure it has no users, it
can be deleted, but if there's the slightest chance it has just one, it
should get orphaned.
James
^ permalink raw reply
* Re: [PATCH] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes
From: Jarkko Sakkinen @ 2020-06-16 21:08 UTC (permalink / raw)
To: David Gibson
Cc: Nayna Jain, linux-kernel, Jason Gunthorpe, Paul Mackerras,
Peter Huewe, linuxppc-dev, linux-integrity, Stefan Berger
In-Reply-To: <20200605063719.456277-1-david@gibson.dropbear.id.au>
On Fri, Jun 05, 2020 at 04:37:19PM +1000, David Gibson wrote:
> The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
> which will need the use of the internal command/response buffer. But,
> we're issuing this *before* we've waited to make sure that buffer is
> allocated.
>
> This can result in intermittent failures to probe if the hypervisor / TPM
> implementation doesn't respond quickly enough. I find it fails almost
> every time with an 8 vcpu guest under KVM with software emulated TPM.
>
> Fixes: 18b3670d79ae9 "tpm: ibmvtpm: Add support for TPM2"
Should be Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2")
Also briefly state what the commit does, not just the problem
description. The code change looks legit.
Please send v2 with these changes.
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> drivers/char/tpm/tpm_ibmvtpm.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 09fe45246b8c..994385bf37c0 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> if (rc)
> goto init_irq_cleanup;
>
> - if (!strcmp(id->compat, "IBM,vtpm20")) {
> - chip->flags |= TPM_CHIP_FLAG_TPM2;
> - rc = tpm2_get_cc_attrs_tbl(chip);
> - if (rc)
> - goto init_irq_cleanup;
> - }
> -
> if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
> ibmvtpm->rtce_buf != NULL,
> HZ)) {
> @@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> goto init_irq_cleanup;
> }
>
> + if (!strcmp(id->compat, "IBM,vtpm20")) {
> + chip->flags |= TPM_CHIP_FLAG_TPM2;
> + rc = tpm2_get_cc_attrs_tbl(chip);
> + if (rc)
> + goto init_irq_cleanup;
> + }
> +
> return tpm_chip_register(chip);
> init_irq_cleanup:
> do {
> --
> 2.26.2
>
/Jarkko
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-16 21:14 UTC (permalink / raw)
To: Joe Perches
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, Jarkko Sakkinen,
David Sterba, David Howells, linux-mm, linux-sctp, keyrings,
linux-stm32, devel, linux-cifs, linux-scsi, James Morris,
kasan-dev, linux-wpan, David Rientjes, Waiman Long, Dan Carpenter,
Serge E. Hallyn, linux-pm, ecryptfs, linux-fscrypt,
linux-mediatek, linux-amlogic, virtualization, linux-integrity,
linux-nfs, Linus Torvalds, linux-wireless, linux-kernel,
linux-bluetooth, linux-security-module, target-devel,
tipc-discussion, linux-crypto, Johannes Weiner, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I worked on adding a 'free' a couple of years ago. That was capable
of freeing percpu, vmalloc, kmalloc and alloc_pages memory. I ran into
trouble when I tried to free kmem_cache_alloc memory -- it works for slab
and slub, but not slob (because slob needs the size from the kmem_cache).
My motivation for this was to change kfree_rcu() to just free_rcu().
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
I would say to leave kfree() alone and just introduce free() as a new
default. There's some weird places in the kernel that have a 'free'
symbol of their own, but those should be renamed anyway.
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS c3405d517d606e965030026daec198d314f20195
From: kernel test robot @ 2020-06-16 22:37 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: c3405d517d606e965030026daec198d314f20195 Automatic merge of 'master', 'next' and 'fixes' (2020-06-17 00:21)
elapsed time: 490m
configs tested: 108
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm pxa_defconfig
um x86_64_defconfig
mips pic32mzda_defconfig
arm versatile_defconfig
ia64 gensparse_defconfig
mips ip28_defconfig
mips ip27_defconfig
c6x evmc6678_defconfig
arm netwinder_defconfig
sh se7721_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64 randconfig-a015-20200615
x86_64 randconfig-a011-20200615
x86_64 randconfig-a016-20200615
x86_64 randconfig-a012-20200615
x86_64 randconfig-a014-20200615
x86_64 randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
---
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 b2f7aff54d10f344bc8424ab98d29e028486ba26
From: kernel test robot @ 2020-06-16 22:37 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: b2f7aff54d10f344bc8424ab98d29e028486ba26 powerpc/ptdump: Fix build failure in hashpagetable.c
elapsed time: 489m
configs tested: 98
configs skipped: 105
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sh secureedge5410_defconfig
mips capcella_defconfig
sparc64 alldefconfig
arm s3c2410_defconfig
arc axs103_defconfig
powerpc pasemi_defconfig
mips bigsur_defconfig
arm cns3420vb_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64 randconfig-a015-20200615
x86_64 randconfig-a011-20200615
x86_64 randconfig-a016-20200615
x86_64 randconfig-a012-20200615
x86_64 randconfig-a014-20200615
x86_64 randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 0bdcfa182506526fbe4e088ff9ca86a31b81828d
From: kernel test robot @ 2020-06-16 22:37 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: 0bdcfa182506526fbe4e088ff9ca86a31b81828d powerpc/64s: Fix KVM interrupt using wrong save area
elapsed time: 491m
configs tested: 87
configs skipped: 104
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm axm55xx_defconfig
mips bigsur_defconfig
mips bmips_stb_defconfig
sh migor_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: David Sterba @ 2020-06-16 23:01 UTC (permalink / raw)
To: Joe Perches
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, Jarkko Sakkinen,
David Sterba, David Howells, linux-mm, linux-sctp, keyrings,
kasan-dev, linux-stm32, devel, linux-cifs, linux-scsi,
James Morris, Matthew Wilcox, linux-wpan, David Rientjes,
Waiman Long, Dan Carpenter, Serge E. Hallyn, linux-pm, ecryptfs,
linux-fscrypt, linux-mediatek, linux-amlogic, virtualization,
linux-integrity, linux-nfs, linuxppc-dev, linux-wireless,
linux-kernel, linux-bluetooth, linux-security-module,
target-devel, tipc-discussion, linux-crypto, Johannes Weiner,
Andrew Morton, Linus Torvalds, netdev, wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I'd consider kfree performance critical for cases where it is called
under locks. If possible the kfree is moved outside of the critical
section, but we have rbtrees or lists that get deleted under locks and
restructuring the code to do eg. splice and free it outside of the lock
is not always possible.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
From: Michael Ellerman @ 2020-06-16 23:21 UTC (permalink / raw)
To: Andrew Morton, Mike Rapoport
Cc: Christophe Leroy, linux-mm, linuxppc-dev, linux-kernel,
Mike Rapoport
In-Reply-To: <20200616124304.bbe36933fcd48c5f467f4be9@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport <rppt@kernel.org> wrote:
>
>> From: Mike Rapoport <rppt@linux.ibm.com>
>>
>> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
>> level to access a PMD entry. Since 8xx has only 2-level page table this can
>> be simplified with pmd_off() shortcut.
>>
>> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
>> and pgd_offset() that are no longer needed.
>>
>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>> ---
>>
>> I think it's powerpc material, but I won't mind if Andrew picks it up :)
>
> Via the powerpc tree would be better, please.
I'll take it into next for v5.9, unless there's a reason it needs to go
into v5.8.
cheers
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Fenghua Yu @ 2020-06-16 23:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dave Hansen, H Peter Anvin, Dave Jiang, Ashok Raj, Joerg Roedel,
x86, amd-gfx, Ingo Molnar, Ravi V Shankar, Yu-cheng Yu,
Andrew Donnellan, Borislav Petkov, Sohil Mehta, Thomas Gleixner,
Tony Luck, linuxppc-dev, Felix Kuehling, linux-kernel, iommu,
Jacob Jun Pan, Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <20200615190928.GJ2531@hirez.programming.kicks-ass.net>
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like the below. It
> takes a bit from the 'strictly current' flags word.
>
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index b62e6aaf28f0..fca830b97055 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -801,6 +801,9 @@ struct task_struct {
> /* Stalled due to lack of memory */
> unsigned in_memstall:1;
> #endif
> +#ifdef CONFIG_PCI_PASID
> + unsigned has_valid_pasid:1;
> +#endif
>
> unsigned long atomic_flags; /* Flags requiring atomic access. */
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 142b23645d82..10b3891be99e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -955,6 +955,10 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
> tsk->use_memdelay = 0;
> #endif
>
> +#ifdef CONFIG_PCI_PASID
> + tsk->has_valid_pasid = 0;
> +#endif
> +
> #ifdef CONFIG_MEMCG
> tsk->active_memcg = NULL;
> #endif
Can I add "Signed-off-by: Peter Zijlstra <peterz@infradead.org>"
to this patch? I will send this patch in the next version of the series.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
From: Nicolin Chen @ 2020-06-16 23:28 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, robh+dt, perex, broonie, festevam, linux-kernel
In-Reply-To: <1592289761-29118-2-git-send-email-shengjiu.wang@nxp.com>
On Tue, Jun 16, 2020 at 02:42:41PM +0800, Shengjiu Wang wrote:
> The one difference on imx6sx platform is that the root clock
> is shared with ASRC module, so we add a new flags "ind_root_clk"
> which means the root clock is independent, then we will not
> do the clk_set_rate and clk_round_rate to avoid impact ASRC
> module usage.
>
> As add a new flags, we include the soc specific data struct.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl_spdif.c | 43 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> index 1b2e516f9162..00e06803d32f 100644
> --- a/sound/soc/fsl/fsl_spdif.c
> +++ b/sound/soc/fsl/fsl_spdif.c
> @@ -42,6 +42,17 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 0xa, 0xb };
>
> #define DEFAULT_RXCLK_SRC 1
>
> +/**
> + * struct fsl_spdif_soc_data: soc specific data
> + *
> + * @imx: for imx platform
> + * @ind_root_clk: flag for round clk rate
> + */
> +struct fsl_spdif_soc_data {
> + bool imx;
> + bool ind_root_clk;
"ind" doesn't look very straightforward; maybe "shared_root_clock"?
And for its comments:
* @shared_root_clock: flag of sharing a clock source with others;
* so the driver shouldn't set root clock rate
> +};
> +
> /*
> * SPDIF control structure
> * Defines channel status, subcode and Q sub
> @@ -93,6 +104,7 @@ struct fsl_spdif_priv {
> struct snd_soc_dai_driver cpu_dai_drv;
> struct platform_device *pdev;
> struct regmap *regmap;
> + const struct fsl_spdif_soc_data *soc;
Looks better if we move it to the top of the list :)
> @@ -421,7 +448,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream *substream,
> sysclk_df = spdif_priv->sysclk_df[rate];
>
> /* Don't mess up the clocks from other modules */
> - if (clk != STC_TXCLK_SPDIF_ROOT)
> + if (clk != STC_TXCLK_SPDIF_ROOT || !spdif_priv->soc->ind_root_clk)
> goto clk_set_bypass;
>
> /* The S/PDIF block needs a clock of 64 * fs * txclk_df */
> @@ -1186,7 +1213,8 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv,
> continue;
>
> ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
> - i == STC_TXCLK_SPDIF_ROOT);
> + i == STC_TXCLK_SPDIF_ROOT &&
> + spdif_priv->soc->ind_root_clk);
Having more than one place that checks the condition, we can add:
/* Check if clk is a root clock that does not share clock source with others */
static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif, int clk)
{
return (clk == STC_TXCLK_SPDIF_ROOT) && !spdif->soc->shared_root_clock;
}
^ permalink raw reply
* Re: [PATCH kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
From: Michael Ellerman @ 2020-06-16 23:37 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy
In-Reply-To: <20200616104231.27805-1-aik@ozlabs.ru>
Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
> possible that not entire table is allocated if it is huge and multilevel
> so xchg may also allocate subtables. If failed, it returns H_HARDWARE
> for failed allocation and H_TOO_HARD if it needs it but cannot do because
> the alloc parameter is "false" (set when called with MMU=off to force
> retry with MMU=on).
>
> The problem is that having separate errors only matters in real mode
> (MMU=off) but the only caller with alloc="false" does not check the exact
> error code and simply returns H_TOO_HARD; and for every other mode
> alloc is "true". Also, the function is also called from the ioctl()
> handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
> hypervisor error codes (H_xxx) and will expose them to the userspace.
>
> This converts wrong error codes to a simple -1.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I could make it "return alloc ? -ENOMEM : -EBUSY" but
> is EBUSY a good match for H_TOO_HARD?
I think -EAGAIN would be the best match.
But it would be simpler if it just returned -ENOMEM always. In both
cases the problem is that the function needs to allocate memory but
couldn't.
If a caller passes alloc=false, it knows that, so if it sees ENOMEM it
can retry with alloc=true.
cheers
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 0:37 UTC (permalink / raw)
To: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200616230130.GJ27795@twin.jikos.cz>
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can be backported to stable.
> > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > > now as there can be a bit more discussion on what is best. It will be
> > > introduced as a separate patch later on after this one is merged.
> >
> > To this larger audience and last week without reply:
> > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
> >
> > Are there _any_ fastpath uses of kfree or vfree?
>
> I'd consider kfree performance critical for cases where it is called
> under locks. If possible the kfree is moved outside of the critical
> section, but we have rbtrees or lists that get deleted under locks and
> restructuring the code to do eg. splice and free it outside of the lock
> is not always possible.
Not just performance critical, but correctness critical. Since kvfree()
may allocate from the vmalloc allocator, I really think that kvfree()
should assert that it's !in_atomic(). Otherwise we can get into trouble
if we end up calling vfree() and have to take the mutex.
^ permalink raw reply
* Re: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset
From: Oliver O'Halloran @ 2020-06-17 0:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Brian King, Wen Xiong, linuxppc-dev, wenxiong
In-Reply-To: <87r1ufdy1x.fsf@mpe.ellerman.id.au>
On Tue, Jun 16, 2020 at 9:55 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> wenxiong@linux.vnet.ibm.com writes:
> > From: Wen Xiong <wenxiong@linux.vnet.ibm.com>
> >
> > Several device drivers hit EEH(Extended Error handling) when triggering
> > kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> > in pci general code when triggering kdump.
>
> Actually it's in pseries specific PCI code, and the reset is done in the
> 2nd kernel as it boots, not when triggering the kdump.
>
> You're doing it as a:
>
> machine_postcore_initcall(pseries, pseries_phb_reset);
>
> But we do the EEH initialisation in:
>
> core_initcall_sync(eeh_init);
>
> Which happens first.
>
> So it seems to me that this should be called from pseries_eeh_init().
This happens to use some of the same RTAS calls as EEH, but it's
entirely orthogonal to it. Wedging the two together doesn't make any
real sense IMO since this should be usable even with !CONFIG_EEH.
> That would isolate the code in the right place, and allow you to use the
> existing ibm_get_config_addr_info.
>
> You probably can't use pseries_eeh_get_pe_addr(), because you won't have
> a "pe" structure yet.
>
> Instead you should add a helper that does the core of that logic but
> accepts config_addr/buid as parameters, and then have your code and
> pseries_eeh_get_pe_addr() call that.
I have a patch in my next pile of eeh reworks which kills off
pseries_eeh_get_pe_addr() entirely. It's used to implement
eeh_ops->get_pe_addr for pseries, but the only caller of
->get_pe_addr() is in pseries EEH code and the powernv version is a
stub so I was going to drop it from EEH ops and fold it into the
caller. We could do that in this patch, but it's just going to create
a merge conflict for you to deal with. Up to you.
> *snip*
> > + list_for_each_entry(phb, &hose_list, list_node) {
> > + config_addr = pseries_get_pdn_addr(phb);
> > + if (config_addr == -1)
> > + continue;
> > +
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_FUNDAMENTAL);
> > +
> > + /* If fundamental-reset not supported, try hot-reset */
> > + if (ret == -8)
>
> Where does -8 come from?
There's a comment right there.
It could be better explained I suppose, but you need to read
PAPR/LoPAPR to make sense of anything RTAS so what's it really buying
you?
> Oh I see, it's copied from pseries_eeh_reset().
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_HOT);
> > +
> > + if (ret) {
> > + pr_err("%s: PHB#%x-PE# failed with rtas_call activate reset=%d\n",
> ^
> again missing PE number.
>
> > + __func__, phb->global_number, ret);
> > + continue;
> > + }
> > + }
> > + msleep(EEH_PE_RST_SETTLE_TIME);
>
> So that loop is basically a copy of pseries_eeh_reset() but with the
> sleep hoisted out of the loop.
>
> I'd really prefer to see that refactored into a helper that takes the
> config_addr and buid and doesn't do the sleep.
>
> Then this loop could call that helper, and so could pseries_eeh_reset().
That's better so long as we're not requiring CONFIG_EEH being
selected. pseries_eeh_reset() uses the rtas token variables
initialised in pseries_eeh_init() which are static to the file so
they'd need to be initialised somewhere common.
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support
From: Nicolin Chen @ 2020-06-17 0:48 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, robh+dt, perex, broonie, festevam, linux-kernel
In-Reply-To: <1592292637-25734-2-git-send-email-shengjiu.wang@nxp.com>
On Tue, Jun 16, 2020 at 03:30:37PM +0800, Shengjiu Wang wrote:
> The MQS codec isn't an i2c device, so add a new platform device for it.
>
> MQS only support playback, so add a new audio map.
>
> Add there maybe "model" property or no "audio-routing" property insertions
"Add" => "And"
> devicetree, so add some enhancement for these two property.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl-asoc-card.c | 70 ++++++++++++++++++++++++++---------
> 1 file changed, 52 insertions(+), 18 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 00be73900888..2ac8cb9ddd10 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c
> @@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> {
> struct device_node *cpu_np, *codec_np, *asrc_np;
> struct device_node *np = pdev->dev.of_node;
> + struct platform_device *codec_pdev = NULL; /* used for non i2c device*/
Having both codec_pdev and codec_dev duplicates things. Actually
only a couple of places really need "codec_dev" -- most of them
need codec_dev->dev pointer instead. So we could have a cleanup:
- struct i2c_client *codec_dev;
+ struct device *codec_dev = NULL;
> @@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> }
>
> codec_np = of_parse_phandle(np, "audio-codec", 0);
> - if (codec_np)
> + if (codec_np) {
> codec_dev = of_find_i2c_device_by_node(codec_np);
> - else
> + if (!codec_dev)
> + codec_pdev = of_find_device_by_node(codec_np);
> + } else {
> codec_dev = NULL;
> + }
Here can have something like (feel free to simplify):
if (codec_np) {
struct platform_device *codec_pdev;
struct i2c_client *codec_i2c;
codec_i2c = of_find_i2c_device_by_node(codec_np);
if (codec_i2c)
codec_dev = &codec_i2c->dev;
if (!codec_dev) {
codec_pdev = of_find_device_by_node(codec_np);
codec_dev = &codec_pdev->dev;
}
}
> asrc_np = of_parse_phandle(np, "audio-asrc", 0);
> if (asrc_np)
> @@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> if (codec_dev) {
> struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
Then here:
- struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
+ struct clk *codec_clk = clk_get(codec_dev, NULL);
> @@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> /* Assign a default DAI format, and allow each card to overwrite it */
> priv->dai_fmt = DAI_FMT_BASE;
>
> + memcpy(priv->dai_link, fsl_asoc_card_dai,
> + sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
> @@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> codec_dai_name = "ac97-hifi";
> priv->card.set_bias_level = NULL;
> priv->dai_fmt = SND_SOC_DAIFMT_AC97;
> + priv->card.dapm_routes = audio_map_ac97;
> + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
> + } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
> + codec_dai_name = "fsl-mqs-dai";
> + priv->card.set_bias_level = NULL;
> + priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
> + SND_SOC_DAIFMT_CBS_CFS |
> + SND_SOC_DAIFMT_NB_NF;
> + priv->dai_link[1].dpcm_playback = 1;
> + priv->dai_link[2].dpcm_playback = 1;
dpcm_playback = 1? That's the default value in fsl_asoc_card_dai.
> @@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
> }
>
> - snprintf(priv->name, sizeof(priv->name), "%s-audio",
> - fsl_asoc_card_is_ac97(priv) ? "ac97" :
> - codec_dev->name);
> -
> /* Initialize sound card */
> priv->pdev = pdev;
> priv->card.dev = &pdev->dev;
> - priv->card.name = priv->name;
> + ret = snd_soc_of_parse_card_name(&priv->card, "model");
> + if (ret) {
> + snprintf(priv->name, sizeof(priv->name), "%s-audio",
> + fsl_asoc_card_is_ac97(priv) ? "ac97" :
> + (codec_dev ? codec_dev->name : codec_pdev->name));
We can just use dev_name() if codec_dev is struct device *
Or having a codec_dev_name to cache codec_pdev/i2c->name.
> - ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> - if (ret) {
> - dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> - goto asrc_fail;
> + if (of_property_read_bool(np, "audio-routing")) {
> + ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> + if (ret) {
> + dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> + goto asrc_fail;
Hmm...audio-routing is a required property in DT binding doc.
So you might need to update that too.
^ permalink raw reply
* [PATCH kernel v2] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
From: Alexey Kardashevskiy @ 2020-06-17 0:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy
The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
possible that not entire table is allocated if it is huge and multilevel
so xchg may also allocate subtables. If failed, it returns H_HARDWARE
for failed allocation and H_TOO_HARD if it needs it but cannot do because
the alloc parameter is "false" (set when called with MMU=off to force
retry with MMU=on).
The problem is that having separate errors only matters in real mode
(MMU=off) but the only caller with alloc="false" does not check the exact
error code and simply returns H_TOO_HARD; and for every other mode
alloc is "true". Also, the function is also called from the ioctl()
handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
hypervisor error codes (H_xxx) and will expose them to the userspace.
This converts wrong error codes to -ENOMEM.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* return -ENOMEM vs. -1
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index f923359d8afc..5218f5da2737 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -166,7 +166,7 @@ int pnv_tce_xchg(struct iommu_table *tbl, long index,
if (!ptce) {
ptce = pnv_tce(tbl, false, idx, alloc);
if (!ptce)
- return alloc ? H_HARDWARE : H_TOO_HARD;
+ return -ENOMEM;
}
if (newtce & TCE_PCI_WRITE)
--
2.17.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