Jeff Xu wrote:
> In linux cases, I think, eventually, mseal() will have a bigger scope than
> BSD's mimmutable().
I don't believe that, considering noone needed this behaviour from the VM
system in the last 4 decades.
> VMA's metadata(vm_area_struct) contains a lot
> of control info, depending
On Tue, Oct 17, 2023 at 4:57 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > May I ask, for BSD's implementation of immutable(), do you cover
> > things such as mlock(),
> > madvice() ? or just the protection bit (WRX) + remap() + unmap().
>
> It only prevents removal of the mapping, placement
On 10/17/23 4:52 PM, Tian, Kevin wrote:
another problem is that intel_iommu_enforce_cache_coherency()
doesn't update existing entries. It only sets a domain flag to affect
future mappings. so it means the 2nd idev is also broken.
This is such a gap, intel driver should not permit that.
yes.
Yu Liao (2):
selftests/ftrace: add loongarch support for kprobe args char tests
selftests/ftrace: Add riscv support for kprobe arg tests
.../selftests/ftrace/test.d/kprobe/kprobe_args_char.tc | 6 ++
.../selftests/ftrace/test.d/kprobe/kprobe_args_string.tc| 3 +++
Add loongarch support for the recently added kprobe args tests.
Signed-off-by: Yu Liao
Acked-by: Masami Hiramatsu (Google)
Acked-by: Steven Rostedt (Google)
---
.../testing/selftests/ftrace/test.d/kprobe/kprobe_args_char.tc | 3 +++
1 file changed, 3 insertions(+)
diff --git
This is the riscv variant of commit 9855c4626c67 ("selftests/ftrace:
Add ppc support for kprobe args tests").
Signed-off-by: Yu Liao
Acked-by: Masami Hiramatsu (Google)
Acked-by: Steven Rostedt (Google)
---
.../selftests/ftrace/test.d/kprobe/kprobe_args_char.tc| 3 +++
The opened file should be closed in main(), otherwise resource
leak will occur that this problem was discovered by code reading
Signed-off-by: zhujun2
---
tools/testing/selftests/efivarfs/create-read.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Mon, 16 Oct 2023 15:27:19 +0200 you wrote:
> Introduce a limit on the amount of learned FDB entries on a bridge,
> configured by netlink with a build time default on bridge creation in
> the kernel config.
>
>
On 10/17/23 11:37, Steven Rostedt wrote:
On Tue, 15 Aug 2023 16:59:10 +0800
Yu Liao wrote:
Yu Liao (2):
selftests/ftrace: add loongarch support for kprobe args char tests
selftests/ftrace: Add riscv support for kprobe arg tests
.../selftests/ftrace/test.d/kprobe/kprobe_args_char.tc
Jeff Xu wrote:
> May I ask, for BSD's implementation of immutable(), do you cover
> things such as mlock(),
> madvice() ? or just the protection bit (WRX) + remap() + unmap().
It only prevents removal of the mapping, placement of a replacement
mapping, or changing the existing permissions. If
On Tue, Oct 17, 2023 at 4:34 PM Nhat Pham wrote:
>
> On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
> >
> > From: Domenico Cerasuolo
> >
> > The memcg-zswap self test is updated to adjust to the behavior change
> > implemented by commit 87730b165089 ("zswap: make shrinking memcg-aware"),
> >
On Tue, Oct 17, 2023 at 4:38 PM Jeff Johnson wrote:
>
> On 10/17/2023 4:35 PM, Nhat Pham wrote:
> > On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
> >>
> >> From: Domenico Cerasuolo
> >>
> >> Since zswap now writes back pages from memcg-specific LRUs, we now need a
> >> new stat to show
On 10/17/2023 4:35 PM, Nhat Pham wrote:
On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
From: Domenico Cerasuolo
Since zswap now writes back pages from memcg-specific LRUs, we now need a
new stat to show writebacks count for each memcg.
Suggested-by: Nhat Pham
Signed-off-by: Domenico
On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
>
> From: Domenico Cerasuolo
>
> Since zswap now writes back pages from memcg-specific LRUs, we now need a
> new stat to show writebacks count for each memcg.
>
> Suggested-by: Nhat Pham
> Signed-off-by: Domenico Cerasuolo
> Signed-off-by: Nhat
On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
>
> From: Domenico Cerasuolo
>
> The memcg-zswap self test is updated to adjust to the behavior change
> implemented by commit 87730b165089 ("zswap: make shrinking memcg-aware"),
> where zswap performs writeback for specific memcg.
>
>
Currently, we only shrink the zswap pool when the user-defined limit is
hit. This means that if we set the limit too high, cold data that are
unlikely to be used again will reside in the pool, wasting precious
memory. It is hard to predict how much zswap space will be needed ahead
of time, as this
From: Domenico Cerasuolo
Currently, we only have a single global LRU for zswap. This makes it
impossible to perform worload-specific shrinking - an memcg cannot
determine which pages in the pool it owns, and often ends up writing
pages from other memcgs. This issue has been previously observed
From: Domenico Cerasuolo
Since zswap now writes back pages from memcg-specific LRUs, we now need a
new stat to show writebacks count for each memcg.
Suggested-by: Nhat Pham
Signed-off-by: Domenico Cerasuolo
Signed-off-by: Nhat Pham
---
include/linux/memcontrol.h | 2 ++
mm/memcontrol.c
From: Domenico Cerasuolo
The memcg-zswap self test is updated to adjust to the behavior change
implemented by commit 87730b165089 ("zswap: make shrinking memcg-aware"),
where zswap performs writeback for specific memcg.
Signed-off-by: Domenico Cerasuolo
Signed-off-by: Nhat Pham
---
The interface of list_lru is based on the assumption that objects are
allocated on the correct node/memcg, with this change it is introduced the
possibility to explicitly specify numa node and memcgroup when adding and
removing objects. This is so that users of list_lru can track node/memcg
of the
Changelog:
v3:
* Add a patch to export per-cgroup zswap writeback counters
* Add a patch to update zswap's kselftest
* Separate the new list_lru functions into its own prep patch
* Do not start from the top of the hierarchy when encounter a memcg
that is not online for the global
ts[i].name);
- /* Do a clone3() with exit signal (SIGCHLD) in flags */
- test_clone3(SIGCHLD, 0, -EINVAL, CLONE3_ARGS_NO_TEST);
+ ksft_test_result(test_clone3(tests[i].flags, size,
+tests[i].expected,
+tests[i].test_mode),
+"%s\n", tests[i].name);
+ }
ksft_finished();
}
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20231017-kselftest-clone3-output-7e8b6462bd1b
Best regards,
--
Mark Brown
On Tue, Oct 17, 2023 at 11:20 AM Theo de Raadt wrote:
>
> Linus Torvalds wrote:
>
> > On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
> > >
> > > It is probably worth noting that I choose to check one and only
> > > one sealing type per syscall. i.e. munmap(2) checks
> > > MM_SEAL_MUNMAP only.
> >
On Tue, Oct 17, 2023 at 10:34 PM Jeff Xu wrote:
>
> On Tue, Oct 17, 2023 at 8:30 AM Pedro Falcato wrote:
> >
> > On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
> > >
> > > On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > > > Modern CPUs support memory permissions
On Tue, Oct 17, 2023 at 8:30 AM Pedro Falcato wrote:
>
> On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
> >
> > On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > > supported NX since the
On 10/17/23 14:38, Steven Rostedt wrote:
On Thu, 5 Oct 2023 21:57:12 +
Beau Belgrave wrote:
The abi_test currently uses a long sized test value for enablement
checks. On LE this works fine, however, on BE this results in inaccurate
assert checks due to a bit being used and assuming it's
On Thu, 5 Oct 2023 21:57:12 +
Beau Belgrave wrote:
> The abi_test currently uses a long sized test value for enablement
> checks. On LE this works fine, however, on BE this results in inaccurate
> assert checks due to a bit being used and assuming it's value is the
> same on both LE and BE.
On Tue, Oct 17, 2023 at 12:53:01PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 17, 2023 at 08:52:49AM +, Tian, Kevin wrote:
> > I prefer to removing enforce_cc in attach fn completely then no parent
> > trick in this patch. Just keep it in hwpt_alloc and leave to iommu driver to
> > figure out
Hi Suren,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on next-20231017]
[cannot apply to linus/master v6.6-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Tue, Oct 17, 2023 at 12:50:11PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 17, 2023 at 04:55:12PM +0800, Yi Liu wrote:
> > On 2023/10/17 02:44, Nicolin Chen wrote:
> > > On Mon, Oct 16, 2023 at 08:59:07AM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Oct 16, 2023 at 03:03:04PM +0800, Yi Liu
On 2023/10/17 23:15, Daniel Borkmann wrote:
On 10/16/23 3:03 PM, Akihiko Odaki wrote:
When linking statically, libraries may require other dependencies to be
included to ld flags. In particular, libelf may require libzstd. Use
pkg-config to determine such dependencies.
Signed-off-by: Akihiko
On 2023/10/18 4:03, Alexei Starovoitov wrote:
On Mon, Oct 16, 2023 at 7:38 PM Jason Wang wrote:
On Tue, Oct 17, 2023 at 7:53 AM Alexei Starovoitov
wrote:
On Sun, Oct 15, 2023 at 10:10 AM Akihiko Odaki wrote:
On 2023/10/16 1:07, Alexei Starovoitov wrote:
On Sun, Oct 15, 2023 at 7:17 AM
On Mon, Oct 16, 2023 at 7:38 PM Jason Wang wrote:
>
> On Tue, Oct 17, 2023 at 7:53 AM Alexei Starovoitov
> wrote:
> >
> > On Sun, Oct 15, 2023 at 10:10 AM Akihiko Odaki
> > wrote:
> > >
> > > On 2023/10/16 1:07, Alexei Starovoitov wrote:
> > > > On Sun, Oct 15, 2023 at 7:17 AM Akihiko Odaki
>
David,
On Tue, Oct 17, 2023 at 05:55:10PM +0200, David Hildenbrand wrote:
> Don't get me wrong, but this feature is already complicated enough that we
> should really think twice if we want to make this even more complicated and
> harder to maintain -- because once it's in we all know it's hard
Linus Torvalds wrote:
> On Tue, 17 Oct 2023 at 11:20, Theo de Raadt wrote:
> >
> > The only case where the immutable marker is ignored is during address space
> > teardown as a result of process termination.
>
> .. and presumably also execve()?
Ah yes of course that also.
> I do like us
On Tue, 17 Oct 2023 at 11:20, Theo de Raadt wrote:
>
> The only case where the immutable marker is ignored is during address space
> teardown as a result of process termination.
.. and presumably also execve()?
I do like us starting with just "mimmutable()", since it already
exists.
Linus Torvalds wrote:
> On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
> >
> > It is probably worth noting that I choose to check one and only
> > one sealing type per syscall. i.e. munmap(2) checks
> > MM_SEAL_MUNMAP only.
>
> Yeah, this is wrong.
>
> It's wrong exactly because other system
On Tue, 17 Oct 2023 at 10:04, Linus Torvalds
wrote:
>
> Honestly, there is only two kinds of sealing that makes sense:
>
> - you cannot change the permissions of some area
>
> - you cannot unmap an area
Actually, I guess at least theoretically, there could be three different things:
- you
On Tue, 15 Aug 2023 16:59:10 +0800
Yu Liao wrote:
> Yu Liao (2):
> selftests/ftrace: add loongarch support for kprobe args char tests
> selftests/ftrace: Add riscv support for kprobe arg tests
>
> .../selftests/ftrace/test.d/kprobe/kprobe_args_char.tc | 6 ++
>
On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
>
> It is probably worth noting that I choose to check one and only
> one sealing type per syscall. i.e. munmap(2) checks
> MM_SEAL_MUNMAP only.
Yeah, this is wrong.
It's wrong exactly because other system calls will unmap things too.
Using mmap()
When we dynamically generate a name for a configuration in get-reg-list
we use strcat() to append to a buffer allocated using malloc() but we
never initialise that buffer. Since malloc() offers no guarantees
regarding the contents of the memory it returns this can lead to us
corrupting, and likely
On Tue, 17 Oct 2023 at 02:08, wrote:
>
> Note: Of all the call paths that goes into do_mmap(),
> ksys_mmap_pgoff() is the only place where
> checkSeals = MM_SEAL_MMAP. The rest has checkSeals = 0.
Again, this is all completely nonsensical.
First off, since seals only exist on existing vma's,
On Tue, 17 Oct 2023 at 02:08, wrote:
>
> Of all the call paths that call into do_vmi_munmap(),
> this is the only place where checkSeals = MM_SEAL_MUNMAP.
> The rest has checkSeals = 0.
Why?
None of this makes sense.
So you say "we can't munmap in this *one* place, but all others ignore
the
Hi Ilpo,
The subject could be shortened to:
selftests/resctrl: Fix MBM test failure when MBA unavailable
On 10/17/2023 5:17 AM, Ilpo Järvinen wrote:
> Commit 20d96b25cc4c ("selftests/resctrl: Fix schemata write error
> check") exposed a problem in feature detection logic in MBM selftest.
> If
On Mon, Oct 16, 2023 at 10:46:10AM -0700, Nicolin Chen wrote:
> On Mon, Oct 16, 2023 at 09:04:54AM -0300, Jason Gunthorpe wrote:
> > On Sun, Oct 15, 2023 at 12:14:01AM -0700, Nicolin Chen wrote:
> > > On Thu, Sep 28, 2023 at 12:15:23AM -0700, Yi Liu wrote:
> > >
> > > > diff --git
On 16.10.23 21:01, Peter Xu wrote:
David,
Hi Peter,
Basically I see it a potential way of moving memory efficiently especially
with thp.
It's an interesting use case indeed. The questions would be if this is (a) a
use case we want to support; (b) why we need to make that decision now and
On 10/16/23 20:08, zhujun2 wrote:
when the argument type is 'unsigned int',printf '%u'
in format string
Please add how you found the problem to the commit log.
Signed-off-by: zhujun2
thanks,
-- Shuah
On Tue, Oct 17, 2023 at 08:52:49AM +, Tian, Kevin wrote:
> > This is why I wanted to get rid of this bad mechanism going forward.
> >
> > Manually created hwpt should have a manual specification of cc and
> > then we don't have so many problems.
> >
> > It means userspace needs to compute
On Tue, Oct 17, 2023 at 04:55:12PM +0800, Yi Liu wrote:
> On 2023/10/17 02:44, Nicolin Chen wrote:
> > On Mon, Oct 16, 2023 at 08:59:07AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Oct 16, 2023 at 03:03:04PM +0800, Yi Liu wrote:
> > > > Current nesting series actually extends HWPT_ALLOC ioctl to
On 10/16/23 20:33, zhujun2 wrote:
The opened file should be closed in main(), otherwise resource
leak will occur
Did you find this by code reading or by any other means. Please
add how you found the problem to the change log.
Signed-off-by: zhujun2
---
nit:
On 10/17/23 02:08, jef...@chromium.org wrote:
| diff --git a/mm/Kconfig b/mm/Kconfig
| index 264a2df5ecf5..db8a567cb4d3 100644
| --- a/mm/Kconfig
| +++ b/mm/Kconfig
| @@ -1258,6 +1258,14 @@ config LOCK_MM_AND_FIND_VMA
| bool
| depends on !STACK_GROWSUP
|
| +config MSEAL
| +
On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
>
> On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > supported NX since the release of kernel version 2.6.8 in August 2004 [1].
>
> This seems
On 2023-10-17 03:28, Jinjie Ruan wrote:
>
>
> On 2023/10/17 4:35, Marco Pagani wrote:
>> Commit 2810c1e99867 ("kunit: Fix wild-memory-access bug in
>> kunit_free_suite_set()") is causing all test suites to run (when
>> built as modules) while still in MODULE_STATE_COMING. In that state,
>>
On 10/16/23 3:03 PM, Akihiko Odaki wrote:
When linking statically, libraries may require other dependencies to be
included to ld flags. In particular, libelf may require libzstd. Use
pkg-config to determine such dependencies.
Signed-off-by: Akihiko Odaki
---
V3 -> V4: Added "2> /dev/null".
V2
On Tue, Oct 17, 2023 at 01:34:35AM -0700, Jeff Xu wrote:
> > > types: bit mask to specify which syscall to seal, currently they are:
> > > MM_SEAL_MSEAL 0x1
> > > MM_SEAL_MPROTECT 0x2
> > > MM_SEAL_MUNMAP 0x4
> > > MM_SEAL_MMAP 0x8
> > > MM_SEAL_MREMAP 0x10
> >
> > I don't understand why we want
Commit 20d96b25cc4c ("selftests/resctrl: Fix schemata write error
check") exposed a problem in feature detection logic in MBM selftest.
If schemata does not support MB:x=x entries, the schemata write to
initialize 100% memory bandwidth allocation in mbm_setup() will now
fail with -EINVAL due to
On Mon, Oct 16, 2023 at 03:27:23PM +0200, Johannes Nixdorf wrote:
> Set any new attributes added to br_policy to be parsed strictly, to
> prevent userspace from passing garbage.
>
> Signed-off-by: Johannes Nixdorf
Reviewed-by: Ido Schimmel
On Mon, Oct 16, 2023 at 03:27:22PM +0200, Johannes Nixdorf wrote:
> The previous patch added accounting and a limit for the number of
> dynamically learned FDB entries per bridge. However it did not provide
> means to actually configure those bounds or read back the count. This
> patch does that.
On 10/16/23 16:27, Johannes Nixdorf wrote:
Set any new attributes added to br_policy to be parsed strictly, to
prevent userspace from passing garbage.
Signed-off-by: Johannes Nixdorf
---
net/bridge/br_netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_netlink.c
On 10/16/23 16:27, Johannes Nixdorf wrote:
The previous patch added accounting and a limit for the number of
dynamically learned FDB entries per bridge. However it did not provide
means to actually configure those bounds or read back the count. This
patch does that.
Two new netlink attributes
> From: Liu, Yi L
> Sent: Tuesday, October 17, 2023 4:52 PM
>
> On 2023/10/17 02:17, Nicolin Chen wrote:
> > On Mon, Oct 16, 2023 at 08:54:07AM -0300, Jason Gunthorpe wrote:
> >> On Mon, Oct 16, 2023 at 11:28:15AM +0800, Yi Liu wrote:
> >>> On 2023/10/14 01:56, Nicolin Chen wrote:
> On Fri,
From: Jeff Xu
selftest for sealing mprotect/munmap/mremap/mmap
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/Makefile |1 +
tools/testing/selftests/mm/mseal_test.c | 1428 +++
2 files changed, 1429 insertions(+)
create mode 100644
From: Jeff Xu
mremap(2) can shrink/expand a VMA, or move a VMA to a fixed
address and overwriting or existing VMA. Sealing will
prevent unintended mremap(2) call.
What this patch does:
When a mremap(2) is invoked, if one of its VMAs has MM_SEAL_MREMAP
set from previous mseal(2) call, this
Hello Linus,
Thank you for the time reviewing this patch set.
On Mon, Oct 16, 2023 at 10:23 AM Linus Torvalds
wrote:
>
> On Mon, 16 Oct 2023 at 07:38, wrote:
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
>
> So I have no objections to adding some kind of "lock down
From: Jeff Xu
mmap(2) can change a protection of existing VMAs.
Sealing will prevent unintended mmap(2) call.
What this patch does:
When a mmap(2) is invoked, if one of its VMAs has MM_SEAL_MMAP set
from previous mseal(2) call, the mmap(2) will fail, without any
VMAs modified.
The patch is
From: Jeff Xu
munmap(2) unmap VMAs in the given address range.
Sealing will prevent unintended munmap(2) call.
What this patch does:
When a munmap(2) is invoked, if one of its VMAs has MM_SEAL_MUNMAP
set from previous mseal(2) call, this munmap(2) will fail,
without any VMA modified.
This
From: Jeff Xu
can_modify_mm:
checks sealing flags for given memory range.
can_modify_vma:
checks sealing flags for given vma.
Signed-off-by: Jeff Xu
---
include/linux/mm.h | 26 ++
mm/mseal.c | 42 --
2 files changed,
From: Jeff Xu
mprotect(2) changes protection of VMAs in the given address
range. Sealing will prevent unintended mprotect call.
What this patch does:
When a mprotect(2) is invoked, if one of its VMAs has MM_SEAL_MPROTECT
set from previous mseal(2) call, this mprotect(2) will fail, without
any
From: Jeff Xu
This patchset proposes a new mseal() syscall for the Linux kernel.
Modern CPUs support memory permissions such as RW and NX bits. Linux has
supported NX since the release of kernel version 2.6.8 in August 2004 [1].
The memory permission feature improves security stance on memory
From: Jeff Xu
Wire up mseal syscall for all architectures.
Signed-off-by: Jeff Xu
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 ++
From: Jeff Xu
This patchset proposes a new mseal() syscall for the Linux kernel.
Modern CPUs support memory permissions such as RW and NX bits. Linux has
supported NX since the release of kernel version 2.6.8 in August 2004 [1].
The memory permission feature improves security stance on memory
> From: Tian, Kevin
> Sent: Tuesday, October 17, 2023 4:53 PM
> >
> > This is why I wanted to get rid of this bad mechanism going forward.
> >
> > Manually created hwpt should have a manual specification of cc and
> > then we don't have so many problems.
> >
Actually I don't see much difference
On 2023/10/17 02:44, Nicolin Chen wrote:
On Mon, Oct 16, 2023 at 08:59:07AM -0300, Jason Gunthorpe wrote:
On Mon, Oct 16, 2023 at 03:03:04PM +0800, Yi Liu wrote:
Current nesting series actually extends HWPT_ALLOC ioctl to accept user
data for allocating domain with vendor specific data. Nested
> From: Jason Gunthorpe
> Sent: Monday, October 16, 2023 7:58 PM
>
> On Mon, Oct 16, 2023 at 08:48:03AM +, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Saturday, October 14, 2023 8:45 AM
> > >
> > > On Tue, Sep 26, 2023 at 01:16:35AM -0700, Tian, Kevin wrote:
> > > > > From: Liu,
On 2023/10/17 02:17, Nicolin Chen wrote:
On Mon, Oct 16, 2023 at 08:54:07AM -0300, Jason Gunthorpe wrote:
On Mon, Oct 16, 2023 at 11:28:15AM +0800, Yi Liu wrote:
On 2023/10/14 01:56, Nicolin Chen wrote:
On Fri, Oct 13, 2023 at 11:04:56AM -0300, Jason Gunthorpe wrote:
On Fri, Oct 13, 2023 at
Hi Jann,
Thank you for reviewing the patch and comments.
On Mon, Oct 16, 2023 at 10:35 AM Jann Horn wrote:
>
> On Mon, Oct 16, 2023 at 4:38 PM wrote:
> >
> > From: Jeff Xu
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > Modern CPUs support memory permissions
Hi Matthew.
Thanks for your comments and time to review the patchset.
On Mon, Oct 16, 2023 at 8:18 AM Matthew Wilcox wrote:
>
> On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > supported NX
[AMD Official Use Only - General]
Hi Peter:
After our internal discussion, the following modifications will be made.
Do you think they are feasible?
1. Add judgement for "highest_perf". When it is less than 255, the
preferred core feature is enabled. And it will set the priority.
On Mon, Oct 16, 2023 at 8:07 AM Greg KH wrote:
>
> On Mon, Oct 16, 2023 at 02:38:20PM +, jef...@chromium.org wrote:
> > +#ifdef CONFIG_MSEAL
> > + /*
> > + * bit masks for seal.
> > + * need this since vm_flags is full.
> > + */
> > + unsigned long vm_seals; /*
79 matches
Mail list logo
