Modify __down_read_trylock() to make it generate slightly better code
(smaller and maybe a tiny bit faster).
Before this patch, down_read_trylock:
0x <+0>: callq 0x5
0x0005 <+5>: jmp0x18
0x0007 <+7>: lea0x1(%rdx),%rcx
On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote:
What LTSI's are these patches likely to end up in? Just to be clear,
I'm not pushing for any specific answer, I just want to know what to
expect.
Thanks,
Alan
>
> On 11/8/18 10:56 PM, Frank Rowand wrote:
> > Hi Rob,
> >
> > Please pull the
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
On Mon, Feb 11, 2019 at 11:35:24AM -0500, Waiman Long wrote:
> On 02/11/2019 06:58 AM, Peter Zijlstra wrote:
> > Which is clearly worse. Now we can write that as:
> >
> > int __down_read_trylock2(unsigned long *l)
> > {
> > long tmp = READ_ONCE(*l);
> >
> > while (tmp >= 0) {
> >
v2:
- Add patch 2 to optimize __down_read_trylock() as suggested by PeterZ.
- Update performance test data in patch 1.
This is part 0 of my rwsem patchset. It just removes the architecture
specific files to make it easer to add enhancements in the upcoming
rwsem patches.
Since the two ll/sc
On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote:
> On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote:
>
> What LTSI's are these patches likely to end up in? Just to be clear,
> I'm not pushing for any specific answer, I just want to know what to
> expect.
I have no idea what you are
On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote:
> > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote:
> >
> > What LTSI's are these patches likely to end up in? Just to be clear,
> > I'm not pushing for any specific
On 11/02/2019 00:30, Benjamin Herrenschmidt wrote:
> On Fri, 2019-02-08 at 14:51 +, Mark Cave-Ayland wrote:
>>
>> Indeed, but there are still some questions to be asked here:
>>
>> 1) Why were these bits removed from the original bitmask in the first place
>> without
>> it being documented
Hi,
This series converts users that account pinned pages with locked_vm to
account with pinned_vm instead, pinned_vm being the correct counter to
use. It's based on a similar patch I posted recently[0].
The patches are based on rdma/for-next to build on Davidlohr Bueso's
recent conversion of
PowerPC experts,
Paul Moore and I are working on the v2.4 release of libseccomp,
and as part of this work I need to update the syscall table for
each architecture.
I have incorporated the new ppc syscall.tbl into libseccomp, but
I am not familiar with the value of "spu" in the ABI column. For
Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
pages"), locked and pinned pages are accounted separately. The FPGA AFU
driver accounts pinned pages to locked_vm; use pinned_vm instead.
pinned_vm recently became atomic and so no longer relies on mmap_sem
held as writer:
On Mon, Feb 11, 2019 at 03:54:47PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 05:44:32PM -0500, Daniel Jordan wrote:
> > Hi,
> >
> > This series converts users that account pinned pages with locked_vm to
> > account with pinned_vm instead, pinned_vm being the correct counter to
> >
Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
pages"), locked and pinned pages are accounted separately. The SPAPR
TCE VFIO IOMMU driver accounts pinned pages to locked_vm; use pinned_vm
instead.
pinned_vm recently became atomic and so no longer relies on mmap_sem
held
Memory used for TCE tables in kvm_vm_ioctl_create_spapr_tce is currently
accounted to locked_vm because it stays resident and its allocation is
directly triggered from userspace as explained in f8626985c7c2 ("KVM:
PPC: Account TCE-containing pages in locked_vm").
However, since the memory comes
Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
pages"), locked and pinned pages are accounted separately. Type1
accounts pinned pages to locked_vm; use pinned_vm instead.
pinned_vm recently became atomic and so no longer relies on mmap_sem
held as writer: delete.
On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> > @@ -266,24 +267,15 @@ static int vfio_lock_acct(struct vfio_dma *dma, long
> > npage, bool async)
> > if (!mm)
> > return -ESRCH; /* process exited
Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
pages"), locked and pinned pages are accounted separately. The IOMMU
MMU helpers on powerpc account pinned pages to locked_vm; use pinned_vm
instead.
pinned_vm recently became atomic and so no longer relies on mmap_sem
held
On Mon, Feb 11, 2019 at 05:44:32PM -0500, Daniel Jordan wrote:
> Hi,
>
> This series converts users that account pinned pages with locked_vm to
> account with pinned_vm instead, pinned_vm being the correct counter to
> use. It's based on a similar patch I posted recently[0].
>
> The patches are
On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> pages"), locked and pinned pages are accounted separately. Type1
> accounts pinned pages to locked_vm; use pinned_vm instead.
>
> pinned_vm recently became
On Mon, 11 Feb 2019 12:37:12 +0100
Thomas Huth wrote:
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>
> So to get the keyboard working in the graphical
On Mon, 11 Feb 2019 at 22:07, Thomas Huth wrote:
>
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
"recent" :D
> So to get the keyboard working in the
The SPAPR TCE KVM device references all hardware IOMMU tables assigned to
some IOMMU group to ensure that in-kernel KVM acceleration of H_PUT_TCE
can work. The tables are references when an IOMMU group gets registered
with the VFIO KVM device by the KVM_DEV_VFIO_GROUP_ADD ioctl;
Andrey Ryabinin writes:
> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>> wrote:
>>>
>>> Hi Andrey,
>>>
>>> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy
wrote:
>
> Hi
On Mon, Feb 11, 2019 at 06:48:01PM +1100, Alexey Kardashevskiy wrote:
> We store 2 multilevel tables in iommu_table - one for the hardware and
> one with the corresponding userspace addresses. Before allocating
> the tables, the iommu_table_group_ops::get_table_size() hook returns
> the combined
Hi Christoph,
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote:
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
>
On Mon, Feb 11, 2019 at 06:49:17PM +1100, Alexey Kardashevskiy wrote:
> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
> a container, we need to unset those from a group so we call unset_window()
> so do we unconditionally. We also unset tables when removing a DMA window
>
Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api
only on Hotplug", 2017-07-21) added two calls to opal_slw_set_reg()
inside pnv_cpu_offline(), with the aim of changing the LPCR value in
the SLW image to disable wakeups from the decrementer while a CPU is
offline. However,
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp,
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp,
Hi Tom,
Sorry this has caused you trouble, using "spu" there is a bit of a hack
and I want to remove it.
See: https://patchwork.ozlabs.org/patch/1025830/
Unfortunately that series clashed with some of Arnd's work and I haven't
got around to rebasing it.
Tom Hromatka writes:
> PowerPC experts,
On 12/02/2019 09:44, Daniel Jordan wrote:
> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> pages"), locked and pinned pages are accounted separately. The SPAPR
> TCE VFIO IOMMU driver accounts pinned pages to locked_vm; use pinned_vm
> instead.
>
> pinned_vm
On 12/02/2019 11:20, David Gibson wrote:
> On Mon, Feb 11, 2019 at 06:48:01PM +1100, Alexey Kardashevskiy wrote:
>> We store 2 multilevel tables in iommu_table - one for the hardware and
>> one with the corresponding userspace addresses. Before allocating
>> the tables, the
On Mon, Feb 11, 2019 at 02:35:49PM +0100, Christoph Hellwig wrote:
> This is where all the related code already lives.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/base/Kconfig | 77
> kernel/dma/Kconfig | 77
On Mon, Feb 11, 2019 at 02:35:51PM +0100, Christoph Hellwig wrote:
> All users of dma_declare_coherent want their allocations to be
> exclusive, so default to exclusive allocations.
>
> Signed-off-by: Christoph Hellwig
> ---
> Documentation/DMA-API.txt | 9 +--
>
On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote:
> No need to carry an unused field around.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/device.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Greg Kroah-Hartman
On Mon, Feb 11, 2019 at 02:43:48PM -0600, Alan Tull wrote:
> On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote:
> > > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand
> > > wrote:
> > >
> > > What LTSI's are these patches
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote:
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users. Also
On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
> index bad2bca..067e265 100644
> --- a/kernel/locking/rwsem.h
> +++ b/kernel/locking/rwsem.h
> @@ -32,6 +32,26 @@
> # define DEBUG_RWSEMS_WARN_ON(c)
> #endif
>
> +/*
> +
On Mon, 2019-02-11 at 07:26 +0100, Christophe Leroy wrote:
>
> Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> > On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> > > /*
> > > + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> > > + */
> > > +.macro
On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > +{
> > + long tmp;
> > +
> > + while ((tmp = atomic_long_read(>count)) >= 0) {
> > +
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ]
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ]
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which means
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ]
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 427c5ce4417cba0801fbf79c8525d1330704759c ]
As of v4.20, the swim3 driver crashes when loaded on a PowerBook G3
(Wallstreet).
MacIO PCI driver attached to Gatwick chipset
MacIO PCI
On Mon 2019-02-11 13:50:35, Andrea Parri wrote:
> Hi Michael,
>
>
> On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote:
> > Arch code can set a "dump stack arch description string" which is
> > displayed with oops output to describe the hardware platform.
> >
> > It is useful to
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ]
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which
On Mon 11-02-19 14:49:09, Ingo Molnar wrote:
>
> * Michal Hocko wrote:
>
> > On Thu 24-01-19 11:10:50, Dave Hansen wrote:
> > > On 1/24/19 6:17 AM, Michal Hocko wrote:
> > > > and nr_cpus set to 4. The underlying reason is tha the device is bound
> > > > to node 2 which doesn't have any memory
On 11/02/19 6:30 AM, Daniel Axtens wrote:
> Hi Sandipan,
>
>> +{
>> +.descr = "RA = LONG_MIN | INT_MIN, RB =
>> LONG_MIN | INT_MIN",
>> +.instr = PPC_INST_ADDC | ___PPC_RT(20) |
>> ___PPC_RA(21) | ___PPC_RB(22),
>> +
* Ingo Molnar wrote:
> Sounds good to me - I've merged this patch, will push it out after
> testing.
Based on Peter's feedback I'm delaying this - performance testing on at
least one key ll/sc arch would be nice indeed.
Thanks,
Ingo
* Will Deacon wrote:
> On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> > > Sounds good to me - I've merged this patch, will push it out after
> > > testing.
> >
> > Based on Peter's feedback I'm delaying this - performance testing on at
> >
Recent versions of QEMU provide a XHCI device by default these
days instead of an old-fashioned OHCI device:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
So to get the keyboard working in the graphical console there again,
we should now include XHCI support in the kernel
This change helps me to get multiple mtd device registered. Without this
I get
sysfs: cannot create duplicate filename '/bus/nvmem/devices/flash0'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2-00557-g1ef20ef21f22 #13
Call Trace:
[c000b38e3220] [c0b58fe4] dump_stack+0xe8/0x164
On 2/11/19 4:46 PM, Boris Brezillon wrote:
On Mon, 11 Feb 2019 16:26:38 +0530
"Aneesh Kumar K.V" wrote:
On 2/10/19 6:25 PM, Boris Brezillon wrote:
Hello Aneesh,
On Fri, 8 Feb 2019 20:44:18 +0530
"Aneesh Kumar K.V" wrote:
With this patch, we use the mtd->name instead of concatenating
Hi all,
this series removes various bits of dead code and refactors the
remaining functionality around dma_declare_coherent to be a somewhat
more coherent code base.
Currently the sm501 mfd driver can be compiled without any dependencies,
but through the use of dma_declare_coherent it really depends on
having DMA and iomem support. Normally we don't explicitly require DMA
support as we have stubs for it if on UML, but in this case the driver
selects support
No need to carry an unused field around.
Signed-off-by: Christoph Hellwig
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..be544400acdd 100644
--- a/include/linux/device.h
+++
This function is only used in of_reserved_mem.c, and never overridden
despite the __weak marker.
Signed-off-by: Christoph Hellwig
---
drivers/of/of_reserved_mem.c| 2 +-
include/linux/of_reserved_mem.h | 7 ---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git
The OF_RESERVED_MEM can be used if we have either CMA or the generic
declare coherent code built and we support the early flattened DT.
So don't bother making it a user visible options that is selected
by most configs that fit the above category, but just select it when
the requirements are met.
memmap return a regular void pointer, not and __iomem one.
Signed-off-by: Christoph Hellwig
---
kernel/dma/coherent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 66f0fb7e9a3a..4b76aba574c2 100644
---
This API is primarily used through DT entries, but two architectures
and two drivers call it directly. So instead of selecting the config
symbol for random architectures pull it in implicitly for the actual
users. Also rename the Kconfig option to describe the feature better.
Signed-off-by:
This is where all the related code already lives.
Signed-off-by: Christoph Hellwig
---
drivers/base/Kconfig | 77
kernel/dma/Kconfig | 77
2 files changed, 77 insertions(+), 77 deletions(-)
diff --git
This API is not used anywhere, so remove it.
Signed-off-by: Christoph Hellwig
---
Documentation/DMA-API.txt | 17 -
include/linux/dma-mapping.h | 9 -
kernel/dma/coherent.c | 23 ---
3 files changed, 49 deletions(-)
diff --git
All users of dma_declare_coherent want their allocations to be
exclusive, so default to exclusive allocations.
Signed-off-by: Christoph Hellwig
---
Documentation/DMA-API.txt | 9 +--
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 12 +++--
We handle allocation and freeing in common code, so we should handle
mmap the same way. Also all users of per-device coherent memory are
exclusive, that is if we can't allocate from the per-device pool we
can't use the system memory either. Unfold the current
dma_mmap_from_dev_coherent
The only useful bit in this function was the already assigned check.
Once that is moved to dma_init_coherent_memory thee rest can easily
be handled in the two callers.
Signed-off-by: Christoph Hellwig
---
kernel/dma/coherent.c | 47 +--
1 file changed, 14
All users of per-device coherent memory are exclusive, that is if we can't
allocate from the per-device pool we can't use the system memory either.
Unfold the current dma_{alloc,free}_from_dev_coherent implementation and
always use the per-device pool if it exists.
Signed-off-by: Christoph
* Michal Hocko wrote:
> On Thu 24-01-19 11:10:50, Dave Hansen wrote:
> > On 1/24/19 6:17 AM, Michal Hocko wrote:
> > > and nr_cpus set to 4. The underlying reason is tha the device is bound
> > > to node 2 which doesn't have any memory and init_cpu_to_node only
> > > initializes memory-less
With this patch, we use the mtd->name instead of concatenating the name with '0'
Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem
API")
Signed-off-by: Aneesh Kumar K.V
---
drivers/mtd/mtdcore.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Michael,
On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote:
> Arch code can set a "dump stack arch description string" which is
> displayed with oops output to describe the hardware platform.
>
> It is useful to initialise this as early as possible, so that an early
> oops
On 02/11/2019 05:39 AM, Ingo Molnar wrote:
> * Ingo Molnar wrote:
>
>> Sounds good to me - I've merged this patch, will push it out after
>> testing.
> Based on Peter's feedback I'm delaying this - performance testing on at
> least one key ll/sc arch would be nice indeed.
>
> Thanks,
>
>
On 11/02/19 6:17 AM, Daniel Axtens wrote:
> Hi Sandipan,
>
> I'm not really confident to review the asm, but I did have a couple of
> questions about the C:
>
>> +#define MAX_INSNS 32
> This doesn't seem to be used...
>
True. Thanks for pointing this out.
>> +int execute_instr(struct
On Mon, Feb 11, 2019 at 10:40:44AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > > +{
> > > + long tmp;
> > >
On Mon, 11 Feb 2019 16:26:38 +0530
"Aneesh Kumar K.V" wrote:
> On 2/10/19 6:25 PM, Boris Brezillon wrote:
> > Hello Aneesh,
> >
> > On Fri, 8 Feb 2019 20:44:18 +0530
> > "Aneesh Kumar K.V" wrote:
> >
> >> With this patch, we use the mtd->name instead of concatenating the name
> >> with
On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > Sounds good to me - I've merged this patch, will push it out after
> > testing.
>
> Based on Peter's feedback I'm delaying this - performance testing on at
> least one key ll/sc arch would be nice
On 2/10/19 6:25 PM, Boris Brezillon wrote:
Hello Aneesh,
On Fri, 8 Feb 2019 20:44:18 +0530
"Aneesh Kumar K.V" wrote:
With this patch, we use the mtd->name instead of concatenating the name with '0'
Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem
API")
On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> +static inline int __down_read_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + while ((tmp = atomic_long_read(>count)) >= 0) {
> + if (tmp == atomic_long_cmpxchg_acquire(>count, tmp,
> +
Em Sat, Feb 09, 2019 at 01:14:25PM -0500, Paul Clarke escreveu:
> [Note this is for POWER*9* and is different content than a
> previous patchset for POWER*8*.]
>
> The patches define metrics and metric groups for computation by "perf"
> for POWER9 processors.
Applied, thanks.
- Arnaldo
On 2/11/19 3:25 PM, Andrey Konovalov wrote:
> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
> wrote:
>>
>> Hi Andrey,
>>
>> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
>>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy
>>> wrote:
Hi Daniel,
Le 08/02/2019 à
On 02/11/2019 06:58 AM, Peter Zijlstra wrote:
> Which is clearly worse. Now we can write that as:
>
> int __down_read_trylock2(unsigned long *l)
> {
> long tmp = READ_ONCE(*l);
>
> while (tmp >= 0) {
> if (try_cmpxchg(l, , tmp + 1))
>
The manpage is missing information about the compatibility hack for
5-level paging that went in in 4.14, around commit ee00f4a32a76 ("x86/mm:
Allow userspace have mappings above 47-bit"). Add some information about
that.
While I don't think any hardware supporting this is shipping yet (?), I
80 matches
Mail list logo
