On Fri, Apr 9, 2021 at 4:39 PM Luis Henriques wrote:
>
> Nicolas Boichat writes:
>
> > On Wed, Feb 24, 2021 at 6:44 PM Nicolas Boichat
> > wrote:
> >>
> >> On Wed, Feb 24, 2021 at 6:22 PM Luis Henriques wrote:
> >> >
> >> > On Tue, Feb 23, 2021 at 08:00:54PM -0500, Olga Kornievskaia wrote:
>
On Sat, Apr 3, 2021 at 10:18 PM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:454c576c Add linux-next specific files for 20210401
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1616e07ed0
> kernel
On Thu, Mar 25, 2021 at 5:43 AM Matthew Wilcox wrote:
>
>
> I decided to see what a filesystem free from struct page would look
> like. I chose sysv more-or-less at random; I wanted a relatively simple
> filesystem, but I didn't want a toy. The advantage of sysv is that the
> maintainer is
> > +``miscattr_get``
>
> I wish this wasn't named "misc" because miscellaneous is vague.
>
> fileattr_get, perhaps?
>
> (FWIW I'm not /that/ passionate about starting a naming bikeshed, feel
> free to ignore.)
>
Eventual bikeshedding is hard to avoid in this case...
I don't feel strongly
On Mon, Mar 8, 2021 at 11:14 AM David Howells wrote:
>
> Amir Goldstein wrote:
>
> > > (0a) As (0) but using SEEK_DATA/SEEK_HOLE instead of bmap and opening the
> > > file for every whole operation (which may combine reads and writes).
> >
> > I rea
On Thu, Mar 4, 2021 at 4:10 PM David Howells wrote:
>
> I'm looking at redesigning the on-disk cache format used by fscache's
> cachefiles driver to try and eliminate the number of synchronous metadata
> operations done by the driver, to improve culling performance and to reduce
> the amount of
information for some errors related to this.
>
> Reported-by: Luis Henriques
> Reported-by: Amir Goldstein
> Related: <https://lwn.net/Articles/846403/>
> Cc: Greg KH
> Cc: Michael Kerrisk
> Cc: Anna Schumaker
> Cc: Jeff Layton
> Cc: Steve French
> Cc: Mi
On Mon, Mar 1, 2021 at 12:25 AM Steve French wrote:
>
> On Sun, Feb 28, 2021 at 1:36 AM Amir Goldstein wrote:
> >
> > On Sun, Feb 28, 2021 at 1:08 AM Steve French wrote:
> > >
> > > On Fri, Feb 26, 2021 at 11:43 PM Amir Goldstein
> > > wrote:
>
On Sun, Feb 28, 2021 at 1:08 AM Steve French wrote:
>
> On Fri, Feb 26, 2021 at 11:43 PM Amir Goldstein wrote:
> >
> > On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)
> > wrote:
> > >
> > > Hello Amir, Luis,
> > >
> > &
information for some errors related to this.
>
> Reported-by: Luis Henriques
> Reported-by: Amir Goldstein
> Related: <https://lwn.net/Articles/846403/>
> Cc: Greg KH
> Cc: Michael Kerrisk
> Cc: Anna Schumaker
> Cc: Jeff Layton
> Cc: Steve French
> Cc: Mi
On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)
wrote:
>
> Hello Amir, Luis,
>
> On 2/24/21 5:10 PM, Amir Goldstein wrote:
> > On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques wrote:
> >>
> >> Update man-page with recent changes to this sy
On Fri, Feb 26, 2021 at 12:13 PM Alejandro Colomar (man-pages)
wrote:
>
> Hello Luis,
>
> On 2/25/21 11:21 AM, Luis Henriques wrote:
> > On Wed, Feb 24, 2021 at 06:10:45PM +0200, Amir Goldstein wrote:
> >> If it were me, I would provide all the details of the situation
On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques wrote:
>
> Update man-page with recent changes to this syscall.
>
> Signed-off-by: Luis Henriques
> ---
> Hi!
>
> Here's a suggestion for fixing the manpage for copy_file_range(). Note that
> I've assumed the fix will hit 5.12.
>
>
On Tue, Feb 23, 2021 at 7:31 PM wrote:
>
> On 2/23/21 8:57 AM, dai@oracle.com wrote:
>
>
> On 2/23/21 8:47 AM, Amir Goldstein wrote:
>
> On Tue, Feb 23, 2021 at 6:02 PM wrote:
>
>
> On 2/23/21 7:29 AM, dai@oracle.com wrote:
>
> On 2/23/21 2:32 AM, Luis
On Tue, Feb 23, 2021 at 6:02 PM wrote:
>
>
> On 2/23/21 7:29 AM, dai@oracle.com wrote:
> >
> > On 2/23/21 2:32 AM, Luis Henriques wrote:
> >> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai@oracle.com wrote:
> >>> On 2/22/21 2:24 AM, Luis Henriques wrote:
> A regression has been
On Tue, Feb 23, 2021 at 12:31 PM Luis Henriques wrote:
>
> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai@oracle.com wrote:
> >
> > On 2/22/21 2:24 AM, Luis Henriques wrote:
> > > A regression has been reported by Nicolas Boichat, found while using the
> > > copy_file_range syscall to copy a
ore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drink...@chromium.org/
> Link:
> https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=zmpsg47cyhfjwnw7zs...@mail.gmail.com/
> Link:
> https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d6060
On Fri, Feb 19, 2021 at 11:18 PM Olga Kornievskaia wrote:
>
> On Thu, Feb 18, 2021 at 12:33 PM Luis Henriques wrote:
> >
> > A regression has been reported by Nicolas Boichat, found while using the
> > copy_file_range syscall to copy a tracefs file. Before commit
> > 5dae222a5ff0 ("vfs: allow
On Thu, Feb 18, 2021 at 5:16 PM Luis Henriques wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file. Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV
On Thu, Feb 18, 2021 at 4:35 PM Luis Henriques wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file. Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV
On Thu, Feb 18, 2021 at 2:14 PM Luis Henriques wrote:
>
> Luis Henriques writes:
>
> > Amir Goldstein writes:
> >
> >> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig
> >> wrote:
> >>>
> >>> Looks good:
> >>>
> &
On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig wrote:
>
> Looks good:
>
> Reviewed-by: Christoph Hellwig
>
> This whole idea of cross-device copie has always been a horrible idea,
> and I've been arguing against it since the patches were posted.
Ok. I'm good with this v2 as well, but need to
On Thu, Feb 18, 2021 at 7:33 AM Olga Kornievskaia wrote:
>
> On Wed, Feb 17, 2021 at 3:30 PM Luis Henriques wrote:
> >
> > A regression has been reported by Nicolas Boichat, found while using the
> > copy_file_range syscall to copy a tracefs file. Before commit
> > 5dae222a5ff0 ("vfs: allow
On Wed, Feb 17, 2021 at 7:25 PM Luis Henriques wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file. Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV
On Tue, Feb 16, 2021 at 11:15 PM Steve French wrote:
>
> On Tue, Feb 16, 2021 at 1:40 PM Amir Goldstein wrote:
> >
> > On Tue, Feb 16, 2021 at 9:31 PM Steve French wrote:
> > >
> > > On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
> > > wrote:
&g
On Tue, Feb 16, 2021 at 9:31 PM Steve French wrote:
>
> On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
> wrote:
> >
> > On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein wrote:
> > >
> > > On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques wrote:
On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques wrote:
>
> Amir Goldstein writes:
>
> > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques wrote:
> >>
> >> Amir Goldstein writes:
> >>
> >> >> Ugh. And I guess overlayfs may have a sim
On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques wrote:
>
> Amir Goldstein writes:
>
> >> Ugh. And I guess overlayfs may have a similar problem.
> >
> > Not exactly.
> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > with the flags
> Ugh. And I guess overlayfs may have a similar problem.
Not exactly.
Generally speaking, overlayfs should call vfs_copy_file_range()
with the flags it got from layer above, so if called from nfsd it
will allow cross fs copy and when called from syscall it won't.
There are some corner cases
On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust wrote:
>
> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
> > tron...@hammerspace.com> wrote:
> > >
> > > On Mon, 2021-02-15 at 18:34 +0200, Am
On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust wrote:
>
> On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques
> > wrote:
> > >
> > > Nicolas Boichat reported an issue when trying to use the
> > &g
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link:
> https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drink...@chromium.org/
> Cc: Nicolas Boichat
> Signed-off-by: Luis Henriques
Code looks ok.
You may add:
Reviewed
On Mon, Feb 15, 2021 at 2:21 PM Luis Henriques wrote:
>
> Luis Henriques writes:
>
> > Amir Goldstein writes:
> >
> >> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques wrote:
> > ...
> >>> Sure, I just wanted to point out that *maybe* the
On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques wrote:
>
> Greg KH writes:
>
> > On Fri, Feb 12, 2021 at 12:05:14PM +, Luis Henriques wrote:
> >> Greg KH writes:
> >>
> >> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
&g
On Mon, Feb 15, 2021 at 3:27 AM Nicolas Boichat wrote:
>
> On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor wrote:
> >
> > On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner wrote:
> > >
> > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > > > On Sat, Feb 13, 2021 at 10:27:26AM
On Fri, Feb 12, 2021 at 9:49 AM Greg KH wrote:
>
> On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > Filesystems such as procfs and sysfs generate their content at
> > runtime. This implies the file sizes do not usually match the
> > amount of data that can be read from the
On Fri, Feb 12, 2021 at 6:47 AM Nicolas Boichat wrote:
>
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
>
> This will be
On Fri, Feb 5, 2021 at 2:20 PM Bhaskar Chowdhury wrote:
>
>
>
> s/fucked/messed/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> fs/notify/inotify/inotify_user.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/notify/inotify/inotify_user.c
>
On Fri, Feb 5, 2021 at 3:12 PM Bhaskar Chowdhury wrote:
>
> On 14:45 Fri 05 Feb 2021, Amir Goldstein wrote:
> >On Fri, Feb 5, 2021 at 2:20 PM Bhaskar Chowdhury
> >wrote:
> >>
> >>
> >>
> >> s/fucked/messed/
> >>
> >
On Mon, Feb 1, 2021 at 11:06 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:6642d600 Merge tag '5.11-rc5-smb3' of git://git.samba.org/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=171405bf50
> kernel config:
On Mon, Feb 1, 2021 at 11:21 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:6642d600 Merge tag '5.11-rc5-smb3' of git://git.samba.org/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=148aef78d0
> kernel config:
On Wed, Jan 20, 2021 at 12:20 PM Miklos Szeredi wrote:
>
> On Tue, Jan 05, 2021 at 08:47:41AM +0200, Amir Goldstein wrote:
> > On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng wrote:
> > >
> > > The function ovl_dir_real_file() currently uses the semaphore of the
&g
On Mon, Jan 18, 2021 at 9:28 PM Alessio Balsini wrote:
>
> Expose the FUSE_PASSTHROUGH interface to user space and declare all the
> basic data structures and functions as the skeleton on top of which the
> FUSE passthrough functionality will be built.
>
> As part of this, introduce the new FUSE
On Tue, Jan 5, 2021 at 8:47 AM Amir Goldstein wrote:
>
> On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng wrote:
> >
> > The function ovl_dir_real_file() currently uses the semaphore of the
> > inode to synchronize write to the upperfile cache field.
>
> Altho
On Tue, Jan 5, 2021 at 6:26 PM Vivek Goyal wrote:
>
> On Tue, Jan 05, 2021 at 09:11:23AM +0200, Amir Goldstein wrote:
> > > >
> > > > What I would rather see is:
> > > > - Non-volatile: first syncfs in every container gets an error (nice to
> >
> >
> > What I would rather see is:
> > - Non-volatile: first syncfs in every container gets an error (nice to have)
>
> I am not sure why are we making this behavior per container. This should
> be no different from current semantics we have for syncfs() on regular
> filesystem. And that will
On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng wrote:
>
> The function ovl_dir_real_file() currently uses the semaphore of the
> inode to synchronize write to the upperfile cache field.
Although the inode lock is a rw_sem it is referred to as the "inode lock"
and you also left semaphore in the
On Mon, Jan 4, 2021 at 5:40 PM Vivek Goyal wrote:
>
> On Mon, Jan 04, 2021 at 05:22:07PM +0200, Amir Goldstein wrote:
> > > > Since Jeff's patch is minimal, I think that it should be the fix applied
> > > > first and proposed for stable (with adaptations for
> > Since Jeff's patch is minimal, I think that it should be the fix applied
> > first and proposed for stable (with adaptations for non-volatile overlay).
>
> Does stable fix has to be same as mainline fix. IOW, I think atleast in
> mainline we should first fix it the right way and then think how
On Mon, Jan 4, 2021 at 9:28 AM Icenowy Zheng wrote:
>
> 在 2021-01-03星期日的 16:10 +0200，Amir Goldstein写道：
> > On Fri, Jan 1, 2021 at 10:12 PM Icenowy Zheng
> > wrote:
> > >
> > > The function ovl_dir_real_file() currently uses the semaphore of
> &
On Fri, Jan 1, 2021 at 10:12 PM Icenowy Zheng wrote:
>
> The function ovl_dir_real_file() currently uses the semaphore of the
> inode to synchronize write to the upperfile cache field.
>
> However, this function will get called by ovl_ioctl_set_flags(), which
> utilizes the inode semaphore too.
On Mon, Dec 28, 2020 at 7:26 PM Jeff Layton wrote:
>
> On Mon, 2020-12-28 at 15:56 +, Matthew Wilcox wrote:
> > On Mon, Dec 28, 2020 at 08:25:50AM -0500, Jeff Layton wrote:
> > > To be clear, the main thing you'll lose with the method above is the
> > > ability to see an unseen error on a
On Mon, Dec 28, 2020 at 3:25 PM Jeff Layton wrote:
>
> On Fri, 2020-12-25 at 08:50 +0200, Amir Goldstein wrote:
> > On Thu, Dec 24, 2020 at 2:13 PM Matthew Wilcox wrote:
> > >
> > > On Thu, Dec 24, 2020 at 11:32:55AM +0200, Amir Goldstein wrote:
> > > &g
On Thu, Dec 24, 2020 at 2:13 PM Matthew Wilcox wrote:
>
> On Thu, Dec 24, 2020 at 11:32:55AM +0200, Amir Goldstein wrote:
> > In current master, syncfs() on any file by any container user will
> > result in full syncfs() of the upperfs, which is very bad for container
> >
On Wed, Dec 23, 2020 at 10:44 PM Matthew Wilcox wrote:
>
> On Wed, Dec 23, 2020 at 08:21:41PM +, Sargun Dhillon wrote:
> > On Wed, Dec 23, 2020 at 08:07:46PM +, Matthew Wilcox wrote:
> > > On Wed, Dec 23, 2020 at 07:29:41PM +, Sargun Dhillon wrote:
> > > > On Wed, Dec 23, 2020 at
On Sun, Dec 20, 2020 at 7:56 PM Shakeel Butt wrote:
>
> On Sun, Dec 20, 2020 at 3:31 AM Amir Goldstein wrote:
> >
> > On Sun, Dec 20, 2020 at 6:24 AM Shakeel Butt wrote:
> > >
> > > On Sat, Dec 19, 2020 at 8:25 AM Amir Goldstein wrote:
> > > >
>
> Signed-off-by: Shakeel Butt
Reviewed-by: Amir Goldstein
> ---
> Changes since v1:
> - introduce fsnotify_alloc_user_group() and convert fanotify in addition
> to inotify to use that function. [suggested by Amir]
>
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs
On Sun, Dec 20, 2020 at 6:24 AM Shakeel Butt wrote:
>
> On Sat, Dec 19, 2020 at 8:25 AM Amir Goldstein wrote:
> >
> > On Sat, Dec 19, 2020 at 4:31 PM Shakeel Butt wrote:
> > >
> > > On Sat, Dec 19, 2020 at 1:48 AM Amir Goldstein wrote:
> > > >
On Sat, Dec 19, 2020 at 4:31 PM Shakeel Butt wrote:
>
> On Sat, Dec 19, 2020 at 1:48 AM Amir Goldstein wrote:
> >
> > On Sat, Dec 19, 2020 at 12:11 AM Shakeel Butt wrote:
> > >
> > > Currently the fs sysctl inotify/max_user_instances is used to limit t
On Sat, Dec 19, 2020 at 12:11 AM Shakeel Butt wrote:
>
> Currently the fs sysctl inotify/max_user_instances is used to limit the
> number of inotify instances on the system. For systems running multiple
> workloads, the per-user namespace sysctl max_inotify_instances can be
> used to further
On Mon, Dec 14, 2020 at 3:24 PM Miklos Szeredi wrote:
>
> On Mon, Dec 14, 2020 at 6:44 AM Amir Goldstein wrote:
>
> > Perhaps, but there is a much bigger issue with this change IMO.
> > Not because of dropping rule (b) of the permission model, but because
> > of relaxi
On Fri, Dec 11, 2020 at 4:44 PM Miklos Szeredi wrote:
>
> On Tue, Dec 8, 2020 at 12:32 PM Amir Goldstein wrote:
> >
> > On Mon, Dec 7, 2020 at 6:37 PM Miklos Szeredi wrote:
> > >
> > > In case the file cannot be opened with O_NOATIME because of lack of
>
On Thu, Dec 10, 2020 at 5:18 PM Miklos Szeredi wrote:
>
> On Tue, Dec 8, 2020 at 12:15 PM Amir Goldstein wrote:
> >
> > On Mon, Dec 7, 2020 at 6:36 PM Miklos Szeredi wrote:
> > >
> > > ovl_ioctl_set_flags() does a capability check using flags, but then the
&
On Fri, Dec 11, 2020 at 12:47 PM Jan Kara wrote:
>
> On Fri 11-12-20 10:42:16, Amir Goldstein wrote:
> > On Fri, Dec 11, 2020 at 1:45 AM Hugh Dickins wrote:
> > >
> > > Hi Jan, Amir,
> > >
> > > There's something wrong with linux-next commit ca
uld be discarded (which the old code did).
After the change (!parent_mark && inode_mark) is not enough to
determine if name should be discarded (it should be discarded only
for "events on child"), so another check is needed.
Thanks,
Amir.
From c7ea57c66c8c9f9607928bf7c55fc409eecc3e57
On Wed, Dec 9, 2020 at 6:20 PM Miklos Szeredi wrote:
>
> On Wed, Dec 9, 2020 at 11:13 AM Miklos Szeredi wrote:
>
> > Hard link indexing should work without fh decoding, since it is only
> > encoding the file handle to search for the index entry, and encoding
> > is not privileged.
>
> Tested
On Mon, Dec 7, 2020 at 6:36 PM Miklos Szeredi wrote:
>
> CAP_DAC_READ_SEARCH is required by open_by_handle_at(2) so check it in
> ovl_decode_real_fh() as well to prevent privilege escalation for
> unprivileged overlay mounts.
>
> Signed-off-by: Miklos Szeredi
> ---
> fs/overlayfs/namei.c | 3
compatible.
>
> Disable redirect_dir and metacopy options, because these would allow
> privilege escalation through direct manipulation of the
> "user.overlay.redirect" or "user.overlay.metacopy" xattrs.
>
> Signed-off-by: Miklos Szeredi
> ---
Reviewed-by: Am
On Mon, Dec 7, 2020 at 6:37 PM Miklos Szeredi wrote:
>
> In case the file cannot be opened with O_NOATIME because of lack of
> capabilities, then clear O_NOATIME instead of failing.
>
> Signed-off-by: Miklos Szeredi
> ---
> fs/overlayfs/file.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
> works).
>
> Xfstests don't show a regression.
>
> Reported-by: Dmitry Vyukov
> Signed-off-by: Miklos Szeredi
Looks reasonable
Reviewed-by: Amir Goldstein
> ---
> fs/overlayfs/file.c | 75 ++---
> 1 file changed, 3 insertions(+), 7
> > It seems like this can all be avoided simply by scheduling the
> > automated fixes scans once the upstream kernel is released, not
> > while it is still being stabilised by -rc releases. That way stable
> > kernels get better tested fixes, they still get the same quantity of
> > fixes, and
n the git commit
because it adds little value in git log perspective.
If you think that the development process is relevant to understanding
the patch (like the discussion leading to the formula of the cost)
then a Link: to the discussion on lore.kernel.org would serve the
commit better.
>
root@f2-vm:/merged# setfacl -m u:1000:rwx /merged/asdf
> root@f2-vm:/merged# getfacl /merged/asdf
> getfacl: Removing leading '/' from absolute path names
> # file: merged/asdf
> # owner: root
> # group: root
> user::rw-
> user:ub
On Thu, Oct 29, 2020 at 8:05 PM Waiman Long wrote:
>
> On 10/29/20 1:27 PM, Amir Goldstein wrote:
> > On Thu, Oct 29, 2020 at 5:46 PM Waiman Long wrote:
> >> The default value of inotify.max_user_watches sysctl parameter was set
> >> to 8192 since the introduction
On Thu, Oct 29, 2020 at 5:46 PM Waiman Long wrote:
>
> The default value of inotify.max_user_watches sysctl parameter was set
> to 8192 since the introduction of the inotify feature in 2005 by
> commit 0eeca28300df ("[PATCH] inotify"). Today this value is just too
> small for many modern usage.
On Mon, Oct 26, 2020 at 10:44 PM Waiman Long wrote:
>
> The default value of inotify.max_user_watches sysctl parameter was set
> to 8192 since the introduction of the inotify feature in 2005 by
> commit 0eeca28300df ("[PATCH] inotify"). Today this value is just too
> small for many modern usage.
kernel.org
> To: linux-unio...@vger.kernel.org
> Cc: Miklos Szeredi
> Cc: Jonathan Corbet
> Cc: Vivek Goyal
> Cc: Eric W. Biederman
> Cc: Amir Goldstein
> Cc: Randy Dunlap
> Cc: Stephen Smalley
> Cc: John Stultz
> Cc: linux-security-mod...@vger.kernel.org
>
file handle.
>
> If you just change the uuid of the backing filesystem, overlay is not
> mounting any more. In Virtuozzo we copy container disks (ploops) when
> create the copy of container and we require fs uuid to be unique for a new
> container.
>
> CC: Amir Goldstein
> CC:
On Mon, Oct 5, 2020 at 10:47 PM Alexander Mikhalitsyn
wrote:
>
> Hi Amir,
>
> On Mon, 5 Oct 2020 10:56:50 +0300
> Amir Goldstein wrote:
>
> > On Sun, Oct 4, 2020 at 10:25 PM Alexander Mikhalitsyn
> > wrote:
> > >
> > > Some time ago we dis
On Mon, Oct 5, 2020 at 8:13 PM Alexander Mikhalitsyn
wrote:
>
> On Mon, 5 Oct 2020 10:08:42 -0700
> Randy Dunlap wrote:
>
> > On 10/5/20 10:02 AM, Alexander Mikhalitsyn wrote:
> > > #defineOVL_IOC_GETLWRFHNDLSNUM _IO('o', 1)
> > > // DISCUSS: what if MAX_HANDLE_SZ will
On Sun, Oct 4, 2020 at 10:25 PM Alexander Mikhalitsyn
wrote:
>
> Some time ago we discussed about the problem of Checkpoint-Restoring
> overlayfs mounts [1]. Big thanks to Amir for review and suggestions.
>
> Brief from previous discussion.
> Problem statement: to checkpoint-restore overlayfs
d:
> #mount(2) system call failed: Stale file handle.
>
> If you just change the uuid of the backing filesystem, overlay is not
> mounting any more. In Virtuozzo we copy container disks (ploops) when
> crate the copy of container and we require fs uuid to be uniq for a new
typos: cra
On Fri, Sep 25, 2020 at 11:35 AM Pavel Tikhomirov
wrote:
>
> This will be used in next patch to be able to change uuid checks and
> add uuid nullification based on ofs->config.index for a new "uuid=off"
> mode.
>
> CC: Amir Goldstein
> CC: Vivek Goyal
>
skip
> v3: rebase to overlayfs-next, replace uuid with null in file handles,
> split ovl_fs propagation to function arguments to separate patch, add
> separate bool "uuid=on/off" option, move numfs check up, add doc note.
change log does not belong in commit message.
Move afte
On Thu, Sep 24, 2020 at 4:18 PM Vivek Goyal wrote:
>
> On Thu, Sep 24, 2020 at 05:44:22AM +0300, Amir Goldstein wrote:
> > On Wed, Sep 23, 2020 at 10:47 PM Vivek Goyal wrote:
> > >
> > > On Wed, Sep 23, 2020 at 06:23:08PM +0300, Pavel Tikhomirov wrote:
&g
On Thu, Sep 24, 2020 at 11:40 AM Pavel Tikhomirov
wrote:
>
>
>
> On 9/23/20 7:09 PM, Amir Goldstein wrote:
> > On Wed, Sep 23, 2020 at 6:23 PM Pavel Tikhomirov
> > wrote:
> >>
> >> This relaxes uuid checks for overlay index feature. It is only possible
On Wed, Sep 23, 2020 at 10:47 PM Vivek Goyal wrote:
>
> On Wed, Sep 23, 2020 at 06:23:08PM +0300, Pavel Tikhomirov wrote:
> > This relaxes uuid checks for overlay index feature. It is only possible
> > in case there is only one filesystem for all the work/upper/lower
> > directories and bare file
> > @@ -414,7 +415,7 @@ static int ovl_check_origin(struct ovl_fs *ofs, struct
> > dentry *upperdentry,
> > * Return 0 on match, -ESTALE on mismatch, < 0 on error.
> > */
> > static int ovl_verify_fh(struct dentry *dentry, const char *name,
> > -const struct ovl_fh
p/work loop-mp/merged
>
> If you just change the uuid of the backing filesystem, overlay is not
> mounting any more. In Virtuozzo we copy container disks (ploops) when
> crate the copy of container and we require fs uuid to be uniq for a new
> container.
>
> v2: in v1 I missed actual uu
On Tue, Sep 22, 2020 at 3:15 PM Alessio Balsini wrote:
>
> On Fri, Sep 18, 2020 at 10:59:16PM +0300, Amir Goldstein wrote:
> > On Fri, Sep 18, 2020 at 7:33 PM Alessio Balsini wrote:
> > [...]
> > > > ... for example:
> > > >
> > > &g
On Mon, Sep 21, 2020 at 2:01 PM Alessio Balsini wrote:
>
> Hi Amir,
>
> On Sat, Sep 12, 2020 at 12:55:35PM +0300, Amir Goldstein wrote:
> > On Fri, Sep 11, 2020 at 7:34 PM Alessio Balsini wrote:
> > > +ssize_t fuse_passthrough_read_i
On Fri, Sep 18, 2020 at 7:33 PM Alessio Balsini wrote:
>
> Hi Amir,
>
> Thanks again for your feedback.
>
> On Sat, Sep 12, 2020 at 02:06:02PM +0300, Amir Goldstein wrote:
> > On Fri, Sep 11, 2020 at 7:34 PM Alessio Balsini wrote:
> > [...]
> > > diff --
On Fri, Sep 11, 2020 at 7:34 PM Alessio Balsini wrote:
>
> Introduce the new FUSE passthrough ioctl(), which allows userspace to
> specify a direct connection between a FUSE file and a lower file system
> file.
> Such ioctl() requires userspace to specify:
> - the file descriptor of one of its
On Fri, Sep 11, 2020 at 7:34 PM Alessio Balsini wrote:
>
> All the read and write operations performed on fuse_files which have the
> passthrough feature enabled are forwarded to the associated lower file
> system file.
>
> Sending the request directly to the lower file system avoids the
On Tue, Jun 23, 2020 at 8:21 AM Dave Chinner wrote:
>
> From: Dave Chinner
>
> The page faultround path ->map_pages is implemented in XFS via
> filemap_map_pages(). This function checks that pages found in page
> cache lookups have not raced with truncate based invalidation by
> checking
On Wed, Sep 9, 2020 at 2:11 PM Jan Kara wrote:
>
> On Wed 09-09-20 10:36:57, Amir Goldstein wrote:
> > On Wed, Sep 9, 2020 at 10:00 AM Xiaoming Ni wrote:
> > >
> > > On 2020/9/9 11:44, Amir Goldstein wrote:
> > > > On Tue, Sep 8, 2020
On Wed, Sep 9, 2020 at 10:00 AM Xiaoming Ni wrote:
>
> On 2020/9/9 11:44, Amir Goldstein wrote:
> > On Tue, Sep 8, 2020 at 8:19 PM Matthew Wilcox wrote:
> >>
> >> On Tue, Sep 08, 2020 at 04:18:29PM +0300, Amir Goldstein wrote:
> >>> On Tue,
On Tue, Sep 8, 2020 at 8:19 PM Matthew Wilcox wrote:
>
> On Tue, Sep 08, 2020 at 04:18:29PM +0300, Amir Goldstein wrote:
> > On Tue, Sep 8, 2020 at 3:53 PM Xiaoming Ni wrote:
> > > For example, in fs/coredump.c, do_coredump() calls filp_open() to
> > > generate core
On Tue, Sep 8, 2020 at 3:53 PM Xiaoming Ni wrote:
>
> On 2020/9/8 18:06, Amir Goldstein wrote:
> > On Tue, Sep 8, 2020 at 11:02 AM Xiaoming Ni wrote:
> >>
> >> The file opening action on the system may be from user-mode sys_open()
> >> or kernel-mode fil
On Tue, Sep 8, 2020 at 11:02 AM Xiaoming Ni wrote:
>
> The file opening action on the system may be from user-mode sys_open()
> or kernel-mode filp_open().
> Currently, fsnotify_open() is invoked in do_sys_openat2().
> But filp_open() is not notified. Why? Is this an omission?
>
> Do we need to
1 - 100 of 783 matches
Mail list logo
