Re: [PATCH v3] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Nicolin Chen
On Tue, Jun 16, 2020 at 10:53:48AM +0800, Shengjiu Wang wrote: > For mono channel, SSI will switch to Normal mode. > > In Normal mode and Network mode, the Word Length Control bits > control the word length divider in clock generator, which is > different with I2S Master mode (the word length is

[PATCH v3] All arch: remove system call sys_sysctl

2020-06-15 Thread Xiaoming Ni
uot; changes in v3: restore include/uapi/linux/sysctl.h rebase on commit bc7d17d55762 ("Add linux-next specific files for 20200615") Conflicts: arch/sh/include/uapi/asm/unistd_64.h arch/sh/kernel/syscalls_64.S v2: According to Kees Cook's suggestion, completely remove sys_

Re: [PATCH 2/2] cpufreq: Specify default governor on command line

2020-06-15 Thread Viresh Kumar
On 15-06-20, 17:55, Quentin Perret wrote: > +static void cpufreq_get_default_governor(void) > +{ > + default_governor = cpufreq_parse_governor(cpufreq_param_governor); > + if (!default_governor) { > + if (*cpufreq_param_governor) > + pr_warn("Failed to find

Re: [PATCH 1/2] cpufreq: Register governors at core_initcall

2020-06-15 Thread Viresh Kumar
On 15-06-20, 17:55, Quentin Perret wrote: > Currently, most CPUFreq governors are registered at core_initcall time > when used as default, and module_init otherwise. In preparation for > letting users specify the default governor on the kernel command line, > change all of them to use

Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/

2020-06-15 Thread Martin K. Petersen
On Tue, 9 Jun 2020 13:45:53 +0100, Kieran Bingham wrote: > I wouldn't normally go through spelling fixes, but I caught sight of > this typo twice, and then foolishly grepped the tree for it, and saw how > pervasive it was. > > so here I am ... fixing a typo globally... but with an addition in >

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-15 Thread Eric Biggers
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() is currently used for the buffer clearing. However, > it is entirely

Re: [PATCH] kbuild: reuse vmlinux.o in vmlinux_link

2020-06-15 Thread Masahiro Yamada
On Tue, Jun 16, 2020 at 6:47 AM Sami Tolvanen wrote: > > On Sat, May 23, 2020 at 8:13 AM Masahiro Yamada wrote: > > > > Hi Nicholas, > > (+CC: Sam Ravnborg) > > > > > > On Sat, May 23, 2020 at 7:06 PM Nicholas Piggin wrote: > > > > > > Excerpts from Masahiro Yamada's message of May 23, 2020

[PATCH v3] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Shengjiu Wang
For mono channel, SSI will switch to Normal mode. In Normal mode and Network mode, the Word Length Control bits control the word length divider in clock generator, which is different with I2S Master mode (the word length is fixed to 32bit), it should be the value of params_width(hw_params). The

[PATCH 2/2] cpufreq: Specify default governor on command line

2020-06-15 Thread Quentin Perret
Currently, the only way to specify the default CPUfreq governor is via Kconfig options, which suits users who can build the kernel themselves perfectly. However, for those who use a distro-like kernel (such as Android, with the Generic Kernel Image project), the only way to use a different

Re: [PATCH v13 3/6] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-06-15 Thread Ira Weiny
On Mon, Jun 15, 2020 at 06:14:04PM +0530, Vaibhav Jain wrote: > Implement support for fetching nvdimm health information via > H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair > of 64-bit bitmap, bitwise-and of which is then stored in > 'struct papr_scm_priv' and subsequently

Re: [PATCH v2] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Shengjiu Wang
On Tue, Jun 16, 2020 at 9:59 AM Nicolin Chen wrote: > > On Tue, Jun 16, 2020 at 09:48:39AM +0800, Shengjiu Wang wrote: > > On Tue, Jun 16, 2020 at 7:11 AM Nicolin Chen wrote: > > > > > > On Mon, Jun 15, 2020 at 01:56:18PM +0800, Shengjiu Wang wrote: > > > > For mono channel, SSI will switch to

Re: [PATCH v2] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Nicolin Chen
On Tue, Jun 16, 2020 at 09:48:39AM +0800, Shengjiu Wang wrote: > On Tue, Jun 16, 2020 at 7:11 AM Nicolin Chen wrote: > > > > On Mon, Jun 15, 2020 at 01:56:18PM +0800, Shengjiu Wang wrote: > > > For mono channel, SSI will switch to Normal mode. > > > > > > In Normal mode and Network mode, the Word

[PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()

2020-06-15 Thread Waiman Long
In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc() was incorrectly paired with kzfree(). According to David Sterba, there isn't any sensitive information in the subvol_info that needs to be cleared before freeing. So kfree_sensitive() isn't really needed, use kfree()

[PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-15 Thread Waiman Long
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

[PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-15 Thread Waiman Long
The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for the buffer clearing. However, it is entirely possible that the compiler may choose to optimize away the memory clearing

[PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-15 Thread Waiman Long
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

Re: [PATCH v2] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Shengjiu Wang
On Tue, Jun 16, 2020 at 7:11 AM Nicolin Chen wrote: > > On Mon, Jun 15, 2020 at 01:56:18PM +0800, Shengjiu Wang wrote: > > For mono channel, SSI will switch to Normal mode. > > > > In Normal mode and Network mode, the Word Length Control bits > > control the word length divider in clock

Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support

2020-06-15 Thread Nathan Chancellor
On Thu, May 21, 2020 at 04:55:52PM +, Christophe Leroy wrote: > From: Michal Simek > > 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. > >

Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/

2020-06-15 Thread Mark Brown
On Tue, 9 Jun 2020 13:45:53 +0100, Kieran Bingham wrote: > I wouldn't normally go through spelling fixes, but I caught sight of > this typo twice, and then foolishly grepped the tree for it, and saw how > pervasive it was. > > so here I am ... fixing a typo globally... but with an addition in >

Re: [PATCH 0/3] ASoC: fsl_easrc: Fix several warnings

2020-06-15 Thread Mark Brown
On Wed, 3 Jun 2020 11:39:38 +0800, Shengjiu Wang wrote: > Fix several warnings with "make W=1" > > Shengjiu Wang (3): > ASoC: fsl_easrc: Fix -Wmissing-prototypes warning > ASoC: fsl_easrc: Fix -Wunused-but-set-variable > ASoC: fsl_easrc: Fix "Function parameter not described" warnings > >

Re: [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

2020-06-15 Thread Fenghua Yu
Hi, Baolu, On Sat, Jun 13, 2020 at 08:17:40PM +0800, Lu Baolu wrote: > Hi Fenghua, > > On 2020/6/13 8:41, Fenghua Yu wrote: > >+implement implement fairness or ensure forward progress can be made. > > Repeated "implement". Will fix this. > >+For example, the Intel Data Streaming Accelerator

Re: [PATCH v2] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-15 Thread Nicolin Chen
On Mon, Jun 15, 2020 at 01:56:18PM +0800, Shengjiu Wang wrote: > For mono channel, SSI will switch to Normal mode. > > In Normal mode and Network mode, the Word Length Control bits > control the word length divider in clock generator, which is > different with I2S Master mode (the word length is

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Raj, Ashok
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > I don't get why you need a rdmsr here, or why not having one would > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > > +*/ > > > > + rdmsrl(MSR_IA32_PASID, pasid_msr); > > > > +

[PATCH 17/25] mm/powerpc: Use mm_fault_accounting()

2020-06-15 Thread Peter Xu
Use the new mm_fault_accounting() helper for page fault accounting. cmo_account_page_fault() is special. Keep that. CC: Michael Ellerman CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-dev@lists.ozlabs.org Signed-off-by: Peter Xu --- arch/powerpc/mm/fault.c | 13 - 1

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 289687 --> https://bugzilla.kernel.org/attachment.cgi?id=289687=edit kernel .config (5.8-rc1, PowerMac G4 DP) -- You are receiving this mail because: You are watching

[Bug 208197] New: OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197 Bug ID: 208197 Summary: OF: /pci@f200/mac-io@17/gpio@50/...: could not find phandle Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.8-rc1

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 01:17:35PM -0700, Fenghua Yu wrote: > 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

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> So what’s the RDMSR for? Surely you > have some state somewhere that says “this task has a PASID.” > Can’t you just make sure that stays in sync with the MSR? Then, on #GP, if > the task already has a PASID, you know the MSR is set. We have state that says the process ("mm") has been

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Steven Rostedt
On Mon, 15 Jun 2020 14:55:52 +0200 Borislav Petkov wrote: > Can you please resend your patchset once a week like everyone else and > not flood inboxes with it? Boris, Haven't you automated your inbox yet? I have patchwork reading my INBOX and it's smart enough to understand new series, and the

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote: > >  >> >> Are we planning to keep PASID live once a task has used it once or are we >> going to swap it lazily? If the latter, a percpu variable might be better. > > Current plan is "touch it once and the task owns it until exit(2)" > >

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> Are we planning to keep PASID live once a task has used it once or are we > going to swap it lazily? If the latter, a percpu variable might be better. Current plan is "touch it once and the task owns it until exit(2)" Maybe someday in the future when we have data on how applications actually

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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287675|0 |1 is obsolete|

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote: > > 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

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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287673|0 |1 is obsolete|

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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287671|0 |1 is obsolete|

Re: [PATCH net v2] ibmvnic: Harden device login requests

2020-06-15 Thread David Miller
From: Thomas Falcon Date: Mon, 15 Jun 2020 10:29:23 -0500 > The VNIC driver's "login" command sequence is the final step > in the driver's initialization process with device firmware, > confirming the available device queue resources to be utilized > by the driver. Under high system load,

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
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

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Brian Gerst
On Mon, Jun 15, 2020 at 2:47 PM Arnd Bergmann wrote: > > On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst wrote: > > On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote: > > > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote: > > > > > > > I'd rather keep it in common code as that

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Dan Williams
On Mon, Jun 15, 2020 at 5:56 AM Borislav Petkov wrote: > > On Mon, Jun 15, 2020 at 06:14:03PM +0530, Vaibhav Jain wrote: > > 'seq_buf' provides a very useful abstraction for writing to a string > > buffer without needing to worry about it over-flowing. However even > > though the API has been

Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

2020-06-15 Thread Bhupesh Sharma
Hello Catalin, Will, On Tue, Jun 2, 2020 at 10:54 AM Bhupesh Sharma wrote: > > Hello, > > On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote: > > > > Apologies for the delayed update. Its been quite some time since I > > posted the last version (v5), but I have been really caught up in some

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
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

Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/

2020-06-15 Thread Jason Gunthorpe
On Tue, Jun 09, 2020 at 01:45:53PM +0100, Kieran Bingham wrote: > I wouldn't normally go through spelling fixes, but I caught sight of > this typo twice, and then foolishly grepped the tree for it, and saw how > pervasive it was. > > so here I am ... fixing a typo globally... but with an addition

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 08:31:16PM +0200, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote: > > > I don't get why you need a rdmsr here, or why not having one would > > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > My

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Arnd Bergmann
On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst wrote: > On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote: > > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote: > > > > I'd rather keep it in common code as that allows all the low-level > > exec stuff to be marked static, and

Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-15 Thread Waiman Long
On 6/15/20 2:07 PM, Dan Carpenter wrote: On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote: diff --git a/mm/slab_common.c b/mm/slab_common.c index 23c7500eea7d..c08bc7eb20bd 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1707,17 +1707,17 @@ void *krealloc(const void *p,

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote: > On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > > > > +

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote: > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > My concern is TIF flags are precious (only 3 slots available). Defining > a new TIF flag

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote: > > Hi, Peter, > > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > > > +/* > > > > + *

Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-15 Thread Dan Carpenter
On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote: > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 23c7500eea7d..c08bc7eb20bd 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1707,17 +1707,17 @@ void *krealloc(const void *p, size_t new_size, gfp_t > flags) >

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
>> The heuristic always initializes the MSR with the per mm PASID IIF the >> mm has a valid PASID but the MSR doesn't have one. This heuristic usually >> happens only once on the first #GP in a thread. > > But it doesn't guarantee the PASID is the right one. Suppose both the mm > has a PASID and

Re: [PATCH v1 4/4] KVM: PPC: Book3S HV: migrate hot plugged memory

2020-06-15 Thread Laurent Dufour
Le 31/05/2020 à 04:27, Ram Pai a écrit : From: Laurent Dufour When a memory slot is hot plugged to a SVM, GFNs associated with that memory slot automatically default to secure GFN. Hence migrate the PFNs associated with these GFNs to device-PFNs. uv_migrate_mem_slot() is called to achieve

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Christoph Hellwig
On Mon, Jun 15, 2020 at 11:33:49AM -0400, Brian Gerst wrote: > If you move those aliases above all the __SYSCALL_* defines it will > work, since that will get the forward declaration too. This would be > the simplest workaround. That compiles and also passes my exaustive x32 tests (chroot + ls

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote: > Hi, Peter, > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > > +/* > > > + * Apply some heuristics to see if the #GP fault was caused by a thread > > >

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > +/* > > + * Apply some heuristics to see if the #GP fault was caused by a thread > > + * that hasn't had the IA32_PASID MSR initialized. If it looks like

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Brian Gerst
On Mon, Jun 15, 2020 at 11:10 AM Christoph Hellwig wrote: > > On Mon, Jun 15, 2020 at 04:46:15PM +0200, Arnd Bergmann wrote: > > How about this one: > > > > diff --git a/arch/x86/entry/syscall_x32.c b/arch/x86/entry/syscall_x32.c > > index 3d8d70d3896c..0ce15807cf54 100644 > > ---

[PATCH net v2] ibmvnic: Harden device login requests

2020-06-15 Thread Thomas Falcon
The VNIC driver's "login" command sequence is the final step in the driver's initialization process with device firmware, confirming the available device queue resources to be utilized by the driver. Under high system load, firmware may not respond to the request in a timely manner or may abort

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-15 Thread Chris Boot
On 15/06/2020 00:28, Finn Thain wrote: > On Sun, 14 Jun 2020, Chris Boot wrote: > >> I expect that if someone finds this useful it can stick around (but >> that's not my call). > > Who's call is that? If the patch had said "From: Martin K. Petersen" and > "This driver is being removed because

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Christoph Hellwig
On Mon, Jun 15, 2020 at 04:46:15PM +0200, Arnd Bergmann wrote: > How about this one: > > diff --git a/arch/x86/entry/syscall_x32.c b/arch/x86/entry/syscall_x32.c > index 3d8d70d3896c..0ce15807cf54 100644 > --- a/arch/x86/entry/syscall_x32.c > +++ b/arch/x86/entry/syscall_x32.c > @@ -16,6 +16,9 @@

Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE

2020-06-15 Thread Scott Wood
On Sat, 2020-06-13 at 23:28 +0700, Arseny Solokha wrote: > Building the current 5.8 kernel for a e500 machine with > CONFIG_RANDOMIZE_BASE set yields the following failure: > > arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init': > arch/powerpc/mm/nohash/kaslr_booke.c:387:2:

Re: [PATCH v2 00/12] x86: tag application address space for devices

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 09:52:02AM +0200, Peter Zijlstra wrote: > On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote: > > > This series only provides simple and basic support for ENQCMD and the MSR: > > 1. Clean up type definitions (patch 1-3). These patches can be in a > >

Re: [PATCH net] ibmvnic: Harden device login requests

2020-06-15 Thread Thomas Falcon
On 6/12/20 4:10 PM, David Miller wrote: From: Thomas Falcon Date: Fri, 12 Jun 2020 13:31:39 -0500 @@ -841,13 +841,14 @@ static int ibmvnic_login(struct net_device *netdev) { struct ibmvnic_adapter *adapter = netdev_priv(netdev); unsigned long timeout =

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Brian Gerst
On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote: > > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote: > > > #ifdef CONFIG_COMPAT > > > - if (unlikely(argv.is_compat)) { > > > + if (in_compat_syscall()) { > > > + const compat_uptr_t __user

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Arnd Bergmann
On Mon, Jun 15, 2020 at 4:43 PM Christoph Hellwig wrote: > > On Mon, Jun 15, 2020 at 04:40:28PM +0200, Arnd Bergmann wrote: > > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1040): undefined reference to > > > `__x32_sys_execve' > > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1108): undefined

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Arnd Bergmann
On Mon, Jun 15, 2020 at 4:12 PM Christoph Hellwig wrote: > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote: > > > I don't really understand > > the comment, why can't this just use this? > > That errors out with: > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1040): undefined

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Christoph Hellwig
On Mon, Jun 15, 2020 at 04:40:28PM +0200, Arnd Bergmann wrote: > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1040): undefined reference to > > `__x32_sys_execve' > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1108): undefined reference to > > `__x32_sys_execveat' > > make: *** [Makefile:1139:

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Christoph Hellwig
On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote: > > #ifdef CONFIG_COMPAT > > - if (unlikely(argv.is_compat)) { > > + if (in_compat_syscall()) { > > + const compat_uptr_t __user *compat_argv = > > + compat_ptr((unsigned long)argv); > >

Re: [PATCH 0/8 v2] PCI: Align return values of PCIe capability and PCI accessors

2020-06-15 Thread Jason Gunthorpe
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote: > From: Bolarinwa Olayemi Saheed > > > PATCH 1/8 to 7/8: > PCIBIOS_ error codes have positive values and they are passed down the > call heirarchy from accessors. For functions which are meant to return > only a negative

Re: [PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Arnd Bergmann
On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > The only differenence betweeen the compat exec* syscalls and their > native versions is that compat_ptr sign extension, and the fact that > the pointer arithmetics for the two dimensional arrays needs to use > the compat pointer size.

Re: properly support exec and wait with kernel pointers

2020-06-15 Thread Arnd Bergmann
On Mon, Jun 15, 2020 at 3:00 PM Christoph Hellwig wrote: > > Hi all, > > this series first cleans up the exec code and then adds proper > kernel_execveat and kernel_wait callers instead of relying on the fact > that the early init code and kernel threads implicitly run with > the address limit

Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 12:57:59PM +, Christophe Leroy wrote: > READ_ONCE() now enforces atomic read, which leads to: > Fixes: 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() > memory accesses") > Cc: Will Deacon > Signed-off-by: Christophe Leroy > --- >

[PATCH] powerpc/ptdump: Fix build failure in hashpagetable.c

2020-06-15 Thread Christophe Leroy
H_SUCCESS is only defined when CONFIG_PPC_PSERIES is defined. != H_SUCCESS means != 0. Modify the test accordingly. Reported-by: kernel test robot Fixes: 65e701b2d2a8 ("powerpc/ptdump: drop non vital #ifdefs") Cc: sta...@vger.kernel.org Signed-off-by: Christophe Leroy ---

[PATCH 6/6] kernel: add a kernel_wait helper

2020-06-15 Thread Christoph Hellwig
Add a helper that waits for a pid and stores the status in the passed in kernel pointer. Use it to fix the usage of kernel_wait4 in call_usermodehelper_exec_sync that only happens to work due to the implicit set_fs(KERNEL_DS) for kernel threads. Signed-off-by: Christoph Hellwig ---

[PATCH 5/6] exec: add a kernel_execveat helper

2020-06-15 Thread Christoph Hellwig
Add a kernel_execveat helper to execute a binary with kernel space argv and envp pointers. Switch executing init and user mode helpers to this new helper instead of relying on the implicit set_fs(KERNEL_DS) for early init code and kernel threads, and move the getname call into the do_execve

[PATCH 4/6] exec: split prepare_arg_pages

2020-06-15 Thread Christoph Hellwig
Move counting the arguments and enviroment variables out of prepare_arg_pages and rename the rest of the function to check_arg_limit. This prepares for a version of do_execvat that takes kernel pointers. Signed-off-by: Christoph Hellwig --- fs/exec.c | 26 ++ 1 file

[PATCH 3/6] exec: cleanup the count() function

2020-06-15 Thread Christoph Hellwig
Remove the max argument as it is hard wired to MAX_ARG_STRINGS, and give the function a slightly less generic name. Signed-off-by: Christoph Hellwig --- fs/exec.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index

[PATCH 2/6] exec: simplify the compat syscall handling

2020-06-15 Thread Christoph Hellwig
The only differenence betweeen the compat exec* syscalls and their native versions is that compat_ptr sign extension, and the fact that the pointer arithmetics for the two dimensional arrays needs to use the compat pointer size. Instead of the compat wrappers and the struct user_arg_ptr machinery

properly support exec and wait with kernel pointers

2020-06-15 Thread Christoph Hellwig
Hi all, this series first cleans up the exec code and then adds proper kernel_execveat and kernel_wait callers instead of relying on the fact that the early init code and kernel threads implicitly run with the address limit set to KERNEL_DS. Note that the cleanup removes the compat execve(at)

[PATCH 1/6] exec: cleanup the execve wrappers

2020-06-15 Thread Christoph Hellwig
Remove a whole bunch of wrappers that eventually all call __do_execve_file, and consolidate the execvce helpers to: (1) __do_execveat, which is the lowest level helper implementing the actual functionality (2) do_execvat, which is used by all callers that want native pointers

[PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages

2020-06-15 Thread Christophe Leroy
READ_ONCE() now enforces atomic read, which leads to: CC mm/gup.o In file included from ./include/linux/kernel.h:11:0, from mm/gup.c:2: In function 'gup_hugepte.constprop', inlined from 'gup_huge_pd.isra.79' at mm/gup.c:2465:8: ./include/linux/compiler.h:392:38: error:

[PATCH 0/3] Fix build failure with v5.8-rc1

2020-06-15 Thread Christophe Leroy
Commit 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses") leads to following build failure on powerpc 8xx. To fix it, this small series introduces a new helper named ptep_get() to replace the direct access with READ_ONCE(). This new helper can be overriden by

[PATCH 1/3] mm/gup: Use huge_ptep_get() in gup_hugepte()

2020-06-15 Thread Christophe Leroy
gup_hugepte() reads hugepage table entries, it can't read them directly, huge_ptep_get() must be used. Fixes: 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses") Cc: Will Deacon Signed-off-by: Christophe Leroy --- mm/gup.c | 2 +- 1 file changed, 1

[PATCH 2/3] mm: Allow arches to provide ptep_get()

2020-06-15 Thread Christophe Leroy
Since commit 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses"), it is not possible anymore to use READ_ONCE() to access complex page table entries like the one defined for powerpc 8xx with 16k size pages. Define a ptep_get() helper that architectures can

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Borislav Petkov
On Mon, Jun 15, 2020 at 06:14:03PM +0530, Vaibhav Jain wrote: > 'seq_buf' provides a very useful abstraction for writing to a string > buffer without needing to worry about it over-flowing. However even > though the API has been stable for couple of years now its still not > exported to kernel

Re: [PATCH v12 0/6] powerpc/papr_scm: Add support for reporting nvdimm health

2020-06-15 Thread Vaibhav Jain
This accidently got reposted. Please ignore. v13 version of the patch series located at https://lore.kernel.org/linux-nvdimm/20200615124407.32596-1-vaib...@linux.ibm.com Vaibhav Jain writes: > Changes since v11 [1]: > * Minor update to 'papr_pdsm.h' fixing a misleading comment about >

Re: [PATCH v12 1/6] powerpc: Document details on H_SCM_HEALTH hcall

2020-06-15 Thread Vaibhav Jain
This accidently got reposted. Please ignore. Vaibhav Jain writes: > Add documentation to 'papr_hcalls.rst' describing the bitmap flags > that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM > specification. > > Cc: "Aneesh Kumar K . V" > Cc: Dan Williams > Cc: Michael Ellerman >

[PATCH v13 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-15 Thread Vaibhav Jain
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm module and add the command family NVDIMM_FAMILY_PAPR to the white list of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the nvdimm command mask and implement necessary scaffolding in the module to handle

[PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Vaibhav Jain
'seq_buf' provides a very useful abstraction for writing to a string buffer without needing to worry about it over-flowing. However even though the API has been stable for couple of years now its still not exported to kernel loadable modules limiting its usage. Hence this patch proposes update to

[PATCH v13 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()

2020-06-15 Thread Vaibhav Jain
Since papr_scm_ndctl() can be called from outside papr_scm, its exposed to the possibility of receiving NULL as value of 'cmd_rc' argument. This patch updates papr_scm_ndctl() to protect against such possibility by assigning it pointer to a local variable in case cmd_rc == NULL. Finally the patch

[PATCH v13 6/6] powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH

2020-06-15 Thread Vaibhav Jain
This patch implements support for PDSM request 'PAPR_PDSM_HEALTH' that returns a newly introduced 'struct nd_papr_pdsm_health' instance containing dimm health information back to user space in response to ND_CMD_CALL. This functionality is implemented in newly introduced papr_pdsm_health() that

[PATCH v13 3/6] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-06-15 Thread Vaibhav Jain
Implement support for fetching nvdimm health information via H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair of 64-bit bitmap, bitwise-and of which is then stored in 'struct papr_scm_priv' and subsequently partially exposed to user-space via newly introduced dimm specific

[PATCH v13 1/6] powerpc: Document details on H_SCM_HEALTH hcall

2020-06-15 Thread Vaibhav Jain
Add documentation to 'papr_hcalls.rst' describing the bitmap flags that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM specification. Cc: "Aneesh Kumar K . V" Cc: Dan Williams Cc: Michael Ellerman Cc: Ira Weiny Acked-by: Ira Weiny Signed-off-by: Vaibhav Jain --- Changelog:

[PATCH v13 0/6] powerpc/papr_scm: Add support for reporting nvdimm health

2020-06-15 Thread Vaibhav Jain
Changes since v12 [1]: * Fixed the clang warning regarding variable length object' being not at the end of the 'struct nd_pdsm_cmd_pkg' by introducing a new layout. * Removed instance of 'struct nd_cmd_pkg hdr' from 'struct nd_pdsm_cmd_pkg' and renamed the struct to 'struct nd_pkg_pdsm' to

Re: [PATCH v2] SUNRPC: Add missing definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE

2020-06-15 Thread Chuck Lever
> On Jun 15, 2020, at 2:25 AM, Christophe Leroy > wrote: > > Even if that's only a warning, not including asm/cacheflush.h > leads to svc_flush_bvec() being empty allthough powerpc defines > ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE. > > CC net/sunrpc/svcsock.o > net/sunrpc/svcsock.c:227:5:

[PATCH v12 6/6] powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH

2020-06-15 Thread Vaibhav Jain
This patch implements support for PDSM request 'PAPR_PDSM_HEALTH' that returns a newly introduced 'struct nd_papr_pdsm_health' instance containing dimm health information back to user space in response to ND_CMD_CALL. This functionality is implemented in newly introduced papr_pdsm_health() that

[PATCH v12 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-15 Thread Vaibhav Jain
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm module and add the command family NVDIMM_FAMILY_PAPR to the white list of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the nvdimm command mask and implement necessary scaffolding in the module to handle

[PATCH v12 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()

2020-06-15 Thread Vaibhav Jain
Since papr_scm_ndctl() can be called from outside papr_scm, its exposed to the possibility of receiving NULL as value of 'cmd_rc' argument. This patch updates papr_scm_ndctl() to protect against such possibility by assigning it pointer to a local variable in case cmd_rc == NULL. Finally the patch

[PATCH v12 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Vaibhav Jain
'seq_buf' provides a very useful abstraction for writing to a string buffer without needing to worry about it over-flowing. However even though the API has been stable for couple of years now its still not exported to kernel loadable modules limiting its usage. Hence this patch proposes update to

[PATCH v12 3/6] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-06-15 Thread Vaibhav Jain
Implement support for fetching nvdimm health information via H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair of 64-bit bitmap, bitwise-and of which is then stored in 'struct papr_scm_priv' and subsequently partially exposed to user-space via newly introduced dimm specific

[PATCH v12 1/6] powerpc: Document details on H_SCM_HEALTH hcall

2020-06-15 Thread Vaibhav Jain
Add documentation to 'papr_hcalls.rst' describing the bitmap flags that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM specification. Cc: "Aneesh Kumar K . V" Cc: Dan Williams Cc: Michael Ellerman Cc: Ira Weiny Acked-by: Ira Weiny Signed-off-by: Vaibhav Jain --- Changelog:

[PATCH v12 0/6] powerpc/papr_scm: Add support for reporting nvdimm health

2020-06-15 Thread Vaibhav Jain
Changes since v11 [1]: * Minor update to 'papr_pdsm.h' fixing a misleading comment about 'possible' padding being added by GCC which doesn't apply in case structs are marked as __packed. * Fix the order of initialization of 'struct nd_papr_pdsm_health' in papr_pdsm_health(). * Added acks

  1   2   >