On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
> On 06/12/2020 16:01, Pavel Begunkov wrote:
> > On 21/11/2020 14:37, Pavel Begunkov wrote:
> >> The problem here is that iov_iter_is_*() helpers check types for
> >> equality, but all iterate_* helpers do bitwise ands. This confuses
>
On Fri, Jan 08, 2021 at 09:26:40AM -0700, Jens Axboe wrote:
> >> Can you show the callers that DO NOT need it?
> >
> > OK, so here's my suggestion:
> >
> > 1) For 5.11, we just re-instate the task_work run in get_signal(). This
> >will make TWA_RESUME have the exact same behavior as before.
>
On Fri, Jan 08, 2021 at 08:13:25AM -0700, Jens Axboe wrote:
> > Anyway, bedtime for me; right now it looks like at least for task ==
> > current we always want TWA_SIGNAL. I'll look into that more tomorrow
> > when I get up, but so far it smells like switching everything to
> > TWA_SIGNAL would be
On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote:
> On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote:
> >
> > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> >
On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote:
> On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote:
> >
> > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> >
On Fri, Jan 08, 2021 at 05:26:51AM +, Al Viro wrote:
> On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > it down to the below patch. Debugging this issue, turns out that the boot
> >
On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> it down to the below patch. Debugging this issue, turns out that the boot
> stalled when a task is waiting on a pipe being released. As we no longer
> run task_w
On Thu, Jan 07, 2021 at 11:33:36AM -0800, Linus Torvalds wrote:
> In fact, even some threaded app that does what I suspect it could do
> would likely be ok with it 99% of the time. Because the situation
> where you change the fd in the poll array is likely not the common
> case, and even if some -
On Thu, Jan 07, 2021 at 10:47:07AM -0800, Linus Torvalds wrote:
> Now, the "whole entry" is just 8 bytes, so it's possible that it would
> actually be faster to do a copy of the whole thing rather than write
> just the 16 bits. But I got very nervous about it, because I could
> easily see some thr
On Thu, Jan 07, 2021 at 10:47:07AM -0800, Linus Torvalds wrote:
> On Thu, Jan 7, 2021 at 10:34 AM Al Viro wrote:
> >
> > I'm not sure it's the best approach, TBH. How about simply
> > for (walk = head; walk; ufds += walk->len, walk = walk->next) {
On Thu, Jan 07, 2021 at 06:40:58PM +, Al Viro wrote:
> do_sys_poll(): do the wholesale copyout
>
> Don't bother with patching up just one field - 16 bits out of each 64.
> The amount of memory traffic is not going to be greater (might be
> smaller, actually) and the loop
On Thu, Jan 07, 2021 at 06:33:58PM +, Al Viro wrote:
> On Thu, Jan 07, 2021 at 09:43:54AM -0800, Linus Torvalds wrote:
>
> > Before, it would do the whole CLAC/STAC dance inside that loop for
> > every entry (and with that commit d55564cfc22 it would be a function
&
On Thu, Jan 07, 2021 at 09:43:54AM -0800, Linus Torvalds wrote:
> Before, it would do the whole CLAC/STAC dance inside that loop for
> every entry (and with that commit d55564cfc22 it would be a function
> call, of course).
>
> Can you verify that this fixes the regression (and in fact I'd expect
On Thu, Jan 07, 2021 at 10:15:44AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> In file included from fs/erofs/xattr.h:10,
> from fs/erofs/namei.c:7:
> fs/erofs/namei.c: In fun
On Wed, Jan 06, 2021 at 08:12:27PM +, Ionela Voinescu wrote:
> Initially I though it always only makes sense to have a __iomem pointer.
> That is, it only makes sense to have a pointer with a cookie attached
> specifying that it addresses a device memory space that should only be
> accessed us
On Wed, Jan 06, 2021 at 03:07:24PM +, Ionela Voinescu wrote:
> > > > 367switch ((u64)reg->address) {
> >
> > That's not a dereference but I guess sparse complains of dropping the
> > __iomem. We could change the cast to (__force u64) to silence sparse.
Oh, yes, it is - that of ®
On Wed, Jan 06, 2021 at 03:52:14PM +, Ionela Voinescu wrote:
> > > > > vim +367 arch/arm64/kernel/topology.c
> > > > >
> > > > >362
> > > > >363int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
> > > > >364{
> > > > >365int ret = -
On Wed, Jan 06, 2021 at 08:51:12AM +0100, Geert Uytterhoeven wrote:
> On m68k, which does not define CORE_DUMP_USE_REGSET:
>
> fs/binfmt_elf.c: In function ‘fill_note_info’:
> fs/binfmt_elf.c:2040:20: error: passing argument 1 of ‘fill_prstatus’
> from incompatible pointer type [-Werror=i
On Tue, Jan 05, 2021 at 07:00:59PM -0500, Paul Moore wrote:
> > > Incidentally, LSM_AUDIT_DATA_DENTRY in mainline is *not* safe wrt
> > > rename() - for long-named dentries it is possible to get preempted
> > > in the middle of
> > > audit_log_untrustedstring(ab, a->u.dentry->d_nam
On Tue, Jan 05, 2021 at 06:03:15PM -0600, Eric W. Biederman wrote:
> > Yes, the current mainline is bloody awful in that area (PRSTATUS_SIZE and
> > SET_PR_FPVALID are not for weak stomach), but that's really not hard to
> > get into sane shape - -next had that done in last cycle and I'm currently
On Tue, Jan 05, 2021 at 12:38:31PM -0800, Linus Torvalds wrote:
> This whole thing isn't important enough to get the dentry lock. It's
> more of a hint than anything else.
>
> Why isn't the fix to just use READ_ONCE() of the name pointer, and do
> it under RCU?
Umm... Take a look at audit_log_u
On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
> LSM_AUDIT_DATA_DENTRY is easy to handle - wrap
> audit_log_untrustedstring(ab, a->u.dentry->d_name.name);
> into grabbing/dropping a->u.dentry->d_lock and we are done.
Incidentally, LSM_AUDIT_DATA_
On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
> struct dentry *d_find_alias_rcu(struct inode *inode)
> {
> struct hlist_head *l = &inode->i_dentry;
> struct dentry *de = NULL;
>
> spin_lock(&inode->i_lock);
> // ->i_den
On Tue, Jan 05, 2021 at 05:59:35AM +, Al Viro wrote:
> Umm... I'm rather worried about the side effect you are removing here -
> you are suddenly exposing a bunch of methods in there to RCU mode.
> E.g. is proc_pid_permission() safe with MAY_NOT_BLOCK in the mask?
> generic_
On Mon, Jan 04, 2021 at 03:21:22PM -0800, Stephen Brennan wrote:
> The pid_revalidate() function drops from RCU into REF lookup mode. When
> many threads are resolving paths within /proc in parallel, this can
> result in heavy spinlock contention on d_lockref as each thread tries to
> grab a refere
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../fs/dax.c: In function '
On Mon, Jan 04, 2021 at 06:47:38PM -0600, Eric W. Biederman wrote:
> >> It is defined in the Ubuntu kernel configs I've got lurking:
> >> Both 3.8.0-19_generic (Ubuntu 13.04) and 5.4.0-56_generic (probably 20.04).
> >> Which is probably why it is in my test builds (I've just cut out
> >> a lot of m
On Tue, Jan 05, 2021 at 09:36:16AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from arch/x86/include/asm/elf.h:8,
> from include/linux/elf.h:6,
>
On Mon, Jan 04, 2021 at 10:55:15AM -0800, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 09:44:18AM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > There's no need for mnt_want_write_file() to increment mnt_writers when
> > the file is already open for writing, provided that
> > mnt_drop
On Mon, Jan 04, 2021 at 01:43:47PM -0500, Jeff Layton wrote:
> @@ -172,7 +172,12 @@ SYSCALL_DEFINE1(syncfs, int, fd)
> ret = sync_filesystem(sb);
> up_read(&sb->s_umount);
>
> - ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err);
> + if (errseq_check(&sb->s_wb_e
On Mon, Jan 04, 2021 at 12:16:56PM +, David Laight wrote:
> On x86 in_compat_syscall() is defined as:
> in_ia32_syscall() || in_x32_syscall()
>
> Now in_ia32_syscall() is a simple check of the TS_COMPAT flag.
> However in_x32_syscall() is a horrid beast that has to indirect
> through to th
.c (regs->pc is a userland pointer when regs
is a
userland pt_regs)
* math-emu/math.c: READ() and WRITE() casts of address should be to userland
pointer.
No changes in code generation and those take care of the majority of noise from
sparse
on sh builds.
Signed-off-by: Al Viro
---
diff --gi
On Wed, Dec 30, 2020 at 03:01:25PM +0800, YANG LI wrote:
> Goto statement jumping will cause lock to be executed again without
> executing unlock, placing the lock statement in front of goto
> label to fix this problem.
>
> Signed-off-by: YANG LI
> Reported-by: Abaci
I am sorry, but have you ev
On Sun, Dec 27, 2020 at 12:12:00PM -0800, Linus Torvalds wrote:
> On Sun, Dec 27, 2020 at 11:05 AM Linus Torvalds
> wrote:
> >
> > On Sun, Dec 27, 2020 at 10:39 AM Jussi Kivilinna
> > wrote:
> > >
> > > 5.10.3 with patch compiles fine, but does not solve the issue.
> >
> > Duh. adding the read_i
On Sat, Dec 26, 2020 at 02:30:13PM -0800, Theodore Dubois wrote:
> I'm currently hacking on Linux trying to run a sort of UML-style thing on
> macOS (please don't question my sanity :), and I've run into various issues
> stemming from macOS having a case-insensitive filesystem.
>
> The one you
Assorted patches from previous cycle(s)...
The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:
Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc
for you
On Wed, Dec 23, 2020 at 07:12:13AM +, Al Viro wrote:
> On Wed, Dec 23, 2020 at 07:03:20AM +, Al Viro wrote:
>
> Argh Wrong commit blamed - the parent of the correct one.
> It's actually 2aa362c49c31 ("coredump: extend core dump note section to
> con
On Wed, Dec 23, 2020 at 07:03:20AM +, Al Viro wrote:
Argh Wrong commit blamed - the parent of the correct one.
It's actually 2aa362c49c31 ("coredump: extend core dump note section to
contain file names of mapped files"). My apologies - fat-finge
[Denys Vlasenko cc'd]
On Wed, Dec 16, 2020 at 09:44:53AM +, Maciej W. Rozycki wrote:
> On Wed, 16 Dec 2020, Al Viro wrote:
>
> > > It may be worth pushing through GDB's gdb.threads/tls-core.exp test
> > > case,
> > > making sure no UNSUPPORTED
On Tue, Dec 22, 2020 at 09:38:35PM +, Al Viro wrote:
> On Tue, Dec 22, 2020 at 08:04:31PM +, Al Viro wrote:
>
> > FWIW, on debian/mips64el (both stretch and buster) the test fails with the
> > distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and
> > 5
On Tue, Dec 22, 2020 at 08:04:31PM +, Al Viro wrote:
> FWIW, on debian/mips64el (both stretch and buster) the test fails with the
> distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and
> 5.10-rc1+that series, all in the same way:
> [Current thread is 1 (LWP 4154)]
>
On Wed, Dec 16, 2020 at 09:44:53AM +, Maciej W. Rozycki wrote:
> On Wed, 16 Dec 2020, Al Viro wrote:
>
> > > It may be worth pushing through GDB's gdb.threads/tls-core.exp test
> > > case,
> > > making sure no UNSUPPORTED results have been produced du
On Tue, Dec 22, 2020 at 11:06:26AM +0800, Liangyan wrote:
> Cc:
> Fixes: a6c606551141 ("ovl: redirect on rename-dir")
> Signed-off-by: Liangyan
> Reviewed-by: Joseph Qi
> Suggested-by: Al Viro
Fine by me... I can put it through vfs.git#fixes, but IMO
that would b
On Tue, Dec 22, 2020 at 02:33:27AM +0800, Liangyan wrote:
> diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
> index 28a075b5f5b2..e9aa4a12ad82 100644
> --- a/fs/overlayfs/dir.c
> +++ b/fs/overlayfs/dir.c
> @@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool
> abs_re
On Tue, Dec 22, 2020 at 12:51:27AM +0800, Liangyan wrote:
> This is the race scenario based on call trace we captured which cause the
> dentry leak.
>
>
> CPU 0CPU 1
> ovl_set_redirect lookup_fast
> ovl_get_redirect
On Mon, Dec 21, 2020 at 07:14:44PM +0800, Joseph Qi wrote:
> Hi Viro,
>
> On 12/21/20 2:26 PM, Al Viro wrote:
> > On Sun, Dec 20, 2020 at 08:09:27PM +0800, Liangyan wrote:
> >
> >> +++ b/fs/overlayfs/dir.c
> >> @@ -973,6 +973,7 @@ static char *ovl_get_red
On Sun, Dec 20, 2020 at 08:09:27PM +0800, Liangyan wrote:
> +++ b/fs/overlayfs/dir.c
> @@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool
> abs_redirect)
> for (d = dget(dentry); !IS_ROOT(d);) {
> const char *name;
> int thislen;
> +
[Christoph added to Cc...]
On Wed, Dec 16, 2020 at 06:31:47PM -0500, Vivek Goyal wrote:
> Current implementation of __sync_filesystem() ignores the return code
> from ->sync_fs(). I am not sure why that's the case. There must have
> been some historical reason for this.
>
> Ignoring ->sync_fs() re
On Tue, Dec 15, 2020 at 06:23:18PM +0530, Siddhesh Poyarekar wrote:
> +static char *copy_mount_devname(const void __user *data)
> +{
> + char *p;
> + long length;
> +
> + if (data == NULL)
> + return NULL;
> +
> + length = strnlen_user(data, PATH_MAX);
> +
> + if (!
On Mon, Dec 07, 2020 at 06:01:43PM +, Maciej W. Rozycki wrote:
> On Thu, 3 Dec 2020, Al Viro wrote:
>
> > > Linux-mips was cc'd, but I'm adding Thomas B to the cc here explicitly
> > > just so that he has a heads-up on this thing and can go and look at
>
On Tue, Dec 15, 2020 at 07:41:23PM +0300, Sergey Temerkhanov wrote:
> Unlock RCU before running another loop iteration
If you are able to keep it looping for a long time, I would really
like to see the reproducer.
On Tue, Dec 15, 2020 at 09:54:54AM +0530, Siddhesh Poyarekar wrote:
> + get_user(byte, (const char __user *)data);
> +
> + return byte ? strndup_user(data, PATH_MAX) : NULL;
> }
No. Not to mention anything else, you
* fetch the same data twice
* fail to check the get_use
0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git regset.followup
for you to fetch changes up to d4948d19d47f08f926db55f0fb8cb324e43f1c19:
c6x: kill ELF_CORE_COPY_FPREGS (2020-10-25 20:0
b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.epoll
for you to fetch changes up to 319c15174757aaedacc89a6e55c965416f130e64:
epoll: take epitem list out of struct file (2020
On Thu, Nov 19, 2020 at 05:12:44PM +, Pavel Begunkov wrote:
> On 19/11/2020 17:03, Christoph Hellwig wrote:
> > On Thu, Nov 19, 2020 at 03:29:43PM +, Pavel Begunkov wrote:
> >> The problem here is that iov_iter_is_*() helpers check types for
> >> equality, but all iterate_* helpers do bitwi
On Sat, Nov 21, 2020 at 10:21:17AM -0800, Linus Torvalds wrote:
> So I think conceptually this is the right thing to do, but I have a
> couple of worries:
>
> - do we really need all those different versions? I'm thinking
> "iter_full" versions in particular. They I think the iter_full version
>
On Thu, Dec 10, 2020 at 10:54:05PM +, Al Viro wrote:
> On Thu, Dec 10, 2020 at 11:30:24PM +0100, Christian Brauner wrote:
> > (requiring btf), i.e. security_file_open, then follow
> > file->f_inode->i_sb->s_type->s_magic. If we change the say struct
> >
On Thu, Dec 10, 2020 at 11:30:24PM +0100, Christian Brauner wrote:
> (requiring btf), i.e. security_file_open, then follow
> file->f_inode->i_sb->s_type->s_magic. If we change the say struct
> super_block I'd expect these bpf programs to break.
To break they would need to have compiled in the firs
On Thu, Dec 10, 2020 at 01:29:01PM -0600, Eric W. Biederman wrote:
> Al Viro writes:
> > What are the users of that thing and is there any chance to replace it
> > with something saner? IOW, what *is* realistically called for each
> > struct file by the users of that iterat
On Wed, Dec 09, 2020 at 03:32:38PM -0600, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Wed, Dec 09, 2020 at 11:13:38AM -0800, Linus Torvalds wrote:
> >> On Wed, Dec 9, 2020 at 10:05 AM Eric W. Biederman
> >> wrote:
> >> >
> >> > -
On Wed, Dec 09, 2020 at 07:49:38PM +, Matthew Wilcox wrote:
> On Wed, Dec 09, 2020 at 12:04:38PM -0600, Eric W. Biederman wrote:
> > @@ -397,8 +397,9 @@ static struct fdtable *close_files(struct files_struct
> > * files)
> > set = fdt->open_fds[j++];
> > while (set) {
>
On Wed, Dec 09, 2020 at 03:24:03PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> Running my yearly branch profiling code, it detected a 100% wrong branch
> condition in name.c for lookup_fast(). The code in question has:
>
> status = d_revalidate(dentry, nd->fla
On Wed, Dec 09, 2020 at 11:13:38AM -0800, Linus Torvalds wrote:
> On Wed, Dec 9, 2020 at 10:05 AM Eric W. Biederman
> wrote:
> >
> > - struct file * file = xchg(&fdt->fd[i],
> > NULL);
> > + struct file * file = fdt->fd[i];
> >
On Wed, Dec 09, 2020 at 02:19:50AM +, Pavel Begunkov wrote:
> The idea is to avoid copying, merging, etc. bvec from iterator to bio
> in direct I/O and use the one we've already got. Hook it up for io_uring.
> Had an eye on it for a long, and it also was brought up by Matthew
> just recently. L
[paulmck Cc'd]
On Mon, Dec 07, 2020 at 10:49:04PM +, Al Viro wrote:
> On Mon, Dec 07, 2020 at 10:46:57PM +0000, Al Viro wrote:
> > On Fri, Nov 20, 2020 at 05:14:26PM -0600, Eric W. Biederman wrote:
> >
> > > /*
> > > * Check whe
On Tue, Dec 08, 2020 at 10:24:57PM -0600, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Tue, Dec 08, 2020 at 04:38:09PM -0600, Eric W. Biederman wrote:
> >
> >> Is there any reason we don't simply rcu free the files_struct?
> >> That would r
On Wed, Dec 09, 2020 at 07:21:00PM +0800, Yahu Gao wrote:
> Get the staus of task from the pointer of proc inode directly is not
> safe. The function get_proc_task make it happen in RCU protection.
This is completely broken, get_proc_task() acquires a reference to
task_struct; your patch is an in
On Wed, Dec 09, 2020 at 08:36:45AM +, Christoph Hellwig wrote:
>
> This is making the iter type even more of a mess than it already is.
> I think we at least need placeholders for 0/1 here and an explicit
> flags namespace, preferably after the types.
>
> Then again I'd much prefer if we didn
On Tue, Dec 08, 2020 at 04:38:09PM -0600, Eric W. Biederman wrote:
> Is there any reason we don't simply rcu free the files_struct?
> That would remove the need for the task_lock entirely.
Umm... Potentially interesting part here is the interaction with
close_files(); currently that can't overla
The following changes since commit 4bbf439b09c5ac3f8b3e9584fe080375d8d0ad2d:
fix return values of seq_read_iter() (2020-11-15 22:12:53 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
for you to fetch changes up to
On Tue, Dec 08, 2020 at 12:25:55PM -0800, Linus Torvalds wrote:
> On Tue, Dec 8, 2020 at 11:49 AM Al Viro wrote:
> >
> > Said that, it does appear to survive all beating, and it does fix
> > a regression introduced in this cycle, so, provided that amount of
> > comme
10a8b46082224376ef119a4dbb75b25c56:
seq_file: add seq_read_iter (2020-11-06 10:05:18 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
for you to fetch changes up to 4bbf439b09c5ac3f8b3e9584fe080375d8d0ad2d:
fix return
On Thu, Dec 03, 2020 at 02:30:46AM +, Pavel Begunkov wrote:
> Handle task works and lock it earlier before it starts killing off
> task's resources like mm. io_uring makes use of it a lot and it'd
> nicer to have all added task_work finding tasks in a consistent state.
>
> Signed-off-by: Pavel
On Tue, Dec 08, 2020 at 03:09:47AM +0300, Anatoly Pugachev wrote:
> Hello!
>
> Sorry for the late report, being 5.10-rc7 is out, but current git
> kernel (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)
> is broken with the networking. It affects my openvpn tunnel and even
>
On Sat, Nov 28, 2020 at 05:12:26AM +, Al Viro wrote:
> On Fri, Nov 20, 2020 at 04:05:47PM -0800, Linus Torvalds wrote:
> > On Fri, Nov 20, 2020 at 3:11 PM Eric W. Biederman
> > wrote:
> > >
> > > This set of changes cleanups of the code in exec so hopefully
On Mon, Dec 07, 2020 at 05:07:55PM -0600, Eric W. Biederman wrote:
> My mistake. I missed that the actual code was highly optimized and only
> safe in the presence of an unshared files struct.
That's a polite way to spell "overoptimized for no good reason" ;-)
> What I saw and what I thought th
On Fri, Nov 20, 2020 at 05:14:32PM -0600, Eric W. Biederman wrote:
> When discussing[1] exec and posix file locks it was realized that none
> of the callers of get_files_struct fundamentally needed to call
> get_files_struct, and that by switching them to helper functions
> instead it will both sim
On Mon, Dec 07, 2020 at 10:46:57PM +, Al Viro wrote:
> On Fri, Nov 20, 2020 at 05:14:26PM -0600, Eric W. Biederman wrote:
>
> > /*
> > * Check whether the specified fd has an open file.
> > */
> > -#define fcheck(fd) fcheck_files(current->
On Fri, Nov 20, 2020 at 05:14:26PM -0600, Eric W. Biederman wrote:
> /*
> * Check whether the specified fd has an open file.
> */
> -#define fcheck(fd) fcheck_files(current->files, fd)
> +#define fcheck(fd) files_lookup_fd_rcu(current->files, fd)
Huh?
fs/file.c:1113: file = fcheck(oldfd)
On Mon, Nov 23, 2020 at 10:25:13AM -0800, Linus Torvalds wrote:
> On Mon, Nov 23, 2020 at 9:52 AM Oleg Nesterov wrote:
> >
> > Can anyone explain why does do_coredump() need unshare_files() at all?
>
> Hmm. It goes back to 2012, and it's placed just before calling
> "->core_dump()", so I assume s
On Fri, Nov 20, 2020 at 05:14:18PM -0600, Eric W. Biederman wrote:
> @@ -1805,8 +1808,12 @@ static int bprm_execve(struct linux_binprm *bprm,
> bprm->file = file;
> /*
>* Record that a name derived from an O_CLOEXEC fd will be
> - * inaccessible after exec. Relies on having
On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
> > > The answer (for mainline) is that mips compat does *NOT* want
> > > COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> > > retested it (seems to work, both for x86_64 and mips64, e
On Thu, Dec 03, 2020 at 02:09:04PM -0800, Linus Torvalds wrote:
> On Thu, Dec 3, 2020 at 1:46 PM Al Viro wrote:
> >
> > The answer (for mainline) is that mips compat does *NOT* want
> > COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> > rete
From: Al Viro
it's always been about MIPS32
Signed-off-by: Al Viro
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2000bb2b0220..32ce052aa3b4 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2
From: Al Viro
To get rid of hardcoded size/offset in those macros we need to have
a definition of i386 variant of struct elf_prstatus. However, we can't
do that in asm/compat.h - the types needed for that are not there and
adding an include of asm/user32.h into asm/compat.h would cause a l
From: Al Viro
with mips converted to use of fs/config_binfmt_elf.c, there's no
need to keep selects of that thing all over arch/* - we can simply
turn into def_bool y if COMPAT && BINFMT_ELF (in fs/Kconfig.binfmt)
and get rid of all selects.
Several architectures got those selec
From: Al Viro
Like amd64, mips has two 32bit ABIs - o32 and n32. Unlike amd64,
it does not use compat_binfmt_elf.c for either of those; each
of those ABIs has a binfmt handler of its own, both very similar
to fs/compat_binfmt_elf.c. And the same technics as we use on
amd64 can be used to make
From: Al Viro
... rather than duplicating declarations from it.
Signed-off-by: Al Viro
---
arch/mips/kernel/binfmt_elfn32.c | 37 -
arch/mips/kernel/binfmt_elfo32.c | 36
2 files changed, 8 insertions(+), 65 deletions
From: Al Viro
Preparations to doing i386 compat elf_prstatus sanely - rather than duplicating
the beginning of compat_elf_prstatus, take these fields into a separate
structure (compat_elf_prstatus_common), so that it could be reused. Due to
the incestous relationship between binfmt_elf.c and
From: Al Viro
normal mips one is just fine - it's only used after we'd done
SET_PERSONALITY2() and by that point TASK_SIZE will yield the
right value
Signed-off-by: Al Viro
---
arch/mips/include/asm/elf.h | 2 --
arch/mips/kernel/binfmt_elfn32.c | 4
arch/mips/kernel/binfm
From: Al Viro
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously
From: Al Viro
mips coredumps are regset-based, so ELF_CORE_EFLAGS is not used at all -
user_..._view.e_flags is.
Signed-off-by: Al Viro
---
arch/mips/kernel/binfmt_elfn32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/kernel/binfmt_elfn32.c b/arch/mips/kernel/binfmt_elfn32.c
From: Al Viro
elf_caddr_t: unused since 2002
jiffies_to_timeval: unused since 2015
TASK_SIZE: used only downstream of SET_PERSONALITY2(), and after that
point the normal definition results in TASK_SIZE32 just fine.
Signed-off-by: Al Viro
---
arch/mips/kernel/binfmt_elfn32.c | 18
seems to work, both for x86_64 and mips64, execs and
coredumps for all ABIs alike), with centralization of Kconfig logics
thrown in.
It's based at 5.10-rc1 and lives in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git#work.elf-compat
I'll post the individua
On Sat, Nov 28, 2020 at 06:19:31PM -0800, Walt Drummond wrote:
> Thanks Al. I want to understand the nuance, so please bear with me as I
> reason this out. The cast in stone nature of this is due to both the need
> to keep userspace and kernel space in sync (ie, you'd have to coordinate
> libc a
sigset_t is
present in user-visible data structures. Including the ones
we are using that thing for - struct rt_sigframe, for starters.
Layout of those suckers is very much cast in stone. We *can't*
change it, no matter what we do kernel-side.
NAKed-by: Al Viro
On Fri, Nov 20, 2020 at 04:05:47PM -0800, Linus Torvalds wrote:
> On Fri, Nov 20, 2020 at 3:11 PM Eric W. Biederman
> wrote:
> >
> > This set of changes cleanups of the code in exec so hopefully this code
> > will not regress again. Then it adds helpers and fixes the users of
> > files_struct so
On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 8:47 AM Mimi Zohar wrote:
> >
> > This discussion seems to be going down the path of requiring an IMA
> > filesystem hook for reading the file, again. That solution was
> > rejected, not by me. What is new
On Sun, Nov 15, 2020 at 05:34:16PM -0700, Nathan Chancellor wrote:
> Still good.
>
> Tested-by: Nathan Chancellor
Pushed into #fixes
> > BTW, is that call of readv() really coming from init? And if it
> > is, what version of init are you using?
>
> I believe that it is but since this is WSL
On Sun, Nov 15, 2020 at 04:51:49PM -0700, Nathan Chancellor wrote:
> Looks good to me on top of d4d50710a8b46082224376ef119a4dbb75b25c56,
> thanks for quickly looking into this!
>
> Tested-by: Nathan Chancellor
OK... a variant with (hopefully) better comments and cleaned up
logics in the second
201 - 300 of 4782 matches
Mail list logo
