On Tue, Jan 17, 2023 at 02:47:47PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the crypto tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
>
> arch/powerpc/crypto/p10_aes_gcm.o: warning: objtool: .text+0x884: unannotated
> intra-function call
> arc
From: ye xingchen
crypto/algapi.h is included more than once.
Signed-off-by: ye xingchen
---
arch/powerpc/crypto/p10-aes-gcm-glue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/crypto/p10-aes-gcm-glue.c
b/arch/powerpc/crypto/p10-aes-gcm-glue.c
index 777e6b5254da..a17d3e8d8f
Convert the raise/on parameter in ->dtr_rts() to bool through the
callchain. The parameter is used like bool. In USB serial, there
remains a few implicit bool -> larger type conversions because some
devices use u8 in their control messages.
In moxa_tiocmget(), dtr variable was reused for line stat
Convert various parameter names for ->dtr_rts() and related functions
from onoff, on, and raise to active.
Reviewed-by: Jiri Slaby
Acked-by: Ulf Hansson # For MMC
Signed-off-by: Ilpo Järvinen
---
drivers/char/pcmcia/synclink_cs.c | 6 +++---
drivers/mmc/core/sdio_uart.c | 6 +++---
driver
From: ye xingchen
Instead of using dma_alloc_coherent() and memset() directly use
dma_zalloc_coherent().
Signed-off-by: ye xingchen
---
arch/powerpc/platforms/cell/axon_msi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c
b/arch
On Tue, Jan 17, 2023 at 01:24:46PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
>
> On Thu, 12 Jan 2023 20:43:49 +0100
> Peter Zijlstra wrote:
>
> > Robot reported that trace_hardirqs_{on,off}() tickle the forbidden
> > _rcuidle() tracepoint through local_irq_{en,dis}able().
> >
> > For 'sane' co
On 13/01/2023 11:37, Herve Codina wrote:
> Add support for the time slot assigner (TSA)
> available in some PowerQUICC SoC such as MPC885
> or MPC866.
>
> Signed-off-by: Herve Codina
> ---
> .../bindings/soc/fsl/cpm_qe/fsl,tsa.yaml | 260 ++
> include/dt-bindings/soc/fsl,tsa
On 13/01/2023 11:37, Herve Codina wrote:
> Add support for the QMC (QUICC Multichannel Controller)
> available in some PowerQUICC SoC such as MPC885 or MPC866.
>
> Signed-off-by: Herve Codina
> ---
> .../bindings/soc/fsl/cpm_qe/fsl,qmc.yaml | 164 ++
> 1 file changed, 164 in
On 13/01/2023 11:37, Herve Codina wrote:
> The QMC (QUICC mutichannel controller) is a controller
> present in some PowerQUICC SoC such as MPC885.
> The QMC audio is an ASoC component that uses the QMC
> controller to transfer the audio data.
>
> Signed-off-by: Herve Codina
Reviewed-by: Krzyszto
On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote:
> I'm sorry to have to bear some bad news on that front. :(
Moo, something had to give..
> IIUC what's happenign here is the PSCI cpuidle driver has entered idle and RCU
> is no longer watching when arm64's cpu_suspend() manipulates
> On 17-Jan-2023, at 3:30 AM, Ian Rogers wrote:
>
> On Mon, Jan 16, 2023 at 4:00 AM Athira Rajeev
> wrote:
>>
>>
>>
>>> On 16-Jan-2023, at 11:47 AM, Ian Rogers wrote:
>>>
>>> On Sun, Jan 15, 2023 at 9:03 PM Athira Rajeev
>>> wrote:
> On 28-Sep-2022, at 10:24 AM, At
On 06 January 2023 at 03:41 pm, Jiri Kosina wrote:
On Fri, 6 Jan 2023, Christian Zigotzky wrote:
Hello,
The reboot issue is still present in the RC2 of kernel 6.2. We still need the
usbhid.patch. [1]
Please check the bad commit. [2]
Ankit,
have you tested with all the devices that you added
On Mon 09-01-23 12:53:04, Suren Baghdasaryan wrote:
[...]
> void vm_area_free(struct vm_area_struct *vma)
> {
> free_anon_vma_name(vma);
> +#ifdef CONFIG_PER_VMA_LOCK
> + call_rcu(&vma->vm_rcu, __vm_area_free);
> +#else
> kmem_cache_free(vm_area_cachep, vma);
> +#endif
Is it safe
On Tue, 17 Jan 2023, Christian Zigotzky wrote:
> >> The reboot issue is still present in the RC2 of kernel 6.2. We still need
> >> the
> >> usbhid.patch. [1]
> >>
> >> Please check the bad commit. [2]
> > Ankit,
> >
> > have you tested with all the devices that you added the quirk for in your
> >
On Fri, Jan 13, 2023 at 11:37:50AM +0100, Herve Codina wrote:
> Add support for the time slot assigner (TSA)
> available in some PowerQUICC SoC such as MPC885
> or MPC866.
An odd line wrap length...
>
> Signed-off-by: Herve Codina
> ---
> .../bindings/soc/fsl/cpm_qe/fsl,tsa.yaml | 260 ++
On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> Introduce a per-VMA rw_semaphore to be used during page fault handling
> instead of mmap_lock. Because there are cases when multiple VMAs need
> to be exclusively locked during VMA tree modifications, instead of the
> usual lock/unlock patter we
On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 5986817f393c..c026d75108b3 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -474,6 +474,7 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct
> *orig)
>*/
>
On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote:
> To keep vma locking correctness when vm_flags are modified, add modifier
> functions to be used whenever flags are updated.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 38 ++
>
On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > instead of mmap_lock. Because there are cases when multiple VMAs need
> > to be exclusively locked during VMA tree modif
On Tue 17-01-23 16:09:03, Michal Hocko wrote:
> On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote:
> > To keep vma locking correctness when vm_flags are modified, add modifier
> > functions to be used whenever flags are updated.
> >
> > Signed-off-by: Suren Baghdasaryan
> > ---
> > include/linu
On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> Move VMA flag modification (which now implies VMA locking) before
> anon_vma_lock_write to match the locking order of page fault handler.
Does this changelog assumes per vma locking in the #PF?
--
Michal Hocko
SUSE Labs
On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> Protect VMA from concurrent page fault handler while collapsing a huge
> page. Page fault handler needs a stable PMD to use PTL and relies on
> per-VMA lock to prevent concurrent PMD changes. pmdp_collapse_flush(),
> set_huge_pmd() and collapse_
On Mon 09-01-23 12:53:21, Suren Baghdasaryan wrote:
> Assert there are no holders of VMA lock for reading when it is about to be
> destroyed.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 8
> kernel/fork.c | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff
On Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote:
> Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> page fault handling. When VMA is not found, can't be locked or changes
> after being locked, the function returns NULL. The lookup is performed
> under RCU protection to pre
On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> call_rcu() can take a long time when callback offloading is enabled.
> Its use in the vm_area_free can cause regressions in the exit path when
> multiple VMAs are being freed.
What kind of regressions.
> To minimize that impact, place VMAs int
Hi Geert!
On 1/6/23 16:17, Geert Uytterhoeven wrote:
I'm not seeing this one, but I am getting this one instead:
In file included from ./arch/sh/include/asm/hw_irq.h:6,
from ./include/linux/irq.h:596,
from ./include/asm-generic/hardirq.h:17,
Michael Ellerman writes:
> Nathan Lynch writes:
>> Laurent Dufour writes:
>>> On 10/01/2023 05:42:55, Nathan Lynch wrote:
--- a/arch/powerpc/include/asm/rtas-types.h
+++ b/arch/powerpc/include/asm/rtas-types.h
@@ -18,7 +18,7 @@ struct rtas_t {
unsigned long entry;
On 12/29/22 19:01, Sean Anderson wrote:
> This adds support for the Lynx 10G SerDes found on the QorIQ T-series
> and Layerscape series. Due to limited time and hardware, only support
> for the LS1046ARDB and LS1088ARDB is added in this initial series.
>
> This series is based on phy/next, but it
Since Linux 5.19 this error is observed:
sysfs: cannot create duplicate filename '/devices/platform/of-display'
This is because multiple devices with the same name 'of-display' are
created on the same bus.
Update the code to create numbered device names for the non-boot
disaplay.
cc: linuxppc-d
Hi Adrian,
On Tue, Jan 17, 2023 at 5:42 PM John Paul Adrian Glaubitz
wrote:
> On 1/6/23 16:17, Geert Uytterhoeven wrote:
> >> I'm not seeing this one, but I am getting this one instead:
> >>
> >> In file included from ./arch/sh/include/asm/hw_irq.h:6,
> >>from ./include/linux/
Hi!
On 1/17/23 18:01, Geert Uytterhoeven wrote:
The issue is that some of the parameters are not arrays, but
NULL. E.g.:
arch/sh/kernel/cpu/sh2/setup-sh7619.c:static
DECLARE_INTC_DESC(intc_desc, "sh7619", vectors, NULL,
arch/sh/kernel/cpu/sh2/setup-sh7619.c- NULL,
prio_registe
https://bugzilla.kernel.org/show_bug.cgi?id=216095
--- Comment #15 from Michal Suchánek (msucha...@suse.de) ---
You do have two outputs defined in the device tree:
/pci@f000/ATY,AlteracParent@10/ATY,Alterac_A@0
/pci@f000/ATY,AlteracParent@10/ATY,Alterac_B@1
If they correspond to a physic
Hello,
On Fri, Jan 13, 2023 at 06:18:41PM +, Gary Guo wrote:
> On Thu, 12 Jan 2023 14:40:59 -0700
> Lucas De Marchi wrote:
>
> > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > >
> > > struct modversion_info {
> > >- unsigned long crc;
> > >- char name[MODULE_NAME_LEN];
> > >
+locking maintainers
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> Introduce a per-VMA rw_semaphore to be used during page fault handling
> instead of mmap_lock. Because there are cases when multiple VMAs need
> to be exclusively locked during VMA tree modifications, instead of the
>
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> rw_semaphore is a sizable structure of 40 bytes and consumes
> considerable space for each vm_area_struct. However vma_lock has
> two important specifics which can be used to replace rw_semaphore
> with a simpler structure:
[...]
> static
On Mon, Jan 16, 2023 at 09:58:35PM -0800, Suren Baghdasaryan wrote:
> On Mon, Jan 16, 2023 at 9:46 PM Matthew Wilcox wrote:
> >
> > On Mon, Jan 16, 2023 at 08:34:36PM -0800, Suren Baghdasaryan wrote:
> > > On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox
> > > wrote:
> > > >
> > > > On Mon, Jan 16
On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
>
> On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > rw_semaphore is a sizable structure of 40 bytes and consumes
> > considerable space for each vm_area_struct. However vma_lock has
> > two important specifics which can be used to rep
On Tue, Jan 17, 2023 at 10:23 AM Matthew Wilcox wrote:
>
> On Mon, Jan 16, 2023 at 09:58:35PM -0800, Suren Baghdasaryan wrote:
> > On Mon, Jan 16, 2023 at 9:46 PM Matthew Wilcox wrote:
> > >
> > > On Mon, Jan 16, 2023 at 08:34:36PM -0800, Suren Baghdasaryan wrote:
> > > > On Mon, Jan 16, 2023 at
On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> >
> > On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > > rw_semaphore is a sizable structure of 40 bytes and consumes
> > > considerable space for each vm_area_str
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> vma->lock being part of the vm_area_struct causes performance regression
> during page faults because during contention its count and owner fields
> are constantly updated and having other parts of vm_area_struct used
> during page fault h
On Tue, Jan 17, 2023 at 7:31 PM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > >
> > > On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan
> > > wrote:
> > > > rw_semaphore is a sizable struct
On Tue, Jan 17, 2023 at 10:31 AM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > >
> > > On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan
> > > wrote:
> > > > rw_semaphore is a sizable struc
On Tue, Jan 17, 2023 at 10:36:42AM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 10:31 AM Matthew Wilcox wrote:
> >
> > On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > > >
> > > > On Mon, Jan 9, 2023 at 9
On Tue, Jan 17, 2023 at 10:36 AM Jann Horn wrote:
>
> On Tue, Jan 17, 2023 at 7:31 PM Matthew Wilcox wrote:
> >
> > On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 10:12 AM Jann Horn wrote:
> > > >
> > > > On Mon, Jan 9, 2023 at 9:55 PM Suren Bag
On Tue, Jan 17, 2023 at 10:47 AM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 10:36:42AM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:31 AM Matthew Wilcox wrote:
> > >
> > > On Tue, Jan 17, 2023 at 10:26:32AM -0800, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 17, 2023 at
On Tue, Jan 17, 2023 at 7:55 PM Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 10:47 AM Matthew Wilcox wrote:
> >
> > On Tue, Jan 17, 2023 at 10:36:42AM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 10:31 AM Matthew Wilcox
> > > wrote:
> > > >
> > > > On Tue, Jan 17, 2023
On Tue, Jan 17, 2023 at 10:34 AM Jann Horn wrote:
>
> On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > vma->lock being part of the vm_area_struct causes performance regression
> > during page faults because during contention its count and owner fields
> > are constantly updated and ha
On Tue, Jan 17, 2023 at 11:00 AM Jann Horn wrote:
>
> On Tue, Jan 17, 2023 at 7:55 PM Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:47 AM Matthew Wilcox wrote:
> > >
> > > On Tue, Jan 17, 2023 at 10:36:42AM -0800, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 17, 2023 at 10:31 AM Matt
On Tue, Jan 17, 2023 at 06:51:44PM +0100, Michal Suchánek wrote:
Hello,
On Fri, Jan 13, 2023 at 06:18:41PM +, Gary Guo wrote:
On Thu, 12 Jan 2023 14:40:59 -0700
Lucas De Marchi wrote:
> On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> >
> > struct modversion_info {
> >- un
On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> Due to the possibility of handle_userfault dropping mmap_lock, avoid fault
> handling under VMA lock and retry holding mmap_lock. This can be handled
> more gracefully in the future.
>
> Signed-off-by: Suren Baghdasaryan
> Suggested-by: P
Hi Adrian,
On Tue, Jan 17, 2023 at 6:06 PM John Paul Adrian Glaubitz
wrote:
> On 1/17/23 18:01, Geert Uytterhoeven wrote:
> > The issue is that some of the parameters are not arrays, but
> > NULL. E.g.:
> >
> > arch/sh/kernel/cpu/sh2/setup-sh7619.c:static
> > DECLARE_INTC_DESC(intc_desc, "sh7619"
On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > Protect VMA from concurrent page fault handler while collapsing a huge
> > page. Page fault handler needs a stable PMD to use PTL and relies on
> > per-VMA lock to prevent concurrent PMD c
On Tue 17-01-23 10:28:40, Suren Baghdasaryan wrote:
[...]
> > Then yes, that's a starvable lock. Preventing starvation on the mmap
> > sem was the original motivation for making rwsems non-starvable, so
> > changing that behaviour now seems like a bad idea. For efficiency, I'd
> > suggest that a
On Tue, Jan 17, 2023 at 8:51 PM Jann Horn wrote:
> On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > Due to the possibility of handle_userfault dropping mmap_lock, avoid fault
> > handling under VMA lock and retry holding mmap_lock. This can be handled
> > more gracefully in the future
Hi!
On 1/17/23 21:05, Geert Uytterhoeven wrote:
Isn't this supposed to be caught by this check:
a, __same_type(a, NULL)
?
Yeah, but gcc thinks it is smarter than us...
Probably it drops the test, assuming UB cannot happen.
Hmm, sounds like a GGC bug to me then. Not sure how to fix
On Tue, Jan 17, 2023 at 12:36 PM Jann Horn wrote:
>
> On Tue, Jan 17, 2023 at 8:51 PM Jann Horn wrote:
> > On Mon, Jan 9, 2023 at 9:55 PM Suren Baghdasaryan wrote:
> > > Due to the possibility of handle_userfault dropping mmap_lock, avoid fault
> > > handling under VMA lock and retry holding mma
On Tue, Jan 17, 2023 at 12:31 PM Michal Hocko wrote:
>
> On Tue 17-01-23 10:28:40, Suren Baghdasaryan wrote:
> [...]
> > > Then yes, that's a starvable lock. Preventing starvation on the mmap
> > > sem was the original motivation for making rwsems non-starvable, so
> > > changing that behaviour n
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> page fault handling. When VMA is not found, can't be locked or changes
> after being locked, the function returns NULL. The lookup is performed
> under RCU protection
On Tue, Jan 17, 2023 at 12:28 PM Jann Horn wrote:
>
> On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > Protect VMA from concurrent page fault handler while collapsing a huge
> > > page. Page fault handler needs a stable PMD to use P
On Tue, Jan 17, 2023 at 7:04 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > instead of mmap_lock. Because there are cases when multiple VMAs need
> > to be exclusively locked during VMA t
On Tue, Jan 17, 2023 at 7:07 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 5986817f393c..c026d75108b3 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -474,6 +474,7 @@ struct vm_area_struct *vm_a
On Tue, Jan 17, 2023 at 7:12 AM Michal Hocko wrote:
>
> On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> > On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > > instead of mmap_lock. Because there are cases when multip
On Tue, Jan 17, 2023 at 11:26:29AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote:
>
> > I'm sorry to have to bear some bad news on that front. :(
>
> Moo, something had to give..
>
>
> > IIUC what's happenign here is the PSCI cpuidle driver has ente
On Tue, Jan 17, 2023 at 11:26:29AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote:
>
> > I'm sorry to have to bear some bad news on that front. :(
>
> Moo, something had to give..
>
>
> > IIUC what's happenign here is the PSCI cpuidle driver has ente
On Tue, Jan 17, 2023 at 01:16:21PM +, Mark Rutland wrote:
> On Tue, Jan 17, 2023 at 11:26:29AM +0100, Peter Zijlstra wrote:
> > On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote:
> >
> > > I'm sorry to have to bear some bad news on that front. :(
> >
> > Moo, something had to give.
On Tue, Jan 17, 2023 at 02:21:40PM +, Sudeep Holla wrote:
> On Tue, Jan 17, 2023 at 01:16:21PM +, Mark Rutland wrote:
> > On Tue, Jan 17, 2023 at 11:26:29AM +0100, Peter Zijlstra wrote:
> > > On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote:
> > >
> > > > I'm sorry to have to b
On Tue, Jan 17, 2023 at 10:03 AM Jann Horn wrote:
>
> +locking maintainers
Thanks! I'll CC the locking maintainers in the next posting.
>
> On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > instead of mmap_loc
Le 17/01/2023 à 10:06, ye.xingc...@zte.com.cn a écrit :
From: ye xingchen
Instead of using dma_alloc_coherent() and memset() directly use
dma_zalloc_coherent().
Hi,
dma_zalloc_coherent() has been removed at the very beginning of 2019 in
commit dfd32cad146e.
It is not existing since v5.0-
On Tue, Jan 17, 2023 at 10:28 PM Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 10:03 AM Jann Horn wrote:
> >
> > +locking maintainers
>
> Thanks! I'll CC the locking maintainers in the next posting.
>
> >
> > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > > Introduce a per-VM
On Tue, Jan 17, 2023 at 01:21:47PM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:12 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> > > On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > > > Introduce a per-VMA rw_semaphore to be used during page
On Tue, Jan 17, 2023 at 1:54 PM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 01:21:47PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:12 AM Michal Hocko wrote:
> > >
> > > On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> > > > On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrot
On Tue, Jan 17, 2023 at 1:46 PM Jann Horn wrote:
>
> On Tue, Jan 17, 2023 at 10:28 PM Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 10:03 AM Jann Horn wrote:
> > >
> > > +locking maintainers
> >
> > Thanks! I'll CC the locking maintainers in the next posting.
> >
> > >
> > > On Mon, Jan
On Tue, Jan 17, 2023 at 02:36:47PM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 1:46 PM Jann Horn wrote:
> > On Tue, Jan 17, 2023 at 10:28 PM Suren Baghdasaryan
> > wrote:
> > > On Tue, Jan 17, 2023 at 10:03 AM Jann Horn wrote:
> > > > One thing that might be gnarly here is that I
* Jann Horn [230117 16:04]:
> On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> > page fault handling. When VMA is not found, can't be locked or changes
> > after being locked, the function returns NULL. The lookup
On Tue, Jan 17, 2023 at 7:47 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote:
> > Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> > page fault handling. When VMA is not found, can't be locked or changes
> > after being locked, the function retu
On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > call_rcu() can take a long time when callback offloading is enabled.
> > Its use in the vm_area_free can cause regressions in the exit path when
> > multiple VMAs are being freed.
>
> Wh
On Tue, Jan 17, 2023 at 7:42 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Mon 09-01-23 12:53:21, Suren Baghdasaryan wrote:
> > Assert there are no holders of VMA lock for reading when it is about to be
> > destroyed.
> >
> > Signed-off-by: Suren Baghdasaryan
> > ---
> > include/linux/mm.h | 8
On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> > Move VMA flag modification (which now implies VMA locking) before
> > anon_vma_lock_write to match the locking order of page fault handler.
>
> Does this changelog assumes per vma lockin
On Tue, Jan 17, 2023 at 7:15 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Tue 17-01-23 16:09:03, Michal Hocko wrote:
> > On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote:
> > > To keep vma locking correctness when vm_flags are modified, add modifier
> > > functions to be used whenever flags a
On Tue, Jan 17, 2023 at 6:25 AM Michal Hocko wrote:
>
> On Mon 09-01-23 12:53:04, Suren Baghdasaryan wrote:
> [...]
> > void vm_area_free(struct vm_area_struct *vma)
> > {
> > free_anon_vma_name(vma);
> > +#ifdef CONFIG_PER_VMA_LOCK
> > + call_rcu(&vma->vm_rcu, __vm_area_free);
> > +#e
On Tue, Jan 17, 2023 at 05:06:57PM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:47 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote:
> > > Introduce lock_vma_under_rcu function to lookup and lock a VMA during
> > > page fault handling. When VMA is n
Hi Herbert,
On Tue, 17 Jan 2023 15:26:24 +0800 Herbert Xu
wrote:
>
> On Tue, Jan 17, 2023 at 02:47:47PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the crypto tree, today's linux-next build (powerpc
> > pseries_le_defconfig) failed like this:
> >
> > arch/powerpc/crypto/p1
Add a function dt_find_by_name_substr() that returns the child node if
it matches till first occurence at "@" of a given name, otherwise NULL.
This is helpful for cases with node name like: "name@addr". In
scenarios where nodes are added with "name@addr" format and if the
value of "addr" is not kno
The nest IMC (In Memory Collection) Performance Monitoring
Unit(PMU) node names are saved in nest_pmus[] array in the
"hw/imc.c" IMC code. Not all the IMC PMUs listed in the device
tree may be available. Nest IMC PMU names along with their
bit values is represented in imc availability vector.
The n
The nest IMC (In Memory Collection) Performance Monitoring
Unit(PMU) node names are saved as "struct nest_pmus_struct"
in the "hw/imc.c" IMC code. Not all the IMC PMUs listed in
the device tree may be available. Nest IMC PMU names along with
their bit values is represented in imc availability vecto
When it saves the branch stack to the perf sample data, it needs to
update the sample flags and the dynamic size. To make sure this,
add the perf_sample_save_brstack() helper and convert all call sites.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x...@kernel.org
Suggested-by: Peter Zijlstra
Acked-by:
From: Russell Currey
The secvar format string and object size sysfs files are both ASCII
text, and should use sysfs_emit(). No functional change.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
v2: New patch (gregkh)
---
arch/powerpc/kern
From: Michael Ellerman
There's no reason for secvar_operations to use uint64_t vs the more
common kernel type u64.
The types are compatible, but they require different printk format
strings which can lead to confusion.
Change all the secvar related routines to use u64.
Signed-off-by: Michael E
From: Russell Currey
The secvar code only supports one consumer at a time.
Multiple consumers aren't possible at this point in time, but we'd want
it to be obvious if it ever could happen.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
arch/powerpc/kernel/secvar-ops.c | 4
This series exposes an interface to userspace for reading and writing
secure variables contained within the PowerVM LPAR Platform KeyStore
(PLPKS) for the purpose of configuring dynamic secure boot, and adds
the glue required to load keys from the PLPKS into the platform keyring.
This series build
From: Russell Currey
The code that handles the format string in secvar-sysfs.c is entirely
OPAL specific, so create a new "format" op in secvar_operations to make
the secvar code more generic. No functional change.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
v2: Use sy
Remove unnecessary prefixes from error messages in secvar_sysfs_init()
(the file defines pr_fmt, so putting "secvar:" in every message is
unnecessary). Make capitalisation and punctuation more consistent.
Signed-off-by: Andrew Donnellan
Signed-off-by: Russell Currey
---
v3: New patch (ajd)
---
plpks_confirm_object_flushed() uses the H_PKS_CONFIRM_OBJECT_FLUSHED hcall
to check whether changes to an object in the Platform KeyStore have been
flushed to non-volatile storage.
The hcall returns two output values, the return code and the flush status.
plpks_confirm_object_flushed() polls the h
From: Russell Currey
Move plpks.h from platforms/pseries/ to include/asm/. This is necessary
for later patches to make use of the PLPKS from code in other subsystems.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
v3: New patch
---
.../powerpc/{platforms/pseries => includ
Currently, the list of variables is populated by calling
secvar_ops->get_next() repeatedly, which is explicitly modelled on the
OPAL API (including the keylen parameter).
For the upcoming PLPKS backend, we have a static list of variable names.
It is messy to fit that into get_next(), so instead, l
Due to sysfs constraints, when writing to a variable, we can only handle
writes of up to PAGE_SIZE.
It's possible that the maximum object size is larger than PAGE_SIZE, in
which case, print a warning on boot so that the user is aware.
Signed-off-by: Andrew Donnellan
Signed-off-by: Russell Currey
If attempting to read the size or data attributes of a non-existent
variable (which will be possible after a later patch to expose the PLPKS
via the secvar interface), don't spam the kernel log with error messages.
Only print errors for return codes that aren't ENOENT.
Reported-by: Sudhakar Kuppu
From: Russell Currey
Currently the max object size is handled in the core secvar code with an
entirely OPAL-specific implementation, so create a new max_size() op and
move the existing implementation into the powernv platform. Should be
no functional change.
Signed-off-by: Russell Currey
Signe
From: Russell Currey
Move the constants defined in plpks.c to plpks.h, and standardise their
naming, so that PLPKS consumers can make use of them later on.
Signed-off-by: Russell Currey
Co-developed-by: Andrew Donnellan
Signed-off-by: Andrew Donnellan
---
v3: New patch
---
arch/powerpc/inc
From: Russell Currey
The plpks code converts hypervisor return codes into their Linux
equivalents so that users can understand them. Having access to the
original return codes is really useful for debugging, so add a
pr_debug() so we don't lose information from the conversion.
Signed-off-by: Ru
1 - 100 of 112 matches
Mail list logo
