On Tue, Aug 11, 2020 at 11:19 PM Linus Torvalds
wrote:
>
> On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
> >
> > So that's where O_ALT comes in. If the application is consenting,
> > then that should prevent exploits. Or?
>
> If the application i
On Tue, Aug 11, 2020 at 10:37 PM Jann Horn wrote:
> If you change the semantics of path strings, you'd have to be
> confident that the new semantics fit nicely with all the path
> validation routines that exist scattered across userspace, and don't
> expose new interfaces through file server
On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler wrote:
> Since ab has known meaning, and lots of applications
> play loose with '/', its really dangerous to treat the string as
> special. We only get away with '.' and '..' because their behavior
> was defined before many of y'all were
On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
wrote:
> and then people do "$(srctree)/". If you haven't seen that kind of
> pattern where the pathname has two (or sometimes more!) slashes in the
> middle, you've led a very sheltered life.
Oh, I have. That's why I opted for triple slashes,
On Tue, Aug 11, 2020 at 5:20 PM Linus Torvalds
wrote:
>
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
>
> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi wrote:
> >
> > >
> > > E.g.
> > > openat
On Tue, Aug 11, 2020 at 4:42 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:
>
> > > > - strip off trailing part after first instance of ///
> > > > - perform path lookup as normal
> > > > - resolve m
On Tue, Aug 11, 2020 at 4:31 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:
> > On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
> > >
> > > On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > > >
On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > > On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> > >
&
On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
>
> > I think we already lost that with the xattr API, that should have been
> > done in a way that fits this philosophy. But given that we have "/&q
On Mon, Aug 10, 2020 at 9:37 PM Vivek Goyal wrote:
>
> On Mon, Aug 10, 2020 at 10:29:13AM +0200, Miklos Szeredi wrote:
> > On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal wrote:
> > >
> > > fuse_file_put(sync) can be called with sync=true/false. If sync=true,
>
On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal wrote:
>
> fuse_file_put(sync) can be called with sync=true/false. If sync=true,
> it waits for release request response and then calls iput() in the
> caller's context. If sync=false, it does not wait for release request
> response, frees the fuse_file
On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal wrote:
>
> Most of the changes are limited to fuse/virtiofs. There are couple
> of changes needed in generic dax infrastructure and couple of changes
> in virtio to be able to access shared memory region.
So what's the plan for merging the different
On Wed, Aug 5, 2020 at 1:36 PM Ian Kent wrote:
>
> I can see in the kernel code that an error is returned if the message
> buffer is full when trying to add a message, I just can't see where
> to get it in the libmount code.
>
> That's not really a communication protocol problem.
>
> Still I
On Wed, Aug 5, 2020 at 1:23 PM Ian Kent wrote:
>
> On Wed, 2020-08-05 at 09:45 +0200, Miklos Szeredi wrote:
> > Hmm, what's the other possibility for lost notifications?
>
> In user space that is:
>
> Multi-threaded application races, single threaded applications and
&
On Wed, Aug 5, 2020 at 4:14 PM David Howells wrote:
> However, looking up that identifier requires some sort of structure for doing
> this and it's kind of worst case for the IDR tree as the keys are gradually
> going to spread out, causing it to eat more memory. It may be a tradeoff
> worth
On Wed, Aug 5, 2020 at 6:07 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > Shoun't we just make sure that the likelyhood of overruns is low
>
> That's not necessarily easy. To avoid overruns you need a bigger buffer. The
> buffer is preallocated from unswap
On Wed, Aug 5, 2020 at 5:37 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > > + __u32 shared_group_id;/* Shared: mount group ID */
> > > + __u32 dependent_source_id;/* Dependent: source mount group ID */
> > > + __u32 depe
On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> I think we already lost that with the xattr API, that should have been
> done in a way that fits this philosophy. But given that we have "/"
> as the only special purpose char in filenames, and even repetitions
>
On Wed, Aug 5, 2020 at 3:33 AM Ian Kent wrote:
>
> On Tue, 2020-08-04 at 16:36 +0200, Miklos Szeredi wrote:
> > And notice how similar the above interface is to getxattr(), or the
> > proposed readfile(). Where has the "everything is a file"
> &
On Wed, Aug 5, 2020 at 4:46 AM Ian Kent wrote:
>
> Coming back to an actual use case.
>
> What I said above is one aspect but, since I'm looking at this right
> now with systemd, and I do have the legacy code to fall back to, the
> "just reset everything" suggestion does make sense.
>
> But I'm
On Wed, Aug 5, 2020 at 3:54 AM Ian Kent wrote:
>
> > > It's way more useful to have these in the notification than
> > > obtainable
> > > via fsinfo() IMHO.
> >
> > What is it useful for?
>
> Only to verify that you have seen all the notifications.
>
> If you have to grab that info with a
On Tue, Aug 4, 2020 at 5:40 PM James Bottomley
wrote:
>
> On Mon, 2020-08-03 at 14:36 +0100, David Howells wrote:
> > Here's a set of patches that adds a system call, fsinfo(), that
> > allows information about the VFS, mount topology, superblock and
> > files to be retrieved.
> >
> > The
On Tue, Aug 4, 2020 at 4:15 AM Ian Kent wrote:
>
> On Mon, 2020-08-03 at 18:42 +0200, Miklos Szeredi wrote:
> > On Mon, Aug 3, 2020 at 5:50 PM David Howells
> > wrote:
> > >
> > > Hi Linus,
> > >
> > > Here's a set of patches that adds a syst
On Mon, Aug 03, 2020 at 02:38:34PM +0100, David Howells wrote:
> Add a filesystem attribute that exports a list of all the visible mounts in
> a namespace, given the caller's chroot setting. The returned list is an
> array of:
>
> struct fsinfo_mount_child {
> __u64
On Mon, Aug 03, 2020 at 02:37:50PM +0100, David Howells wrote:
> Provide support for the handling of an overrun in a watch queue. In the
> event that an overrun occurs, the watcher needs to be able to find out what
> it was that they missed. To this end, previous patches added event
> counters
On Mon, Aug 03, 2020 at 02:37:33PM +0100, David Howells wrote:
> Add a couple of attributes to allow information about the mount topology
> and propagation to be retrieved:
>
> (1) FSINFO_ATTR_MOUNT_TOPOLOGY.
>
> Information about a mount's parentage in the mount topology tree and
>
On Tue, Aug 4, 2020 at 1:39 PM Ian Kent wrote:
>
> On Mon, 2020-08-03 at 11:29 +0200, Miklos Szeredi wrote:
> > On Thu, Jul 23, 2020 at 12:48 PM David Howells
> > wrote:
> >
> > > > > __u32 topology_changes;
> &g
On Mon, Aug 03, 2020 at 02:37:16PM +0100, David Howells wrote:
> Add a uniquifier ID to struct mount that is effectively unique over the
> kernel lifetime to deal around mnt_id values being reused. This can then
> be exported through fsinfo() to allow detection of replacement mounts that
> happen
On Mon, Aug 03, 2020 at 02:37:08PM +0100, David Howells wrote:
> Allow the fsinfo() syscall to look up a mount object by ID rather than by
> pathname. This is necessary as there can be multiple mounts stacked up at
> the same pathname and there's no way to look through them otherwise.
>
> This
On Mon, Aug 03, 2020 at 02:36:42PM +0100, David Howells wrote:
> Add a system call to allow filesystem information to be queried. A request
> value can be given to indicate the desired attribute. Support is provided
> for enumerating multi-value attributes.
>
> ===
> NEW SYSTEM CALL
ble with device IDs).
>
> The counter could also be used to tag other features, such as mount
> objects.
>
> Signed-off-by: David Howells
Reviewed-by: Miklos Szeredi
On Mon, Aug 3, 2020 at 5:50 PM David Howells wrote:
>
>
> Hi Linus,
>
> Here's a set of patches that adds a system call, fsinfo(), that allows
> information about the VFS, mount topology, superblock and files to be
> retrieved.
>
> The patchset is based on top of the mount notifications patchset
On Mon, Aug 3, 2020 at 12:18 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > > fsinfo() then allows you to retrieve them by path or by mount ID.
> >
> > Shouldn't the notification interface provide the unique ID?
>
> Hmmm... If I'm going to do that,
On Thu, Jul 23, 2020 at 6:43 PM André Almeida wrote:
>
> As stated in https://sourceforge.net/projects/fuse/, "the FUSE project has
> moved to https://github.com/libfuse/; in 22-Dec-2015. Update URLs to
> reflect this.
>
> Signed-off-by: André Almeida
Thanks, applied.
Miklos
On Fri, Jul 24, 2020 at 1:36 PM David Howells wrote:
>
> Ian Kent wrote:
>
> > I was wondering about id re-use.
> >
> > Assuming that ids that are returned to the idr db are re-used
> > what would the chance that a recently used id would end up
> > being used?
> >
> > Would that chance increase
On Thu, Jul 23, 2020 at 12:48 PM David Howells wrote:
>
> > > __u32 topology_changes;
> > > __u32 attr_changes;
> > > __u32 aux_topology_changes;
> >
> > Being 32bit this introduces wraparound effects. Is that really worth it?
>
> You'd have
mount API
- saner behavior of fsconfig(2) for the reconfigure case
- an ancient issue with FS_IOC_{GET,SET}FLAGS ioctls.
Thanks,
Miklos
Chirantan Ekbote (1):
fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS
Miklos Szeredi (6
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
tags/ovl-fixes-5.8-rc6
Fix the following:
- a regression introduced in v4.20 in handling a regenerated squashfs
lower layer
- two regressions in this cycle, one of which is Oops inducing
-
On Wed, Jul 15, 2020 at 9:43 PM Pavel Begunkov wrote:
>
> To clear details for those who are not familiar with io_uring:
>
> io_uring has a pair of queues, submission (SQ) and completion queues (CQ),
> both shared between kernel and user spaces. The userspace submits requests
> by filling a chunk
On Wed, Jul 15, 2020 at 11:02 AM Pavel Begunkov wrote:
> I think, if you're going to push this idea, we should start a new thread
> CC'ing strace devs.
Makes sense. I've pruned the Cc list, so here's the link for reference:
Hi,
This thread is to discuss the possibility of stracing requests
submitted through io_uring. I'm not directly involved in io_uring
development, so I'm posting this out of interest in using strace on
processes utilizing io_uring.
io_uring gives the developer a way to bypass the syscall
On Wed, Jul 15, 2020 at 10:33 AM Pavel Begunkov wrote:
>
> On 14/07/2020 14:55, Miklos Szeredi wrote:
> > On Tue, Jul 14, 2020 at 1:36 PM Pavel Begunkov
> > wrote:
> >>
> >> On 14/07/2020 11:07, Miklos Szeredi wrote:
> >>> On Tue, Jul 14, 2020
On Tue, Jul 14, 2020 at 2:40 PM Sedat Dilek wrote:
> Did you sent out a new version of your patch?
> If yes, where can I get it from?
Just pushed a bunch of fixes including this one to
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#for-next
Thanks,
Miklos
On Thu, Jun 25, 2020 at 11:39 AM Vasily Averin wrote:
>
> fuse_writepages() ignores some errors taken from fuse_writepages_fill()
> I believe it is a bug: if .writepages is called with WB_SYNC_ALL
> it should either guarantee that all data was successfully saved
> or return error.
>
> Fixes:
he same action;
> }
> }
>
> - ap->num_pages check is always true and can be removed
> - "if" and "else if" calls the same action and can be merged.
Makes sense. Attached patch goes further and moves checking the
conditions to a separate helper for clari
On Tue, Jul 14, 2020 at 1:36 PM Pavel Begunkov wrote:
>
> On 14/07/2020 11:07, Miklos Szeredi wrote:
> > On Tue, Jul 14, 2020 at 8:51 AM Pavel Machek wrote:
> >>
> >> Hi!
> >>
> >>>> At first, I thought that the proposed system call is
On Tue, Jul 14, 2020 at 8:51 AM Pavel Machek wrote:
>
> Hi!
>
> > > At first, I thought that the proposed system call is capable of
> > > reading *multiple* small files using a single system call - which
> > > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > > operations
On Mon, Jul 13, 2020 at 10:02 AM Vasily Averin wrote:
>
> On 7/11/20 7:01 AM, Miklos Szeredi wrote:
> > On Thu, Jun 25, 2020 at 11:02 AM Vasily Averin wrote:
> >>
> >> In current implementation fuse_writepages_fill() tries to share the code:
> >> for new wp
On Thu, Jun 25, 2020 at 11:02 AM Vasily Averin wrote:
>
> In current implementation fuse_writepages_fill() tries to share the code:
> for new wpa it calls tree_insert() with num_pages = 0
> then switches to common code used non-modified num_pages
> and increments it at the very end.
>
> Though it
On Sat, Jul 4, 2020 at 10:50 PM Alexey Dobriyan wrote:
>
> Al wrote:
>
> > > On Sat, Jul 04, 2020 at 09:41:09PM +0200, Miklos Szeredi wrote:
> > > 1) just leave the first explanation (it's an open + read + close
> > > equivalent) and leave out the re
On Sat, Jul 4, 2020 at 4:03 PM Greg Kroah-Hartman
wrote:
>
> It's a tiny syscall, meant to allow a user to do a single "open this
> file, read into this buffer, and close the file" all in a single shot.
>
> Should be good for reading "tiny" files like sysfs, procfs, and other
> "small" files.
>
>
On Mon, Jun 15, 2020 at 7:59 AM Vasily Averin wrote:
>
> On 6/15/20 3:50 AM, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 6b2fb79963fbed7db3ef850926d913518fd5c62f ("fuse: optimize
> > writepages search")
> >
On Tue, Jun 16, 2020 at 1:45 AM Mike Kravetz wrote:
>
> On 6/15/20 12:53 AM, Miklos Szeredi wrote:
> > On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz
> > wrote:
> >> On 6/12/20 11:53 PM, Amir Goldstein wrote:
> >>>
> >>> The simplest thing fo
On Mon, Jun 15, 2020 at 12:05 PM Amir Goldstein wrote:
>
> On Mon, Jun 15, 2020 at 10:53 AM Miklos Szeredi wrote:
> >
> > On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz
> > wrote:
> > >
> > > On 6/12/20 11:53 PM, Amir Goldstein wrote:
> >
> &
On Sun, Jun 14, 2020 at 5:07 AM Ian Kent wrote:
>
> On Thu, 2020-04-02 at 17:19 +0200, Miklos Szeredi wrote:
> >
> > > Firstly, a watch queue needs to be created:
> > >
> > > pipe2(fds, O_NOTIFICATION_PIPE);
> > >
On Sat, Jun 13, 2020 at 8:53 AM Amir Goldstein wrote:
> > I also looked at normal filesystem lower and hugetlbfs upper. Yes,
> > overlayfs
> > allows this. This is somewhat 'interesting' as write() is not supported in
> > hugetlbfs. Writing to files in the overlay actually ended up writing
On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz wrote:
>
> On 6/12/20 11:53 PM, Amir Goldstein wrote:
> As a hugetlbfs developer, I do not know of a use case for interoperability
> with overlayfs. So yes, I am not too interested in making them work well
> together. However, if there was an actual
On Sat, Jun 13, 2020 at 3:05 PM David Howells wrote:
> > I'm so far just reading this thread and the arguments for users, and I
> > haven't yet looked at all the actual details in the pull request - but
> > last time I had objections to things it wasn't the code, it was the
> > lack of any use.
):
fuse: Update stale comment in queue_interrupt()
Masayoshi Mizuma (1):
virtiofs: Add mount option and atime behavior to the doc
Maxim Patlasov (1):
fuse: optimize writepages search
Miklos Szeredi (8):
fuse: always flush dirty data on close(2)
fuse: always allow query
les
Miklos Szeredi (10):
ovl: pass correct flags for opening real directory
ovl: switch to mounter creds in readdir
ovl: verify permissions in ovl_path_open()
ovl: call secutiry hook in ovl_real_ioctl()
ovl: check permission to open real file
ovl: add accessor for
ur but preserves the
> initially intended optimization for architectures which don't need that PV
> handling.
Thanks for fixing.
Tested-by: Miklos Szeredi
Miklos
On Sun, Jun 7, 2020 at 11:04 AM youngjun wrote:
>
> dir is always locked until "out_unlock" label.
> So lock check is not needed.
Thanks, applied.
Miklos
On Fri, Jun 5, 2020 at 12:12 PM Thomas Gleixner wrote:
>
> Paolo Bonzini writes:
> > On 04/06/20 21:28, Miklos Szeredi wrote:
> >> time(2) returns good time, while clock_gettime(2) returns bad time.
> >> Here's an example:
> >>
> >> time=1591298
On Thu, Jun 4, 2020 at 5:57 PM Kees Cook wrote:
>
> On Thu, Jun 04, 2020 at 10:42:45AM +0200, gli...@google.com wrote:
> > Under certain circumstances (we found this out running Docker on a
> > Clang-built kernel with CONFIG_INIT_STACK_ALL) ovl_copy_xattr() may
> > return uninitialized value of
On Thu, Jun 4, 2020 at 10:14 PM Paolo Bonzini wrote:
>
> On 04/06/20 21:28, Miklos Szeredi wrote:
> > time(2) returns good time, while clock_gettime(2) returns bad time.
> > Here's an example:
> >
> > time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582 BOO
On Thu, Jun 4, 2020 at 7:30 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Thomas Gleixner writes:
> >> Of course this does not reproduce here. What kind of host is this
> >> running on? Can you provide a full demsg of the host please from boot to
> >> post resume?
> >
> > Plus /proc/cpuinfo please
On Thu, Jun 4, 2020 at 11:27 AM Colin Ian King wrote:
>
> On 04/06/2020 08:25, Miklos Szeredi wrote:
> > On Wed, Jun 3, 2020 at 6:15 PM Colin Ian King
> > wrote:
> >>
> >> On 03/06/2020 17:11, Amir Goldstein wrote:
> >>> On Wed,
On Thu, May 28, 2020 at 11:01 PM Mike Kravetz wrote:
>
> On 5/28/20 1:37 AM, kbuild test robot wrote:
> > Hi Mike,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on miklos-vfs/overlayfs-next]
> > [also build test ERROR on linus/master v5.7-rc7]
> > [cannot
On Thu, Jun 4, 2020 at 10:43 AM wrote:
>
> Under certain circumstances (we found this out running Docker on a
> Clang-built kernel with CONFIG_INIT_STACK_ALL) ovl_copy_xattr() may
> return uninitialized value of |error| from ovl_copy_xattr().
> It is then returned by ovl_create() to
On Wed, May 27, 2020 at 5:20 AM Yuxuan Shui wrote:
>
>
> In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private
> xattrs, the copy loop will terminate without assigning anything to the
> error variable, thus returning an uninitialized value.
>
> If ovl_copy_xattr is called from
On Wed, Jun 3, 2020 at 6:15 PM Colin Ian King wrote:
>
> On 03/06/2020 17:11, Amir Goldstein wrote:
> > On Wed, Jun 3, 2020 at 6:46 PM Colin King wrote:
> >>
> >> From: Colin Ian King
> >>
> >> There are two error return paths where the call to path_put is
> >> dereferencing the null pointer
On Wed, Jun 3, 2020 at 3:51 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the overlayfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: "security_file_ioctl" [fs/overlayfs/overlay.ko] undefined!
>
> Caused by commit
>
> b5940870e166 ("ovl:
On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
> > Can you please describe the setup of this test?
> >
> > - Host kernel version
5.5.16-100.fc30.x86_64
> > - Guest kernel version
75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
>
On Fri, May 29, 2020 at 2:21 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Miklos Szeredi writes:
> > On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
> >> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner
> >> wrote:
> >> >
On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
>
> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
> >
> > Miklos Szeredi writes:
> > > Bisected it to:
> > >
> > > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode stora
On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
>
> Miklos Szeredi writes:
> > Bisected it to:
> >
> > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
> >
> > The effect observed is that after the host is resumed, the cl
Bisected it to:
b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
The effect observed is that after the host is resumed, the clock in
the guest is somewhat in the future and is stopped. I.e. repeated
date(1) invocations show the same time.
Attaching the .config
Thanks,
Miklos
On Fri, May 22, 2020 at 9:56 PM Al Viro wrote:
>
> On Fri, May 22, 2020 at 08:53:49PM +0200, Miklos Szeredi wrote:
> > Right, we should just get rid of ofs->upper_mnt and ofs->upperdir_trap
> > and use ofs->layers[0] to store those.
>
> For that you'd need to
On Fri, May 22, 2020 at 7:02 PM Amir Goldstein wrote:
>
> > > > - mntput(ofs->upper_mnt);
> > > > - for (i = 1; i < ofs->numlayer; i++) {
> > > > - iput(ofs->layers[i].trap);
> > > > - mntput(ofs->layers[i].mnt);
> > > > +
> > > > + if (!ofs->layers) {
> > > >
On Fri, May 22, 2020 at 6:08 PM Al Viro wrote:
>
> On Fri, May 22, 2020 at 10:57:23AM +0200, Miklos Szeredi wrote:
> > Overlayfs is using clone_private_mount() to create internal mounts for
> > underlying layers. These are used for operations requiring a path, such
On Wed, May 20, 2020 at 10:27:15AM -0700, Mike Kravetz wrote:
> I am fairly confident it is all about checking limits and alignment. The
> filesystem knows if it can/should align to base or huge page size. DAX has
> some interesting additional restrictions, and several 'traditional'
>
) that can take care of multiple
longterm mounts with a single RCU grace period.
Cc: Al Viro
Signed-off-by: Miklos Szeredi
---
fs/namespace.c| 16
fs/overlayfs/super.c | 19 ++-
include/linux/mount.h | 2 ++
3 files changed, 32 insertions(+), 5 deletion
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
tags/ovl-fixes-5.7-rc7
Fix two bugs introduced in this cycle and one introduced in v5.5.
Thanks,
Miklos
Dan Carpenter (1):
ovl:
On Tue, May 19, 2020 at 2:35 AM Mike Kravetz wrote:
>
> On 5/18/20 4:41 PM, Colin Walters wrote:
> >
> > On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote:
> >
> >>> However, in this syzbot test case the 'file' is in an overlayfs filesystem
> &g
On Sat, May 16, 2020 at 12:15 AM Mike Kravetz wrote:
> I started going down the path of creating a get_unmapped_area f_op for
> overlayfs. That is pretty straight forward and works well. But that
> did not take care of the is_file_hugepages() routine. Recall that
> is_file_hugepages simply
On Fri, May 15, 2020 at 3:04 PM Miklos Szeredi wrote:
>
> On Fri, May 15, 2020 at 1:40 PM Michael Kerrisk (man-pages)
> wrote:
> >
> > Hello David, Miklos,
> >
> > I've been looking at the new mount API (fsopen(), fsconfig(),
> > fsmount(), move_mount(),
On Fri, May 15, 2020 at 1:40 PM Michael Kerrisk (man-pages)
wrote:
>
> Hello David, Miklos,
>
> I've been looking at the new mount API (fsopen(), fsconfig(),
> fsmount(), move_mount(), etc.) and among the details that remain
> mysterious to me is this: how does one set the propagation type
>
gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12921933e0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172e940be0
> >
> > The bug was bisected to:
> >
> > commit e950564b97fd0f541b02eb207685d074
On Fri, May 8, 2020 at 12:14 PM Chakra Divi wrote:
>
> On Tue, Apr 28, 2020 at 1:51 PM Miklos Szeredi wrote:
> >
> > On Mon, Apr 27, 2020 at 3:46 PM Chakra Divi wrote:
> > >
> > > On Tue, Apr 21, 2020 at 4:21 PM Chakra Divi
> > > wrote:
> >
On Mon, Apr 27, 2020 at 3:46 PM Chakra Divi wrote:
>
> On Tue, Apr 21, 2020 at 4:21 PM Chakra Divi wrote:
> >
> > On Mon, Apr 20, 2020 at 4:55 PM Miklos Szeredi wrote:
> > >
> > > On Wed, Apr 1, 2020 at 11:31 AM Chakra Divi
> > > wrote:
From: Miklos Szeredi
This allows xattr ops on symlink/special files referenced by an O_PATH
descriptor without having to play games with /proc/self/fd/NN (which
doesn't work for symlinks anyway).
This capability is the same as would be given by introducing ...at()
variants with an AT_EMPTY_PATH
On Mon, Aug 19, 2019 at 7:48 AM Vasily Averin wrote:
>
> Currently fuse_writepages_fill() calls get_fuse_inode() few times with
> the same argument.
Thanks, applied.
Miklos
On Mon, Aug 19, 2019 at 8:53 AM Vasily Averin wrote:
>
> commit 963545357202 ("fuse: reduce allocation size for splice_write")
> changed size of bufs array, so BUG_ON which checks the index of the array
> shold also be fixed.
>
> Fixes: 963545357202 ("fuse: reduce allocation size for
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
tags/virtio-fs-5.4
[There's a trivial merge conflict under Documentation/]
Virtio-fs allows exporting directory trees on the host and mounting them in
guest(s).
This isn't actually a new filesystem,
: kmemcg account fs data
Kirill Smelkov (1):
fuse: require /dev/fuse reads to have enough buffer capacity (take 2)
Maxim Patlasov (1):
fuse: cleanup fuse_wait_on_page_writeback
Michael S. Tsirkin (1):
fuse: reserve byteswapped init opcodes
Miklos Szeredi (33):
cuse: fix broken
On Mon, Sep 23, 2019 at 7:53 AM YueHaibing wrote:
>
> Fix sparse warning:
>
> fs/fuse/dev.c:468:6: warning: symbol 'fuse_args_to_req' was not declared.
> Should it be static?
Thanks, applied.
Miklos
On Sun, Sep 22, 2019 at 3:19 PM Tejun Heo wrote:
>
> With DEBUG_PAGEALLOC on, the following triggers.
>
> BUG: unable to handle page fault for address: 88859367c000
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 3001067 P4D 3001067 PUD
On Wed, Sep 18, 2019 at 2:57 PM Michael S. Tsirkin wrote:
> Overall this looks ok to me. Handling full vq by a timer is really gross
> but it's correct - just terribly inefficient.
Yes. The reason this didn't get too much attention is that it's
relatively difficult to make the queues actually
On Fri, May 10, 2019 at 04:09:41PM -0400, J. Bruce Fields wrote:
> On Tue, May 07, 2019 at 10:24:58AM +1000, NeilBrown wrote:
> > Interesting perspective though doesn't NFSv4 explicitly allow
> > client-side ACL enforcement in the case of delegations?
>
> Not really. What you're probably
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
tags/ovl-fixes-5.3
Fix a regression in docker introduced by overlayfs changes in 4.19. Also
fix a couple of miscellaneous bugs.
Thanks,
Miklos
201 - 300 of 5427 matches
Mail list logo
