On Wed, Jan 18, 2023 at 4:23 AM Lucas De Marchi
wrote:
>
> 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,
From: Russell Currey
Before interacting with the PLPKS, we ask the hypervisor to generate a
password for the current boot, which is then required for most further
PLPKS operations.
If we kexec into a new kernel, the new kernel will try and fail to
generate a new password, as the password has
From: Russell Currey
The forthcoming pseries consumer of the secvar API wants to expose a
number of config variables. Allowing secvar implementations to provide
their own sysfs attributes makes it easy for consumers to expose what
they need to.
This is not being used by the OPAL secvar
From: Russell Currey
A few improvements to load_powerpc.c:
- include integrity.h for the pr_fmt()
- move all error reporting out of get_cert_list()
- use ERR_PTR() to better preserve error detail
- don't use pr_err() for missing keys
Signed-off-by: Russell Currey
Signed-off-by: Andrew
From: Nayna Jain
The Platform Keystore provides a signed update interface which can be used
to create, replace or append to certain variables in the PKS in a secure
fashion, with the hypervisor requiring that the update be signed using the
Platform Key.
Implement an interface to the
From: Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant variables for pseries dynamic secure boot through the
From: Russell Currey
Add helper functions to get the PLPKS password. This will be used in a
later patch to support passing the password between kernels over kexec.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
v3: New patch
---
arch/powerpc/include/asm/plpks.h |
From: Russell Currey
The secvar object format is only in the device tree under powernv.
We now have an API call to retrieve it in a generic way, so we should
use that instead of having to handle the DT here.
Add support for pseries secvar, with the "ibm,plpks-sb-v1" format.
The object format is
From: Nayna Jain
The plpks driver uses the H_PKS_GET_CONFIG hcall to retrieve configuration
and status information about the PKS from the hypervisor.
Update _plpks_get_config() to handle some additional fields. Add getter
functions to allow the PKS configuration information to be accessed from
Currently, plpks_read_var() allocates a buffer to pass to the
H_PKS_READ_OBJECT hcall, then allocates another buffer, of the caller's
preferred size if necessary, into which the data is copied, and returns
that buffer to the caller.
This is a bit over the top - while we probably still want to
A number of structures and buffers passed to PKS hcalls have alignment
requirements, which could on occasion cause problems:
- Authorisation structures must be 16-byte aligned and must not cross a
page boundary
- Label structures must not cross page coundaries
- Password output buffers must
It seems a bit unnecessary for the PLPKS code to have a user-visible
config option when it doesn't do anything on its own, and there's existing
options for enabling Secure Boot-related features.
It should be enabled by PPC_SECURE_BOOT, which will eventually be what
uses PLPKS to populate
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:
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
---
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
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
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
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,
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 =>
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
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)
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
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
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
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
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)
---
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:
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
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
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
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:
> >
> >
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
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(>vm_rcu, __vm_area_free);
> > +#else
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
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
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 |
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.
>
>
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
* 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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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: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
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
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
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
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 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
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,
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:
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 {
> >-
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
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
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: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
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
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
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
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
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
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
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: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
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
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:
[...]
>
+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
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];
> >
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
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,
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
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:
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
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;
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,
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
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
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: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
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 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
> > ---
> >
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
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 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: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
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 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 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(>vm_rcu, __vm_area_free);
> +#else
> kmem_cache_free(vm_area_cachep, vma);
> +#endif
Is it safe to
1 - 100 of 112 matches
Mail list logo
