linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-07-27 23:18 Stephen Rothwell
  2023-07-27 23:29 ` Stephen Rothwell
  2023-07-27 23:49 ` Matthew Wilcox
  0 siblings, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-27 23:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jann Horn, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle),
	Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/memory.c

between commit:

  657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")

from Linus' tree and commits:

  69f6bbd1317f ("mm: handle userfaults under VMA lock")
  a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")

from the mm tree.

I fixed it up (I think, please check - see below) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/memory.c
index ca632b58f792,271982fab2b8..000000000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -5392,32 -5597,18 +5597,21 @@@ retry
  	if (!vma)
  		goto inval;
  
- 	/* Only anonymous and tcp vmas are supported for now */
- 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
 -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
 -	if (vma_is_anonymous(vma) && !vma->anon_vma)
--		goto inval;
--
  	if (!vma_start_read(vma))
  		goto inval;
  
 +	/*
 +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
 +	 * This check must happen after vma_start_read(); otherwise, a
 +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
 +	 * from its anon_vma.
 +	 */
- 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
- 		goto inval_end_read;
- 
- 	/*
- 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
- 	 * it for now and fall back to page fault handling under mmap_lock.
- 	 */
- 	if (userfaultfd_armed(vma))
++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
 +		goto inval_end_read;
 +
  	/* Check since vm_start/vm_end might change before we lock the VMA */
 -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
 -		vma_end_read(vma);
 -		goto inval;
 -	}
 +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
 +		goto inval_end_read;
  
  	/* Check if the VMA got isolated after we found it */
  	if (vma->detached) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-07-06 22:54 Stephen Rothwell
  2023-07-07  4:52 ` Baoquan He
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-06 22:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alexander Gordeev, Baoquan He, Heiko Carstens,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  arch/s390/kernel/perf_cpum_sf.c

between commits:

  51f513fd9659 ("s390/mm: do not include <asm-generic/io.h> directly")
  b378a9826143 ("s390: include linux/io.h instead of asm/io.h")

from Linus' tree and commit:

  c594d5c4b630 ("s390: mm: convert to GENERIC_IOREMAP")

from the mm tree.

I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-06-18 23:23 Stephen Rothwell
  2023-06-19 20:25 ` Andrew Morton
  2023-06-19 20:43 ` Will Deacon
  0 siblings, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2023-06-18 23:23 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Liam R. Howlett, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/mmap.c

between commit:

  606c812eb1d5 ("mm/mmap: Fix error path in do_vmi_align_munmap()")

from the origin tree and commits:

  66106c364147 ("mm: change do_vmi_align_munmap() side tree index")
  47b1d8de18f5 ("mm/mmap: change vma iteration order in do_vmi_align_munmap()")

from the mm tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/mmap.c
index 98cda6f72605,474a0d856622..000000000000
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@@ -2398,15 -2409,27 +2396,29 @@@ do_vmi_align_munmap(struct vma_iterato
  			if (error)
  				goto end_split_failed;
  		}
 -		mas_set(&mas_detach, count);
 -		error = munmap_sidetree(next, &mas_detach);
 -		if (error)
 -			goto munmap_sidetree_failed;
 +		vma_start_write(next);
- 		mas_set_range(&mas_detach, next->vm_start, next->vm_end - 1);
 +		if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
 +			goto munmap_gather_failed;
 +		vma_mark_detached(next, true);
 +		if (next->vm_flags & VM_LOCKED)
 +			locked_vm += vma_pages(next);
  
  		count++;
+ 		if (unlikely(uf)) {
+ 			/*
+ 			 * If userfaultfd_unmap_prep returns an error the vmas
+ 			 * will remain split, but userland will get a
+ 			 * highly unexpected error anyway. This is no
+ 			 * different than the case where the first of the two
+ 			 * __split_vma fails, but we don't undo the first
+ 			 * split, despite we could. This is unlikely enough
+ 			 * failure that it's not worth optimizing it for.
+ 			 */
+ 			error = userfaultfd_unmap_prep(next, start, end, uf);
+ 
+ 			if (error)
+ 				goto userfaultfd_error;
+ 		}
  #ifdef CONFIG_DEBUG_VM_MAPLE_TREE
  		BUG_ON(next->vm_start < start);
  		BUG_ON(next->vm_start > end);
@@@ -2454,14 -2455,18 +2444,20 @@@
  		BUG_ON(count != test_count);
  	}
  #endif
- 	/* Point of no return */
 +	error = -ENOMEM;
- 	vma_iter_set(vmi, start);
+ 	while (vma_iter_addr(vmi) > start)
+ 		vma_iter_prev_range(vmi);
+ 
  	if (vma_iter_clear_gfp(vmi, start, end, GFP_KERNEL))
 -		return -ENOMEM;
 +		goto clear_tree_failed;
  
 +	mm->locked_vm -= locked_vm;
  	mm->map_count -= count;
+ 	prev = vma_iter_prev_range(vmi);
+ 	next = vma_next(vmi);
+ 	if (next)
+ 		vma_iter_prev_range(vmi);
+ 
  	/*
  	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
  	 * VM_GROWSUP VMA. Such VMAs can change their size under

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-02-24 23:39 Stephen Rothwell
  2023-02-25  2:04 ` Andrew Morton
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-02-24 23:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Charan Teja Kalla, Christian Brauner (Microsoft),
	Giuseppe Scrivano, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/shmem.c

between commit:

  7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs")

from Linus' tree and commit:

  9323c8b93d95 ("mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem")

from the mm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/shmem.c
index 448f393d8ab2,31bd5e1f9faa..000000000000
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@@ -2344,9 -2347,120 +2347,121 @@@ static void shmem_set_inode_flags(struc
  #define shmem_initxattrs NULL
  #endif
  
+ static void shmem_isolate_pages_range(struct address_space *mapping, loff_t start,
+ 				loff_t end, struct list_head *list)
+ {
+ 	XA_STATE(xas, &mapping->i_pages, start);
+ 	struct folio *folio;
+ 
+ 	rcu_read_lock();
+ 	xas_for_each(&xas, folio, end) {
+ 		if (xas_retry(&xas, folio))
+ 			continue;
+ 		if (xa_is_value(folio))
+ 			continue;
+ 
+ 		if (!folio_try_get(folio))
+ 			continue;
+ 		if (folio_test_unevictable(folio) || folio_mapped(folio) ||
+ 				folio_isolate_lru(folio)) {
+ 			folio_put(folio);
+ 			continue;
+ 		}
+ 		folio_put(folio);
+ 
+ 		/*
+ 		 * Prepare the folios to be passed to reclaim_pages().
+ 		 * VM can't reclaim a folio unless young bit is
+ 		 * cleared in its flags.
+ 		 */
+ 		folio_clear_referenced(folio);
+ 		folio_test_clear_young(folio);
+ 		list_add(&folio->lru, list);
+ 		if (need_resched()) {
+ 			xas_pause(&xas);
+ 			cond_resched_rcu();
+ 		}
+ 	}
+ 	rcu_read_unlock();
+ }
+ 
+ static int shmem_fadvise_dontneed(struct address_space *mapping, loff_t start,
+ 				loff_t end)
+ {
+ 	LIST_HEAD(folio_list);
+ 
+ 	if (!total_swap_pages || mapping_unevictable(mapping))
+ 		return 0;
+ 
+ 	lru_add_drain();
+ 	shmem_isolate_pages_range(mapping, start, end, &folio_list);
+ 	reclaim_pages(&folio_list);
+ 
+ 	return 0;
+ }
+ 
+ static int shmem_fadvise_willneed(struct address_space *mapping,
+ 				 pgoff_t start, pgoff_t long end)
+ {
+ 	struct folio *folio;
+ 	pgoff_t index;
+ 
+ 	xa_for_each_range(&mapping->i_pages, index, folio, start, end) {
+ 		if (!xa_is_value(folio))
+ 			continue;
+ 		folio = shmem_read_folio(mapping, index);
+ 		if (!IS_ERR(folio))
+ 			folio_put(folio);
+ 	}
+ 
+ 	return 0;
+ }
+ 
+ static int shmem_fadvise(struct file *file, loff_t offset, loff_t len, int advice)
+ {
+ 	loff_t endbyte;
+ 	pgoff_t start_index;
+ 	pgoff_t end_index;
+ 	struct address_space *mapping;
+ 	struct inode *inode = file_inode(file);
+ 	int ret = 0;
+ 
+ 	if (S_ISFIFO(inode->i_mode))
+ 		return -ESPIPE;
+ 
+ 	mapping = file->f_mapping;
+ 	if (!mapping || len < 0 || !shmem_mapping(mapping))
+ 		return -EINVAL;
+ 
+ 	endbyte = fadvise_calc_endbyte(offset, len);
+ 
+ 	start_index = offset >> PAGE_SHIFT;
+ 	end_index   = endbyte >> PAGE_SHIFT;
+ 	switch (advice) {
+ 	case POSIX_FADV_DONTNEED:
+ 		ret = shmem_fadvise_dontneed(mapping, start_index, end_index);
+ 		break;
+ 	case POSIX_FADV_WILLNEED:
+ 		ret = shmem_fadvise_willneed(mapping, start_index, end_index);
+ 		break;
+ 	case POSIX_FADV_NORMAL:
+ 	case POSIX_FADV_RANDOM:
+ 	case POSIX_FADV_SEQUENTIAL:
+ 	case POSIX_FADV_NOREUSE:
+ 		/*
+ 		 * No bad return value, but ignore advice.
+ 		 */
+ 		break;
+ 	default:
+ 		return -EINVAL;
+ 	}
+ 
+ 	return ret;
+ }
+ 
 -static struct inode *shmem_get_inode(struct super_block *sb, struct inode *dir,
 -				     umode_t mode, dev_t dev, unsigned long flags)
 +static struct inode *shmem_get_inode(struct mnt_idmap *idmap, struct super_block *sb,
 +				     struct inode *dir, umode_t mode, dev_t dev,
 +				     unsigned long flags)
  {
  	struct inode *inode;
  	struct shmem_inode_info *info;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-11-07  2:52 Stephen Rothwell
  0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2022-11-07  2:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu (Google),
	Rafael Mendonca, wuqiang

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  kernel/trace/fprobe.c

between commit:

  d05ea35e7eea ("fprobe: Check rethook_alloc() return in rethook initialization")

from Linus' tree and commit:

  7ceeb4e77fec ("kprobes,lib: kretprobe scalability improvement")

from the mm tree.

I fixed it up (the latter included the fix from the former, so I just
used the latter) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-09-06  9:01 Stephen Rothwell
  2022-09-06  9:21 ` Rolf Eike Beer
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2022-09-06  9:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Rolf Eike Beer, Steven Price

[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/pagewalk.c

between commit:

  8782fb61cc84 ("mm: pagewalk: Fix race between unmap and page walker")

from Linus' tree and commits:

  fa02fb928200 ("mm: pagewalk: make error checks more obvious")
  66c217081bd0 ("mm: pagewalk: allow walk_page_range_novma() without mm")

from the mm tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/pagewalk.c
index fa7a3d21a751,418717eec09e..000000000000
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@@ -108,13 -104,16 +104,16 @@@ static int walk_pmd_range(pud_t *pud, u
  
  	pmd = pmd_offset(pud, addr);
  	do {
- again:
+ 		int err;
+ 
+  again:
  		next = pmd_addr_end(addr, end);
 -		if (pmd_none(*pmd) || (!walk->vma && !walk->no_vma)) {
 +		if (pmd_none(*pmd)) {
- 			if (ops->pte_hole)
+ 			if (ops->pte_hole) {
  				err = ops->pte_hole(addr, next, depth, walk);
- 			if (err)
- 				break;
+ 				if (err)
+ 					return err;
+ 			}
  			continue;
  		}
  
@@@ -169,13 -168,16 +168,16 @@@ static int walk_pud_range(p4d_t *p4d, u
  
  	pud = pud_offset(p4d, addr);
  	do {
+ 		int err;
+ 
   again:
  		next = pud_addr_end(addr, end);
 -		if (pud_none(*pud) || (!walk->vma && !walk->no_vma)) {
 +		if (pud_none(*pud)) {
- 			if (ops->pte_hole)
+ 			if (ops->pte_hole) {
  				err = ops->pte_hole(addr, next, depth, walk);
- 			if (err)
- 				break;
+ 				if (err)
+ 					return err;
+ 			}
  			continue;
  		}
  
@@@ -447,20 -456,17 +456,21 @@@ int walk_page_range(struct mm_struct *m
  
  	vma = find_vma(walk.mm, start);
  	do {
+ 		int err;
+ 
+ 		walk.vma = vma;
  		if (!vma) { /* after the last vma */
- 			walk.vma = NULL;
  			next = end;
 +			if (ops->pte_hole)
 +				err = ops->pte_hole(start, next, -1, &walk);
  		} else if (start < vma->vm_start) { /* outside vma */
  			walk.vma = NULL;
  			next = min(end, vma->vm_start);
 +			if (ops->pte_hole)
 +				err = ops->pte_hole(start, next, -1, &walk);
  		} else { /* inside vma */
- 			walk.vma = vma;
  			next = min(end, vma->vm_end);
- 			vma = vma->vm_next;
+ 			vma = find_vma(mm, vma->vm_end);
  
  			err = walk_page_test(start, next, &walk);
  			if (err > 0) {
@@@ -472,17 -478,26 +482,24 @@@
  				continue;
  			}
  			if (err < 0)
- 				break;
+ 				return err;
 -		}
 -		if (walk.vma || walk.ops->pte_hole) {
  			err = __walk_page_range(start, next, &walk);
+ 			if (err)
+ 				return err;
  		}
- 		if (err)
- 			break;
  	} while (start = next, start < end);
- 	return err;
+ 	return 0;
  }
  
- /*
+ /**
+  * walk_page_range_novma - walk a range of pagetables not backed by a vma
+  * @mm:		mm_struct representing the target process of page table walk
+  * @start:	start address of the virtual address range
+  * @end:	end address of the virtual address range
+  * @ops:	operation to call during the walk
+  * @pgd:	pgd to walk if different from mm->pgd
+  * @private:	private data for callbacks' usage
+  *
   * Similar to walk_page_range() but can walk any page tables even if they are
   * not backed by VMAs. Because 'unusual' entries may be walked this function
   * will also not lock the PTEs for the pte_entry() callback. This is useful for
@@@ -501,10 -518,11 +520,11 @@@ int walk_page_range_novma(struct mm_str
  		.no_vma		= true
  	};
  
- 	if (start >= end || !walk.mm)
+ 	if (start >= end || (!walk.mm && !walk.pgd))
  		return -EINVAL;
  
- 	mmap_assert_write_locked(walk.mm);
+ 	if (walk.mm)
 -		mmap_assert_locked(walk.mm);
++		mmap_assert_write_locked(walk.mm);
  
  	return walk_pgd_range(start, end, &walk);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread
* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-05-26  6:09 Stephen Rothwell
  0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2022-05-26  6:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Oliver Glitta, Vlastimil Babka

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hi all,

Today's linux-next merge of the mm tree got conflicts in:

  init/Kconfig
  lib/Kconfig.debug

between commit:

  5cf909c553e9 ("mm/slub: use stackdepot to save stack trace in objects")

from Linus' tree and commit:

  21445ae47041 ("mm: Kconfig: reorganize misplaced mm options")

from the mm tree.

I fixed it up (I used the latter version of this file and applied the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 26 May 2022 16:05:37 +1000
Subject: [PATCH] fix up for "mm: Kconfig: reorganize misplaced mm options"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/Kconfig.debug | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 197eb287bf82..ce8dded36de9 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -57,6 +57,7 @@ config SLUB_DEBUG
 	default y
 	bool "Enable SLUB debugging support" if EXPERT
 	depends on SLUB && SYSFS
+	select STACKDEPOT if STACKTRACE_SUPPORT
 	help
 	  SLUB has extensive debug support features. Disabling these can
 	  result in significant savings in code size. This also disables
@@ -66,6 +67,7 @@ config SLUB_DEBUG
 config SLUB_DEBUG_ON
 	bool "SLUB debugging on by default"
 	depends on SLUB && SLUB_DEBUG
+	select STACKDEPOT_ALWAYS_INIT if STACKTRACE_SUPPORT
 	default n
 	help
 	  Boot with debugging on by default. SLUB boots by default with
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 30+ messages in thread
end of thread, other threads:[~2023-07-28  3:13 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-27 23:18 linux-next: manual merge of the mm tree with Linus' tree Stephen Rothwell
2023-07-27 23:29 ` Stephen Rothwell
2023-07-27 23:40   ` Suren Baghdasaryan
2023-07-27 23:50     ` Matthew Wilcox
2023-07-28  0:08       ` Suren Baghdasaryan
2023-07-28  0:00   ` Stephen Rothwell
2023-07-28  3:13     ` Matthew Wilcox
2023-07-27 23:49 ` Matthew Wilcox
2023-07-28  0:21   ` Stephen Rothwell
2023-07-28  0:23     ` Suren Baghdasaryan
2023-07-28  0:29       ` Stephen Rothwell
2023-07-28  0:30         ` Suren Baghdasaryan
  -- strict thread matches above, loose matches on Subject: below --
2023-07-06 22:54 Stephen Rothwell
2023-07-07  4:52 ` Baoquan He
2023-06-18 23:23 Stephen Rothwell
2023-06-19 20:25 ` Andrew Morton
2023-06-19 20:43 ` Will Deacon
2023-06-19 21:39   ` Andrew Morton
2023-06-20  9:43     ` Will Deacon
2023-06-20 15:00       ` Jain, Ayush
2023-02-24 23:39 Stephen Rothwell
2023-02-25  2:04 ` Andrew Morton
2023-02-25  7:13   ` Christian Brauner
2023-02-25 20:52     ` Andrew Morton
2023-02-27 10:18       ` Christian Brauner
2023-02-27 17:55         ` Andrew Morton
2022-11-07  2:52 Stephen Rothwell
2022-09-06  9:01 Stephen Rothwell
2022-09-06  9:21 ` Rolf Eike Beer
2022-05-26  6:09 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).