lp:~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack

Get this repository:
git clone https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
Members of Ubuntu Kernel Test can upload to this repository. Log in for directions.

Updating repository...

Launchpad is processing new changes to this repository which will be available shortly. Reload to see the changes.

Branches

Name Last Modified Last Commit
master 2024-04-24 16:22:51 UTC
Merge tag 'for-6.9-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/...

Author: Linus Torvalds
Author Date: 2024-04-24 16:22:51 UTC

Merge tag 'for-6.9-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux

Pull btrfs fixes from David Sterba:

 - fix information leak by the buffer returned from LOGICAL_INO ioctl

 - fix flipped condition in scrub when tracking sectors in zoned mode

 - fix calculation when dropping extent range

 - reinstate fallback to write uncompressed data in case of fragmented
   space that could not store the entire compressed chunk

 - minor fix to message formatting style to make it conforming to the
   commonly used style

* tag 'for-6.9-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: fix wrong block_start calculation for btrfs_drop_extent_map_range()
  btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
  btrfs: fallback if compressed IO fails for ENOSPC
  btrfs: scrub: run relocation repair when/only needed
  btrfs: remove colon from messages with state

x86-uaccess-cleanup 2023-05-03 17:37:22 UTC
x86-64: mm: clarify the 'positive addresses' user address rules

Author: Linus Torvalds
Author Date: 2023-05-03 17:13:41 UTC

x86-64: mm: clarify the 'positive addresses' user address rules

Dave Hansen found the "(long) addr >= 0" code in the x86-64 access_ok
checks somewhat confusing, and suggested using a helper to clarify what
the code is doing.

So this does exactly that: clarifying what the sign bit check is all
about, by adding a helper macro that makes it clear what it is testing.

This also adds some explicit comments talking about how even with LAM
enabled, any addresses with the sign bit will still GP-fault in the
non-canonical region just above the sign bit.

This is all what allows us to do the user address checks with just the
sign bit, and furthermore be a bit cavalier about accesses that might be
done with an additional offset even past that point.

(And yes, this talks about 'positive' even though zero is also a valid
user address and so technically we should call them 'non-negative'. But
I don't think using 'non-negative' ends up being more understandable).

Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86-rep-insns 2023-04-16 03:03:37 UTC
x86: inline the 'rep movs' in user copies for the FSRM case

Author: Linus Torvalds
Author Date: 2023-04-16 02:31:34 UTC

x86: inline the 'rep movs' in user copies for the FSRM case

This does the same thing for the user copies as commit 0db7058e8e23
("x86/clear_user: Make it faster") did for clear_user(). In other
words, it inlines the "rep movs" case when X86_FEATURE_FSRM is set,
avoiding the function call entirely.

In order to do that, it makes the calling convention for the out-of-line
case ("copy_user_generic_unrolled") match the 'rep movs' calling
convention, although it does also end up clobbering a number of
additional registers.

Also, to simplify code sharing in the low-level assembly with the
__copy_user_nocache() function (that uses the normal C calling
convention), we end up with a kind of mixed return value for the
low-level asm code: it will return the result in both %rcx (to work as
an alternative for the 'rep movs' case), _and_ in %rax (for the nocache
case).

We could avoid this by wrapping __copy_user_nocache() callers in an
inline asm, but since the cost is just an extra register copy, it's
probably not worth it.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmu_gather-race-fix 2022-10-31 18:22:42 UTC
mm: delay rmap removal until after TLB flush

Author: Linus Torvalds
Author Date: 2022-10-29 18:45:07 UTC

mm: delay rmap removal until after TLB flush

When we remove a page table entry, we are very careful to only free the
page after we have flushed the TLB, because other CPUs could still be
using the page through stale TLB entries until after the flush.

However, we have removed the rmap entry for that page early, which means
that functions like folio_mkclean() would end up not serializing with
the page table lock because the page had already been made invisible to
rmap.

And that is a problem, because while the TLB entry exists, we could end
up with the followign situation:

 (a) one CPU could come in and clean it, never seeing our mapping of
     the page

 (b) another CPU could continue to use the stale and dirty TLB entry
     and continue to write to said page

resulting in a page that has been dirtied, but then marked clean again,
all while another CPU might have dirtied it some more.

End result: possibly lost dirty data.

This commit uses the same old TLB gather array that we use to delay the
freeing of the page to also say 'remove from rmap after flush', so that
we can keep the rmap entries alive until all TLB entries have been
flushed.

NOTE! While the "possibly lost dirty data" sounds catastrophic, for this
all to happen you need to have a user thread doing either madvise() with
MADV_DONTNEED or a full re-mmap() of the area concurrently with another
thread continuing to use said mapping.

So arguably this is about user space doing crazy things, but from a VM
consistency standpoint it's better if we track the dirty bit properly
even when user space goes off the rails.

Reported-by: Nadav Amit <nadav.amit@gmail.com>
Link: Link: https://lore.kernel.org/all/B88D3073-440A-41C7-95F4-895D3F657EF2@gmail.com/
Cc: Will Deacon <will@kernel.org>
Cc: Aneesh Kumar <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

tty-splice 2021-01-21 18:34:33 UTC
tty: fix up iterate_tty_read() EOVERFLOW handling

Author: Linus Torvalds
Author Date: 2021-01-21 18:17:25 UTC

tty: fix up iterate_tty_read() EOVERFLOW handling

When I converted the tty_ldisc_ops 'read()' function to take a kernel
pointer, I was a bit too aggressive about the ldisc returning EOVERFLOW.

Yes, we want to have EOVERFLOW override any partially read data (because
the whole point is that the buffer was too small for the whole packet,
and we don't want to see partial packets), but it shouldn't override a
previous EFAULT.

And in fact, it really is just EOVERFLOW that is special and should
throw away any partially read data, not "any error". Admittedly
EOVERFLOW is currently the only one that can happen for a continuation
read - and if the first read iteration returns an error we won't have this issue.

So this is more of a technicality, but let's just make the intent very
explicit, and re-organize the error handling a bit so that this is all
clearer.

Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

linus 2018-09-17 05:24:28 UTC
Merge tag 'linux-kselftest-4.19-rc5' of git://git.kernel.org/pub/scm/linux/ke...

Author: Greg Kroah-Hartman
Author Date: 2018-09-17 05:24:28 UTC

Merge tag 'linux-kselftest-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

Pulled kselftest fixes from Shuah:
 "This Kselftest fixes update for 4.9-rc5 consists of:

  -- fixes to build failures
  -- fixes to add missing config files to increase test coverage
  -- fixes to cgroup test and a new cgroup test for memory.oom.group"

tlb-fixes 2018-08-23 18:56:31 UTC
x86/mm: Only use tlb_remove_table() for paravirt

Author: Peter Zijlstra
Author Date: 2018-08-22 15:30:16 UTC

x86/mm: Only use tlb_remove_table() for paravirt

If we don't use paravirt; don't play unnecessary and complicated games
to free page-tables.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Rik van Riel <riel@surriel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

proc-cmdline 2018-05-17 22:35:02 UTC
fs/proc: simplify and clarify get_mm_cmdline() function

Author: Linus Torvalds
Author Date: 2018-05-17 22:17:33 UTC

fs/proc: simplify and clarify get_mm_cmdline() function

We have some very odd semantics for reading the command line through
/proc, because we allow people to rewrite their own command line pretty
much at will, and things get positively funky when you extend your
command line past the point that used to be the end of the command line,
and is now in the environment variable area.

But our weird semantics doesn't mean that we should write weird and
complex code to handle them.

So re-write get_mm_cmdline() to be much simpler, and much more explicit
about what it is actually doing and why. And avoid the extra check for
"is there a NUL character at the end of the command line where I expect
one to be", by simply making the NUL character handling be part of the
normal "once you hit the end of the command line, stop at the first NUL
character" logic.

It's quite possible that we should stop the crazy "walk into
environment" entirely, but happily it's not really the usual case.

NOTE! We tried to really simplify and limit our odd cmdline parsing some
time ago, but people complained. See commit c2c0bb44620d ("proc: fix
PAGE_SIZE limit of /proc/$PID/cmdline") for details about why we have
this complexity.

Cc: Tejun Heo <tj@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

WIP-syscall 2018-02-27 21:25:49 UTC
Broken, but working, ptregs system call conversion for x86-64

Author: Linus Torvalds
Author Date: 2018-02-27 20:39:30 UTC

Broken, but working, ptregs system call conversion for x86-64

Not-yet-signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

next 2014-06-06 23:35:10 UTC
Merge branch 'akpm' (patches from Andrew Morton) into next

Author: Linus Torvalds
Author Date: 2014-06-06 23:35:10 UTC

Merge branch 'akpm' (patches from Andrew Morton) into next

Merge more updates from Andrew Morton:

 - Most of the rest of MM.

   This includes "mark remap_file_pages syscall as deprecated" but the
   actual "replace remap_file_pages syscall with emulation" is held
   back. I guess we'll need to work out when to pull the trigger on
   that one.

 - various minor cleanups to obscure filesystems

 - the drivers/rtc queue

 - hfsplus updates

 - ufs, hpfs, fatfs, affs, reiserfs

 - Documentation/

 - signals

 - procfs

 - cpu hotplug

 - lib/idr.c

 - rapidio

 - sysctl

 - ipc updates

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (171 commits)
  ufs: sb mutex merge + mutex_destroy
  powerpc: update comments for generic idle conversion
  cris: update comments for generic idle conversion
  idle: remove cpu_idle() forward declarations
  nbd: zero from and len fields in NBD_CMD_DISCONNECT.
  mm: convert some level-less printks to pr_*
  MAINTAINERS: adi-buildroot-devel is moderated
  MAINTAINERS: add linux-api for review of API/ABI changes
  mm/kmemleak-test.c: use pr_fmt for logging
  fs/dlm/debug_fs.c: replace seq_printf by seq_puts
  fs/dlm/lockspace.c: convert simple_str to kstr
  fs/dlm/config.c: convert simple_str to kstr
  mm: mark remap_file_pages() syscall as deprecated
  mm: memcontrol: remove unnecessary memcg argument from soft limit functions
  mm: memcontrol: clean up memcg zoneinfo lookup
  mm/memblock.c: call kmemleak directly from memblock_(alloc|free)
  mm/mempool.c: update the kmemleak stack trace for mempool allocations
  lib/radix-tree.c: update the kmemleak stack trace for radix tree allocations
  mm: introduce kmemleak_update_trace()
  mm/kmemleak.c: use %u to print ->checksum
  ...

110 of 10 results
This repository contains Public information 
Everyone can see this information.