* Re: [GIT PULL] pipe: Notification queue preparation
From: Linus Torvalds @ 2019-12-05 17:33 UTC (permalink / raw)
To: David Sterba, David Howells, Linus Torvalds, Rasmus Villemoes,
Greg Kroah-Hartman, Peter Zijlstra, raven, Christian Brauner,
keyrings, linux-usb, linux-block, LSM List, linux-fsdevel,
Linux API, Linux Kernel Mailing List
In-Reply-To: <20191205172127.GW2734@suse.cz>
On Thu, Dec 5, 2019 at 9:22 AM David Sterba <dsterba@suse.cz> wrote:
>
> I rerun the test again (with a different address where it's stuck), there's
> nothing better I can get from the debug info, it always points to pipe_wait,
> disassembly points to.
Hah. I see another bug.
"pipe_wait()" depends on the fact that all events that wake it up
happen with the pipe lock held.
But we do some of the "do_wakeup()" handling outside the pipe lock now
on the reader side
__pipe_unlock(pipe);
/* Signal writers asynchronously that there is more room. */
if (do_wakeup) {
wake_up_interruptible_poll(&pipe->wait, EPOLLOUT | EPOLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
However, that isn't new to this series _either_, so I don't think
that's it. It does wake up things inside the lock _too_ if it ended up
emptying a whole buffer.
So it could be triggered by timing and behavior changes, but I doubt
this pipe_wait() thing is it either. The fact that it bisects to the
thing that changes things to use head/tail pointers makes me think
there's some other incorrect update or comparison somewhere.
That said, "pipe_wait()" is an abomination. It should use a proper
wait condition and use wait_event(), but the code predates all of
that. I suspect pipe_wait() goes back to the dark ages with the BKL
and no actual races between kernel code.
Linus
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: David Howells @ 2019-12-05 17:25 UTC (permalink / raw)
To: dsterba
Cc: dhowells, torvalds, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api,
linux-kernel
In-Reply-To: <20191205172127.GW2734@suse.cz>
I've just posted a couple of patches - can you check to see if they fix your
problem?
https://lore.kernel.org/linux-fsdevel/157556649610.20869.8537079649495343567.stgit@warthog.procyon.org.uk/T/#t
Thanks,
David
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: Linus Torvalds @ 2019-12-05 17:24 UTC (permalink / raw)
To: David Howells
Cc: David Sterba, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, LSM List, linux-fsdevel, Linux API,
Linux Kernel Mailing List
In-Reply-To: <CAHk-=wgwwJ+ZEtycujFdNmpS8TjwCYyT+oHfV7d-GekyaX91xg@mail.gmail.com>
On Thu, Dec 5, 2019 at 9:12 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> It would be interesting to hear if somebody else is waiting on the
> read side too.
Looking once more at that commit, I find at least one bug, but I'm
pretty sure that's not the cause of this problem.
DavidH, watch out for things like this:
- for (idx = 0; idx < pipe->nrbufs && rem < len; idx++)
+ for (idx = tail; idx < head && rem < len; idx++)
which is a completely buggy conversion.
You can't compare tail and head with an inequality, it gets the
wraparound case wrong.
But I found only one of those, and it's fuse-specific, plus the
overflow would take a long time to trigger, so I'm pretty sure this
isn't what DavidS is reporting.
Linus
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: David Sterba @ 2019-12-05 17:21 UTC (permalink / raw)
To: David Howells
Cc: torvalds, Rasmus Villemoes, Greg Kroah-Hartman, Peter Zijlstra,
raven, Christian Brauner, keyrings, linux-usb, linux-block,
linux-security-module, linux-fsdevel, linux-api, linux-kernel
In-Reply-To: <1593.1575554217@warthog.procyon.org.uk>
On Thu, Dec 05, 2019 at 01:56:57PM +0000, David Howells wrote:
> David Sterba <dsterba@suse.cz> wrote:
>
> > [<0>] pipe_write+0x1be/0x4b0
>
> Can you get me a line number of that? Assuming you've built with -g, load
> vmlinux into gdb and do "i li pipe_write+0x1be".
I built it with -g (DEBUG_INFO) but there's no output for the command (gdb 8.2):
(gdb) i li pipe_write+0x1be
Function "pipe_write+0x1be" not defined.
But the address can tell something:
(gdb) l *(pipe_write+0x1be)
0xffffffff81390b8e is in pipe_write (fs/pipe.c:509).
warning: Source file is more recent than executable.
504 kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
505 do_wakeup = 0;
506 }
507 pipe->waiting_writers++;
508 pipe_wait(pipe);
509 pipe->waiting_writers--;
510 }
511 out:
512 __pipe_unlock(pipe);
513 if (do_wakeup) {
I rerun the test again (with a different address where it's stuck), there's
nothing better I can get from the debug info, it always points to pipe_wait,
disassembly points to:
0xffffffff81390b71 <+417>: jne 0xffffffff81390c23 <pipe_write+595>
0xffffffff81390b77 <+423>: test %ecx,%ecx
0xffffffff81390b79 <+425>: jne 0xffffffff81390b95 <pipe_write+453>
0xffffffff81390b7b <+427>: addl $0x1,0x110(%rbx)
0xffffffff81390b82 <+434>: mov %rbx,%rdi
0xffffffff81390b85 <+437>: callq 0xffffffff813908c0 <pipe_wait>
0xffffffff81390b8a <+442>: subl $0x1,0x110(%rbx)
(pipe_write+0x1ba == 0xffffffff81390b8a)
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: Linus Torvalds @ 2019-12-05 17:12 UTC (permalink / raw)
To: David Howells
Cc: David Sterba, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, LSM List, linux-fsdevel, Linux API,
Linux Kernel Mailing List
In-Reply-To: <1593.1575554217@warthog.procyon.org.uk>
On Thu, Dec 5, 2019 at 5:57 AM David Howells <dhowells@redhat.com> wrote:
>
> David Sterba <dsterba@suse.cz> wrote:
>
> > [<0>] pipe_write+0x1be/0x4b0
>
> Can you get me a line number of that? Assuming you've built with -g, load
> vmlinux into gdb and do "i li pipe_write+0x1be".
If the kernel is built with debug info (which you need for the gdb
command anyway), it's much better to just use
./scripts/decode_stacktrace.sh
which gives all the information for the whole backtrace.
It would be interesting to hear if somebody else is waiting on the
read side too.
Linus
^ permalink raw reply
* Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings
From: Mike Rapoport @ 2019-12-05 15:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: LKML, Alexey Dobriyan, Andrew Morton, Arnd Bergmann,
Borislav Petkov, Dave Hansen, James Bottomley, Peter Zijlstra,
Steven Rostedt, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Linux API, Linux-MM, X86 ML, Mike Rapoport, Alan Cox,
Reshetova, Elena, Tycho Andersen, Christopher Lameter
In-Reply-To: <CALCETrXajrY+0SmzkL7t++ndYwRoYLLE9VPKwSGSyW8HZx-TeA@mail.gmail.com>
On Wed, Oct 30, 2019 at 02:28:21PM -0700, Andy Lutomirski wrote:
>
> IMO a major benefit of a chardev approach is that you don't need a new
> VM_ flag and you don't need to worry about wiring it up everywhere in
> the core mm code.
I've done a couple of experiments with secret/exclusive/whatever
memory backed by a file-descriptor using a chardev and memfd_create
syscall. There is indeed no need for VM_ flag, but there are still places
that would require special care, e.g vm_normal_page(), madvise(DO_FORK), so
it won't be completely free of core mm modifications.
Below is a POC that implements extension to memfd_create() that allows
mapping of a "secret" memory. The "secrecy" mode should be explicitly set
using ioctl(), for now I've implemented exclusive and uncached mappings.
The POC primarily indented to illustrate a possible userspace API for
fd-based secret memory. The idea is that user will create a file
descriptor using a system call. The user than has to use ioctl() to define
the desired mode of operation and only when the mode is set it is possible
to mmap() the memory. I.e something like
fd = memfd_create("secret", MFD_SECRET);
ioctl(fd, MFD_SECRET_UNCACHED);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, 0);
The ioctl() allows a lot of flexibility in how the secrecy should be
defined. It could be either a request for a particular protection (e.g.
exclusive, uncached) or something like "secrecy level" from "a bit more
secret than normally" to "do your best even at the expense of performance".
The POC implements the first option and the modes are mutually exclusive
for now, but there is no fundamental reason they cannot be mixed.
I've chosen memfd over a chardev as it seem to play more neatly with
anon_inodes and would allow simple (ab)use of the page cache for tracking
pages allocated for the "secret" mappings as well as using
address_space_operations for e.g. page migration callbacks.
The POC implementation uses set_memory/pageattr APIs to manipulate the
direct map and does not address the direct map fragmentation issue.
Of course this is something that must be addresses, as well as
modifications to core mm to required keep the secret memory secret, but I'd
really like to focus on the userspace ABI first.
>From 0e1bd1b63f38685ffc5aab8c89b31086bde3da7b Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Mon, 18 Nov 2019 09:32:22 +0200
Subject: [PATCH] mm: extend memfd with ability to create secret memory
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
include/linux/memfd.h | 9 ++
include/uapi/linux/magic.h | 1 +
include/uapi/linux/memfd.h | 6 +
mm/Kconfig | 3 +
mm/Makefile | 1 +
mm/memfd.c | 10 +-
mm/secretmem.c | 233 +++++++++++++++++++++++++++++++++++++
7 files changed, 261 insertions(+), 2 deletions(-)
create mode 100644 mm/secretmem.c
diff --git a/include/linux/memfd.h b/include/linux/memfd.h
index 4f1600413f91..d3ca7285f51a 100644
--- a/include/linux/memfd.h
+++ b/include/linux/memfd.h
@@ -13,4 +13,13 @@ static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned long a)
}
#endif
+#ifdef CONFIG_MEMFD_SECRETMEM
+extern struct file *secretmem_file_create(const char *name, unsigned int flags);
+#else
+static inline struct file *secretmem_file_create(const char *name, unsigned int flags)
+{
+ return ERR_PTR(-EINVAL);
+}
+#endif
+
#endif /* __LINUX_MEMFD_H */
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index 903cc2d2750b..3dad6208c8de 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -94,5 +94,6 @@
#define ZSMALLOC_MAGIC 0x58295829
#define DMA_BUF_MAGIC 0x444d4142 /* "DMAB" */
#define Z3FOLD_MAGIC 0x33
+#define SECRETMEM_MAGIC 0x5345434d /* "SECM" */
#endif /* __LINUX_MAGIC_H__ */
diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
index 7a8a26751c23..3320a79b638d 100644
--- a/include/uapi/linux/memfd.h
+++ b/include/uapi/linux/memfd.h
@@ -8,6 +8,12 @@
#define MFD_CLOEXEC 0x0001U
#define MFD_ALLOW_SEALING 0x0002U
#define MFD_HUGETLB 0x0004U
+#define MFD_SECRET 0x0008U
+
+/* ioctls for secret memory */
+#define MFD_SECRET_IOCTL '-'
+#define MFD_SECRET_EXCLUSIVE _IOW(MFD_SECRET_IOCTL, 0x13, unsigned long)
+#define MFD_SECRET_UNCACHED _IOW(MFD_SECRET_IOCTL, 0x14, unsigned long)
/*
* Huge page size encoding when MFD_HUGETLB is specified, and a huge page
diff --git a/mm/Kconfig b/mm/Kconfig
index a5dae9a7eb51..aa828f240287 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -736,4 +736,7 @@ config ARCH_HAS_PTE_SPECIAL
config ARCH_HAS_HUGEPD
bool
+config MEMFD_SECRETMEM
+ def_bool MEMFD_CREATE && ARCH_HAS_SET_DIRECT_MAP
+
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..54cb8a60d698 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -107,3 +107,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
obj-$(CONFIG_ZONE_DEVICE) += memremap.o
obj-$(CONFIG_HMM_MIRROR) += hmm.o
obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_MEMFD_SECRETMEM) += secretmem.o
diff --git a/mm/memfd.c b/mm/memfd.c
index 2647c898990c..3e1cc37e0389 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -245,7 +245,8 @@ long memfd_fcntl(struct file *file, unsigned int cmd, unsigned long arg)
#define MFD_NAME_PREFIX_LEN (sizeof(MFD_NAME_PREFIX) - 1)
#define MFD_NAME_MAX_LEN (NAME_MAX - MFD_NAME_PREFIX_LEN)
-#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB)
+#define MFD_SECRET_MASK (MFD_CLOEXEC | MFD_SECRET)
+#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_SECRET)
SYSCALL_DEFINE2(memfd_create,
const char __user *, uname,
@@ -257,6 +258,9 @@ SYSCALL_DEFINE2(memfd_create,
char *name;
long len;
+ if (flags & ~(unsigned int)MFD_SECRET_MASK)
+ return -EINVAL;
+
if (!(flags & MFD_HUGETLB)) {
if (flags & ~(unsigned int)MFD_ALL_FLAGS)
return -EINVAL;
@@ -296,7 +300,9 @@ SYSCALL_DEFINE2(memfd_create,
goto err_name;
}
- if (flags & MFD_HUGETLB) {
+ if (flags & MFD_SECRET) {
+ file = secretmem_file_create(name, flags);
+ } else if (flags & MFD_HUGETLB) {
struct user_struct *user = NULL;
file = hugetlb_file_setup(name, 0, VM_NORESERVE, &user,
diff --git a/mm/secretmem.c b/mm/secretmem.c
new file mode 100644
index 000000000000..e787b8dc925b
--- /dev/null
+++ b/mm/secretmem.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/printk.h>
+#include <linux/fs.h>
+#include <linux/mount.h>
+#include <linux/memfd.h>
+#include <linux/pseudo_fs.h>
+#include <linux/set_memory.h>
+#include <uapi/linux/memfd.h>
+#include <uapi/linux/magic.h>
+
+#include <asm/tlb.h>
+
+#define SECRETMEM_EXCLUSIVE 0x1
+#define SECRETMEM_UNCACHED 0x2
+
+struct secretmem_state {
+ unsigned int mode;
+};
+
+static vm_fault_t secretmem_fault(struct vm_fault *vmf)
+{
+ struct secretmem_state *state = vmf->vma->vm_file->private_data;
+ struct address_space *mapping = vmf->vma->vm_file->f_mapping;
+ pgoff_t offset = vmf->pgoff;
+ unsigned long addr;
+ struct page *page;
+ int err;
+
+ page = find_get_page(mapping, offset);
+ if (!page) {
+ page = pagecache_get_page(mapping, offset,
+ FGP_CREAT|FGP_FOR_MMAP,
+ vmf->gfp_mask);
+ if (!page)
+ return vmf_error(-ENOMEM);
+
+ __SetPageUptodate(page);
+ }
+
+ if (state->mode == SECRETMEM_EXCLUSIVE)
+ err = set_direct_map_invalid_noflush(page);
+ else if (state->mode == SECRETMEM_UNCACHED)
+ err = set_pages_array_uc(&page, 1);
+ else
+ BUG();
+
+ if (err) {
+ delete_from_page_cache(page);
+ return vmf_error(err);
+ }
+
+ addr = (unsigned long)page_address(page);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+
+ vmf->page = page;
+ return 0;
+}
+
+static void secretmem_close(struct vm_area_struct *vma)
+{
+ struct secretmem_state *state = vma->vm_file->private_data;
+ struct address_space *mapping = vma->vm_file->f_mapping;
+ struct page *page;
+ pgoff_t index;
+
+ xa_for_each(&mapping->i_pages, index, page) {
+ get_page(page);
+ lock_page(page);
+
+ if (state->mode == SECRETMEM_EXCLUSIVE)
+ set_direct_map_default_noflush(page);
+ else if (state->mode == SECRETMEM_UNCACHED)
+ set_pages_array_wb(&page, 1);
+ else
+ BUG();
+
+ __ClearPageDirty(page);
+ delete_from_page_cache(page);
+
+ unlock_page(page);
+ put_page(page);
+ }
+}
+
+static const struct vm_operations_struct secretmem_vm_ops = {
+ .fault = secretmem_fault,
+ .close = secretmem_close,
+};
+
+static int secretmem_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct secretmem_state *state = file->private_data;
+ unsigned long mode = state->mode;
+
+ if (!mode)
+ return -EINVAL;
+
+ switch (mode) {
+ case SECRETMEM_UNCACHED:
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ /* fallthrough */
+ case SECRETMEM_EXCLUSIVE:
+ vma->vm_ops = &secretmem_vm_ops;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static long secretmem_ioctl(struct file *file, unsigned cmd, unsigned long arg)
+{
+ struct secretmem_state *state = file->private_data;
+ unsigned long mode = state->mode;
+
+ if (mode)
+ return -EINVAL;
+
+ switch (cmd) {
+ case MFD_SECRET_EXCLUSIVE:
+ mode = SECRETMEM_EXCLUSIVE;
+ break;
+ case MFD_SECRET_UNCACHED:
+ mode = SECRETMEM_UNCACHED;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ state->mode = mode;
+
+ return 0;
+}
+
+static int secretmem_release(struct inode *inode, struct file *file)
+{
+ struct secretmem_state *state = file->private_data;
+
+ kfree(state);
+
+ return 0;
+}
+
+const struct file_operations secretmem_fops = {
+ .release = secretmem_release,
+ .mmap = secretmem_mmap,
+ .unlocked_ioctl = secretmem_ioctl,
+ .compat_ioctl = secretmem_ioctl,
+};
+
+static bool secretmem_isolate_page(struct page *page, isolate_mode_t mode)
+{
+ return false;
+}
+
+static int secretmem_migratepage(struct address_space *mapping,
+ struct page *newpage, struct page *page,
+ enum migrate_mode mode)
+{
+ return -EBUSY;
+}
+
+static void secretmem_putback_page(struct page *page)
+{
+}
+
+static const struct address_space_operations secretmem_aops = {
+ .migratepage = secretmem_migratepage,
+ .isolate_page = secretmem_isolate_page,
+ .putback_page = secretmem_putback_page,
+};
+
+static struct vfsmount *secretmem_mnt;
+
+struct file *secretmem_file_create(const char *name, unsigned int flags)
+{
+ struct inode *inode = alloc_anon_inode(secretmem_mnt->mnt_sb);
+ struct file *file = ERR_PTR(-ENOMEM);
+ struct secretmem_state *state;
+
+ if (IS_ERR(inode))
+ return ERR_CAST(inode);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ goto err_free_inode;
+
+ file = alloc_file_pseudo(inode, secretmem_mnt, "secretmem",
+ O_RDWR, &secretmem_fops);
+ if (IS_ERR(file))
+ goto err_free_state;
+
+ mapping_set_unevictable(inode->i_mapping);
+
+ inode->i_mapping->private_data = state;
+ inode->i_mapping->a_ops = &secretmem_aops;
+
+ file->private_data = state;
+
+ return file;
+
+err_free_state:
+ kfree(state);
+err_free_inode:
+ iput(inode);
+ return file;
+}
+
+static int secretmem_init_fs_context(struct fs_context *fc)
+{
+ return init_pseudo(fc, SECRETMEM_MAGIC) ? 0 : -ENOMEM;
+}
+
+static struct file_system_type secretmem_fs = {
+ .name = "secretmem",
+ .init_fs_context = secretmem_init_fs_context,
+ .kill_sb = kill_anon_super,
+};
+
+static int secretmem_init(void)
+{
+ int ret = 0;
+
+ secretmem_mnt = kern_mount(&secretmem_fs);
+ if (IS_ERR(secretmem_mnt))
+ ret = PTR_ERR(secretmem_mnt);
+
+ return ret;
+}
+fs_initcall(secretmem_init);
--
2.24.0
--
Sincerely yours,
Mike.
^ permalink raw reply related
* Re: [GIT PULL] pipe: Notification queue preparation
From: David Howells @ 2019-12-05 13:56 UTC (permalink / raw)
To: dsterba
Cc: dhowells, torvalds, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api,
linux-kernel
In-Reply-To: <20191205125826.GK2734@twin.jikos.cz>
David Sterba <dsterba@suse.cz> wrote:
> [<0>] pipe_write+0x1be/0x4b0
Can you get me a line number of that? Assuming you've built with -g, load
vmlinux into gdb and do "i li pipe_write+0x1be".
David
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: David Sterba @ 2019-12-05 12:58 UTC (permalink / raw)
To: David Howells
Cc: torvalds, Rasmus Villemoes, Greg Kroah-Hartman, Peter Zijlstra,
raven, Christian Brauner, keyrings, linux-usb, linux-block,
linux-security-module, linux-fsdevel, linux-api, linux-kernel
In-Reply-To: <31452.1574721589@warthog.procyon.org.uk>
On Mon, Nov 25, 2019 at 10:39:49PM +0000, David Howells wrote:
> David Howells (12):
> pipe: Reduce #inclusion of pipe_fs_i.h
> Remove the nr_exclusive argument from __wake_up_sync_key()
> Add wake_up_interruptible_sync_poll_locked()
> pipe: Use head and tail pointers for the ring, not cursor and length
This commit (8cefc107ca54c8b06438b7dc9) causes hangs of 'btrfs send'
commands, that's eg. inside fstests or in btrfs-progs testsuite. The
'send' uses pipe/splice to get data from kernel to userspace.
The test that reliably worked for me leaves the process hanging with
this stacktrace (no CPU or IO activity):
[<0>] pipe_write+0x1be/0x4b0
[<0>] new_sync_write+0x11e/0x1c0
[<0>] vfs_write+0xc1/0x1d0
[<0>] kernel_write+0x2c/0x40
[<0>] send_cmd+0x78/0xf0 [btrfs]
[<0>] send_extent_data+0x4b1/0x52c [btrfs]
[<0>] process_extent+0xe46/0xe9d [btrfs]
[<0>] changed_cb+0xcf5/0xd2f [btrfs]
[<0>] send_subvol+0x8ad/0xc0b [btrfs]
[<0>] btrfs_ioctl_send+0xe50/0xf30 [btrfs]
[<0>] _btrfs_ioctl_send+0x80/0x110 [btrfs]
[<0>] btrfs_ioctl+0x18e1/0x3450 [btrfs]
[<0>] do_vfs_ioctl+0xa5/0x710
[<0>] ksys_ioctl+0x70/0x80
[<0>] __x64_sys_ioctl+0x16/0x20
[<0>] do_syscall_64+0x56/0x220
[<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
I've bisected that to the mentioned commit, using test in btrfs-progs
testsuite with command "make TEST=016\* test-misc". Normally the test
can run up to 10 seconds, in the buggy case it stays there.
I can help testing fixes or gathering more information, please let me
know.
Full bisect log:
# bad: [3c0edea9b29f9be6c093f236f762202b30ac9431] pipe: Remove sync on wake_ups
# good: [da0c9ea146cbe92b832f1b0f694840ea8eb33cce] Linux 5.4-rc2
git bisect start '3c0edea9b29f9be6c093f236f762202b30ac9431' 'd055b4fb4d165b06d912e7f846610d120c3bb9fb^'
# bad: [b667b867344301e24f21d4a4c844675ff61d89e1] pipe: Advance tail pointer inside of wait spinlock in pipe_read()
git bisect bad b667b867344301e24f21d4a4c844675ff61d89e1
# good: [f94df9890e98f2090c6a8d70c795134863b70201] Add wake_up_interruptible_sync_poll_locked()
git bisect good f94df9890e98f2090c6a8d70c795134863b70201
# bad: [6718b6f855a0b4962d54bd625be2718cb820cec6] pipe: Allow pipes to have kernel-reserved slots
git bisect bad 6718b6f855a0b4962d54bd625be2718cb820cec6
# bad: [8cefc107ca54c8b06438b7dc9cc08bc0a11d5b98] pipe: Use head and tail pointers for the ring, not cursor and length
git bisect bad 8cefc107ca54c8b06438b7dc9cc08bc0a11d5b98
# first bad commit: [8cefc107ca54c8b06438b7dc9cc08bc0a11d5b98] pipe: Use head and tail pointers for the ring, not cursor and length
> pipe: Allow pipes to have kernel-reserved slots
> pipe: Advance tail pointer inside of wait spinlock in pipe_read()
> pipe: Conditionalise wakeup in pipe_read()
> pipe: Rearrange sequence in pipe_write() to preallocate slot
> pipe: Remove redundant wakeup from pipe_write()
> pipe: Check for ring full inside of the spinlock in pipe_write()
> pipe: Increase the writer-wakeup threshold to reduce context-switch count
> pipe: Remove sync on wake_ups
^ permalink raw reply
* Re: [PATCH v7 1/1] ns: add binfmt_misc to the user namespace
From: Christian Brauner @ 2019-12-03 15:40 UTC (permalink / raw)
To: Laurent Vivier
Cc: linux-kernel, Henning Schild, Dmitry Safonov, linux-api,
containers, Jann Horn, Greg Kurz, Alexander Viro, James Bottomley,
Eric Biederman, Jan Kiszka, linux-fsdevel, Cédric Le Goater,
dhowells
In-Reply-To: <20191107140304.8426-2-laurent@vivier.eu>
On Thu, Nov 07, 2019 at 03:03:04PM +0100, Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace a new empty binfmt instance is created and
> used in this namespace.
>
> For instance, using "unshare" we can start a chroot of another
> architecture and configure the binfmt_misc interpreter without being root
> to run the binaries in this chroot.
>
> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> Acked-by: Andrei Vagin <avagin@gmail.com>
> ---
> fs/binfmt_misc.c | 115 +++++++++++++++++++++++++--------
> include/linux/user_namespace.h | 15 +++++
> kernel/user.c | 14 ++++
> kernel/user_namespace.c | 3 +
> 4 files changed, 119 insertions(+), 28 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index cdb45829354d..ba5f0d2ade96 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -40,9 +40,6 @@ enum {
> VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
> };
>
> -static LIST_HEAD(entries);
> -static int enabled = 1;
> -
> enum {Enabled, Magic};
> #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
> #define MISC_FMT_OPEN_BINARY (1 << 30)
> @@ -62,10 +59,7 @@ typedef struct {
> struct file *interp_file;
> } Node;
>
> -static DEFINE_RWLOCK(entries_lock);
> static struct file_system_type bm_fs_type;
> -static struct vfsmount *bm_mnt;
> -static int entry_count;
>
> /*
> * Max length of the register string. Determined by:
> @@ -82,18 +76,37 @@ static int entry_count;
> */
> #define MAX_REGISTER_LENGTH 1920
>
> +static struct binfmt_namespace *binfmt_ns(struct user_namespace *ns)
> +{
> + struct binfmt_namespace *b_ns;
> +
> + while (ns) {
> + b_ns = READ_ONCE(ns->binfmt_ns);
> + if (b_ns)
> + return b_ns;
> + ns = ns->parent;
> + }
> + /* as the first user namespace is initialized with
> + * &init_binfmt_ns we should never come here
> + * but we try to stay safe by logging a warning
> + * and returning a sane value
> + */
> + WARN_ON_ONCE(1);
> + return &init_binfmt_ns;
> +}
> +
> /*
> * Check if we support the binfmt
> * if we do, return the node, else NULL
> * locking is done in load_misc_binary
> */
> -static Node *check_file(struct linux_binprm *bprm)
> +static Node *check_file(struct binfmt_namespace *ns, struct linux_binprm *bprm)
> {
> char *p = strrchr(bprm->interp, '.');
> struct list_head *l;
>
> /* Walk all the registered handlers. */
> - list_for_each(l, &entries) {
> + list_for_each(l, &ns->entries) {
> Node *e = list_entry(l, Node, list);
> char *s;
> int j;
> @@ -135,17 +148,18 @@ static int load_misc_binary(struct linux_binprm *bprm)
> struct file *interp_file = NULL;
> int retval;
> int fd_binary = -1;
> + struct binfmt_namespace *ns = binfmt_ns(current_user_ns());
>
> retval = -ENOEXEC;
> - if (!enabled)
> + if (!ns->enabled)
> return retval;
>
> /* to keep locking time low, we copy the interpreter string */
> - read_lock(&entries_lock);
> - fmt = check_file(bprm);
> + read_lock(&ns->entries_lock);
> + fmt = check_file(ns, bprm);
> if (fmt)
> dget(fmt->dentry);
> - read_unlock(&entries_lock);
> + read_unlock(&ns->entries_lock);
> if (!fmt)
> return retval;
>
> @@ -611,19 +625,19 @@ static void bm_evict_inode(struct inode *inode)
> kfree(e);
> }
>
> -static void kill_node(Node *e)
> +static void kill_node(struct binfmt_namespace *ns, Node *e)
> {
> struct dentry *dentry;
>
> - write_lock(&entries_lock);
> + write_lock(&ns->entries_lock);
> list_del_init(&e->list);
> - write_unlock(&entries_lock);
> + write_unlock(&ns->entries_lock);
>
> dentry = e->dentry;
> drop_nlink(d_inode(dentry));
> d_drop(dentry);
> dput(dentry);
> - simple_release_fs(&bm_mnt, &entry_count);
> + simple_release_fs(&ns->bm_mnt, &ns->entry_count);
> }
>
> /* /<entry> */
> @@ -653,6 +667,9 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
> struct dentry *root;
> Node *e = file_inode(file)->i_private;
> int res = parse_command(buffer, count);
> + struct binfmt_namespace *ns;
> +
> + ns = binfmt_ns(file->f_path.dentry->d_sb->s_user_ns);
Sorry for being so late to the party.
The naked dereferences here are not very pretty and also likely mean you
access the wrong dentry when you do (weird but possible) things like:
mount -t overlay overlay -o lowerdir=/proc/sys/fs/binfmt_misc,workdir=/work,upperdir=/upper /merged
(which might already cause trouble in other parts of this code)
so I think it's better if you replace
file->f_path.dentry->d_sb->s_user_ns
with
file_dentry(file)->d_sb->s_user_ns
in places where you do naked dereferences now.
^ permalink raw reply
* Re: [PATCH v7 1/1] ns: add binfmt_misc to the user namespace
From: Laurent Vivier @ 2019-12-03 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Dmitry Safonov, Henning Schild, linux-fsdevel, James Bottomley,
Eric Biederman, linux-api, Andrei Vagin, Cédric Le Goater,
Greg Kurz, Jann Horn, containers, Alexander Viro, Jan Kiszka
In-Reply-To: <20191107140304.8426-2-laurent@vivier.eu>
Ping
Thanks,
Laurent
Le 07/11/2019 à 15:03, Laurent Vivier a écrit :
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace a new empty binfmt instance is created and
> used in this namespace.
>
> For instance, using "unshare" we can start a chroot of another
> architecture and configure the binfmt_misc interpreter without being root
> to run the binaries in this chroot.
>
> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> Acked-by: Andrei Vagin <avagin@gmail.com>
> ---
> fs/binfmt_misc.c | 115 +++++++++++++++++++++++++--------
> include/linux/user_namespace.h | 15 +++++
> kernel/user.c | 14 ++++
> kernel/user_namespace.c | 3 +
> 4 files changed, 119 insertions(+), 28 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index cdb45829354d..ba5f0d2ade96 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -40,9 +40,6 @@ enum {
> VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
> };
>
> -static LIST_HEAD(entries);
> -static int enabled = 1;
> -
> enum {Enabled, Magic};
> #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
> #define MISC_FMT_OPEN_BINARY (1 << 30)
> @@ -62,10 +59,7 @@ typedef struct {
> struct file *interp_file;
> } Node;
>
> -static DEFINE_RWLOCK(entries_lock);
> static struct file_system_type bm_fs_type;
> -static struct vfsmount *bm_mnt;
> -static int entry_count;
>
> /*
> * Max length of the register string. Determined by:
> @@ -82,18 +76,37 @@ static int entry_count;
> */
> #define MAX_REGISTER_LENGTH 1920
>
> +static struct binfmt_namespace *binfmt_ns(struct user_namespace *ns)
> +{
> + struct binfmt_namespace *b_ns;
> +
> + while (ns) {
> + b_ns = READ_ONCE(ns->binfmt_ns);
> + if (b_ns)
> + return b_ns;
> + ns = ns->parent;
> + }
> + /* as the first user namespace is initialized with
> + * &init_binfmt_ns we should never come here
> + * but we try to stay safe by logging a warning
> + * and returning a sane value
> + */
> + WARN_ON_ONCE(1);
> + return &init_binfmt_ns;
> +}
> +
> /*
> * Check if we support the binfmt
> * if we do, return the node, else NULL
> * locking is done in load_misc_binary
> */
> -static Node *check_file(struct linux_binprm *bprm)
> +static Node *check_file(struct binfmt_namespace *ns, struct linux_binprm *bprm)
> {
> char *p = strrchr(bprm->interp, '.');
> struct list_head *l;
>
> /* Walk all the registered handlers. */
> - list_for_each(l, &entries) {
> + list_for_each(l, &ns->entries) {
> Node *e = list_entry(l, Node, list);
> char *s;
> int j;
> @@ -135,17 +148,18 @@ static int load_misc_binary(struct linux_binprm *bprm)
> struct file *interp_file = NULL;
> int retval;
> int fd_binary = -1;
> + struct binfmt_namespace *ns = binfmt_ns(current_user_ns());
>
> retval = -ENOEXEC;
> - if (!enabled)
> + if (!ns->enabled)
> return retval;
>
> /* to keep locking time low, we copy the interpreter string */
> - read_lock(&entries_lock);
> - fmt = check_file(bprm);
> + read_lock(&ns->entries_lock);
> + fmt = check_file(ns, bprm);
> if (fmt)
> dget(fmt->dentry);
> - read_unlock(&entries_lock);
> + read_unlock(&ns->entries_lock);
> if (!fmt)
> return retval;
>
> @@ -611,19 +625,19 @@ static void bm_evict_inode(struct inode *inode)
> kfree(e);
> }
>
> -static void kill_node(Node *e)
> +static void kill_node(struct binfmt_namespace *ns, Node *e)
> {
> struct dentry *dentry;
>
> - write_lock(&entries_lock);
> + write_lock(&ns->entries_lock);
> list_del_init(&e->list);
> - write_unlock(&entries_lock);
> + write_unlock(&ns->entries_lock);
>
> dentry = e->dentry;
> drop_nlink(d_inode(dentry));
> d_drop(dentry);
> dput(dentry);
> - simple_release_fs(&bm_mnt, &entry_count);
> + simple_release_fs(&ns->bm_mnt, &ns->entry_count);
> }
>
> /* /<entry> */
> @@ -653,6 +667,9 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
> struct dentry *root;
> Node *e = file_inode(file)->i_private;
> int res = parse_command(buffer, count);
> + struct binfmt_namespace *ns;
> +
> + ns = binfmt_ns(file->f_path.dentry->d_sb->s_user_ns);
>
> switch (res) {
> case 1:
> @@ -669,7 +686,7 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
> inode_lock(d_inode(root));
>
> if (!list_empty(&e->list))
> - kill_node(e);
> + kill_node(ns, e);
>
> inode_unlock(d_inode(root));
> break;
> @@ -695,6 +712,7 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
> struct inode *inode;
> struct super_block *sb = file_inode(file)->i_sb;
> struct dentry *root = sb->s_root, *dentry;
> + struct binfmt_namespace *ns;
> int err = 0;
>
> e = create_entry(buffer, count);
> @@ -718,7 +736,9 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
> if (!inode)
> goto out2;
>
> - err = simple_pin_fs(&bm_fs_type, &bm_mnt, &entry_count);
> + ns = binfmt_ns(file->f_path.dentry->d_sb->s_user_ns);
> + err = simple_pin_fs(&bm_fs_type, &ns->bm_mnt,
> + &ns->entry_count);
> if (err) {
> iput(inode);
> inode = NULL;
> @@ -727,12 +747,16 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
>
> if (e->flags & MISC_FMT_OPEN_FILE) {
> struct file *f;
> + const struct cred *old_cred;
>
> + old_cred = override_creds(file->f_cred);
> f = open_exec(e->interpreter);
> + revert_creds(old_cred);
> if (IS_ERR(f)) {
> err = PTR_ERR(f);
> pr_notice("register: failed to install interpreter file %s\n", e->interpreter);
> - simple_release_fs(&bm_mnt, &entry_count);
> + simple_release_fs(&ns->bm_mnt,
> + &ns->entry_count);
> iput(inode);
> inode = NULL;
> goto out2;
> @@ -745,9 +769,9 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
> inode->i_fop = &bm_entry_operations;
>
> d_instantiate(dentry, inode);
> - write_lock(&entries_lock);
> - list_add(&e->list, &entries);
> - write_unlock(&entries_lock);
> + write_lock(&ns->entries_lock);
> + list_add(&e->list, &ns->entries);
> + write_unlock(&ns->entries_lock);
>
> err = 0;
> out2:
> @@ -772,7 +796,9 @@ static const struct file_operations bm_register_operations = {
> static ssize_t
> bm_status_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
> {
> - char *s = enabled ? "enabled\n" : "disabled\n";
> + struct binfmt_namespace *ns =
> + binfmt_ns(file->f_path.dentry->d_sb->s_user_ns);
> + char *s = ns->enabled ? "enabled\n" : "disabled\n";
>
> return simple_read_from_buffer(buf, nbytes, ppos, s, strlen(s));
> }
> @@ -780,25 +806,28 @@ bm_status_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
> static ssize_t bm_status_write(struct file *file, const char __user *buffer,
> size_t count, loff_t *ppos)
> {
> + struct binfmt_namespace *ns;
> int res = parse_command(buffer, count);
> struct dentry *root;
>
> + ns = binfmt_ns(file->f_path.dentry->d_sb->s_user_ns);
> switch (res) {
> case 1:
> /* Disable all handlers. */
> - enabled = 0;
> + ns->enabled = 0;
> break;
> case 2:
> /* Enable all handlers. */
> - enabled = 1;
> + ns->enabled = 1;
> break;
> case 3:
> /* Delete all handlers. */
> root = file_inode(file)->i_sb->s_root;
> inode_lock(d_inode(root));
>
> - while (!list_empty(&entries))
> - kill_node(list_first_entry(&entries, Node, list));
> + while (!list_empty(&ns->entries))
> + kill_node(ns, list_first_entry(&ns->entries,
> + Node, list));
>
> inode_unlock(d_inode(root));
> break;
> @@ -825,24 +854,53 @@ static const struct super_operations s_ops = {
> static int bm_fill_super(struct super_block *sb, struct fs_context *fc)
> {
> int err;
> + struct user_namespace *ns = sb->s_user_ns;
> static const struct tree_descr bm_files[] = {
> [2] = {"status", &bm_status_operations, S_IWUSR|S_IRUGO},
> [3] = {"register", &bm_register_operations, S_IWUSR},
> /* last one */ {""}
> };
>
> + /* create a new binfmt namespace
> + * if we are not in the first user namespace
> + * but the binfmt namespace is the first one
> + */
> + if (READ_ONCE(ns->binfmt_ns) == NULL) {
> + struct binfmt_namespace *new_ns;
> +
> + new_ns = kmalloc(sizeof(struct binfmt_namespace),
> + GFP_KERNEL);
> + if (new_ns == NULL)
> + return -ENOMEM;
> + INIT_LIST_HEAD(&new_ns->entries);
> + new_ns->enabled = 1;
> + rwlock_init(&new_ns->entries_lock);
> + new_ns->bm_mnt = NULL;
> + new_ns->entry_count = 0;
> + /* ensure new_ns is completely initialized before sharing it */
> + smp_wmb();
> + WRITE_ONCE(ns->binfmt_ns, new_ns);
> + }
> +
> err = simple_fill_super(sb, BINFMTFS_MAGIC, bm_files);
> if (!err)
> sb->s_op = &s_ops;
> return err;
> }
>
> +static void bm_free(struct fs_context *fc)
> +{
> + if (fc->s_fs_info)
> + put_user_ns(fc->s_fs_info);
> +}
> +
> static int bm_get_tree(struct fs_context *fc)
> {
> - return get_tree_single(fc, bm_fill_super);
> + return get_tree_keyed(fc, bm_fill_super, get_user_ns(fc->user_ns));
> }
>
> static const struct fs_context_operations bm_context_ops = {
> + .free = bm_free,
> .get_tree = bm_get_tree,
> };
>
> @@ -861,6 +919,7 @@ static struct file_system_type bm_fs_type = {
> .owner = THIS_MODULE,
> .name = "binfmt_misc",
> .init_fs_context = bm_init_fs_context,
> + .fs_flags = FS_USERNS_MOUNT,
> .kill_sb = kill_litter_super,
> };
> MODULE_ALIAS_FS("binfmt_misc");
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index fb9f4f799554..16e6f3a97a01 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -52,6 +52,18 @@ enum ucount_type {
> UCOUNT_COUNTS,
> };
>
> +#if IS_ENABLED(CONFIG_BINFMT_MISC)
> +struct binfmt_namespace {
> + struct list_head entries;
> + rwlock_t entries_lock;
> + int enabled;
> + struct vfsmount *bm_mnt;
> + int entry_count;
> +} __randomize_layout;
> +
> +extern struct binfmt_namespace init_binfmt_ns;
> +#endif
> +
> struct user_namespace {
> struct uid_gid_map uid_map;
> struct uid_gid_map gid_map;
> @@ -86,6 +98,9 @@ struct user_namespace {
> #endif
> struct ucounts *ucounts;
> int ucount_max[UCOUNT_COUNTS];
> +#if IS_ENABLED(CONFIG_BINFMT_MISC)
> + struct binfmt_namespace *binfmt_ns;
> +#endif
> } __randomize_layout;
>
> struct ucounts {
> diff --git a/kernel/user.c b/kernel/user.c
> index 5235d7f49982..092b2b4d47a6 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -20,6 +20,17 @@
> #include <linux/user_namespace.h>
> #include <linux/proc_ns.h>
>
> +#if IS_ENABLED(CONFIG_BINFMT_MISC)
> +struct binfmt_namespace init_binfmt_ns = {
> + .entries = LIST_HEAD_INIT(init_binfmt_ns.entries),
> + .enabled = 1,
> + .entries_lock = __RW_LOCK_UNLOCKED(init_binfmt_ns.entries_lock),
> + .bm_mnt = NULL,
> + .entry_count = 0,
> +};
> +EXPORT_SYMBOL_GPL(init_binfmt_ns);
> +#endif
> +
> /*
> * userns count is 1 for root user, 1 for init_uts_ns,
> * and 1 for... ?
> @@ -67,6 +78,9 @@ struct user_namespace init_user_ns = {
> .keyring_name_list = LIST_HEAD_INIT(init_user_ns.keyring_name_list),
> .keyring_sem = __RWSEM_INITIALIZER(init_user_ns.keyring_sem),
> #endif
> +#if IS_ENABLED(CONFIG_BINFMT_MISC)
> + .binfmt_ns = &init_binfmt_ns,
> +#endif
> };
> EXPORT_SYMBOL_GPL(init_user_ns);
>
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index 8eadadc478f9..f42c32269e20 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -191,6 +191,9 @@ static void free_user_ns(struct work_struct *work)
> kfree(ns->projid_map.forward);
> kfree(ns->projid_map.reverse);
> }
> +#if IS_ENABLED(CONFIG_BINFMT_MISC)
> + kfree(ns->binfmt_ns);
> +#endif
> retire_userns_sysctls(ns);
> key_free_user_ns(ns);
> ns_free_inum(&ns->ns);
>
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: Steven Rostedt @ 2019-12-02 23:54 UTC (permalink / raw)
To: Matthew Garrett
Cc: dann frazier, Linux Kernel Mailing List, LSM List, Seth Forshee,
James Morris, Linux API, Ben Hutchings, Al Viro, Linus Torvalds
In-Reply-To: <CACdnJuuXBQ__Sb8=V7CTZfXH=5LfbiU9SmUKapJov3Cd+aHQcw@mail.gmail.com>
On Mon, 2 Dec 2019 15:31:52 -0800
Matthew Garrett <mjg59@google.com> wrote:
> On Fri, Nov 1, 2019 at 2:08 PM dann frazier <dann.frazier@canonical.com> wrote:
>
> > [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
>
> This is expected.
>
> > [ 2.913934] ------------[ cut here ]------------
> > [ 2.918435] Could not register function stat for cpu 0
> > [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
>
> This is not. I'll look into it.
I think it has to do with ftrace triggering WARN_ON() if it fails to
create files. We don't want this to happen if it fails because of
lockdown.
I'm already looking into it.
Thanks!
-- Steve
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: Matthew Garrett @ 2019-12-02 23:31 UTC (permalink / raw)
To: dann frazier
Cc: Steven Rostedt, Linux Kernel Mailing List, LSM List, Seth Forshee,
James Morris, Linux API, Ben Hutchings, Al Viro, Linus Torvalds
In-Reply-To: <20191101210803.GA9841@xps13.dannf>
On Fri, Nov 1, 2019 at 2:08 PM dann frazier <dann.frazier@canonical.com> wrote:
> [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
This is expected.
> [ 2.913934] ------------[ cut here ]------------
> [ 2.918435] Could not register function stat for cpu 0
> [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
This is not. I'll look into it.
^ permalink raw reply
* Re: [GIT PULL] sysctl: Remove the sysctl system call
From: pr-tracker-bot @ 2019-12-02 0:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, linux-kernel, linux-arch, linux-api
In-Reply-To: <87r21tuulj.fsf@x220.int.ebiederm.org>
The pull request you sent on Wed, 27 Nov 2019 10:55:52 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ad0b314e003049292a23dd248d3c3ca4a3d75f55
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] y2038: syscall implementation cleanups
From: pr-tracker-bot @ 2019-12-02 0:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, y2038 Mailman List, Linux Kernel Mailing List,
Thomas Gleixner, linuxppc-dev, Linux API
In-Reply-To: <CAK8P3a38Q_yhiyODpFd6ZqLv=QyKRmCm8FOMuSr4RPvGtWNPYw@mail.gmail.com>
The pull request you sent on Wed, 27 Nov 2019 14:36:16 +0100:
> git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git tags/y2038-cleanups-5.5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ceb307474506f888e8f16dab183405ff01dffa08
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: pr-tracker-bot @ 2019-11-30 23:05 UTC (permalink / raw)
Cc: torvalds, dhowells, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api,
linux-kernel
In-Reply-To: <31452.1574721589@warthog.procyon.org.uk>
The pull request you sent on Mon, 25 Nov 2019 22:39:49 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/notifications-pipe-prep-20191115
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6a965666b7e7475c2f8c8e724703db58b8a8a445
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: dann frazier @ 2019-11-28 17:35 UTC (permalink / raw)
To: Jordan Glover
Cc: Steven Rostedt, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, Seth Forshee,
Matthew Garrett, James Morris, Linux API, Ben Hutchings, Al Viro,
Linus Torvalds
In-Reply-To: <2vtDIdkutRsBBbaiswjFZlGeQPSlDHF3et5ZxQ4YJ4zArOKo7-53A6d8SwpUtt7NCYdQEmmkeTADvrS7NCzw0Stw33n44vJC_qspqXgRPZQ=@protonmail.ch>
On Thu, Nov 28, 2019 at 03:31:31PM +0000, Jordan Glover wrote:
> On Friday, November 1, 2019 10:15 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Fri, 1 Nov 2019 15:08:03 -0600
> > dann frazier dann.frazier@canonical.com wrote:
> >
> > > hey,
> > > fyi, I'm seeing a bunch of errors from tracefs when booting 5.4-rc5 in
> > > lockdown=confidentiality mode:
> > > [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > > [ 1.772332] Could not create tracefs 'available_events' entry
> > > [ 1.778633] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > > [ 1.787095] Could not create tracefs 'set_event' entry
> > > [ 1.792412] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > > (...)
> > > [ 2.899481] Could not create tracefs 'set_graph_notrace' entry
> > > [ 2.905671] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > > [ 2.913934] ------------[ cut here ]------------
> > > [ 2.918435] Could not register function stat for cpu 0
> > > [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
> > > [ 2.933939] Modules linked in:
> > > [ 2.937290] CPU: 1 PID: 1 Comm:
> >
> > Looks to me that it's working as designed ;-)
> >
> > I'm guessing we could quiet these warnings for boot up though. :-/
> >
> > But there should be at least one message that states that the tracefs
> > files are not being created due to lockdown.
> >
> > -- Steve
>
> Could you clarify what functionality is lost here and if it affects
> system stability?
None that I'm aware of.
> I agree that triggering WARNING on every boot with supported kernel
> configuration isn't optimal experience for users.
Yes, that's my concern.
-dann
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: Jordan Glover @ 2019-11-28 15:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: dann frazier, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, Seth Forshee,
Matthew Garrett, James Morris, Linux API, Ben Hutchings, Al Viro,
Linus Torvalds
In-Reply-To: <20191101181501.4beff81b@grimm.local.home>
On Friday, November 1, 2019 10:15 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 1 Nov 2019 15:08:03 -0600
> dann frazier dann.frazier@canonical.com wrote:
>
> > hey,
> > fyi, I'm seeing a bunch of errors from tracefs when booting 5.4-rc5 in
> > lockdown=confidentiality mode:
> > [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > [ 1.772332] Could not create tracefs 'available_events' entry
> > [ 1.778633] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > [ 1.787095] Could not create tracefs 'set_event' entry
> > [ 1.792412] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > (...)
> > [ 2.899481] Could not create tracefs 'set_graph_notrace' entry
> > [ 2.905671] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
> > [ 2.913934] ------------[ cut here ]------------
> > [ 2.918435] Could not register function stat for cpu 0
> > [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
> > [ 2.933939] Modules linked in:
> > [ 2.937290] CPU: 1 PID: 1 Comm:
>
> Looks to me that it's working as designed ;-)
>
> I'm guessing we could quiet these warnings for boot up though. :-/
>
> But there should be at least one message that states that the tracefs
> files are not being created due to lockdown.
>
> -- Steve
Could you clarify what functionality is lost here and if it affects
system stability?
I agree that triggering WARNING on every boot with supported kernel
configuration isn't optimal experience for users.
Jordan
^ permalink raw reply
* Re: [PATCH v17 10/13] namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution
From: Aleksa Sarai @ 2019-11-28 10:10 UTC (permalink / raw)
To: Al Viro
Cc: Jeff Layton, J. Bruce Fields, Arnd Bergmann, David Howells,
Shuah Khan, Shuah Khan, Ingo Molnar, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Andrii Nakryiko, Jonathan Corbet,
Christian Brauner, Jann Horn, Linus Torvalds, Eric Biederman,
Andy Lutomirski, Andrew Morton, Kees Cook, Tycho Andersen,
David Drysdale
In-Reply-To: <20191125132145.btaxuurs2w3ldyxf@yavin.dot.cyphar.com>
[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]
On 2019-11-26, Aleksa Sarai <cyphar@cyphar.com> wrote:
> On 2019-11-25, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Sun, Nov 17, 2019 at 12:17:10PM +1100, Aleksa Sarai wrote:
> > > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) {
> > > + /*
> > > + * If there was a racing rename or mount along our
> > > + * path, then we can't be sure that ".." hasn't jumped
> > > + * above nd->root (and so userspace should retry or use
> > > + * some fallback).
> > > + */
> > > + if (unlikely(read_seqretry(&mount_lock, nd->m_seq)))
> > > + return -EAGAIN;
> > > + if (unlikely(read_seqretry(&rename_lock, nd->r_seq)))
> > > + return -EAGAIN;
> > > + }
> >
> > Looks like excessive barriers to me - it's
> > rmb
> > check mount_lock.sequence
> > rmb
> > check rename_lock.sequence
>
> If you like, I can switch this to
>
> smp_rmb();
> if (unlikely(__read_seqcount_retry(&mount_lock.seqcount, nd->m_seq)))
> return -EAGAIN;
> if (unlikely(__read_seqcount_retry(&rename_lock.seqcount, nd->r_seq)))
> return -EAGAIN;
>
> Though I think it makes it more noisy (and this code-path will only be
> hit for ".." and LOOKUP_IS_SCOPED).
>
> > > @@ -2266,6 +2274,10 @@ static const char *path_init(struct nameidata *nd, unsigned flags)
> > > nd->last_type = LAST_ROOT; /* if there are only slashes... */
> > > nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT;
> > > nd->depth = 0;
> > > +
> > > + nd->m_seq = read_seqbegin(&mount_lock);
> > > + nd->r_seq = read_seqbegin(&rename_lock);
> >
> > Same here, pretty much (fetch/rmb/fetch/rmb)
>
> Unless I'm mistaken, wouldn't we have to do
> seqcount_lockdep_reader_access() explicitly -- so it would end up
> looking something like:
>
> seqcount_lockdep_reader_access(&mount_lock.seqcount);
> nd->m_seq = __read_seqcount_begin(&mount_lock.seqcount);
> seqcount_lockdep_reader_access(&mount_lock.seqcount);
> nd->r_seq = __read_seqcount_begin(&rename_lock.seqcount);
> smp_rmb();
Actually, looking it again (unless I'm mistaken) the following should be
acceptable and it also avoids the extra fetch+rmb of mount_lock for
LOOKUP_ROOT. The only downside is that we don't get lockdep information
but path_init() already ignores lockdep when grabbing d_seq.
I will include the following in v18, but let me know if I'm missing
something obvious:
>> nd->m_seq = __read_seqcount_begin(&mount_lock);
>> nd->r_seq = __read_seqcount_begin(&rename_lock);
>> smp_rmb();
if (flags & LOOKUP_ROOT) {
struct dentry *root = nd->root.dentry;
struct inode *inode = root->d_inode;
if (*s && unlikely(!d_can_lookup(root)))
return ERR_PTR(-ENOTDIR);
nd->path = nd->root;
nd->inode = inode;
if (flags & LOOKUP_RCU) {
>> nd->seq = raw_read_seqcount_begin(&nd->path.dentry->d_seq);
nd->root_seq = nd->seq;
} else {
path_get(&nd->path);
}
return s;
}
I could also move the smp_rmb() to after LOOKUP_ROOT (and add an
smp_rmb() at the end of LOOKUP_ROOT) which would avoid a double-rmb for
LOOKUP_ROOT -- but it makes it harder to read IMHO.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Add prctl support for controlling mem reclaim V4
From: Bart Van Assche @ 2019-11-27 18:07 UTC (permalink / raw)
To: Mike Christie, linux-api, idryomov, mhocko, david, linux-mm,
linux-kernel, linux-scsi, linux-fsdevel, linux-block, martin,
Damien.LeMoal
Cc: Michal Hocko, Masato Suzuki
In-Reply-To: <20191112001900.9206-1-mchristi@redhat.com>
On 11/11/19 4:19 PM, Mike Christie wrote:
> There are several storage drivers like dm-multipath, iscsi, tcmu-runner,
> amd nbd that have userspace components that can run in the IO path. For
> example, iscsi and nbd's userspace deamons may need to recreate a socket
> and/or send IO on it, and dm-multipath's daemon multipathd may need to
> send SG IO or read/write IO to figure out the state of paths and re-set
> them up.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* [GIT PULL] sysctl: Remove the sysctl system call
From: Eric W. Biederman @ 2019-11-27 16:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-arch, linux-api
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus
HEAD: 61a47c1ad3a4dc6882f01ebdc88138ac62d0df03 sysctl: Remove the sysctl system call
As far as I can tell we have reached the point where no one enables the
sysctl system call anymore. It still is enabled in a few defconfigs
but they are mostly the rarely used one and in asking people about
that it was more cut & paste enabled than anything else.
This is single commit that just deletes code. Leaving just enough code
so that the deprecated sysctl warning continues to be printed. If my
analysis turns out to be wrong and someone actually cares it will be
easy to revert this commit and have the system call again.
There was one new xtensa defconfig in linux-next that enabled the system
call this cycle and when asked about it the maintainer of the code
replied that it was not enabled on purpose. As of today's linux-next
tree that defconfig no longer enables the system call.
I have recently amended the commit to include the review status.
Some of the mailing list choked on my patch posting, I don't know why
but here is a link to part of the review that made it to linux-kernel.
https://lore.kernel.org/lkml/201910011140.EA0181F13@keescook/
What we saw in the review discussion was that if we go a step farther
than my patch and mess with uapi headers there are pieces of code that
won't compile, but nothing minds the system call actually disappearing
from the kernel.
Eric W. Biederman (1):
sysctl: Remove the sysctl system call
arch/arc/configs/nps_defconfig | 1 -
arch/arc/configs/tb10x_defconfig | 1 -
arch/arm/configs/axm55xx_defconfig | 1 -
arch/arm/configs/keystone_defconfig | 1 -
arch/arm/configs/lpc32xx_defconfig | 1 -
arch/arm/configs/moxart_defconfig | 1 -
arch/arm/configs/qcom_defconfig | 1 -
arch/arm/configs/zx_defconfig | 1 -
arch/m68k/configs/m5475evb_defconfig | 1 -
arch/mips/configs/ci20_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/mips/configs/malta_qemu_32r6_defconfig | 1 -
arch/mips/configs/maltaaprp_defconfig | 1 -
arch/mips/configs/maltasmvp_defconfig | 1 -
arch/mips/configs/maltasmvp_eva_defconfig | 1 -
arch/mips/configs/maltaup_defconfig | 1 -
arch/mips/configs/omega2p_defconfig | 1 -
arch/mips/configs/qi_lb60_defconfig | 1 -
arch/mips/configs/vocore2_defconfig | 1 -
arch/nios2/configs/10m50_defconfig | 1 -
arch/nios2/configs/3c120_defconfig | 1 -
arch/parisc/configs/c8000_defconfig | 1 -
arch/parisc/configs/generic-32bit_defconfig | 1 -
arch/powerpc/configs/40x/klondike_defconfig | 1 -
arch/sh/configs/rsk7264_defconfig | 1 -
arch/xtensa/configs/audio_kc705_defconfig | 1 -
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/generic_kc705_defconfig | 1 -
arch/xtensa/configs/iss_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
arch/xtensa/configs/smp_lx200_defconfig | 1 -
arch/xtensa/configs/virt_defconfig | 1 -
init/Kconfig | 17 -
kernel/sysctl_binary.c | 1305 ---------------------------
34 files changed, 1354 deletions(-)
^ permalink raw reply
* [GIT PULL] y2038: syscall implementation cleanups
From: Arnd Bergmann @ 2019-11-27 13:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: y2038 Mailman List, Linux API, Thomas Gleixner, linuxppc-dev,
Linux Kernel Mailing List
The following changes since commit a99d8080aaf358d5d23581244e5da23b35e340b9:
Linux 5.4-rc6 (2019-11-03 14:07:26 -0800)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038-cleanups-5.5
for you to fetch changes up to b111df8447acdeb4b9220f99d5d4b28f83eb56ad:
y2038: alarm: fix half-second cut-off (2019-11-25 21:52:35 +0100)
----------------------------------------------------------------
y2038: syscall implementation cleanups
This is a series of cleanups for the y2038 work, mostly intended
for namespace cleaning: the kernel defines the traditional
time_t, timeval and timespec types that often lead to y2038-unsafe
code. Even though the unsafe usage is mostly gone from the kernel,
having the types and associated functions around means that we
can still grow new users, and that we may be missing conversions
to safe types that actually matter.
There are still a number of driver specific patches needed to
get the last users of these types removed, those have been
submitted to the respective maintainers.
Link: https://lore.kernel.org/lkml/20191108210236.1296047-1-arnd@arndb.de/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----------------------------------------------------------------
Arnd Bergmann (26):
y2038: remove CONFIG_64BIT_TIME
y2038: add __kernel_old_timespec and __kernel_old_time_t
y2038: vdso: change timeval to __kernel_old_timeval
y2038: vdso: change timespec to __kernel_old_timespec
y2038: vdso: change time_t to __kernel_old_time_t
y2038: vdso: nds32: open-code timespec_add_ns()
y2038: vdso: powerpc: avoid timespec references
y2038: ipc: remove __kernel_time_t reference from headers
y2038: stat: avoid 'time_t' in 'struct stat'
y2038: uapi: change __kernel_time_t to __kernel_old_time_t
y2038: rusage: use __kernel_old_timeval
y2038: syscalls: change remaining timeval to __kernel_old_timeval
y2038: socket: remove timespec reference in timestamping
y2038: socket: use __kernel_old_timespec instead of timespec
y2038: make ns_to_compat_timeval use __kernel_old_timeval
y2038: elfcore: Use __kernel_old_timeval for process times
y2038: timerfd: Use timespec64 internally
y2038: time: avoid timespec usage in settimeofday()
y2038: itimer: compat handling to itimer.c
y2038: use compat_{get,set}_itimer on alpha
y2038: move itimer reset into itimer.c
y2038: itimer: change implementation to timespec64
y2038: allow disabling time32 system calls
y2038: fix typo in powerpc vdso "LOPART"
y2038: ipc: fix x32 ABI breakage
y2038: alarm: fix half-second cut-off
arch/Kconfig | 11 +-
arch/alpha/kernel/osf_sys.c | 67 +----------
arch/alpha/kernel/syscalls/syscall.tbl | 4 +-
arch/ia64/kernel/asm-offsets.c | 2 +-
arch/mips/include/uapi/asm/msgbuf.h | 6 +-
arch/mips/include/uapi/asm/sembuf.h | 4 +-
arch/mips/include/uapi/asm/shmbuf.h | 6 +-
arch/mips/include/uapi/asm/stat.h | 16 +--
arch/mips/kernel/binfmt_elfn32.c | 4 +-
arch/mips/kernel/binfmt_elfo32.c | 4 +-
arch/nds32/kernel/vdso/gettimeofday.c | 61 +++++-----
arch/parisc/include/uapi/asm/msgbuf.h | 6 +-
arch/parisc/include/uapi/asm/sembuf.h | 4 +-
arch/parisc/include/uapi/asm/shmbuf.h | 6 +-
arch/powerpc/include/asm/asm-prototypes.h | 3 +-
arch/powerpc/include/asm/vdso_datapage.h | 6 +-
arch/powerpc/include/uapi/asm/msgbuf.h | 6 +-
arch/powerpc/include/uapi/asm/sembuf.h | 4 +-
arch/powerpc/include/uapi/asm/shmbuf.h | 6 +-
arch/powerpc/include/uapi/asm/stat.h | 2 +-
arch/powerpc/kernel/asm-offsets.c | 18 ++-
arch/powerpc/kernel/syscalls.c | 4 +-
arch/powerpc/kernel/time.c | 5 +-
arch/powerpc/kernel/vdso32/gettimeofday.S | 6 +-
arch/powerpc/kernel/vdso64/gettimeofday.S | 8 +-
arch/sparc/include/uapi/asm/msgbuf.h | 6 +-
arch/sparc/include/uapi/asm/sembuf.h | 4 +-
arch/sparc/include/uapi/asm/shmbuf.h | 6 +-
arch/sparc/include/uapi/asm/stat.h | 24 ++--
arch/sparc/vdso/vclock_gettime.c | 36 +++---
arch/x86/entry/vdso/vclock_gettime.c | 6 +-
arch/x86/entry/vsyscall/vsyscall_64.c | 4 +-
arch/x86/include/uapi/asm/msgbuf.h | 6 +-
arch/x86/include/uapi/asm/sembuf.h | 4 +-
arch/x86/include/uapi/asm/shmbuf.h | 6 +-
arch/x86/um/vdso/um_vdso.c | 12 +-
fs/aio.c | 2 +-
fs/binfmt_elf.c | 12 +-
fs/binfmt_elf_fdpic.c | 12 +-
fs/compat_binfmt_elf.c | 4 +-
fs/select.c | 10 +-
fs/timerfd.c | 14 +--
fs/utimes.c | 8 +-
include/linux/compat.h | 19 +--
include/linux/skbuff.h | 7 +-
include/linux/syscalls.h | 16 +--
include/linux/time.h | 9 +-
include/linux/time32.h | 2 +-
include/linux/types.h | 2 +-
include/trace/events/timer.h | 16 +--
include/uapi/asm-generic/msgbuf.h | 12 +-
include/uapi/asm-generic/posix_types.h | 1 +
include/uapi/asm-generic/sembuf.h | 7 +-
include/uapi/asm-generic/shmbuf.h | 12 +-
include/uapi/linux/cyclades.h | 6 +-
include/uapi/linux/elfcore.h | 8 +-
include/uapi/linux/errqueue.h | 7 ++
include/uapi/linux/msg.h | 6 +-
include/uapi/linux/ppp_defs.h | 4 +-
include/uapi/linux/resource.h | 4 +-
include/uapi/linux/sem.h | 4 +-
include/uapi/linux/shm.h | 6 +-
include/uapi/linux/time.h | 6 +-
include/uapi/linux/time_types.h | 5 +
include/uapi/linux/utime.h | 4 +-
ipc/syscall.c | 2 +-
kernel/compat.c | 24 ----
kernel/power/power.h | 2 +-
kernel/sys.c | 4 +-
kernel/sys_ni.c | 23 ++++
kernel/time/hrtimer.c | 2 +-
kernel/time/itimer.c | 189 +++++++++++++++++++++---------
kernel/time/time.c | 32 +++--
lib/vdso/gettimeofday.c | 4 +-
net/compat.c | 2 +-
net/core/scm.c | 6 +-
net/ipv4/tcp.c | 28 +++--
net/socket.c | 4 +-
security/selinux/hooks.c | 10 +-
79 files changed, 472 insertions(+), 468 deletions(-)
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [RFC PATCH v3 09/12] btrfs: support different disk extent size for delalloc
From: Nikolay Borisov @ 2019-11-27 10:33 UTC (permalink / raw)
To: Omar Sandoval, linux-fsdevel, linux-btrfs
Cc: Dave Chinner, Jann Horn, Amir Goldstein, Aleksa Sarai, linux-api,
kernel-team
In-Reply-To: <bfa7cb307be92418aee1cec4e23f98bf32a171de.1574273658.git.osandov@fb.com>
On 20.11.19 г. 20:24 ч., Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> Currently, we always reserve the same extent size in the file and extent
> size on disk for delalloc because the former is the worst case for the
> latter. For RWF_ENCODED writes, we know the exact size of the extent on
> disk, which may be less than or greater than (for bookends) the size in
> the file. Add a disk_num_bytes parameter to
> btrfs_delalloc_reserve_metadata() so that we can reserve the correct
> amount of csum bytes. Additionally, make
> btrfs_free_reserve_data_space_noquota() take a number of bytes instead
> of a range, as it refers to the extent size on disk, not in the file. No
> functional change.
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
^ permalink raw reply
* Re: [RFC PATCH v3 08/12] btrfs: add ram_bytes and offset to btrfs_ordered_extent
From: Nikolay Borisov @ 2019-11-27 10:13 UTC (permalink / raw)
To: Omar Sandoval, linux-fsdevel, linux-btrfs
Cc: Dave Chinner, Jann Horn, Amir Goldstein, Aleksa Sarai, linux-api,
kernel-team
In-Reply-To: <acc02c48287b503195a513e4210d6ddd9e89418a.1574273658.git.osandov@fb.com>
On 20.11.19 г. 20:24 ч., Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> Currently, we only create ordered extents when ram_bytes == num_bytes
> and offset == 0. However, RWF_ENCODED writes may create extents which
> only refer to a subset of the full unencoded extent, so we need to plumb
> these fields through the ordered extent infrastructure and pass them
> down to insert_reserved_file_extent().
>
> Since we're changing the btrfs_add_ordered_extent* signature, let's get
> rid of the trivial wrappers and add a kernel-doc.
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
^ permalink raw reply
* Re: [RFC PATCH v3 03/12] fs: add RWF_ENCODED for reading/writing compressed data
From: Omar Sandoval @ 2019-11-27 9:10 UTC (permalink / raw)
To: Nikolay Borisov
Cc: linux-fsdevel, linux-btrfs, Dave Chinner, Jann Horn,
Amir Goldstein, Aleksa Sarai, linux-api, kernel-team
In-Reply-To: <73e9b52f-afed-fa0d-5463-222e41fead56@suse.com>
On Wed, Nov 27, 2019 at 11:00:15AM +0200, Nikolay Borisov wrote:
>
>
> On 26.11.19 г. 19:36 ч., Omar Sandoval wrote:
> > On Tue, Nov 26, 2019 at 03:53:02PM +0200, Nikolay Borisov wrote:
> >>
> >>
> >> On 20.11.19 г. 20:24 ч., Omar Sandoval wrote:
> >>> From: Omar Sandoval <osandov@fb.com>
> >>
> >> <snip>
> >>
> >>>
> >>> +enum {
> >>> + ENCODED_IOV_COMPRESSION_NONE,
> >>> +#define ENCODED_IOV_COMPRESSION_NONE ENCODED_IOV_COMPRESSION_NONE
> >>> + ENCODED_IOV_COMPRESSION_ZLIB,
> >>> +#define ENCODED_IOV_COMPRESSION_ZLIB ENCODED_IOV_COMPRESSION_ZLIB
> >>> + ENCODED_IOV_COMPRESSION_LZO,
> >>> +#define ENCODED_IOV_COMPRESSION_LZO ENCODED_IOV_COMPRESSION_LZO
> >>> + ENCODED_IOV_COMPRESSION_ZSTD,
> >>> +#define ENCODED_IOV_COMPRESSION_ZSTD ENCODED_IOV_COMPRESSION_ZSTD
> >>> + ENCODED_IOV_COMPRESSION_TYPES = ENCODED_IOV_COMPRESSION_ZSTD,
> >>
> >> This looks very dodgy, what am I missing?
> >
> > This is a somewhat common trick so that enum values can be checked for
> > with ifdef/ifndef. See include/uapi/linux.in.h, for example.
>
> I cannot seem to have this file on my system (or any .in.h file for that
> matter in the kernel source dir).
Whoops, that should be include/uapi/linux/in.h
^ permalink raw reply
* Re: [RFC PATCH v3 03/12] fs: add RWF_ENCODED for reading/writing compressed data
From: Nikolay Borisov @ 2019-11-27 9:00 UTC (permalink / raw)
To: Omar Sandoval
Cc: linux-fsdevel, linux-btrfs, Dave Chinner, Jann Horn,
Amir Goldstein, Aleksa Sarai, linux-api, kernel-team
In-Reply-To: <20191126173607.GA657777@vader>
On 26.11.19 г. 19:36 ч., Omar Sandoval wrote:
> On Tue, Nov 26, 2019 at 03:53:02PM +0200, Nikolay Borisov wrote:
>>
>>
>> On 20.11.19 г. 20:24 ч., Omar Sandoval wrote:
>>> From: Omar Sandoval <osandov@fb.com>
>>
>> <snip>
>>
>>>
>>> +enum {
>>> + ENCODED_IOV_COMPRESSION_NONE,
>>> +#define ENCODED_IOV_COMPRESSION_NONE ENCODED_IOV_COMPRESSION_NONE
>>> + ENCODED_IOV_COMPRESSION_ZLIB,
>>> +#define ENCODED_IOV_COMPRESSION_ZLIB ENCODED_IOV_COMPRESSION_ZLIB
>>> + ENCODED_IOV_COMPRESSION_LZO,
>>> +#define ENCODED_IOV_COMPRESSION_LZO ENCODED_IOV_COMPRESSION_LZO
>>> + ENCODED_IOV_COMPRESSION_ZSTD,
>>> +#define ENCODED_IOV_COMPRESSION_ZSTD ENCODED_IOV_COMPRESSION_ZSTD
>>> + ENCODED_IOV_COMPRESSION_TYPES = ENCODED_IOV_COMPRESSION_ZSTD,
>>
>> This looks very dodgy, what am I missing?
>
> This is a somewhat common trick so that enum values can be checked for
> with ifdef/ifndef. See include/uapi/linux.in.h, for example.
I cannot seem to have this file on my system (or any .in.h file for that
matter in the kernel source dir).
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox