On Fri, Nov 13, 2020 at 04:54:53PM -0700, Nathan Chancellor wrote:
> Hi Al,
>
> On Wed, Nov 11, 2020 at 10:21:16PM +, Al Viro wrote:
> > On Wed, Nov 11, 2020 at 09:52:20PM +, Al Viro wrote:
> >
> > > That can be done, but I would rather go with
> > >
On Sat, Nov 14, 2020 at 07:00:25AM +, Al Viro wrote:
> On Fri, Nov 13, 2020 at 11:19:34PM -0700, Nathan Chancellor wrote:
>
> > Assuming so, I have attached the output both with and without the
> > WARN_ON. Looks like mountinfo is what is causing the error?
>
> C
On Fri, Nov 13, 2020 at 11:19:34PM -0700, Nathan Chancellor wrote:
> Assuming so, I have attached the output both with and without the
> WARN_ON. Looks like mountinfo is what is causing the error?
Cute... FWIW, on #origin + that commit with fix folded in I don't
see anything unusual in reads
On Fri, Nov 13, 2020 at 09:14:20PM -0700, Nathan Chancellor wrote:
> Unfortunately that patch does not solve my issue. Is there any other
> debugging I should add?
Hmm... I wonder which file it is; how about
if (WARN_ON(!iovec.iov_len))
printk(KERN_ERR
On Fri, Nov 13, 2020 at 08:01:24PM -0700, Nathan Chancellor wrote:
> Sure thing, it does trigger.
>
> [0.235058] [ cut here ]
> [0.235062] WARNING: CPU: 15 PID: 237 at fs/seq_file.c:176
> seq_read_iter+0x3b3/0x3f0
> [0.235064] CPU: 15 PID: 237 Comm: localhost
On Fri, Nov 13, 2020 at 04:54:53PM -0700, Nathan Chancellor wrote:
> This patch in -next (6a9f696d1627bacc91d1cebcfb177f474484e8ba) breaks
> WSL2's interoperability feature, where Windows paths automatically get
> added to PATH on start up so that Windows binaries can be accessed from
> within
On Fri, Nov 13, 2020 at 05:56:09PM +0800, Yicong Yang wrote:
> The attr->set() receive a value of u64, but simple_strtoll() is used
> for doing the conversion. It will lead to the error cast if user inputs
> a negative value.
>
> Use kstrtoull() instead of simple_strtoll() to convert a string got
On Thu, Nov 12, 2020 at 04:48:09PM -0800, Andrew Morton wrote:
> [v...@zeniv.linux.org.uk: use linux/uaccess.h]
> Link: https://lkml.kernel.org/r/2020005826.gy3576...@zeniv.linux.org.uk
> Link: https://lkml.kernel.org/r/2020004440.8783-1-ansuels...@gmail.com
> Fixes: df325e05a682
On Fri, Nov 13, 2020 at 08:02:39AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 5f85b351d3d6 ("fix return values of seq_read_iter()")
>
> Fixes tag
>
> Fixes: d4d50710a8b (seq_file: add seq_read_iter)
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
c cause to ever need other errors
there (well, short of some clown attaching a hook, pardon the obscenity),
so I would recommend something like the patch below (completely untested):
sanitize sock_from_file() calling conventions
deal with error value (always -ENOTSOCK) in the callers
Signed-off-by: Al Viro
On Wed, Nov 11, 2020 at 04:53:00PM +0800, yulei zhang wrote:
> > ... same here, seeing that you only call that thing from the next two
> > functions
> > and you do *not* provide ->mknod() as a method (unsurprisingly - what would
> > device nodes do there?)
> >
>
> Thanks for pointing this out.
On Wed, Nov 11, 2020 at 02:27:02PM -0800, Linus Torvalds wrote:
> On Wed, Nov 11, 2020 at 2:21 PM Al Viro wrote:
> >
> > Something like below (build-tested only):
>
> Apart from my usual "oh, Gods, the iter model really does confuse me"
> this lo
On Wed, Nov 11, 2020 at 09:52:20PM +, Al Viro wrote:
> That can be done, but I would rather go with
> n = copy_to_iter(m->buf + m->from, m->count, iter);
> m->count -= n;
> m->from += n;
> copied +=
On Wed, Nov 11, 2020 at 09:54:12AM -0800, Linus Torvalds wrote:
> On Tue, Nov 10, 2020 at 3:20 PM Al Viro wrote:
> >
> > Any objections to the following?
>
> Well, I don't _object_, but I find it ugly.
>
> And I think both the old and the "fixed" c
On Wed, Nov 11, 2020 at 12:58:26AM +, Al Viro wrote:
> On Wed, Nov 11, 2020 at 01:44:38AM +0100, Ansuel Smith wrote:
> > Fix a compilation error as PF_KTHREAD is defined in linux/sched.h and
> > this is missing.
> >
> > Fixes: df325e05a682 ("arm64: Valida
On Wed, Nov 11, 2020 at 01:44:38AM +0100, Ansuel Smith wrote:
> Fix a compilation error as PF_KTHREAD is defined in linux/sched.h and
> this is missing.
>
> Fixes: df325e05a682 ("arm64: Validate tagged addresses in access_ok()
> called from kernel threads")
> Signed-off-by: Ansuel Smith
> ---
>
On Tue, Nov 10, 2020 at 09:35:11PM +, Al Viro wrote:
> On Tue, Nov 10, 2020 at 09:32:53PM +0000, Al Viro wrote:
>
> > AFAICS, not all callers want that semantics, but I think it's worth
> > a new primitive. I'm not saying it should be a prereq for your
>
On Tue, Nov 10, 2020 at 09:32:53PM +, Al Viro wrote:
> AFAICS, not all callers want that semantics, but I think it's worth
> a new primitive. I'm not saying it should be a prereq for your
> series, but either that or an explicit iov_iter_revert() is needed.
Seeing that it alr
On Wed, Nov 04, 2020 at 09:27:33AM +0100, Christoph Hellwig wrote:
> ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t
> *ppos)
> {
> - struct seq_file *m = file->private_data;
> + struct iovec iov = { .iov_base = buf, .iov_len = size};
> + struct kiocb
On Thu, Oct 08, 2020 at 03:53:51PM +0800, yulei.ker...@gmail.com wrote:
> +static struct inode *
> +dmemfs_get_inode(struct super_block *sb, const struct inode *dir, umode_t
> mode,
> + dev_t dev);
WTF is 'dev' for?
> +static int
> +dmemfs_mknod(struct inode *dir, struct dentry
On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote:
> I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd like
> it to go through the sparc tree anyway).
Done - sorry for disappearing ;-/
/pub/scm/linux/kernel/git/viro/vfs.git fixes
for you to fetch changes up to 77f6ab8b7768cf5e6bdd0e72499270a0671506ee:
don't dump the threads that had been already exiting when zapped. (2020-10-28
16:39:49 -0400)
Al Viro (1
On Fri, Oct 30, 2020 at 02:33:11PM -0600, Jens Axboe wrote:
> On 10/30/20 12:49 PM, Al Viro wrote:
> > On Fri, Oct 30, 2020 at 12:46:26PM -0600, Jens Axboe wrote:
> >
> >> See other reply, it's being posted soon, just haven't gotten there yet
> >> and it wasn't r
On Fri, Oct 30, 2020 at 12:46:26PM -0600, Jens Axboe wrote:
> See other reply, it's being posted soon, just haven't gotten there yet
> and it wasn't ready.
>
> It's a prep patch so we can call do_renameat2 and pass in a filename
> instead. The intent is not to have any functional changes in that
On Fri, Oct 30, 2020 at 11:24:07AM -0400, Qian Cai wrote:
> We will need to call putname() before do_renameat2() returning -EINVAL
> to avoid memory leaks.
>
> Fixes: 3c5499fa56f5 ("fs: make do_renameat2() take struct filename")
> Signed-off-by: Qian Cai
May I ask where has the original commit
On Wed, Oct 28, 2020 at 02:27:20PM +0800, zc wrote:
> Hi viro:
>
> have time for reviewing this?
Start with removing unused boilerplate. When quite a chunk
of the codebase is simply never used, filtering _that_ out
is on the author, not reviewers.
On Wed, Oct 28, 2020 at 11:03:52AM +0800, Zhiqiang Liu wrote:
>
> In create_pipe_files(), if alloc_file_clone() fails, we will call
> put_pipe_info to release pipe, and call fput() to release f.
> However, we donot call iput() to free inode.
Huh? Have you actually tried to trigger that failure
On Tue, Oct 20, 2020 at 02:30:07PM +0800, Zou Cao wrote:
> +ssize_t regfs_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
> +{
> + struct file *file = iocb->ki_filp;
> + struct inode *inode = file->f_mapping->host;
> + ssize_t ret;
> +
> + inode_lock(inode);
> + ret
On Tue, Oct 27, 2020 at 03:14:14PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (sparc_defconfig)
> failed like this:
>
> arch/sparc/lib/memset.S: Assembler messages:
> arch/sparc/lib/memset.S:149: Error: Unknown opcode: `ext(12b, 13b,21f)'
>
On Mon, Oct 26, 2020 at 06:03:18PM -0600, Jens Axboe wrote:
> The removal of compat_process_vm_{readv,writev} didn't change
> process_vm_rw(), which always assumes it's not doing a compat syscall.
> Instead of passing in 'false' unconditionally for 'compat', make it
> conditional on
On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote:
> On 10/26/20 4:55 PM, Kyle Huey wrote:
> > A test program from the rr[0] test suite, vm_readv_writev[1], no
> > longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
> > on a 64 bit kernel. The first process_vm_readv
changes up to f2d077ff1b5c17008cff5dc27e7356a694e55462:
fs: remove KSTAT_QUERY_FLAGS (2020-09-26 22:55:05 -0400)
Al Viro (1):
reduce boilerplate in fsid handling
Alex Dewar (1):
fs: omfs: use kmemdup() rather than
On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote:
> Now, I am not a compiler expert, but as I already cited, at least on
> x86-64 clang expects that the high bits were cleared by the caller - in
> contrast to gcc. I suspect it's the same on arm64, but again, I am no
> compiler
On Thu, Oct 22, 2020 at 01:59:32PM -0700, Eric Biggers wrote:
> Also note the following program succeeds on Linux 5.9 on x86_64. On kernels
> that have this bug, it should fail. (I couldn't get it to actually fail, so
> it
> must depend on the compiler and/or the kernel config...)
It doesn't.
On Thu, Oct 22, 2020 at 09:06:29PM +0100, Al Viro wrote:
> On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote:
>
> > Depending upon the calling conventions, compiler might do truncation in
> > caller or
> > in a callee, but it must be done _somewhere_.
>
>
On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote:
> Depending upon the calling conventions, compiler might do truncation in
> caller or
> in a callee, but it must be done _somewhere_.
Unless I'm misreading AAPCS64,
"Unlike in the 32-bit AAPCS, named integr
On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote:
> On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote:
>
> > Passing an `unsigned long` as an `unsigned int` does no such
> > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail
>
On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote:
> Passing an `unsigned long` as an `unsigned int` does no such
> narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail
> calls, no masking instructions).
> So if rw_copy_check_uvector() is inlined into import_iovec()
On Thu, Oct 22, 2020 at 05:40:40PM +0100, Matthew Wilcox wrote:
> On Thu, Oct 22, 2020 at 04:35:17PM +, David Laight wrote:
> > Wait...
> > readv(2) defines:
> > ssize_t readv(int fd, const struct iovec *iov, int iovcnt);
>
> It doesn't really matter what the manpage says. What does the
On Thu, Oct 22, 2020 at 04:39:52PM +0800, Luo Jiaxing wrote:
> We already own DEFINE_SHOW_ATTRIBUTE() helper macro for defining attribute
> for read-only file, but we found many of drivers also want a helper marco for
> read-write file too.
DEFINE_SHOW_ATTRIBUTE is a bloody bad idea; let's not
Christoph's set_fs base series + fixups. A few trivial conflicts
(arch/{ia64,m68k/s390}/Kconfig and arch/x86/lib/getuser.S); proposed
resolution in #merge-candidate, same as in -next.
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1
On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote:
> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote:
> > From: David Laight
> >
> > This lets the compiler inline it into import_iovec() generating
> > much better code.
> >
> > Signed-off-by: David Laight
> >
On Wed, Oct 14, 2020 at 05:31:14PM -0700, Darrick J. Wong wrote:
> AFAICT, nobody is attempting to land any major changes in any of the vfs
> remap functions during the 5.10 window -- for-next showed conflicts only
> in the Makefile, so it seems like a quiet enough time to do this. There
> are
On Wed, Oct 14, 2020 at 03:51:00PM -0700, Linus Torvalds wrote:
> On Wed, Oct 14, 2020 at 3:27 PM Jason A. Donenfeld wrote:
> >
> > This patch is causing crashes in WireGuard's CI over at
> > https://www.wireguard.com/build-status/ . Apparently sending a simple
> > network packet winds up
On Wed, Oct 14, 2020 at 01:45:28PM -0700, Andrii Nakryiko wrote:
> Fix data race in prepend_path() with re-reading mnt->mnt_ns twice without
> holding the lock. is_mounted() does check for NULL, but
> is_anon_ns(mnt->mnt_ns)
> might re-read the pointer again which could be NULL already, if in
On Wed, Oct 14, 2020 at 02:49:18PM -0700, Linus Torvalds wrote:
> On Wed, Oct 14, 2020 at 2:40 PM Andrii Nakryiko wrote:
> >
> > Fix data race in prepend_path() with re-reading mnt->mnt_ns twice without
> > holding the lock. is_mounted() does check for NULL, but
> > is_anon_ns(mnt->mnt_ns)
> >
On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
> + spin_lock(_fds->file_lock);
> + fdt = files_fdtable(cur_fds);
> + cur_max = fdt->max_fds - 1;
> + max_fd = min(max_fd, cur_max);
> + while (fd <= max_fd)
> +
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You
The last remnants of mount(2) compat buried. Buried into NFS, that is;
generally I'm less enthusiastic about "let's use in_compat_syscall() deep in
call chain" kind of approach than Christoph seems to be, but in this case it's
warranted - that crap had been an NFS-specific wart, hopefully
More Christoph's compat cleanups: quotactl(2).
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.quota-compat
Christoph's series around import_iovec() and compat variant thereof.
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the git repository at:
)
Al Viro (19):
skb_copy_and_csum_bits(): don't bother with the last argument
icmp_push_reply(): reorder adding the checksum up
unify generic instances of csum_partial_copy_nocheck()
csum_partial_copy_nocheck(): drop the last argument
csum_and_copy_..._user
On Mon, Oct 12, 2020 at 12:46:03AM +0500, Mikhail Gavrilov wrote:
> Hi folks!
> I have a question.
> What happens when dd writes data to a missing device?
>
> For example:
> # dd
> if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
> of=/dev/adb
>
> Today I and
Sat in -next for a while, fixes an obvious bug
(leak introduced in 5.8, i.e. the mess from previous cycle).
The following changes since commit 933a3752babcf6513117d5773d2b70782d6ad149:
fuse: fix the ->direct_IO() treatment of iov_iter (2020-09-17 17:26:56 -0400)
are available in the
On Sun, Oct 11, 2020 at 07:17:49AM -0700, Guenter Roeck wrote:
> Someone didn't bother test building this patch.
>
> arch/alpha/kernel/osf_sys.c: In function '__do_sys_osf_mount':
> arch/alpha/kernel/osf_sys.c:437:14: error: 'path' redeclared as different
> kind of symbol
Quite. Matter of
On Mon, Oct 05, 2020 at 04:37:18PM -0400, Qian Cai wrote:
> On Sun, 2020-10-04 at 03:39 +0100, Al Viro wrote:
> > /*
> > * Must be called with "mtx" held.
> > */
> > @@ -1367,19 +1454,21 @@ static int ep_insert(struct eventpoll *ep, const
> > st
On Sun, Oct 04, 2020 at 11:08:11AM -0700, Linus Torvalds wrote:
> On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote:
> >
> > Locking and especially control flow in fs/eventpoll.c is
> > overcomplicated. As the result, the code has been hard to follow
> > and easy
On Sun, Oct 04, 2020 at 03:17:45PM +0100, Al Viro wrote:
> On Sun, Oct 04, 2020 at 08:56:19PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 9ee1cc56661640a2ace2f7d0b52dec56b3573c53 (
n itself")
> url:
> https://github.com/0day-ci/linux/commits/Al-Viro/epoll-switch-epitem-pwqlist-to-single-linked-list/20201004-113938
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> 22fbc037cd32e4e6771d2271b565806cfb8c134c
False positive, actually - tha
On Sun, Oct 04, 2020 at 01:13:29PM +0100, Matthew Wilcox wrote:
> Have you considered just storing a pointer to each struct file in an
> epoll set in an XArray? Linked lists suck for modern CPUs, and there'd
> be no need to store any additional data in each struct file. Using
> xa_alloc() to
On Sun, Oct 04, 2020 at 03:36:08AM +0100, Al Viro wrote:
> Locking and especilly control flow in fs/eventpoll.c is
> overcomplicated. As the result, the code has been hard to follow
> and easy to fuck up while modifying.
>
> The following series attempts to untangle i
From: Al Viro
We know there's no loops by the time we call it; the
only thing we care about is too deep reverse paths.
Signed-off-by: Al Viro
---
fs/eventpoll.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 3e6f1f97f246
From: Al Viro
we use it only to indicate allocation failures within queueing
callback back to ep_insert(). Might as well use epq.epi for that
reporting...
Signed-off-by: Al Viro
---
fs/eventpoll.c | 46 --
1 file changed, 20 insertions(+), 26
From: Al Viro
Move the head of epitem list out of struct file; for epoll ones it's
moved into struct eventpoll (->refs there), for non-epoll - into
the new object (struct epitem_head). In place of ->f_ep_links we
leave a pointer to the list head (->f_ep).
->f_ep is protected
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 43aecae0935c..bd2cc78c47c8 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -424,6 +424,21 @@ static
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 0f540e91aa92..33af838046ea 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1317,23 +1317,15
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 33af838046ea..9edea3933790 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1877,9 +1877,6 @@ static int
From: Al Viro
The only remaining user is loop checking. But there we only need
to check that we have not walked into the epoll we are inserting
into - we are adding an edge to acyclic graph, so any loop being
created will have to pass through the source of that edge.
So we don't need
From: Al Viro
we don't care about the order of elements there
Signed-off-by: Al Viro
---
fs/eventpoll.c| 18 +-
include/linux/eventpoll.h | 4 ++--
include/linux/fs.h| 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/eventpoll.c b
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index bd2cc78c47c8..9a6ee5991f3d 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -455,15 +455,7 @@ static bool
From: Al Viro
... and kill ep_scan_ready_list()
Signed-off-by: Al Viro
---
fs/eventpoll.c | 33 +
1 file changed, 5 insertions(+), 28 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 9b9e29e0c85f..3b3a862f8014 100644
--- a/fs/eventpoll.c
+++ b
From: Al Viro
no need to force its calling conventions to match the callback for
late unlamented ep_call_nested()...
Signed-off-by: Al Viro
---
fs/eventpoll.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 8c3b02755a50
From: Al Viro
We do need ep->mtx (and we are holding it all along), but that's
the lock on the epoll we are inserting into; locking of the
epoll being inserted is not needed for most of that work -
as the matter of fact, we only need it to provide barriers
for the fastpath check (for now).
M
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 49 -
1 file changed, 20 insertions(+), 29 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a50b48d26c55..1efe8a1a022a 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 51 ++-
1 file changed, 14 insertions(+), 37 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9c567af1f5f..c987b61701e4 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
From: Al Viro
The only reason why ep_item_poll() can't simply call ep_eventpoll_poll()
(or, better yet, call vfs_poll() in all cases) is that we need to tell
lockdep how deep into the hierarchy of ->mtx we are. So let's add
a variant of ep_eventpoll_poll() that would take depth explici
From: Al Viro
That's the beginning of preparations for taking f_ep_links out of struct file.
If insertion might fail, we will need a new failure exit. Having wakeup
source creation done after that point will simplify life there; ep_remove()
can (and commonly does) live with NULL epi->ws,
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 78b8769b72dc..8a7ad752befd 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1257,7 +1257,6 @@ static int
From: Al Viro
Signed-off-by: Al Viro
---
fs/eventpoll.c | 43 +++
1 file changed, 11 insertions(+), 32 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 9a6ee5991f3d..8c3b02755a50 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -439,25
From: Al Viro
take the stuff done before and after the callback into separate helpers
Signed-off-by: Al Viro
---
fs/eventpoll.c | 63 +-
1 file changed, 36 insertions(+), 27 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
From: Al Viro
1) 'cookie' argument is unused; kill it.
2) 'priv' one is always an epoll struct file, and we only care
about its associated struct eventpoll; pass that instead.
Signed-off-by: Al Viro
---
fs/eventpoll.c | 38 --
1 file changed, 16 insertions
From: Al Viro
in the "non-epoll target" cases do it in ep_insert() rather than
in do_epoll_ctl(), so that we do it only with some epitem is already
guaranteed to exist.
Signed-off-by: Al Viro
---
fs/eventpoll.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
From: Al Viro
get rid of depth/ep_locked arguments there and document
the kludge in ep_item_poll() that has lead to ep_locked existence in
the first place
Signed-off-by: Al Viro
---
fs/eventpoll.c | 57 ++---
1 file changed, 26 insertions
From: Al Viro
IOW,
* no locking is needed to protect the list
* the list is actually a stack
* no need to check ->ctx
* it can bloody well be a static 5-element array - nobody is
going to be accessing it in parallel.
Signed-off-by: Al Viro
---
fs/eventpol
From: Al Viro
We only traverse it once to destroy all associated eppoll_entry at
epitem destruction time. The order of traversal is irrelevant there.
Signed-off-by: Al Viro
---
fs/eventpoll.c | 51 +--
1 file changed, 25 insertions(+), 26
From: Al Viro
ctx is always equal to current, ncalls - to _loop_ncalls.
Signed-off-by: Al Viro
---
fs/eventpoll.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 44aca681d897..ef73d71a5dc8 100644
From: Al Viro
Expand the calls of ep_scan_ready_list() that get ep_read_events_proc().
As a side benefit we can pass depth to ep_read_events_proc() by value
and not by address - the latter used to be forced by the signature
expected from ep_scan_ready_list() callback.
Signed-off-by: Al Viro
From: Al Viro
... and get rid of struct ep_send_events_data - not needed anymore.
The weird way of passing the arguments in (and real return value
out - nominal return value of ep_send_events_proc() is ignored)
was due to the signature forced on ep_scan_ready_list() callbacks.
Signed-off-by: Al
Locking and especilly control flow in fs/eventpoll.c is
overcomplicated. As the result, the code has been hard to follow
and easy to fuck up while modifying.
The following series attempts to untangle it; there's more to be done
there, but this should take care of some of the
On Fri, Oct 02, 2020 at 08:15:12AM +0200, Christoph Hellwig wrote:
> ping? This is needed to unbreak the work.iov_iter branch that is in
> for-next.
Folded into "iov_iter: refactor rw_copy_check_uvector and import_iovec"
and force-pushed...
rg/pub/scm/linux/kernel/git/viro/vfs.git work.epoll
for you to fetch changes up to 3701cb59d892b88d569427586f01491552f377b1:
ep_create_wakeup_source(): dentry name can change under you... (2020-09-24
19:41:58 -0400)
--------
Al Viro (4):
On Thu, Oct 01, 2020 at 03:38:52PM -0700, Eric Biggers wrote:
> mutex_lock(>pipe_mutex);
> while (bytes) {
> - wr = __kernel_write(file, data, bytes, NULL);
> + wr = __kernel_write(file, data, bytes, >f_pos);
Better
loff_t dummy = 0;
...
On Thu, Oct 01, 2020 at 02:39:25PM -0400, Alan Stern wrote:
> The problem with a plain write is that it isn't guaranteed to be atomic
> in any sense. In principle, the compiler could generate code for CPU1
> which would write 0 to V->A more than once.
>
> Although I strongly doubt that any
On Thu, Oct 01, 2020 at 12:15:29PM -0400, Alan Stern wrote:
> > CPU1:
> > to_free = NULL
> > spin_lock()
> > if (!smp_load_acquire(>B))
> > to_free = V
> > V->A = 0
> > spin_unlock()
> > kfree(to_free)
> >
> > CPU2:
> >
On Thu, Oct 01, 2020 at 09:37:02AM -0400, Qian Cai wrote:
> > Fixed by providing a dummy wath_queue_init() in !CONFIG_WATCH_QUEUE
watch_queue_init(), that is
> > case and by having failures of wath_queue_init() handled the same way
On Thu, Oct 01, 2020 at 08:50:55AM -0400, Qian Cai wrote:
> Calling pipe2() with O_NOTIFICATION_PIPE could results in memory leaks
> in an error path or CONFIG_WATCH_QUEUE=n. Plug them.
[snip the copy of bug report]
No objections on the patch itself, but commit message is just about
unreadable.
On Wed, Sep 30, 2020 at 08:58:04PM -0400, Qian Cai wrote:
> Fixes: c73be61cede5 ("pipe: Add general notification queue support")
> Signed-off-by: Qian Cai
> ---
> fs/pipe.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 60dbee457143..5184972cd9c0
On Mon, Sep 28, 2020 at 09:00:54PM +0300, Dmitry Kasatkin wrote:
> But why "we" should allow "discarding" failed part instead of failing
> with EFAULT as a whole?
Because there might very well be absolutely legitimate users of mount(2)
passing it something smaller than 4Kb immediately followed
On Fri, Sep 25, 2020 at 06:51:37AM +0200, Christoph Hellwig wrote:
> Hi Al,
>
> this series changes import_iovec to transparently deal with compat iovec
> structures, and then cleanups up a lot of code dupliation.
OK, I can live with that. Applied, let's see if it passes smoke tests
into -next
On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> $ x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Debian) 2.35
>
> and the gcc plugins don't get built for the allnoconfig builds.
> I
301 - 400 of 11792 matches
Mail list logo
