* Re: [PATCH 2/6] exec: simplify the compat syscall handling
From: Brian Gerst @ 2020-06-15 19:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Parisc List, the arch/x86 maintainers,
open list:BROADCOM NVRAM DRIVER, linux-kernel@vger.kernel.org,
Linux FS-devel Mailing List, Luis Chamberlain, Al Viro,
sparclinux, linuxppc-dev, Christoph Hellwig, Linux ARM
In-Reply-To: <CAK8P3a3q-hC7kZwLPbc+E5VYcqthQS4J4Rqo+rKkBRU2n071XA@mail.gmail.com>
On Mon, Jun 15, 2020 at 2:47 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst <brgerst@gmail.com> wrote:
> > On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig <hch@lst.de> 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 avoid us growing new pointless
> > > compat variants through copy and paste.
> > > smart compiler to d
> > >
> > > > 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 reference to
> > > `__x32_sys_execve'
> > > ld: arch/x86/entry/syscall_x32.o:(.rodata+0x1108): undefined reference to
> > > `__x32_sys_execveat'
> > > make: *** [Makefile:1139: vmlinux] Error 1
> >
> > I think I have a fix for this, by modifying the syscall wrappers to
> > add an alias for the __x32 variant to the native __x64_sys_foo().
> > I'll get back to you with a patch.
>
> Do we actually need the __x32 prefix any more, or could we just
> change all x32 specific calls to use __x64_compat_sys_foo()?
I suppose that would work too. The prefix really describes the
register mapping.
--
Brian Gerst
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Fenghua Yu @ 2020-06-15 20:17 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
The PASID MSR is x86 specific although PASID is PCIe concept and per-mm.
Checking if the MSR has valid PASID (bit31=1) is an x86 specifc work.
The flag should be cleared in cloned()/forked() and is only set and
read in fixup() in x86 #GP for heuristic. It's not used anywhere outside
of x86.
That's why we think the flag should be in x86 struct thread_info instead
of in generice struct task_struct.
Please advice.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH net v2] ibmvnic: Harden device login requests
From: David Miller @ 2020-06-15 20:18 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev, danymadden
In-Reply-To: <1592234963-9535-1-git-send-email-tlfalcon@linux.ibm.com>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
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, firmware may not respond
> to the request in a timely manner or may abort the request. In
> such cases, the driver should reattempt the login command
> sequence. In case of a device error, the number of retries
> is bounded.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
> ---
> v2: declare variables in Reverse Christmas tree format
Applied, thanks.
^ permalink raw reply
* [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
From: bugzilla-daemon @ 2020-06-15 20:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206203-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206203
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #287671|0 |1
is obsolete| |
Attachment #288565|0 |1
is obsolete| |
--- Comment #13 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 289675
--> https://bugzilla.kernel.org/attachment.cgi?id=289675&action=edit
kmemleak output (kernel 5.8-rc1, PowerMac G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
From: bugzilla-daemon @ 2020-06-15 20:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206203-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206203
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #287673|0 |1
is obsolete| |
Attachment #288567|0 |1
is obsolete| |
--- Comment #14 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 289677
--> https://bugzilla.kernel.org/attachment.cgi?id=289677&action=edit
dmesg (kernel 5.8-rc1, PowerMac G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Andy Lutomirski @ 2020-06-15 20:51 UTC (permalink / raw)
To: Fenghua Yu
Cc: Peter Zijlstra, 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: <20200615201735.GE13792@romley-ivt3.sc.intel.com>
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu <fenghua.yu@intel.com> 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 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
>
> The PASID MSR is x86 specific although PASID is PCIe concept and per-mm.
> Checking if the MSR has valid PASID (bit31=1) is an x86 specifc work.
> The flag should be cleared in cloned()/forked() and is only set and
> read in fixup() in x86 #GP for heuristic. It's not used anywhere outside
> of x86.
>
> That's why we think the flag should be in x86 struct thread_info instead
> of in generice struct task_struct.
>
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.
> Please advice.
>
> Thanks.
>
> -Fenghua
^ permalink raw reply
* [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
From: bugzilla-daemon @ 2020-06-15 20:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206203-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206203
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #287675|0 |1
is obsolete| |
--- Comment #15 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 289679
--> https://bugzilla.kernel.org/attachment.cgi?id=289679&action=edit
kernel .config (kernel 5.8-rc1, PowerMac G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Luck, Tony @ 2020-06-15 20:56 UTC (permalink / raw)
To: Andy Lutomirski, Yu, Fenghua
Cc: Peter Zijlstra, Hansen, Dave, H Peter Anvin, Jiang, Dave,
Raj, Ashok, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
Shankar, Ravi V, Yu, Yu-cheng, Andrew Donnellan, Borislav Petkov,
Mehta, Sohil, Thomas Gleixner, linuxppc-dev, Felix Kuehling,
linux-kernel, iommu@lists.linux-foundation.org, Pan, Jacob jun,
Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <C41D099B-BE2E-4D0E-A7B5-7CE587E11930@amacapital.net>
> 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 use accelerators we could look at something more complex
if usage patterns look like it would be beneficial.
-Tony
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Andy Lutomirski @ 2020-06-15 21:18 UTC (permalink / raw)
To: Luck, Tony
Cc: Shankar, Ravi V, Peter Zijlstra, Hansen, Dave, H Peter Anvin,
Jiang, Dave, Raj, Ashok, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
Yu, Fenghua, Yu, Yu-cheng, Andrew Donnellan, Borislav Petkov,
Mehta, Sohil, Thomas Gleixner, linuxppc-dev, Felix Kuehling,
linux-kernel, iommu@lists.linux-foundation.org, Pan, Jacob jun,
Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F7F66C849@ORSMSX115.amr.corp.intel.com>
> On Jun 15, 2020, at 1:56 PM, Luck, Tony <tony.luck@intel.com> 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)"
>
> Maybe someday in the future when we have data on how applications
> actually use accelerators we could look at something more complex
> if usage patterns look like it would be beneficial.
>
>
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.
^ permalink raw reply
* Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf
From: Steven Rostedt @ 2020-06-15 21:24 UTC (permalink / raw)
To: Borislav Petkov
Cc: Santosh Sivaraj, Ira Weiny, linux-nvdimm, Aneesh Kumar K . V,
Cezary Rojewski, linux-kernel, Piotr Maziarz, Christoph Hellwig,
Oliver O'Halloran, Vaibhav Jain, Dan Williams, linuxppc-dev
In-Reply-To: <20200615125552.GI14668@zn.tnic>
On Mon, 15 Jun 2020 14:55:52 +0200
Borislav Petkov <bp@alien8.de> 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 old one simply
disappears as "superseded".
Email is just the wires to our infrastructure. Get with the times man! ;-)
-- Steve
^ permalink raw reply
* RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Luck, Tony @ 2020-06-15 21:24 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Shankar, Ravi V, Peter Zijlstra, Hansen, Dave, H Peter Anvin,
Jiang, Dave, Raj, Ashok, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
Yu, Fenghua, Yu, Yu-cheng, Andrew Donnellan, Borislav Petkov,
Mehta, Sohil, Thomas Gleixner, linuxppc-dev, Felix Kuehling,
linux-kernel, iommu@lists.linux-foundation.org, Pan, Jacob jun,
Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <E39A5DE2-5615-41FF-9953-4F4C4E8499D8@amacapital.net>
> 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 allocated a PASID. But not for each task.
E.g. a process may clone a bunch of tasks, then one of them opens a device that needs
a PASID. We did internally have patches to go hunt down all those other tasks and
force a PASID onto each. But the code was big and ugly. Also maybe the wrong thing
to do if those threads didn't ever need to access the device.
PeterZ suggested that we can add a bit to the task structure for this purpose.
Fenghua is hesitant about adding an x86 only bit there.
-Tony
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Peter Zijlstra @ 2020-06-15 21:53 UTC (permalink / raw)
To: Fenghua Yu
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: <20200615201735.GE13792@romley-ivt3.sc.intel.com>
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 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
>
> The PASID MSR is x86 specific although PASID is PCIe concept and per-mm.
> Checking if the MSR has valid PASID (bit31=1) is an x86 specifc work.
> The flag should be cleared in cloned()/forked() and is only set and
> read in fixup() in x86 #GP for heuristic. It's not used anywhere outside
> of x86.
>
> That's why we think the flag should be in x86 struct thread_info instead
> of in generice struct task_struct.
I don't think anybody really cares, it's just one bit, we have plenty
left.
On x86_64 there's a u32 sized alignment hole in thread_info, also we
don't use the upper 32bit of thread_info::flags, however using those
would still mean you have to use atomic ops, which you really don't
need.
^ permalink raw reply
* [Bug 208197] New: OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle
From: bugzilla-daemon @ 2020-06-15 22:02 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=208197
Bug ID: 208197
Summary: OF: /pci@f2000000/mac-io@17/gpio@50/...: could not
find phandle
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.8-rc1
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: Yes
Created attachment 289685
--> https://bugzilla.kernel.org/attachment.cgi?id=289685&action=edit
dmesg (5.8-rc1, PowerMac G4 DP)
Since 5.8-rc1 I get these OF errors on my PowerMac G4 DP:
[...]
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio5@6f: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/extint-gpio15@67: could not
find phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio6@70: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/extint-gpio16@68: could not
find phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/extint-gpio14@66: could not
find phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio12@76: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio11@75: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio5@6f: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio6@70: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/extint-gpio4@5c: could not
find phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/gpio11@75: could not find
phandle
T600 kernel: OF: /pci@f2000000/mac-io@17/gpio@50/extint-gpio15@67: could not
find phandle[...]
This has not been the case in kernel 5.7 or earlier.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle
From: bugzilla-daemon @ 2020-06-15 22:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-208197-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=208197
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 289687
--> https://bugzilla.kernel.org/attachment.cgi?id=289687&action=edit
kernel .config (5.8-rc1, PowerMac G4 DP)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH 17/25] mm/powerpc: Use mm_fault_accounting()
From: Peter Xu @ 2020-06-15 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Andrea Arcangeli, linuxppc-dev, peterx, Paul Mackerras,
Andrew Morton, Linus Torvalds, Gerald Schaefer
In-Reply-To: <20200615221607.7764-1-peterx@redhat.com>
Use the new mm_fault_accounting() helper for page fault accounting.
cmo_account_page_fault() is special. Keep that.
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/powerpc/mm/fault.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 84af6c8eecf7..6043b639ae42 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -481,8 +481,6 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,
if (!arch_irq_disabled_regs(regs))
local_irq_enable();
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
-
if (error_code & DSISR_KEYFAULT)
return bad_key_fault_exception(regs, address,
get_mm_addr_key(mm, address));
@@ -604,14 +602,11 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,
/*
* Major/minor page fault accounting.
*/
- if (major) {
- current->maj_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1, regs, address);
+ if (major)
cmo_account_page_fault();
- } else {
- current->min_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, regs, address);
- }
+
+ mm_fault_accounting(current, regs, address, major);
+
return 0;
}
NOKPROBE_SYMBOL(__do_page_fault);
--
2.26.2
^ permalink raw reply related
* [PATCH 0/2] cpufreq: Specify the default governor on command line
From: Quentin Perret @ 2020-06-15 16:55 UTC (permalink / raw)
To: rjw, rafael, viresh.kumar
Cc: juri.lelli, kernel-team, vincent.guittot, arnd, linux-pm, peterz,
adharmap, qperret, linux-kernel, mingo, paulus, linuxppc-dev,
tkjos
This series enables users of prebuilt kernels (e.g. distro kernels) to
specify their CPUfreq governor of choice using the kernel command line,
instead of having to wait for the system to fully boot to userspace to
switch using the sysfs interface. This is helpful for 2 reasons:
1. users get to choose the governor that runs during the actual boot;
2. it simplifies the userspace boot procedure a bit (one less thing to
worry about).
To enable this, the first patch moves all governor init calls to
core_initcall, to make sure they are registered by the time the drivers
probe. This should be relatively low impact as registering a governor
is a simple procedure (it gets added to a llist), and all governors
already load at core_initcall anyway when they're set as the default
in Kconfig. This also allows to clean-up the governors' init/exit code,
and reduces boilerplate.
The second patch introduces the new command line parameter, inspired by
its cpuidle counterpart. More details can be found in the respective
patch headers.
Feedback is very much welcome :-)
Thanks,
Quentin
Quentin Perret (2):
cpufreq: Register governors at core_initcall
cpufreq: Specify default governor on command line
.../admin-guide/kernel-parameters.txt | 5 +++
Documentation/admin-guide/pm/cpufreq.rst | 6 ++--
.../platforms/cell/cpufreq_spudemand.c | 26 ++------------
drivers/cpufreq/cpufreq.c | 34 ++++++++++++++++---
drivers/cpufreq/cpufreq_conservative.c | 22 +++---------
drivers/cpufreq/cpufreq_ondemand.c | 24 ++++---------
drivers/cpufreq/cpufreq_performance.c | 14 ++------
drivers/cpufreq/cpufreq_powersave.c | 18 ++--------
drivers/cpufreq/cpufreq_userspace.c | 18 ++--------
include/linux/cpufreq.h | 14 ++++++++
kernel/sched/cpufreq_schedutil.c | 6 +---
11 files changed, 73 insertions(+), 114 deletions(-)
--
2.27.0.290.gba653c62da-goog
^ permalink raw reply
* [PATCH 1/2] cpufreq: Register governors at core_initcall
From: Quentin Perret @ 2020-06-15 16:55 UTC (permalink / raw)
To: rjw, rafael, viresh.kumar
Cc: juri.lelli, kernel-team, vincent.guittot, arnd, linux-pm, peterz,
adharmap, qperret, linux-kernel, mingo, paulus, linuxppc-dev,
tkjos
In-Reply-To: <20200615165554.228063-1-qperret@google.com>
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 core_initcall unconditionally, as is already
the case for schedutil and performance. This will enable us to assume
builtin governors have been registered before the builtin CPUFreq
drivers probe.
And since all governors now have similar init/exit patterns, introduce
two new macros cpufreq_governor_{init,exit}() to factorize the code.
Signed-off-by: Quentin Perret <qperret@google.com>
---
Note: I couldn't boot-test the change to spudemand, by lack of hardware.
But I can confirm cell_defconfig compiles just fine.
---
.../platforms/cell/cpufreq_spudemand.c | 26 ++-----------------
drivers/cpufreq/cpufreq_conservative.c | 22 ++++------------
drivers/cpufreq/cpufreq_ondemand.c | 24 +++++------------
drivers/cpufreq/cpufreq_performance.c | 14 ++--------
drivers/cpufreq/cpufreq_powersave.c | 18 +++----------
drivers/cpufreq/cpufreq_userspace.c | 18 +++----------
include/linux/cpufreq.h | 14 ++++++++++
kernel/sched/cpufreq_schedutil.c | 6 +----
8 files changed, 36 insertions(+), 106 deletions(-)
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index 55b31eadb3c8..ca7849e113d7 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -126,30 +126,8 @@ static struct cpufreq_governor spu_governor = {
.stop = spu_gov_stop,
.owner = THIS_MODULE,
};
-
-/*
- * module init and destoy
- */
-
-static int __init spu_gov_init(void)
-{
- int ret;
-
- ret = cpufreq_register_governor(&spu_governor);
- if (ret)
- printk(KERN_ERR "registration of governor failed\n");
- return ret;
-}
-
-static void __exit spu_gov_exit(void)
-{
- cpufreq_unregister_governor(&spu_governor);
-}
-
-
-module_init(spu_gov_init);
-module_exit(spu_gov_exit);
+cpufreq_governor_init(spu_governor);
+cpufreq_governor_exit(spu_governor);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Krafft <krafft@de.ibm.com>");
-
diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index 737ff3b9c2c0..aa39ff31ec9f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -322,17 +322,7 @@ static struct dbs_governor cs_governor = {
.start = cs_start,
};
-#define CPU_FREQ_GOV_CONSERVATIVE (&cs_governor.gov)
-
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
+#define CPU_FREQ_GOV_CONSERVATIVE (cs_governor.gov)
MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>");
MODULE_DESCRIPTION("'cpufreq_conservative' - A dynamic cpufreq governor for "
@@ -343,11 +333,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
struct cpufreq_governor *cpufreq_default_governor(void)
{
- return CPU_FREQ_GOV_CONSERVATIVE;
+ return &CPU_FREQ_GOV_CONSERVATIVE;
}
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
#endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_CONSERVATIVE);
+cpufreq_governor_exit(CPU_FREQ_GOV_CONSERVATIVE);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 82a4d37ddecb..ac361a8b1d3b 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -408,7 +408,7 @@ static struct dbs_governor od_dbs_gov = {
.start = od_start,
};
-#define CPU_FREQ_GOV_ONDEMAND (&od_dbs_gov.gov)
+#define CPU_FREQ_GOV_ONDEMAND (od_dbs_gov.gov)
static void od_set_powersave_bias(unsigned int powersave_bias)
{
@@ -429,7 +429,7 @@ static void od_set_powersave_bias(unsigned int powersave_bias)
continue;
policy = cpufreq_cpu_get_raw(cpu);
- if (!policy || policy->governor != CPU_FREQ_GOV_ONDEMAND)
+ if (!policy || policy->governor != &CPU_FREQ_GOV_ONDEMAND)
continue;
policy_dbs = policy->governor_data;
@@ -461,16 +461,6 @@ void od_unregister_powersave_bias_handler(void)
}
EXPORT_SYMBOL_GPL(od_unregister_powersave_bias_handler);
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
MODULE_AUTHOR("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
MODULE_AUTHOR("Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>");
MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for "
@@ -480,11 +470,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
struct cpufreq_governor *cpufreq_default_governor(void)
{
- return CPU_FREQ_GOV_ONDEMAND;
+ return &CPU_FREQ_GOV_ONDEMAND;
}
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
#endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_ONDEMAND);
+cpufreq_governor_exit(CPU_FREQ_GOV_ONDEMAND);
diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c
index def9afe0f5b8..71c1d9aba772 100644
--- a/drivers/cpufreq/cpufreq_performance.c
+++ b/drivers/cpufreq/cpufreq_performance.c
@@ -23,16 +23,6 @@ static struct cpufreq_governor cpufreq_gov_performance = {
.limits = cpufreq_gov_performance_limits,
};
-static int __init cpufreq_gov_performance_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_performance);
-}
-
-static void __exit cpufreq_gov_performance_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_performance);
-}
-
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE
struct cpufreq_governor *cpufreq_default_governor(void)
{
@@ -50,5 +40,5 @@ MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'performance'");
MODULE_LICENSE("GPL");
-core_initcall(cpufreq_gov_performance_init);
-module_exit(cpufreq_gov_performance_exit);
+cpufreq_governor_init(cpufreq_gov_performance);
+cpufreq_governor_exit(cpufreq_gov_performance);
diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c
index 1ae66019eb83..7749522355b5 100644
--- a/drivers/cpufreq/cpufreq_powersave.c
+++ b/drivers/cpufreq/cpufreq_powersave.c
@@ -23,16 +23,6 @@ static struct cpufreq_governor cpufreq_gov_powersave = {
.owner = THIS_MODULE,
};
-static int __init cpufreq_gov_powersave_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_powersave);
-}
-
-static void __exit cpufreq_gov_powersave_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_powersave);
-}
-
MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'powersave'");
MODULE_LICENSE("GPL");
@@ -42,9 +32,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
{
return &cpufreq_gov_powersave;
}
-
-core_initcall(cpufreq_gov_powersave_init);
-#else
-module_init(cpufreq_gov_powersave_init);
#endif
-module_exit(cpufreq_gov_powersave_exit);
+
+cpufreq_governor_init(cpufreq_gov_powersave);
+cpufreq_governor_exit(cpufreq_gov_powersave);
diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index b43e7cd502c5..50a4d7846580 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -126,16 +126,6 @@ static struct cpufreq_governor cpufreq_gov_userspace = {
.owner = THIS_MODULE,
};
-static int __init cpufreq_gov_userspace_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_userspace);
-}
-
-static void __exit cpufreq_gov_userspace_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_userspace);
-}
-
MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>, "
"Russell King <rmk@arm.linux.org.uk>");
MODULE_DESCRIPTION("CPUfreq policy governor 'userspace'");
@@ -146,9 +136,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
{
return &cpufreq_gov_userspace;
}
-
-core_initcall(cpufreq_gov_userspace_init);
-#else
-module_init(cpufreq_gov_userspace_init);
#endif
-module_exit(cpufreq_gov_userspace_exit);
+
+cpufreq_governor_init(cpufreq_gov_userspace);
+cpufreq_governor_exit(cpufreq_gov_userspace);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3494f6763597..e62b022cb07e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -577,6 +577,20 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy);
int cpufreq_register_governor(struct cpufreq_governor *governor);
void cpufreq_unregister_governor(struct cpufreq_governor *governor);
+#define cpufreq_governor_init(__governor) \
+static int __init __governor##_init(void) \
+{ \
+ return cpufreq_register_governor(&__governor); \
+} \
+core_initcall(__governor##_init)
+
+#define cpufreq_governor_exit(__governor) \
+static void __exit __governor##_exit(void) \
+{ \
+ return cpufreq_unregister_governor(&__governor); \
+} \
+module_exit(__governor##_exit)
+
struct cpufreq_governor *cpufreq_default_governor(void);
struct cpufreq_governor *cpufreq_fallback_governor(void);
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 7fbaee24c824..402a09af9f43 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -909,11 +909,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
}
#endif
-static int __init sugov_register(void)
-{
- return cpufreq_register_governor(&schedutil_gov);
-}
-core_initcall(sugov_register);
+cpufreq_governor_init(schedutil_gov);
#ifdef CONFIG_ENERGY_MODEL
extern bool sched_energy_update;
--
2.27.0.290.gba653c62da-goog
^ permalink raw reply related
* [PATCH 2/2] cpufreq: Specify default governor on command line
From: Quentin Perret @ 2020-06-15 16:55 UTC (permalink / raw)
To: rjw, rafael, viresh.kumar
Cc: juri.lelli, kernel-team, vincent.guittot, arnd, linux-pm, peterz,
adharmap, qperret, linux-kernel, mingo, paulus, linuxppc-dev,
tkjos
In-Reply-To: <20200615165554.228063-1-qperret@google.com>
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
default is to boot to userspace, and to then switch using the sysfs
interface. Being able to specify the default governor on the command
line, like is the case for cpuidle, would enable those users to specify
their governor of choice earlier on, and to simplify slighlty the
userspace boot procedure.
To support this use-case, add a kernel command line parameter enabling
to specify a default governor for CPUfreq, which takes precedence over
the builtin default.
This implementation has one notable limitation: the default governor
must be registered before the driver. This is solved for builtin
governors and drivers using appropriate *_initcall() functions. And in
the modular case, this must be reflected as a constraint on the module
loading order.
Signed-off-by: Quentin Perret <qperret@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 +++
Documentation/admin-guide/pm/cpufreq.rst | 6 ++--
drivers/cpufreq/cpufreq.c | 34 ++++++++++++++++---
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fb95fad81c79..5fd3c9f187eb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -703,6 +703,11 @@
cpufreq.off=1 [CPU_FREQ]
disable the cpufreq sub-system
+ cpufreq.default_governor=
+ [CPU_FREQ] Name of the default cpufreq governor to use.
+ This governor must be registered in the kernel before
+ the cpufreq driver probes.
+
cpu_init_udelay=N
[X86] Delay for N microsec between assert and de-assert
of APIC INIT to start processors. This delay occurs
diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index 0c74a7784964..368e612145d2 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -147,9 +147,9 @@ CPUs in it.
The next major initialization step for a new policy object is to attach a
scaling governor to it (to begin with, that is the default scaling governor
-determined by the kernel configuration, but it may be changed later
-via ``sysfs``). First, a pointer to the new policy object is passed to the
-governor's ``->init()`` callback which is expected to initialize all of the
+determined by the kernel command line or configuration, but it may be changed
+later via ``sysfs``). First, a pointer to the new policy object is passed to
+the governor's ``->init()`` callback which is expected to initialize all of the
data structures necessary to handle the given policy and, possibly, to add
a governor ``sysfs`` interface to it. Next, the governor is started by
invoking its ``->start()`` callback.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0128de3603df..0f05caedc320 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -50,6 +50,9 @@ static LIST_HEAD(cpufreq_governor_list);
#define for_each_governor(__governor) \
list_for_each_entry(__governor, &cpufreq_governor_list, governor_list)
+static char cpufreq_param_governor[CPUFREQ_NAME_LEN];
+static struct cpufreq_governor *default_governor;
+
/**
* The "cpufreq driver" - the arch- or hardware-dependent low
* level driver of CPUFreq support, and its spinlock. This lock
@@ -1055,7 +1058,6 @@ __weak struct cpufreq_governor *cpufreq_default_governor(void)
static int cpufreq_init_policy(struct cpufreq_policy *policy)
{
- struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
@@ -1065,8 +1067,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
if (gov) {
pr_debug("Restoring governor %s for cpu %d\n",
policy->governor->name, policy->cpu);
- } else if (def_gov) {
- gov = def_gov;
+ } else if (default_governor) {
+ gov = default_governor;
} else {
return -ENODATA;
}
@@ -1074,8 +1076,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
/* Use the default policy if there is no last_policy. */
if (policy->last_policy) {
pol = policy->last_policy;
- } else if (def_gov) {
- pol = cpufreq_parse_policy(def_gov->name);
+ } else if (default_governor) {
+ pol = cpufreq_parse_policy(default_governor->name);
/*
* In case the default governor is neiter "performance"
* nor "powersave", fall back to the initial policy
@@ -2196,6 +2198,24 @@ __weak struct cpufreq_governor *cpufreq_fallback_governor(void)
return NULL;
}
+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 %s\n", cpufreq_param_governor);
+ default_governor = cpufreq_default_governor();
+ }
+}
+
+static void cpufreq_put_default_governor(void)
+{
+ if (!default_governor)
+ return;
+ module_put(default_governor->owner);
+ default_governor = NULL;
+}
+
static int cpufreq_init_governor(struct cpufreq_policy *policy)
{
int ret;
@@ -2701,6 +2721,8 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
if (driver_data->setpolicy)
driver_data->flags |= CPUFREQ_CONST_LOOPS;
+ else
+ cpufreq_get_default_governor();
if (cpufreq_boost_supported()) {
ret = create_boost_sysfs_file();
@@ -2769,6 +2791,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
subsys_interface_unregister(&cpufreq_interface);
remove_boost_sysfs_file();
cpuhp_remove_state_nocalls_cpuslocked(hp_online);
+ cpufreq_put_default_governor();
write_lock_irqsave(&cpufreq_driver_lock, flags);
@@ -2792,4 +2815,5 @@ static int __init cpufreq_core_init(void)
return 0;
}
module_param(off, int, 0444);
+module_param_string(default_governor, cpufreq_param_governor, CPUFREQ_NAME_LEN, 0444);
core_initcall(cpufreq_core_init);
--
2.27.0.290.gba653c62da-goog
^ permalink raw reply related
* Re: [PATCH 2/2] cpufreq: Specify default governor on command line
From: Quentin Perret @ 2020-06-15 17:41 UTC (permalink / raw)
To: rjw, rafael, viresh.kumar
Cc: juri.lelli, kernel-team, vincent.guittot, arnd, linux-pm, peterz,
adharmap, linux-kernel, mingo, paulus, linuxppc-dev, tkjos
In-Reply-To: <20200615165554.228063-3-qperret@google.com>
On Monday 15 Jun 2020 at 17:55:54 (+0100), Quentin Perret wrote:
> static int cpufreq_init_governor(struct cpufreq_policy *policy)
> {
> int ret;
> @@ -2701,6 +2721,8 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
>
> if (driver_data->setpolicy)
> driver_data->flags |= CPUFREQ_CONST_LOOPS;
> + else
> + cpufreq_get_default_governor();
Looking at this again, it appears that the comment above
cpufreq_parse_governor() confused me a bit -- this needs doing
unconditionally I think.
I'll fix it in v2.
Thanks,
Quentin
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Raj, Ashok @ 2020-06-15 18:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ravi V Shankar, Dave Hansen, H Peter Anvin, Dave Jiang, Ashok Raj,
Joerg Roedel, x86, amd-gfx, Ingo Molnar, Fenghua Yu, 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: <20200615160357.GA2531@hirez.programming.kicks-ass.net>
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);
> > > > + if (pasid_msr & MSR_IA32_PASID_VALID)
> > > > + return false;
> > > > +
> > > > + /* Fix up the MSR if the MSR doesn't have a valid PASID. */
> > > > + wrmsrl(MSR_IA32_PASID, pasid | MSR_IA32_PASID_VALID);
>
> How much more expensive is the wrmsr over the rdmsr? Can't we just
> unconditionally write the current PASID and call it a day?
The reason to check the rdmsr() is because we are using a hueristic taking
GP faults. If we already setup the MSR, but we get it a second time it
means the reason is something other than PASID_MSR not being set.
Ideally we should use the TIF_ to track this would be cheaper, but we were
told those bits aren't easy to give out.
Cheers,
Ashok
^ permalink raw reply
* Re: [PATCH] kbuild: reuse vmlinux.o in vmlinux_link
From: Sami Tolvanen @ 2020-06-15 21:47 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michal Marek, Kees Cook, Sam Ravnborg, Linux Kbuild mailing list,
Linux Kernel Mailing List, Nicholas Piggin, linuxppc-dev
In-Reply-To: <CAK7LNAR_-q3jhaUzDpkC3ej_DpAerzMsORT-tFw_3AwX7xM0Yw@mail.gmail.com>
On Sat, May 23, 2020 at 8:13 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Hi Nicholas,
> (+CC: Sam Ravnborg)
>
>
> On Sat, May 23, 2020 at 7:06 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > Excerpts from Masahiro Yamada's message of May 23, 2020 3:44 am:
> > > + Michael, and PPC ML.
> > >
> > > They may know something about the reason of failure.
> >
> > Because the linker can't put branch stubs within object code sections,
> > so when you incrementally link them too large, the linker can't resolve
> > branches into other object files.
>
>
> Ah, you are right.
>
> So, this is a problem not only for PPC
> but also for ARM (both 32 and 64 bit), etc.
>
> ARM needs to insert a veneer to jump far.
>
> Prior to thin archive, we could not compile
> ARCH=arm allyesconfig because
> drivers/built-in.o was too large.
>
> This patch gets us back to the too large
> incremental object situation.
>
> With my quick compile-testing,
> ARCH=arm allyesconfig
> and ARCH=arm64 allyesconfig are broken.
Thanks for looking into this! Clang doesn't appear to have this issue
with LTO because it always enables both -ffunction-sections and
-fdata-sections. I confirmed that -ffunction-sections also fixes arm64
allyesconfig with this patch. While I'm fine with reusing vmlinux.o
only with LTO, how would you feel about enabling -ffunction-sections
in the kernel by default?
Sami
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl_ssi: Fix bclk calculation for mono channel
From: Nicolin Chen @ 2020-06-15 23:09 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, perex, broonie,
festevam, linux-kernel
In-Reply-To: <b5cf5e3cc39c62f6bb3660b7588b037ffc57f780.1592200690.git.shengjiu.wang@nxp.com>
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 fixed to
> 32bit), it should be the value of params_width(hw_params).
>
> The condition "slots == 2" is not good for I2S Master mode,
> because for Network mode and Normal mode, the slots can also
> be 2. Then we need to use (ssi->i2s_net & SSI_SCR_I2S_MODE_MASK)
> to check if it is I2S Master mode.
The fsl_ssi_set_bclk is only called when fsl_ssi_is_i2s_master,
though I agree that that line of comments sounds confusing now.
> So we refine the famula for mono channel, otherwise there
famula => formula?
> will be sound issue for S24_LE.
>
> Fixes: b0a7043d5c2c ("ASoC: fsl_ssi: Caculate bit clock rate using slot number and width")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2
> - refine patch for Network mode and Normal mode.
>
> sound/soc/fsl/fsl_ssi.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index bad89b0d129e..cbf67d132fda 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -678,7 +678,8 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
> struct regmap *regs = ssi->regs;
> u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
> unsigned long clkrate, baudrate, tmprate;
> - unsigned int slots = params_channels(hw_params);
> + unsigned int channels = params_channels(hw_params);
> + unsigned int slots;
> unsigned int slot_width = 32;
> u64 sub, savesub = 100000;
> unsigned int freq;
> @@ -688,9 +689,15 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
> /* Override slots and slot_width if being specifically set... */
> if (ssi->slots)
> slots = ssi->slots;
> - /* ...but keep 32 bits if slots is 2 -- I2S Master mode */
> - if (ssi->slot_width && slots != 2)
> - slot_width = ssi->slot_width;
> + else
> + /* Apply two slots for mono channel, because DC = 2 */
> + slots = (channels == 1) ? 2 : channels;
> +
> + /* ...but keep 32 bits if I2S Master mode */
> + if ((ssi->i2s_net & SSI_SCR_I2S_MODE_MASK) != SSI_SCR_I2S_MODE_MASTER ||
> + channels == 1)
> + slot_width = ssi->slot_width ? ssi->slot_width :
This looks very complicated...can you review and try mine?
(Basically, take 32-bit out of default but force it later)
@@ -678,8 +678,9 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
struct regmap *regs = ssi->regs;
u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
unsigned long clkrate, baudrate, tmprate;
- unsigned int slots = params_channels(hw_params);
- unsigned int slot_width = 32;
+ unsigned int channels = params_channels(hw_params);
+ unsigned int slot_width = params_width(hw_params);
+ unsigned int slots = 2;
u64 sub, savesub = 100000;
unsigned int freq;
bool baudclk_is_used;
@@ -688,10 +689,16 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
/* Override slots and slot_width if being specifically set... */
if (ssi->slots)
slots = ssi->slots;
- /* ...but keep 32 bits if slots is 2 -- I2S Master mode */
- if (ssi->slot_width && slots != 2)
+ if (ssi->slot_width)
slot_width = ssi->slot_width;
+ /*
+ * ...but force 32 bits for stereo audio. Note that mono audio is also
+ * sent in 2 slots via NORMAL mode, so check both slots and channels.
+ */
+ if (slots == 2 && channels == 2)
+ slot_width = 32;
+
/* Generate bit clock based on the slot number and slot width */
freq = slots * slot_width * params_rate(hw_params);
^ permalink raw reply
* Re: [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)
From: Fenghua Yu @ 2020-06-15 23:16 UTC (permalink / raw)
To: Lu Baolu
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, David Woodhouse, Felix Kuehling, linux-kernel, iommu,
Jacob Jun Pan, Frederic Barrat, linuxppc-dev
In-Reply-To: <9d1bd13c-0e0d-bead-f9a8-9422996a33f8@linux.intel.com>
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 (DSA) uses
> >+intel_svm_bind_mm(), which will do the following.
>
> The Intel SVM APIs have been deprecated. Drivers should use
> iommu_sva_bind_device() instead. Please also update other places in
> this document.
Will fix this.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: fsl_easrc: Fix several warnings
From: Mark Brown @ 2020-06-15 23:40 UTC (permalink / raw)
To: nicoleotsuka, timur, perex, lgirdwood, alsa-devel, festevam,
tiwai, Shengjiu Wang, Xiubo.Lee
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1591155860.git.shengjiu.wang@nxp.com>
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
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/3] ASoC: fsl_easrc: Fix -Wmissing-prototypes warning
commit: e4cc0aaac390a87f80ae542c75d4c84de08816f9
[2/3] ASoC: fsl_easrc: Fix -Wunused-but-set-variable
commit: 633a2c7d6e621e748d69423fa85be88c7dcd4f94
[3/3] ASoC: fsl_easrc: Fix "Function parameter not described" warnings
commit: d73d682a9e87fa494868e8094fcc5b6a6b505464
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/
From: Mark Brown @ 2020-06-15 23:41 UTC (permalink / raw)
To: Kieran Bingham, Kieran Bingham
Cc: linux-usb, linux-scsi, linux-mm, linux-rdma, netdev, linux-pm,
linux-wireless, linux-kernel, ath10k, virtualization,
linux-renesas-soc, linux-gpio, linux-mtd, dri-devel, linux-input,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200609124610.3445662-1-kieran.bingham+renesas@ideasonboard.com>
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
> scripts/spelling.txt so it shouldn't re-appear ;-)
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/2] regulator: Fix trivial spelling
commit: d3f3723387f97118c337689fc73e4199fb4331ce
[2/2] regulator: gpio: Fix trivial spelling
commit: 1f0b740004f09d2f1b716fd6c2fdca81004ded05
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
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