Re: [PATCH] powerpc/pseries: Make vio and ibmebus initcalls pseries specific

2020-04-17 Thread Tyrel Datwyler
On 4/16/20 9:07 PM, Oliver O'Halloran wrote: > The vio and ibmebus buses are used for pseries specific paravirtualised > devices and currently they're initialised by the generic initcall types. > This is mostly fine, but it can result in some nuisance errors in dmesg > when booting on PowerNV on

Re: [RFC PATCH] powerpc/64/signal: balance return predictor stack in signal trampoline

2020-04-17 Thread Alan Modra
On Fri, Apr 17, 2020 at 07:17:47PM +1000, Nicholas Piggin wrote: > I don't know much about dwarf, gdb still seems to recognize the signal > frame and unwind properly if I break inside a signal handler. Yes, the dwarf unwind info still looks good. The commented out dwarf near the end of

Re: [PATCH] drivers: uio: new driver uio_fsl_85xx_cache_sram

2020-04-17 Thread Scott Wood
On Fri, 2020-04-17 at 10:21 -0700, Wang Wenhu wrote: > Implements a new uio driver for freescale 85xx platforms to access > the Cache-Sram form user level. It is extremely helpful for the user > space applications that require high performance memory accesses. > > Cc: Greg Kroah-Hartman > Cc:

Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread Scott Wood
On Fri, 2020-04-17 at 22:16 +0800, 王文虎 wrote: > > On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote:>> On Thu, Apr 16, 2020 > > at 11:58:29PM -0500, Scott Wood wrote: > > > > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote: > > > > > Sounds it is. And does the modification below fit well? > > > > >

Re: remove set_fs calls from the exec and coredump code v2

2020-04-17 Thread Eric W. Biederman
Christoph Hellwig writes: > Hi all, > > this series gets rid of playing with the address limit in the exec and > coredump code. Most of this was fairly trivial, the biggest changes are > those to the spufs coredump code. > > Changes since v1: > - properly spell NUL > - properly handle the

[PATCH 2/2] signal: Remove the set_fs in binfmt_elf.c:fill_siginfo_note

2020-04-17 Thread Eric W. Biederman
The code in binfmt_elf.c is differnt from the rest of the code that processes siginfo, as it sends siginfo from a kernel buffer to a file rather than from kernel memory to userspace buffers. To remove it's use of set_fs the code needs some different siginfo helpers. Add the helper

[PATCH 1/2] signal: Factor copy_siginfo_to_external32 from copy_siginfo_to_user32

2020-04-17 Thread Eric W. Biederman
To remove the use of set_fs in the coredump code there needs to be a way to convert a kernel siginfo to a userspace compat siginfo. Call that function copy_siginfo_to_compat and factor it out of copy_siginfo_to_user32. The existence of x32 complicates this code. On x32 SIGCHLD uses 64bit

Re: [PATCH 2/8] signal: clean up __copy_siginfo_to_user32

2020-04-17 Thread Eric W. Biederman
Christoph Hellwig writes: > Instead of an architecture specific calling convention in common code > just pass a flags argument with architecture specific values. This bothers me because it makes all architectures pay for the sins of x32. Further it starts burying the details of the what is

Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer

2020-04-17 Thread Arnd Bergmann
On Fri, Apr 17, 2020 at 8:13 PM Eric W. Biederman wrote: > > Christoph Hellwig writes: > > > On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote: > >> > I'd rather keep it out of this series and to > >> > an interested party. Then again x32 doesn't seem to have a whole lot > >> > of

[PATCH v3 0/4] Clean up hugetlb boot command line processing

2020-04-17 Thread Mike Kravetz
v3 - Used weak attribute method of defining arch_hugetlb_valid_size. This eliminates changes to arch specific hugetlb.h files (Peter) Updated documentation (Peter, Randy) Fixed handling of implicitly specified gigantic page preallocation in existing code and removed

[PATCH v3 4/4] hugetlbfs: clean up command line processing

2020-04-17 Thread Mike Kravetz
With all hugetlb page processing done in a single file clean up code. - Make code match desired semantics - Update documentation with semantics - Make all warnings and errors messages start with 'HugeTLB:'. - Consistently name command line parsing routines. - Check for hugepages_supported()

[PATCH v3 1/4] hugetlbfs: add arch_hugetlb_valid_size

2020-04-17 Thread Mike Kravetz
The architecture independent routine hugetlb_default_setup sets up the default huge pages size. It has no way to verify if the passed value is valid, so it accepts it and attempts to validate at a later time. This requires undocumented cooperation between the arch specific and arch independent

[PATCH v3 3/4] hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate

2020-04-17 Thread Mike Kravetz
The routine hugetlb_add_hstate prints a warning if the hstate already exists. This was originally done as part of kernel command line parsing. If 'hugepagesz=' was specified more than once, the warning pr_warn("hugepagesz= specified twice, ignoring\n"); would be printed. Some

[PATCH v3 2/4] hugetlbfs: move hugepagesz= parsing to arch independent code

2020-04-17 Thread Mike Kravetz
Now that architectures provide arch_hugetlb_valid_size(), parsing of "hugepagesz=" can be done in architecture independent code. Create a single routine to handle hugepagesz= parsing and remove all arch specific routines. We can also remove the interface hugetlb_bad_size() as this is no longer

Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer

2020-04-17 Thread Eric W. Biederman
Christoph Hellwig writes: > On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote: >> > I'd rather keep it out of this series and to >> > an interested party. Then again x32 doesn't seem to have a whole lot >> > of interested parties.. >> >> Fine with me. It's on my mental list of

Re: [PATCH] drivers: uio: new driver uio_fsl_85xx_cache_sram

2020-04-17 Thread Randy Dunlap
On 4/17/20 10:21 AM, Wang Wenhu wrote: > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index 202ee81cfc2b..f6e6ec0089c0 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -105,6 +105,14 @@ config UIO_NETX > To compile this driver as a module, choose M here; the

[PATCH] drivers: uio: new driver uio_fsl_85xx_cache_sram

2020-04-17 Thread Wang Wenhu
Implements a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. It is extremely helpful for the user space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman Cc: Christophe Leroy Cc: Scott Wood Cc: Michael Ellerman Cc:

Re: ppc64 early slub caches have zero random value

2020-04-17 Thread Vlastimil Babka
On 4/17/20 6:53 PM, Michal Suchánek wrote: > Hello, Hi, thanks for reproducing on latest upstream! > instrumenting the kernel with the following patch > > --- > mm/slub.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/slub.c b/mm/slub.c > index d6787bbe0248..d40995d5f8ff 100644 >

[PATCH v4 2/2] powerpc/uaccess: Implement unsafe_copy_to_user() as a simple loop

2020-04-17 Thread Christophe Leroy
At the time being, unsafe_copy_to_user() is based on raw_copy_to_user() which calls __copy_tofrom_user(). __copy_tofrom_user() is a big optimised function to copy big amount of data. It aligns destinations to cache line in order to use dcbz instruction. Today unsafe_copy_to_user() is called only

[PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-04-17 Thread Christophe Leroy
unsafe_put_user() is designed to take benefit of 'asm goto'. Instead of using the standard __put_user() approach and branch based on the returned error, use 'asm goto' and make the exception code branch directly to the error label. There is no code anymore in the fixup section. This change

[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-04-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #12 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288567 --> https://bugzilla.kernel.org/attachment.cgi?id=288567=edit dmesg (kernel 5.7-rc1, PowerMac G5 11,2) -- You are receiving this mail because: You are

[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-04-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #11 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288565 --> https://bugzilla.kernel.org/attachment.cgi?id=288565=edit kmemleak output (kernel 5.7-rc1, PowerMac G5 11,2) Applied Frank's patch set on top of 5.7-rc1.

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Naveen N. Rao
Qian Cai wrote: On Apr 17, 2020, at 3:01 AM, Naveen N. Rao wrote: Hi Qian, Qian Cai wrote: OK, reverted the commit, c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE”) or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this thread,

Re: [PATCH] soc: fsl: dpio: avoid stack usage warning

2020-04-17 Thread Arnd Bergmann
On Wed, Apr 8, 2020 at 10:24 PM Russell King - ARM Linux admin wrote: > On Wed, Apr 08, 2020 at 08:58:16PM +0200, Arnd Bergmann wrote: > > - int i; > > - struct qbman_eq_desc ed[32]; > > + struct qbman_eq_desc *ed = kcalloc(sizeof(struct qbman_eq_desc), 32, > > GFP_KERNEL); > > I

Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread 王文虎
>On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote:>> On Thu, Apr 16, 2020 at >11:58:29PM -0500, Scott Wood wrote: >> > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote: >> > > Sounds it is. And does the modification below fit well? >> > > --- >> > > -static const struct of_device_id

Re: [PATCH 4/8] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer

2020-04-17 Thread Christoph Hellwig
On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote: > > I'd rather keep it out of this series and to > > an interested party. Then again x32 doesn't seem to have a whole lot > > of interested parties.. > > Fine with me. It's on my mental list of things that we want to kill off >

Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs

2020-04-17 Thread Qian Cai
> On Apr 2, 2020, at 7:24 AM, Michael Ellerman wrote: > > Qian Cai writes: >> From: Peter Zijlstra >> >> In the CPU-offline process, it calls mmdrop() after idle entry and the >> subsequent call to cpuhp_report_idle_dead(). Once execution passes the >> call to rcu_report_dead(), RCU is

Re: [PATCH v6 09/10] powerpc/64s: Implement KUAP for Radix MMU

2020-04-17 Thread Christophe Leroy
Le 17/04/2020 à 12:39, Nicholas Piggin a écrit : Excerpts from Christophe Leroy's message of April 17, 2020 8:10 pm: Le 18/04/2019 à 08:51, Michael Ellerman a écrit : Kernel Userspace Access Prevention utilises a feature of the Radix MMU which disallows read and write access to userspace

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Qian Cai
> On Apr 17, 2020, at 3:01 AM, Naveen N. Rao wrote: > > Hi Qian, > > Qian Cai wrote: >> OK, reverted the commit, >> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with >> RELOCATABLE”) >> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this >>

[PATCH] powerpc/mm: Kill the task on KUAP fault

2020-04-17 Thread Christophe Leroy
If a task generates a KUAP fault, even from an acceptable user access sequence, it is not a simple EFAULT. Instead of emiting a warning, print a critical message and kill the task with SIGSEGV. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/32/kup.h | 7 +--

[PATCH] powerpc/mm: Fix CONFIG_PPC_KUAP_DEBUG on PPC32

2020-04-17 Thread Christophe Leroy
CONFIG_PPC_KUAP_DEBUG is not selectable because it depends on PPC_32 which doesn't exists. Fixing it leads to a deadlock due to a vital register getting clobbered in _switch(). Change dependency to PPC32 and use r0 instead of r4 in _switch() Fixes: e2fb9f544431 ("powerpc/32: Prepare for Kernel

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Qian Cai
> On Apr 16, 2020, at 10:46 PM, Russell Currey wrote: > > On Thu, 2020-04-16 at 22:40 -0400, Qian Cai wrote: >>> On Apr 16, 2020, at 10:27 PM, Russell Currey >>> wrote: >>> >>> Reverting the patch with the given config will have the same effect >>> as >>> STRICT_KERNEL_RWX=n. Not

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Michael Ellerman
"Naveen N. Rao" writes: > Hi Qian, > > Qian Cai wrote: >> OK, reverted the commit, >> >> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with >> RELOCATABLE”) >> >> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this >> thread, >> >>

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Michael Ellerman
Steven Rostedt writes: > On Thu, 16 Apr 2020 21:19:10 -0400 > Qian Cai wrote: > >> OK, reverted the commit, >> >> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with >> RELOCATABLE”) >> >> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this >>

Re: [PATCH v6 09/10] powerpc/64s: Implement KUAP for Radix MMU

2020-04-17 Thread Nicholas Piggin
Excerpts from Christophe Leroy's message of April 17, 2020 8:10 pm: > > > Le 18/04/2019 à 08:51, Michael Ellerman a écrit : >> Kernel Userspace Access Prevention utilises a feature of the Radix MMU >> which disallows read and write access to userspace addresses. By >> utilising this, the kernel

Re: [PATCH v6 09/10] powerpc/64s: Implement KUAP for Radix MMU

2020-04-17 Thread Christophe Leroy
Le 18/04/2019 à 08:51, Michael Ellerman a écrit : Kernel Userspace Access Prevention utilises a feature of the Radix MMU which disallows read and write access to userspace addresses. By utilising this, the kernel is prevented from accessing user data from outside of trusted paths that perform

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午5:38, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 05:33:56PM +0800, Jason Wang wrote: On 2020/4/17 下午5:01, Michael S. Tsirkin wrote: There could be some misunderstanding here. I thought it's somehow similar: a CONFIG_VHOST_MENU=y will be left in the defconfigs even if

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 05:33:56PM +0800, Jason Wang wrote: > > On 2020/4/17 下午5:01, Michael S. Tsirkin wrote: > > > There could be some misunderstanding here. I thought it's somehow > > > similar: a > > > CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is > > > not set.

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午5:01, Michael S. Tsirkin wrote: There could be some misunderstanding here. I thought it's somehow similar: a CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is not set. Thanks BTW do entries with no prompt actually appear in defconfig? Yes. I can

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午5:25, Geert Uytterhoeven wrote: Hi Michael, On Fri, Apr 17, 2020 at 10:57 AM Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote: On 2020/4/17 下午4:46, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: On

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Geert Uytterhoeven
Hi Michael, On Fri, Apr 17, 2020 at 10:57 AM Michael S. Tsirkin wrote: > On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote: > > On 2020/4/17 下午4:46, Michael S. Tsirkin wrote: > > > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: > > > > On 2020/4/17 下午4:29, Michael S.

[RFC PATCH] powerpc/64/signal: balance return predictor stack in signal trampoline

2020-04-17 Thread Nicholas Piggin
Returning from an interrupt or syscall to a signal handler currently begins execution directly at the handler's entry point, with LR set to the address of the sigreturn trampoline. When the signal handler function returns, it runs the trampoline. It looks like this: # interrupt at user

Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread Scott Wood
On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote: > On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote: > > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote: > > > Sounds it is. And does the modification below fit well? > > > --- > > > -static const struct of_device_id

[PATCH v6 9/9] Documentation/powerpc: VAS API

2020-04-17 Thread Haren Myneni
Power9 introduced Virtual Accelerator Switchboard (VAS) which allows userspace to communicate with Nest Accelerator (NX) directly. But kernel has to establish channel to NX for userspace. This document describes user space API that application can use to establish communication channel.

[PATCH v6 8/9] crypto/nx: Remove 'pid' in vas_tx_win_attr struct

2020-04-17 Thread Haren Myneni
When window is opened, pid reference is taken for user space windows. Not needed for kernel windows. So remove 'pid' in vas_tx_win_attr struct. Signed-off-by: Haren Myneni Acked-by: Herbert Xu --- arch/powerpc/include/asm/vas.h| 1 - drivers/crypto/nx/nx-common-powernv.c | 1 - 2

[PATCH v6 7/9] crypto/nx: Enable and setup GZIP compression type

2020-04-17 Thread Haren Myneni
Changes to probe GZIP device-tree nodes, open RX windows and setup GZIP compression type. No plans to provide GZIP usage in kernel right now, but this patch enables GZIP for user space usage. Signed-off-by: Haren Myneni Acked-by: Herbert Xu --- drivers/crypto/nx/nx-common-powernv.c | 46

[PATCH v6 6/9] crypto/nx: Make enable code generic to add new GZIP compression type

2020-04-17 Thread Haren Myneni
Make setup and enable code generic to support new GZIP compression type. Changed nx842 reference to nx and moved some code to new functions. Functionality is not changed except sparse warning fix - setting NULL instead of 0 for per_cpu send window in nx_delete_coprocs(). Signed-off-by: Haren

[PATCH v6 5/9] crypto/nx: Rename nx-842-powernv file name to nx-common-powernv

2020-04-17 Thread Haren Myneni
Rename nx-842-powernv.c to nx-common-powernv.c to add code for setup and enable new GZIP compression type. The actual functionality is not changed in this patch. Signed-off-by: Haren Myneni Acked-by: Herbert Xu --- drivers/crypto/nx/Makefile|2 +-

[PATCH v6 4/9] crypto/nx: Initialize coproc entry with kzalloc

2020-04-17 Thread Haren Myneni
coproc entry is initialized during NX probe on power9, but not on P8. nx842_delete_coprocs() is used for both and frees receive window if it is allocated. Getting crash for rmmod on P8 since coproc->vas.rxwin is not initialized. This patch replaces kmalloc with kzalloc in nx842_powernv_probe()

[PATCH v6 3/9] powerpc/vas: Add VAS user space API

2020-04-17 Thread Haren Myneni
On power9, userspace can send GZIP compression requests directly to NX once kernel establishes NX channel / window with VAS. This patch provides user space API which allows user space to establish channel using open VAS_TX_WIN_OPEN ioctl, mmap and close operations. Each window corresponds to

[PATCH v6 2/9] powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API

2020-04-17 Thread Haren Myneni
Define the VAS_TX_WIN_OPEN ioctl interface for NX GZIP access from user space. This interface is used to open GZIP send window and mmap region which can be used by userspace to send requests to NX directly with copy/paste instructions. Signed-off-by: Haren Myneni ---

[PATCH v6 1/9] powerpc/vas: Initialize window attributes for GZIP coprocessor type

2020-04-17 Thread Haren Myneni
Initialize send and receive window attributes for GZIP high and normal priority types. Signed-off-by: Haren Myneni --- arch/powerpc/platforms/powernv/vas-window.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/powernv/vas-window.c

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote: > > On 2020/4/17 下午4:46, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: > > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote: > > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: >

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote: > > On 2020/4/17 下午4:46, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: > > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote: > > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: >

[PATCH v6 0/9] crypto/nx: Enable GZIP engine and provide userpace API

2020-04-17 Thread Haren Myneni
Power9 processor supports Virtual Accelerator Switchboard (VAS) which allows kernel and userspace to send compression requests to Nest Accelerator (NX) directly. The NX unit comprises of 2 842 compression engines and 1 GZIP engine. Linux kernel already has 842 compression support on kernel. This

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午4:46, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: On 2020/4/17 下午4:29, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: On 2020/4/17 下午2:33, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote: > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: > > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote: > > > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote: >

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午4:29, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: On 2020/4/17 下午2:33, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote: On 2020/4/17 上午6:55, Michael S. Tsirkin wrote: On Wed, Apr 15, 2020 at

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-17 Thread Florian Weimer
* Segher Boessenkool: > On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote: >> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote: >> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote: >> > > > I think my choice would be just making the inline syscall be a

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote: > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote: > > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote: > > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote: >

Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line

2020-04-17 Thread Christoph Hellwig
On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote: > And the fact they were exported leaves possibility that there is a > driver somewhere relying on these symbols or distro kernel won't build > because the symbol disappeared from exports (I do not know what KABI > guarantees or

Re:[PATCH v5,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread 王文虎
>A driver for freescale 85xx platforms to access the Cache-Sram form>user >level. This is extremely helpful for some user-space applications >that require high performance memory accesses. > >Cc: Greg Kroah-Hartman >Cc: Christophe Leroy >Cc: Scott Wood >Cc: Michael Ellerman >Cc:

Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread Greg KH
On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote: > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote: > > > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote: > > > > > +#define UIO_INFO_VER "devicetree,pseudo" > > > > > > > > What does this mean? Changing a number into a non-obvious

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang
On 2020/4/17 下午2:33, Michael S. Tsirkin wrote: On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote: On 2020/4/17 上午6:55, Michael S. Tsirkin wrote: On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote: We try to keep the defconfig untouched after decoupling CONFIG_VHOST out of

[PATCH 4/4] powerpc/powernv/pci: Sprinkle around some WARN_ON()s

2020-04-17 Thread Oliver O'Halloran
pnv_pci_ioda_configure_bus() should now only ever be called when a device is added to the bus so add a WARN_ON() to the empty bus check. Similarly, pnv_pci_ioda_setup_bus_PE() should only ever be called for an unconfigured PE, so add a WARN_ON() for that case too. Signed-off-by: Oliver O'Halloran

[PATCH 3/4] powerpc/powernv/pci: Reserve the root bus PE during init

2020-04-17 Thread Oliver O'Halloran
Doing it once during boot rather than doing it on the fly and drop the janky populated logic. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 26 +- arch/powerpc/platforms/powernv/pci.h | 1 - 2 files changed, 9 insertions(+), 18

[PATCH 2/4] powerpc/powernv/pci: Re-work bus PE configuration

2020-04-17 Thread Oliver O'Halloran
For normal PHBs IODA PEs are handled on a per-bus basis so all the devices on that bus will share a PE. Which PE specificly is determined by the location of the MMIO BARs for the devices on the bus so we can't actually configure the bus PEs until after MMIO resources are allocated. As a result PEs

[PATCH 1/4] powerpc/powernv/pci: Add helper to find ioda_pe from BDFN

2020-04-17 Thread Oliver O'Halloran
For each PHB we maintain a reverse-map that can be used to find the PE that a BDFN is currently mapped to. Add a helper for doing this lookup so we can check if a PE has been configured without looking at pdn->pe_number. Signed-off-by: Oliver O'Halloran ---

Fix sysfs pci bus rescan on PowerNV (and other things)

2020-04-17 Thread Oliver O'Halloran
This series is based on top of my previously posted series which reworks how devices are added to their IOMMU groups. The two series are largely orthogonal to each other, but they both touch pnv_pci_ioda_dma_dev_setup() so there's a minor merge conflict if they aren't applied together. I can fix

[PATCH v5, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram

2020-04-17 Thread Wang Wenhu
Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman Cc: Christophe Leroy Cc: Scott Wood Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add

[PATCH v5, 2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram

2020-04-17 Thread Wang Wenhu
Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function

[PATCH v5, 1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr

2020-04-17 Thread Wang Wenhu
Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11:

[PATCH v5,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram

2020-04-17 Thread Wang Wenhu
This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the

[PATCH v5,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread Wang Wenhu
A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman Cc: Christophe Leroy Cc: Scott Wood Cc: Michael Ellerman Cc:

Re:Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

2020-04-17 Thread 王文虎
>> > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote: >> > > > +#define UIO_INFO_VER "devicetree,pseudo" >> > > >> > > What does this mean? Changing a number into a non-obvious string (Why >> > > "pseudo"? Why does the UIO user care that the config came from the >> > > device >> > >

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-17 Thread Naveen N. Rao
Hi Qian, Qian Cai wrote: OK, reverted the commit, c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE”) or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this thread,

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Michael S. Tsirkin
On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote: > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote: > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote: > > > We try to keep the defconfig untouched after decoupling CONFIG_VHOST > > > out of CONFIG_VIRTUALIZATION in commit