> From: Jason Gunthorpe
> Sent: Friday, October 20, 2023 7:54 AM
>
> On Thu, Oct 19, 2023 at 01:56:01AM +, Tian, Kevin wrote:
>
> > > Otherwise we have a problem where the order devices are attached to
> > > the domain decides how many domains you get. ie the first device
> > > attached
.org/0day-ci/archive/20231019/202310192236.fde97031-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On 10/20/2023 07:35 AM, Andrew Morton wrote:
On Fri, 20 Oct 2023 00:08:12 +0100 Mark Brown wrote:
Use a filter function to skip the time namespace test on systems with
!CONFIG_TIME_NS. This reworks a fix originally done by Tiezhu Yang prior
to the refactoring in 34dce23f7e40
On Thu, Oct 19, 2023 at 01:56:01AM +, Tian, Kevin wrote:
> > Otherwise we have a problem where the order devices are attached to
> > the domain decides how many domains you get. ie the first device
> > attached does not want CC (but is compatible with it) so we create a
> > non-CC domain
>
>
On Fri, 20 Oct 2023 00:08:12 +0100 Mark Brown wrote:
> Use a filter function to skip the time namespace test on systems with
> !CONFIG_TIME_NS. This reworks a fix originally done by Tiezhu Yang prior
> to the refactoring in 34dce23f7e40 ("selftests/clone3: Report descriptive
> test names"). The
ize = 0,
.expected = 0,
.test_mode = CLONE3_ARGS_NO_TEST,
+ .filter = timens_unsupported,
},
{
.name = "exit signal (SIGCHLD) in flags",
---
base-commit: 8d4099dd0727acfc8b0f644eacaf852f9d5dc649
change-id: 20231019-kselftest-clone3-time-ns-730b6f4187c7
Best regards,
--
Mark Brown
On Thu, 19 Oct 2023 at 15:47, Pedro Falcato wrote:
> >
> > For mprotect()/mmap(), is Linux implementation limited by POSIX ?
>
> No. POSIX works merely as a baseline that UNIX systems aim towards.
> You can (and very frequently do) extend POSIX interfaces (in fact,
> it's how most of POSIX was
On Thu, Oct 19, 2023 at 6:30 PM Jeff Xu wrote:
>
> Hi Pedro
>
> Some followup on mmap() + mprotect():
>
> On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
> >
> > On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato
> > wrote:
> > >
> > > > >
> > > > > I think it's worth pointing out that this
On Tue, Oct 17, 2023 at 12:40 PM kernel test robot wrote:
>
> 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
On Fri, Oct 13, 2023 at 9:08 AM Peter Xu wrote:
>
> On Fri, Oct 13, 2023 at 11:56:31AM +0200, David Hildenbrand wrote:
> > Hi Peter,
>
> Hi, David,
>
> >
> > > I used to have the same thought with David on whether we can simplify the
> > > design to e.g. limit it to single mm. Then I found that
On Thu, Oct 12, 2023 at 3:00 PM Peter Xu wrote:
>
> On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> > From: Andrea Arcangeli
> >
> > Implement the uABI of UFFDIO_MOVE ioctl.
> > UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
> > needs pages to be
On Thu, Oct 19, 2023 at 01:02:39PM -0700, Suren Baghdasaryan wrote:
> Hi Folks,
> Sorry, I'm just catching up on all the comments in this thread after a
Not a problem.
> week-long absence. Will be addressing other questions separately but
> for cross-mm one, I think the best way forward would be
On Thu, Oct 19, 2023 at 12:53 PM Peter Xu wrote:
>
> On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
> > That's not my main point. It can easily become a maintenance burden without
> > any real use cases yet that we are willing to support.
>
> That's why I requested a few times
On 10/16/23 6:47 AM, Breno Leitao wrote:
Expand the sockopt test to use also check for io_uring {g,s}etsockopt
commands operations.
This patch starts by marking each test if they support io_uring support
or not.
Right now, io_uring cmd getsockopt() has a limitation of only
accepting level ==
On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
> That's not my main point. It can easily become a maintenance burden without
> any real use cases yet that we are willing to support.
That's why I requested a few times that we can discuss the complexity of
cross-mm support
On Thu, Oct 19, 2023 at 10:29:27AM -0700, Axel Rasmussen wrote:
> On Thu, Oct 19, 2023 at 8:43 AM Suren Baghdasaryan wrote:
> >
> > On Thu, Oct 12, 2023 at 3:29 PM Peter Xu wrote:
> > >
> > > On Sun, Oct 08, 2023 at 11:42:28PM -0700, Suren Baghdasaryan wrote:
> > > > Add a test for new
On Thu, 19 Oct 2023, Andrew Morton wrote:
> On Thu, 19 Oct 2023 11:31:17 -0700 Nhat Pham wrote:
>
> > > There are parts of the code that I would feel more comfortable if
> > > someone took a look at (which I mentioned in individual patches). So
> > > unless this happens in the next few days I
esOn Fri, Sep 29, 2023 at 06:23:48PM +0530, Swarup Laxman Kotiaklapudi wrote:
> Change namespace creation for root and non-root
> user differently in create_and_enter_ns() function
>
> Test result with root user:
> $sudo make TARGETS="capabilities" kselftest
> ...
> TAP version 13
> 1..1
>
On Thu, 19 Oct 2023 11:31:17 -0700 Nhat Pham wrote:
> > There are parts of the code that I would feel more comfortable if
> > someone took a look at (which I mentioned in individual patches). So
> > unless this happens in the next few days I wouldn't say so.
> >
>
> I'm not super familiar with
On Thu, Oct 19, 2023 at 10:34 AM Yosry Ahmed wrote:
>
> On Thu, Oct 19, 2023 at 10:12 AM Andrew Morton
> wrote:
> >
> > On Tue, 17 Oct 2023 16:21:47 -0700 Nhat Pham wrote:
> >
> > > Subject: [PATCH v3 0/5] workload-specific and memory pressure-driven
> > > zswap writeback
> >
> > We're at -rc6
On Thu, Oct 19, 2023 at 10:12 AM Andrew Morton
wrote:
>
> On Tue, 17 Oct 2023 16:21:47 -0700 Nhat Pham wrote:
>
> > Subject: [PATCH v3 0/5] workload-specific and memory pressure-driven zswap
> > writeback
>
> We're at -rc6 and I'd prefer to drop this series from mm.git, have
> another go during
Hi Pedro
Some followup on mmap() + mprotect():
On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
>
> On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato wrote:
> >
> > > >
> > > > I think it's worth pointing out that this suggestion (with PROT_*)
> > > > could easily integrate with mmap() and as such
On Thu, Oct 19, 2023 at 8:43 AM Suren Baghdasaryan wrote:
>
> On Thu, Oct 12, 2023 at 3:29 PM Peter Xu wrote:
> >
> > On Sun, Oct 08, 2023 at 11:42:28PM -0700, Suren Baghdasaryan wrote:
> > > Add a test for new UFFDIO_MOVE ioctl which uses uffd to move source
> > > into destination buffer while
On Tue, 17 Oct 2023 16:21:47 -0700 Nhat Pham wrote:
> Subject: [PATCH v3 0/5] workload-specific and memory pressure-driven zswap
> writeback
We're at -rc6 and I'd prefer to drop this series from mm.git, have
another go during the next cycle.
However Hugh's v2 series "mempolicy: cleanups
On Thu, Oct 05, 2023 at 06:23:10PM +0100, Catalin Marinas wrote:
> I haven't checked how many clone() or clone3() uses outside the libc are
> (I tried some quick search in Debian but did not dig into the specifics
> to see how generic that code is). I agree that having to change valid
> cases
On Thu, Oct 19, 2023 at 5:47 AM Domenico Cerasuolo
wrote:
>
> On Thu, Oct 19, 2023 at 3:12 AM Yosry Ahmed wrote:
> >
> > On Wed, Oct 18, 2023 at 4:47 PM Nhat Pham wrote:
> > >
> > > On Wed, Oct 18, 2023 at 4:20 PM Yosry Ahmed wrote:
> > > >
> > > > On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham
[..]
> > >
> > > +/*
> > > +* lru functions
> > > +**/
> > > +static bool zswap_lru_add(struct list_lru *list_lru, struct zswap_entry
> > > *entry)
> > > +{
> > > + struct mem_cgroup *memcg = get_mem_cgroup_from_entry(entry);
>
On Thu, Oct 12, 2023 at 3:29 PM Peter Xu wrote:
>
> On Sun, Oct 08, 2023 at 11:42:28PM -0700, Suren Baghdasaryan wrote:
> > Add a test for new UFFDIO_MOVE ioctl which uses uffd to move source
> > into destination buffer while checking the contents of both after
> > remapping. After the operation
On 17.10.23 20:59, Peter Xu wrote:
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
On Fri, Oct 13, 2023 at 1:04 AM David Hildenbrand wrote:
>
> On 13.10.23 00:01, Peter Xu wrote:
> > On Sun, Oct 08, 2023 at 11:42:26PM -0700, Suren Baghdasaryan wrote:
> >> From: Andrea Arcangeli
> >>
> >> For now, folio_move_anon_rmap() was only used to move a folio to a
> >> different anon_vma
On Thu, Oct 19, 2023 at 11:59:00AM +0200, Thomas Huth wrote:
> For easier use of the tests in automation and for having some
> status information for the user while the test is running, let's
> provide some TAP output in this test.
>
> Signed-off-by: Thomas Huth
> ---
> NB: This patch does not
On Thu, Oct 19, 2023 at 3:12 AM Yosry Ahmed wrote:
>
> On Wed, Oct 18, 2023 at 4:47 PM Nhat Pham wrote:
> >
> > On Wed, Oct 18, 2023 at 4:20 PM Yosry Ahmed wrote:
> > >
> > > On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
> > > >
> > > > From: Domenico Cerasuolo
> > > >
> > > > Currently,
On Thu, Oct 19, 2023 at 1:20 AM Yosry Ahmed wrote:
>
> On Tue, Oct 17, 2023 at 4:21 PM Nhat Pham wrote:
> >
> > 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
> >
For easier use of the tests in automation and for having some
status information for the user while the test is running, let's
provide some TAP output in this test.
Signed-off-by: Thomas Huth
---
NB: This patch does not use the interface from kselftest_harness.h
since it is not very
From: jef...@chromium.org
> Sent: 17 October 2023 10:08
>
> This patchset proposes a new mseal() syscall for the Linux kernel.
I'm sure you can give it a better name, there isn't a 6 character
limit on identifiers!
FWIW you could also use mprotect(addr, len, IMMUTABLE);
David
-
> > IMO: The approaches mimmutable() and mseal() took are different, but
> > we all want to seal the memory from attackers and make the linux
> > application safer.
>
> I think you are building mseal for chrome, and chrome alone.
>
> I do not think this will work out for the rest of the
> I do like us starting with just "mimmutable()", since it already
> exists. Particularly if chrome already knows how to use it.
>
> Maybe add a flag field (require it to be zero initially) just to allow
> any future expansion. Maybe the chrome team has *wanted* to have some
> finer granularity
> Without that practical reason, I think the only two sane sealing operations
> are:
>
> - SEAL_MUNMAP: "don't allow this mapping address to go away"
>
>IOW no unmap, no shrinking, no moving mremap
>
> - SEAL_MPROTECT: "don't allow any mapping permission changes"
>
> Again, that permission
On Wed, Oct 18, 2023 at 12:51:55PM -0700, Sean Christopherson wrote:
> On Fri, Oct 06, 2023, Dongli Zhang wrote:
> > As inspired by the discussion in [1], the boottime wallclock may drift due
> > to the fact that the masterclock (or host monotonic clock) and kvmclock are
> > calculated based on
39 matches
Mail list logo
