On Fri, 2024-11-01 at 12:30 +, Mark Brown wrote:
> > Where can I find this base commit?
>
> Ah, that's still my branch from when I posted what's now applied in the
> arm64 tree, this is the same code:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-
> next/gcs
>
>
On Thu, Oct 31, 2024 at 09:06:09PM +, Edgecombe, Rick P wrote:
> On Thu, 2024-10-31 at 19:25 +, Mark Brown wrote:
> > base-commit: d17cd7b7cc92d37ee8b2df8f975fc859a261f4dc
> Where can I find this base commit?
Ah, that's still my branch from when I posted what's now applied in the
arm64 t
Unlike with the normal stack there is no API for configuring the the shadow
stack for a new thread, instead the kernel will dynamically allocate a new
shadow stack with the same size as the normal stack. This appears to be due
to the shadow stack series having been in development since before the m
On Thu, 2024-10-31 at 19:25 +, Mark Brown wrote:
> ---
> base-commit: d17cd7b7cc92d37ee8b2df8f975fc859a261f4dc
Where can I find this base commit?
> change-id: 20231019-clone3-shadow-stack-15d40d2bf536
ts: Provide helper header for shadow stack testing
fork: Add shadow stack support to clone3()
selftests/clone3: Remove redundant flushes of output streams
selftests/clone3: Factor more of main loop into test_clone3()
selftests/clone3: Allow tests to flag if -E2BIG is a val
On Wed, Oct 30, 2024 at 02:08:59PM +, Mark Brown wrote:
> On Sat, Oct 05, 2024 at 11:31:27AM +0100, Mark Brown wrote:
> > The kernel has recently added support for shadow stacks, currently
> > x86 only using their CET feature but both arm64 and RISC-V have
> > equivalent features (GCS and Zicfi
On Sat, Oct 05, 2024 at 11:31:27AM +0100, Mark Brown wrote:
> The kernel has recently added support for shadow stacks, currently
> x86 only using their CET feature but both arm64 and RISC-V have
> equivalent features (GCS and Zicfiss respectively), I am actively
> working on GCS[1]. With shadow st
This reverts commit e142cc87ac4ec618f2ccf5f68aedcd6e28a59d9d.
fork_event_consumer may be called by other tests that do not initialize
the pthread_barrier, so this approach is not correct. The subsequent
patch will revert to using atomic_bool instead.
Fixes: e142cc87ac4e ("fix deadlock for
ate(&thread, NULL, fork_event_consumer, &args))
err("pthread_create()");
+ while (!ready_for_fork)
+ ; /* Wait for the poll_thread to start executing before
forking */
}
child = fork();
--
2.47.0.105.g07ac214952-goog
Unlike with the normal stack there is no API for configuring the the shadow
stack for a new thread, instead the kernel will dynamically allocate a new
shadow stack with the same size as the normal stack. This appears to be due
to the shadow stack series having been in development since before the m
Documentation: userspace-api: Add shadow stack API documentation
selftests: Provide helper header for shadow stack testing
fork: Add shadow stack support to clone3()
selftests/clone3: Remove redundant flushes of output streams
selftests/clone3: Factor more
tatic void *fork_event_consumer(void *data)
fork_event_args *args = data;
struct uffd_msg msg = { 0 };
+ /* Ready for parent thread to fork */
+ pthread_barrier_wait(&ready_for_fork);
+
/* Read until a full msg received */
while (uffd_read_msg(args->
On Tue, Oct 01, 2024 at 05:12:38PM +0200, Christian Brauner wrote:
> > Thanks for the info!
> >
> > >
> > > My preference is to keep the api consistent and require a stack_size for
> > > shadow stacks as well.
> >
> > Did you catch that a token can be at a different offsets location on the
> >
On Wed, 2024-10-02 at 22:01 +0100, Mark Brown wrote:
> BTW it's probably also worth noting that at least on arm64 (perhaps x86
> is different here?) the shadow stack of a thread that exited won't have
> a token placed on it so it won't be possible to use it with clone3() at
> all unless another tok
On Wed, Oct 02, 2024 at 02:42:58PM +0100, Mark Brown wrote:
> On Tue, Oct 01, 2024 at 11:03:10PM +, Edgecombe, Rick P wrote:
> > I'm not so sure. The thing is a regular stack can be re-used in full - just
> > set
> > the RSP to the end and take advantage of the whole stack. A shadow stack can
On Tue, Oct 01, 2024 at 11:03:10PM +, Edgecombe, Rick P wrote:
> On Tue, 2024-10-01 at 18:33 +0100, Mark Brown wrote:
> > My suspicion would be that if we're doing the pivot to a previously used
> > shadow stack we'd also be pivoting the regular stack along with it which
> > would face similar
On Tue, 2024-10-01 at 18:33 +0100, Mark Brown wrote:
> > > A shadow stack size is more symmetric on the surface, but I'm not sure it
> > > will
> > > be easier for userspace to handle. So I think we should just have a
> > > pointer to
> > > the token. But it will be a usable implementation either w
On Tue, Oct 01, 2024 at 05:12:38PM +0200, Christian Brauner wrote:
> On Fri, Sep 27, 2024 at 03:21:59PM GMT, Edgecombe, Rick P wrote:
> > Did you catch that a token can be at a different offsets location on the
> > stack
> > depending on args passed to map_shadow_stack? So userspace will need
>
On Fri, Sep 27, 2024 at 03:21:59PM GMT, Edgecombe, Rick P wrote:
> On Fri, 2024-09-27 at 10:50 +0200, Christian Brauner wrote:
> > The legacy clone system call had required userspace to know in which
> > direction the stack was growing and then pass down the stack pointer
> > appropriately (e.g., p
On Fri, 2024-09-27 at 10:50 +0200, Christian Brauner wrote:
> The legacy clone system call had required userspace to know in which
> direction the stack was growing and then pass down the stack pointer
> appropriately (e.g., parisc grows upwards).
>
> And in fact, the old clone() system call did t
On Wed, Aug 21, 2024 at 06:23:18PM GMT, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 03:54:49PM +, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
>
> > > It's entirely possible it just leaked. My own attempts to dig through
> > > the archives haven't turned u
On Wed, Apr 7, 2021 at 12:23 PM Linus Torvalds
wrote:
>
> On Wed, Apr 7, 2021 at 11:47 AM Mikulas Patocka wrote:
> >
> > So, we fixed it, but we don't know why.
> >
> > Peter Xu's patchset that fixed it is here:
> > https://lore.kernel.org/lkml/20200821234958.7896-1-pet...@redhat.com/
>
> Yeah, t
On Wed, Apr 7, 2021 at 11:47 AM Mikulas Patocka wrote:
>
> So, we fixed it, but we don't know why.
>
> Peter Xu's patchset that fixed it is here:
> https://lore.kernel.org/lkml/20200821234958.7896-1-pet...@redhat.com/
Yeah, that's the part that ends up being really painful to backport
(with all t
On Wed, 7 Apr 2021, Linus Torvalds wrote:
> On Wed, Apr 7, 2021 at 9:33 AM Suren Baghdasaryan wrote:
> >
> > Trying my hand at backporting the patchsets Peter mentioned proved
> > this to be far from easy with many dependencies. Let me look into
> > Vlastimil's suggestion to backport only 1783
On Wed, Apr 7, 2021 at 9:33 AM Suren Baghdasaryan wrote:
>
> Trying my hand at backporting the patchsets Peter mentioned proved
> this to be far from easy with many dependencies. Let me look into
> Vlastimil's suggestion to backport only 17839856fd58 and it sounds
> like 5.4 already followed that
On Wed, Apr 7, 2021 at 9:07 AM Linus Torvalds
wrote:
>
> On Wed, Apr 7, 2021 at 6:22 AM Vlastimil Babka wrote:
> >
> > 1) Ignore the issue (outside of Android at least). The security model of
> > zygote
> > is unusual. Where else a parent of fork() doesn't
On Wed, Apr 7, 2021 at 6:22 AM Vlastimil Babka wrote:
>
> 1) Ignore the issue (outside of Android at least). The security model of
> zygote
> is unusual. Where else a parent of fork() doesn't trust the child, which is
> the
> same binary?
Agreed. I think this is basicall
On Wed, Apr 07, 2021 at 03:21:55PM +0200, Vlastimil Babka wrote:
> 2) For backports go with the original approach of 17839856fd58 ("gup: document
> and work around "COW can break either way" issue"), thus break COW during the
> GUP. But only for vmplice() so that nothing else gets broken. I think 5
wn.net/Articles/849876/
> So NAK on this for now, I think this limited patch-set likely
> introduces more problems than it fixes.
I personally think there are only two options safe enough for stable backports
(so that not more harm is caused than actually prevented).
1) Ignore the issue (ou
Andrew Morton 于2021年3月31日周三 下午1:44写道：
>
> On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
>
> > From: jun qian
> >
> > In our project, Many business delays come from fork, so
> > we started looking for the reason why fork is time-cons
On Thu, Apr 1, 2021 at 4:47 PM Peter Xu wrote:
>
> Hi, Suren,
>
> On Thu, Apr 01, 2021 at 12:43:51PM -0700, Suren Baghdasaryan wrote:
> > On Thu, Apr 1, 2021 at 11:59 AM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > We rece
Hi, Suren,
On Thu, Apr 01, 2021 at 12:43:51PM -0700, Suren Baghdasaryan wrote:
> On Thu, Apr 1, 2021 at 11:59 AM Linus Torvalds
> wrote:
> >
> > On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan
> > wrote:
> > >
> > > We received a report that the copy-on-write issue repored by Jann Horn in
>
On Thu, Apr 1, 2021 at 11:59 AM Linus Torvalds
wrote:
>
> On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan wrote:
> >
> > We received a report that the copy-on-write issue repored by Jann Horn in
> > https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
> > reproducible on 4.1
On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan wrote:
>
> We received a report that the copy-on-write issue repored by Jann Horn in
> https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
> reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer
> coded in
We received a report that the copy-on-write issue repored by Jann Horn in
https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer
coded in vmsplice.c). I confirmed this and also that the issue was not
reprodu
We received a report that the copy-on-write issue repored by Jann Horn in
https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still
reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer
coded in vmsplice.c). I confirmed this and also that the issue was not
reprodu
On 3/31/21 2:11 PM, Vlastimil Babka wrote:
> On 3/31/21 7:44 AM, Andrew Morton wrote:
>> On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
>>
>>> From: jun qian
>>>
>>> In our project, Many business delays come from fork, so
>>
On 3/31/21 7:44 AM, Andrew Morton wrote:
> On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
>
>> From: jun qian
>>
>> In our project, Many business delays come from fork, so
>> we started looking for the reason why fork is time-consum
On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
> From: jun qian
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, f
From: jun qian
In our project, Many business delays come from fork, so
we started looking for the reason why fork is time-consuming.
I used the ftrace with function_graph to trace the fork, found
that the vm_normal_page will be called tens of thousands and
the execution time of this
From: Fenghua Yu
[ Upstream commit 82e69a121be4b1597ce758534816a8ee04c8b761 ]
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
This patch was part of the series introducing mm->pasid, but got lost
along the way [1].
From: Fenghua Yu
[ Upstream commit 82e69a121be4b1597ce758534816a8ee04c8b761 ]
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
This patch was part of the series introducing mm->pasid, but got lost
along the way [1].
It should be handled similarly like other uffd-wp wr-protected ptes: we should
pass it over when the dst_vma has VM_UFFD_WP armed, otherwise drop it.
Signed-off-by: Peter Xu
---
mm/memory.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memor
From: Fenghua Yu
[ Upstream commit 82e69a121be4b1597ce758534816a8ee04c8b761 ]
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
This patch was part of the series introducing mm->pasid, but got lost
along the way [1].
From: Fenghua Yu
[ Upstream commit 82e69a121be4b1597ce758534816a8ee04c8b761 ]
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
This patch was part of the series introducing mm->pasid, but got lost
along the way [1].
Filippo Sironi writes:
> We've seen a number of crashes with the following signature:
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> ...
> Oops: [#1] SMP PTI
>
On 3/10/21 5:37 AM, Filippo Sironi wrote:
> We've seen a number of crashes with the following signature:
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> ...
> Oops: 0
We've seen a number of crashes with the following signature:
BUG: kernel NULL pointer dereference, address:
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
...
Oops: [#1] SMP PTI
...
RIP: 0010:__rb_erase_color+
Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
On Tue, Mar 02, 2021 at 06:45:49PM -0800, Linus Torvalds wrote:
> On Tue, Mar 2, 2021 at 5:47 PM Peter Xu wrote:
> >
> > As Jason and Wei pointed out, I think some userspace still got corrupted
> > data
> > without this series when using hugetlb backend. I don't think it'll suite
> > for
> > a
On Tue, Mar 2, 2021 at 5:47 PM Peter Xu wrote:
>
> As Jason and Wei pointed out, I think some userspace still got corrupted data
> without this series when using hugetlb backend. I don't think it'll suite for
> a late RC release but it'll still be great if it can be considered as an early
> rc ca
On Mon, Mar 01, 2021 at 04:28:46PM -0800, Andrew Morton wrote:
> On Mon, 1 Mar 2021 09:11:51 -0500 Peter Xu wrote:
>
> > On Wed, Feb 17, 2021 at 06:35:42PM -0500, Peter Xu wrote:
> > > v5:
> > > - patch 4: change "int cow" into "bool cow"
> > > - collect r-bs for Jason
> >
> > Andrew,
> >
> > I
svm_list, that tells whether a
PASID is already allocated for the mm. The SMMU driver relies only on
iommu_sva_alloc_pasid() for this.
> For the fork children even mm->pasid is non-zero,
> it has no effect since it is not loaded onto MSRs.
> Perhaps you could also add a check or W
From: Fenghua Yu
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Reviewed-by: Tony Luck
Signed-off-by: Fenghua Yu
Signed-off-by: Jean-Philippe Brucker
---
This patch was part of the series introducing mm->pasid, but
; >
>
> It has taken a while to settle down. What is the case for
> fast-tracking it into 5.12?
IIRC hugetlb users and fork and DMA will get the unexpected VA
corruption that triggered all this work.
Jason
ot;
> > > - collect r-bs for Jason
> >
> > Andrew,
> >
> > I just noticed 5.12-rc1 has released; is this series still possible to make
> > it
> > for 5.12, or needs to wait for 5.13?
> >
>
> It has taken a while to settle down. What is the case f
On Mon, 1 Mar 2021 09:11:51 -0500 Peter Xu wrote:
> On Wed, Feb 17, 2021 at 06:35:42PM -0500, Peter Xu wrote:
> > v5:
> > - patch 4: change "int cow" into "bool cow"
> > - collect r-bs for Jason
>
> Andrew,
>
> I just noticed 5.12-rc1 has released; is this series still possible to make it
> for
ew mm is created.
> This patch somehow is losted:(
>
> >
> > Currently iommu_sva_alloc_pasid() assumes mm->pasid is always
> > initialized to 0 and fails on forked tasks. I'm trying to figure out
> > how to fix this. Could we clear the pasid on fork or does it
On Wed, Feb 17, 2021 at 06:35:42PM -0500, Peter Xu wrote:
> v5:
> - patch 4: change "int cow" into "bool cow"
> - collect r-bs for Jason
Andrew,
I just noticed 5.12-rc1 has released; is this series still possible to make it
for 5.12, or needs to wait for 5.13?
Thanks,
--
Peter Xu
Sorry. Drop this patch serie.
Thanks,
John Wood
On Sat, Feb 27, 2021 at 04:30:05PM +0100, John Wood wrote:
>
> This patch serie is a task of the KSPP [1] and can also be accessed from my
> github tree [2] in the "brute_v4" branch.
Sorry. The correct branch is "brute_v5".
Apologies.
John Wood
>
> [1] https://github.com/KSPP/linux/issues/39
> [2
Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
ks. I'm trying to figure out how to fix this.
> Could we clear the pasid on fork or does it break the x86 model?
x86 calls ioasid_alloc() instead of iommu_sva_alloc_pasid(). So
functionality is not a problem without this patch on x86. But I think
we do need to have this patch in the kernel
itialized
to 0 and fails on forked tasks. I'm trying to figure out how to fix this.
Could we clear the pasid on fork or does it break the x86 model?
Thanks,
Jean
>
> Signed-off-by: Fenghua Yu
> Reviewed-by: Tony Luck
> ---
> v2:
> - Add this patch to initialize PASID va
Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
o linux-next/akpm, switch to the new HPAGE helpers [MikeK]
- correct error check for alloc_huge_page(); test it this time to make sure
fork() fails gracefully when overcommit [MikeK]
- move page copy out of pgtable lock: this changed quite a bit of the logic in
the last patch, prealloc is droppe
: Paul E. McKenney
CommitterDate: Thu, 21 Jan 2021 10:06:44 -08:00
tools/nolibc: Implement fork() based on clone()
Some archs such as arm64 do not have fork() and have to use clone()
instead. This commit therefore makes fork() use clone() when
available. This requires including signal.h to
_page(); test it this time to make sure
fork() fails gracefully when overcommit [MikeK]
- move page copy out of pgtable lock: this changed quite a bit of the logic in
the last patch, prealloc is dropped since I found it easier to understand
without looping at all [MikeK]
v2:
- pass in
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
[ Upstream commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 ]
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
From: Benjamin Valentin
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https
v3:
- rebase to linux-next/akpm, switch to the new HPAGE helpers [MikeK]
- correct error check for alloc_huge_page(); test it this time to make sure
fork() fails gracefully when overcommit [MikeK]
- move page copy out of pgtable lock: this changed quite a bit of the logic in
the last patch
v2:
- pass in 1 to alloc_huge_page() last param [Mike]
- reduce comment, unify the comment in one place [Linus]
- add r-bs for Mike and Miaohe
As reported by Gal [1], we still miss the code clip to handle early cow for
hugetlb case, which is true. Again, it still feels odd to fork() after using
On 03/02/2021 23:08, Peter Xu wrote:
> As reported by Gal [1], we still miss the code clip to handle early cow for
>
> hugetlb case, which is true. Again, it still feels odd to fork() after using
> a
>
> few huge pages, especially if they're privately mapped to me..
As reported by Gal [1], we still miss the code clip to handle early cow for
hugetlb case, which is true. Again, it still feels odd to fork() after using a
few huge pages, especially if they're privately mapped to me.. However I do
agree with Gal and Jason in that we should still have that
Some archs such as arm64 do not have fork() and have to use clone()
instead so let's make fork() always use clone() when available. This
requires to include signal.h to get the definition of SIGCHLD.
[This is nolibc's upstream commit d2dc42fd6149]
Signed-off-by: Willy Tarreau
---
too
We tried to do something similar in b569a1760782 ("userfaultfd: wp: drop
_PAGE_UFFD_WP properly when fork") previously, but it's not doing it all
right.. A few fixes around the code path:
1. We were referencing VM_UFFD_WP vm_flags on the _old_ vma rather than the
n
It should be handled similarly like other uffd-wp wr-protected ptes: we should
pass it over when the dst_vma has VM_UFFD_WP armed, otherwise drop it.
Signed-off-by: Peter Xu
---
mm/memory.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memor
Huge zero page is handled in a special path in copy_huge_pmd(), however it
should share most codes with a normal thp page. Trying to share more code with
it by removing the special path. The only leftover so far is the huge zero
page refcounting (mm_get_huge_zero_page()), because that's separatel
Use the maple tree iterator to duplicate the mm_struct trees.
Signed-off-by: Liam R. Howlett
---
include/linux/sched/mm.h | 3 +++
kernel/fork.c| 22 +-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched/mm.h b/include/linux/sched
From: Jason Gunthorpe
[ Upstream commit 57efa1fe5957694fa541c9062de0a127f0b9acb0 ]
Since commit 70e806e4e645 ("mm: Do early cow for pinned pages during
fork() for ptes") pages under a FOLL_PIN will not be write protected
during COW for fork. This means that pages returned from
pin_
David Laight 于2020年12月23日周三 上午2:42写道：
>
> From: qianjun
> > Sent: 22 December 2020 12:19
> >
> > In our project, Many business delays come from fork, so
> > we started looking for the reason why fork is time-consuming.
> > I used the ftrace with function_gra
From: qianjun
> Sent: 22 December 2020 12:19
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, found
> that the vm_normal_page will be called ten
Souptick Joarder 于2020年12月22日周二 下午11:08写道：
>
> On Tue, Dec 22, 2020 at 5:49 PM wrote:
> >
> > From: jun qian
> >
> > In our project, Many business delays come from fork, so
> > we started looking for the reason why fork is time-consuming.
> > I used t
On Tue, Dec 22, 2020 at 5:49 PM wrote:
>
> From: jun qian
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, found
> that the vm_normal_page w
From: jun qian
In our project, Many business delays come from fork, so
we started looking for the reason why fork is time-consuming.
I used the ftrace with function_graph to trace the fork, found
that the vm_normal_page will be called tens of thousands and
the execution time of this
Use the maple tree iterator to duplicate the mm_struct trees.
Signed-off-by: Liam R. Howlett
---
include/linux/sched/mm.h | 3 +++
kernel/fork.c| 22 +-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched/mm.h b/include/linux/sched
On Tue, Dec 01, 2020 at 08:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 02:11:33PM -0500, Joel Fernandes wrote:
> > On Wed, Nov 25, 2020 at 12:15:41PM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 17, 2020 at 06:19:52PM -0500, Joel Fernandes (Google) wrote:
> > >
> > > > +/*
> >
Hi Peter,
On Tue, Dec 01, 2020 at 08:34:51PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 02:20:28PM -0500, Joel Fernandes wrote:
> > On Wed, Nov 25, 2020 at 12:10:14PM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 17, 2020 at 06:19:52PM -0500, Joel Fernandes (Google) wrote:
> > > > +vo
On Tue, Dec 1, 2020 at 11:55 PM Peter Zijlstra wrote:
>
> Then disallow sharing a task cookie when the tasks are in different
> cgroups or disallow cgroup movement when they share a cookie.
Yes, we could restrict task cookie sharing to tasks that are in the
same cgroup. Then the cookie easily jus
1 - 100 of 1266 matches
Mail list logo
