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 Mon, Feb 22,
Vivek Goyal writes:
> On Mon, Mar 29, 2021 at 03:54:03PM +0100, Luis Henriques wrote:
>> On Thu, Mar 25, 2021 at 11:18:22AM -0400, Vivek Goyal wrote:
>> > Fuse client needs to send additional information to file server when
>> > it calls SETXATTR(system.p
On Thu, Mar 25, 2021 at 11:18:22AM -0400, Vivek Goyal wrote:
> Fuse client needs to send additional information to file server when
> it calls SETXATTR(system.posix_acl_access). Right now there is no extra
> space in fuse_setxattr_in. So introduce a v2 of the structure which has
> more space in it
On Thu, Mar 25, 2021 at 11:18:22AM -0400, Vivek Goyal wrote:
> Fuse client needs to send additional information to file server when
> it calls SETXATTR(system.posix_acl_access). Right now there is no extra
> space in fuse_setxattr_in. So introduce a v2 of the structure which has
> more space in it
On Fri, Mar 19, 2021 at 09:02:33AM +, Luis Henriques wrote:
> On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> > On Thu, Mar 18, 2021 at 11:29:28AM +0000, Luis Henriques wrote:
> > > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
>
On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> On Thu, Mar 18, 2021 at 11:29:28AM +0000, Luis Henriques wrote:
> > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
>
On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> On Thu, Mar 18, 2021 at 11:29:28AM +0000, Luis Henriques wrote:
> > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
>
On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
> > [CC linux-mm]
> >
> > On Thu, Mar 18, 2021 at 10:25 AM Luis Henriques wrote:
> > >
> > > (I thought Vlastimil was alrea
(I thought Vlastimil was already on CC...)
On Mon, Mar 15, 2021 at 11:06:59AM +, Matthew Wilcox wrote:
> On Mon, Mar 15, 2021 at 09:47:45AM +0000, Luis Henriques wrote:
> > On Fri, Mar 12, 2021 at 01:11:23PM +, Matthew Wilcox wrote:
> > > On Fri, Mar 12, 2021 at 12:2
e_ksize() in
> slab_post_alloc_hook() (and avoid new IS_ENABLED(CONFIG_DEBUG_KMEMLEAK)
> guard), just call kfence_ksize() in mm/kmemleak.c:create_object().
>
> Reported-by: Luis Henriques
> Cc: Catalin Marinas
> Signed-off-by: Marco Elver
Tested-by: Luis Henriques
> ---
> m
[<08f727ce>] do_init_module+0x5c/0x260
[<3cdedab6>] __do_sys_finit_module+0xb5/0x120
[<ad2f48c6>] do_syscall_64+0x33/0x40
[<809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Cc: sta...@vger.kernel.org
Signed-off-by: Luis H
On Tue, Mar 16, 2021 at 07:47:00PM +0100, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 06:19PM +, Catalin Marinas wrote:
> > On Tue, Mar 16, 2021 at 06:30:00PM +0100, Marco Elver wrote:
> > > On Tue, Mar 16, 2021 at 04:42PM +0000, Luis Henriques wrote:
> > > >
Vivek Goyal writes:
> On Tue, Mar 16, 2021 at 05:02:34PM +0000, Luis Henriques wrote:
>> When accidentally passing twice the same tag to qemu, kmemleak ended up
>> reporting a memory leak in virtiofs. Also, looking at the log I saw the
>> following error (that's when I re
On Tue, Mar 16, 2021 at 06:30:00PM +0100, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 04:42PM +0000, Luis Henriques wrote:
> > Hi!
> >
> > This is probably a known issue, but just in case: looks like it's not
> > possible to use kmemleak when kfence is enable
[<08f727ce>] do_init_module+0x5c/0x260
[<3cdedab6>] __do_sys_finit_module+0xb5/0x120
[<ad2f48c6>] do_syscall_64+0x33/0x40
[<809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Cc: sta...@vger.kernel.org
Signed-off-by: Luis Henriqu
Hi!
This is probably a known issue, but just in case: looks like it's not
possible to use kmemleak when kfence is enabled:
[0.272136] kmemleak: Cannot insert 0x888236e02f00 into the object
search tree (overlaps existing)
[0.272136] CPU: 0 PID: 8 Comm: kthreadd Not tainted
On Fri, Mar 12, 2021 at 01:11:23PM +, Matthew Wilcox wrote:
> On Fri, Mar 12, 2021 at 12:21:59PM +0000, Luis Henriques wrote:
> > > > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > > > reproducible in kernels as early as 5.4.
>
> If t
On Fri, Mar 12, 2021 at 10:48:40AM +0100, Miklos Szeredi wrote:
> On Fri, Mar 12, 2021 at 9:51 AM Luis Henriques wrote:
> >
> > Hi Miklos,
> >
> > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > reproducible in kernels as early as 5.4.
Hi Miklos,
I've seen a bug report (5.10.16 kernel splat below) that seems to be
reproducible in kernels as early as 5.4.
The commit that caught my attention when looking at what was merged in 5.4
was e4648309b85a ("fuse: truncate pending writes on O_TRUNC") but I didn't
went too deeper on that
On Mon, Mar 01, 2021 at 11:33:24AM -0500, Vivek Goyal wrote:
> On Fri, Feb 26, 2021 at 06:33:57PM +0000, Luis Henriques wrote:
> > Setting file permissions with POSIX ACLs (setxattr) isn't clearing the
> > setgid bit. This seems to be CVE-2016-7097, detected by running fstest
tting file permissions"), FUSE didn't had ACLs support yet.
Signed-off-by: Luis Henriques
---
fs/fuse/acl.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/acl.c b/fs/fuse/acl.c
index f529075a2ce8..1b273277c1c9 100644
--- a/fs/fuse/a
On Wed, Feb 24, 2021 at 06:10:45PM +0200, Amir Goldstein wrote:
> 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!
> >
&
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.
man2/copy_file_range.2 | 10 +-
1 file changed, 9 insertions(+), 1 deletion
On Tue, Feb 23, 2021 at 08:00:54PM -0500, Olga Kornievskaia wrote:
> On Mon, Feb 22, 2021 at 5:25 AM 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
&
On Tue, Feb 23, 2021 at 08:57:38AM -0800, 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 Henri
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 tracefs file. Before commit
> > 5
wnw7zs...@mail.gmail.com/
Link:
https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
Changes since v7
- set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
er
wnw7zs...@mail.gmail.com/
Link:
https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
Changes since v6
- restored i_sb checks for the clone operation
Changes since v5
- check if -&
wnw7zs...@mail.gmail.com/
Link:
https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
And v6 is upon us. Behold!
Changes since v5
- check if ->copy_file_range is NULL before c
Amir Goldstein writes:
> 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_f
wnw7zs...@mail.gmail.com/
Link:
https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
And v5! Sorry. Sure, it makes sense to go through the all the vfs_cfr()
checks first.
Again,
/CANMq1KDZuxir2LM5jOTm0xx+BnvW=zmpsg47cyhfjwnw7zs...@mail.gmail.com/
Link:
https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
And here's v4. I'd like to request help for testing. I know
Luis Henriques writes:
> Amir Goldstein writes:
>
>> 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 alway
Amir Goldstein writes:
> 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
linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat
Signed-off-by: Luis Henriques
---
Ok, I've tried to address all the issues and comments. Hopefully this v3
is a bit closer to the final fix.
Changes since v2
- do all the required checks earlie
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 similar problem.
>> >
>> > Not exactly.
>> > Generally speaking, overlayfs
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 it got from layer above, so if called from nfsd it
> will allow cross fs copy and when called from syscall it
"gre...@linuxfoundation.org" writes:
> On Tue, Feb 16, 2021 at 11:17:34AM +, Luis Henriques wrote:
>> Amir Goldstein writes:
>>
>> > On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust
>> > wrote:
>> >>
>> >> On Mon, 2021
t; >
>> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
>> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
>> > > > lhenriq...@suse.de>
>> > > > wrote:
>> > > > >
>> > > > > Nicol
ore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drink...@chromium.org/
Cc: Nicolas Boichat
Signed-off-by: Luis Henriques
---
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description
fs/
Amir Goldstein writes:
> 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:
>> > ...
>> >>
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* there are other options than
>>> simply reverting that commit :-)
>>>
>>>
Amir Goldstein writes:
> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques wrote:
...
>> Sure, I just wanted to point out that *maybe* there are other options than
>> simply reverting that commit :-)
>>
>> Something like the patch below (completely untested!) should rev
Greg KH writes:
> On Fri, Feb 12, 2021 at 12:41:48PM +0000, Luis Henriques wrote:
>> Greg KH writes:
...
>> >> >> Our option now are:
>> >> >> - Restore the cross-fs restriction into generic_copy_file_range()
>> >> >
>> >&
Greg KH writes:
> On Fri, Feb 12, 2021 at 12:05:14PM +0000, Luis Henriques wrote:
>> Greg KH writes:
>>
>> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
>> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH
>> >> wrote:
>>
Greg KH writes:
> On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
>> 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.
Jeff Layton writes:
> On Mon, 2020-11-23 at 17:38 +0000, Luis Henriques wrote:
>> Add a new vxattr that allows userspace to list the caps for a specific
>> directory or file.
>>
>> Signed-off-by: Luis Henriques
>> ---
>> Hi!
>>
>> Here'
Add a new vxattr that allows userspace to list the caps for a specific
directory or file.
Signed-off-by: Luis Henriques
---
Hi!
Here's a version that also shows the caps in hexadecimal format, as
suggested by Jeff. IMO the parenthesis and the '0x' prefix help the
readability, but they may make
Add a new vxattr that allows userspace to list the caps for a specific
directory or file.
Signed-off-by: Luis Henriques
---
fs/ceph/xattr.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c
index 197cb1234341..996512e05513 100644
doing a cross
quota realms rename.
URL: https://tracker.ceph.com/issues/48203
Signed-off-by: Luis Henriques
---
fs/ceph/dir.c | 9
fs/ceph/quota.c | 58 +
fs/ceph/super.h | 3 +--
3 files changed, 6 insertions(+), 64 deletions(-)
diff
Jeff Layton writes:
> On Thu, 2020-11-12 at 10:40 +0000, Luis Henriques wrote:
>> Jeff Layton writes:
>>
>> > On Wed, 2020-11-11 at 18:28 +, Luis Henriques wrote:
>> > > Jeff Layton writes:
>> > >
>> > > > On Wed, 2020-11
Jeff Layton writes:
> On Thu, 2020-11-12 at 20:43 +0800, Yan, Zheng wrote:
>> On Thu, Nov 12, 2020 at 6:48 PM Luis Henriques wrote:
>> >
>> > A NULL pointer dereference may occur in __ceph_remove_cap with some of the
>> > callbacks used in ceph_itera
: mdsmap_decode got incorrect state(up:standby-replay)
This patch downgrades these warnings to debug, as they may flood the logs
if the cluster is unstable for a while.
Signed-off-by: Luis Henriques
---
Hi!
This patch follows from my other patch "ceph: fix race in concurrent
__ceph_remov
the i_ceph_lock, the fix is simply
a matter of returning immediately if caps->ci is NULL.
Based on a patch from Jeff Layton.
Cc: sta...@vger.kernel.org
URL: https://tracker.ceph.com/issues/43272
Link: https://www.spinics.net/lists/ceph-devel/msg47064.html
Signed-off-by: Luis Henriques
---
fs/ceph/cap
Jeff Layton writes:
> On Wed, 2020-11-11 at 18:28 +0000, Luis Henriques wrote:
>> Jeff Layton writes:
>>
>> > On Wed, 2020-11-11 at 15:39 +, Luis Henriques wrote:
>> > > When doing a rename across quota realms, there's a corner case that isn't
>>
Jeff Layton writes:
> On Wed, 2020-11-11 at 15:39 +0000, Luis Henriques wrote:
>> When doing a rename across quota realms, there's a corner case that isn't
>> handled correctly. Here's a testcase:
>>
>> mkdir files limit
>> truncate files/f
ename operation under different quota
realms")
URL: https://tracker.ceph.com/issues/36593
Signed-off-by: Luis Henriques
---
fs/ceph/inode.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
index 526faf4778ce..30e3f240ac96 10064
David Laight writes:
> From: Luis Henriques
>> Sent: 14 August 2020 10:38
>>
>> Since there's a return immediately after the 'break', there's no need for
>> this extra 'return' in the S_IFDIR case.
>>
>> Signed-off-by: Luis Henriques
>> ---
&g
Since there's a return immediately after the 'break', there's no need for
this extra 'return' in the S_IFDIR case.
Signed-off-by: Luis Henriques
---
fs/ceph/file.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index d51c3f2fdca0..04ab99c0223a 100644
Hi!
I've just got the following WARNING followed by a BUG on rc7. Maybe it's
already a known issue, but here it is anyway.
Cheers,
--
Luis
[ 38.001304] [ cut here ]
[ 38.001312] list_add corruption. prev->next should be next
(8fe713397b88), but was
ly this fix can be included in 5.8. Not that
I'm seeing this WARNING frequently, but frequent enough to annoy me :-)
Cheers,
--
Luis
> > -Daniel
> >
> > On Thu, Jun 25, 2020 at 12:22 PM Luis Henriques wrote:
> > >
> > > Hi!
> > >
> > > I've be
Hi!
I've been seeing this warning occasionally, not sure if it has been
reported yet. It's not a regression as I remember seeing it in, at least,
5.7.
Anyway, here it is:
[ cut here ]
sysfs group 'power' not found for kobject 'i2c-7'
WARNING: CPU: 1 PID: 17996 at
only if i_nlink is 0 *and* i_count is 1.
This patch also makes sure we have LINK caps before checking i_nlink.
Signed-off-by: Luis Henriques
---
Hi!
(and sorry for the delay in my reply!)
So, from the discussion thread and some IRC chat with Jeff, I'm sending
v2. What changed?
On Fri, May 15, 2020 at 09:42:24AM +0300, Amir Goldstein wrote:
> +CC: fstests
>
> On Thu, May 14, 2020 at 4:15 PM Jeff Layton wrote:
> >
> > On Thu, 2020-05-14 at 13:48 +0100, Luis Henriques wrote:
> > > On Thu, May 14, 2020 at 08:10:09AM -0400, Jeff Layton wro
On Thu, May 14, 2020 at 08:10:09AM -0400, Jeff Layton wrote:
> On Thu, 2020-05-14 at 12:14 +0100, Luis Henriques wrote:
> > Similarly to commit 03f219041fdb ("ceph: check i_nlink while converting
> > a file handle to dentry"), this fixes another corner case w
t;)
- open("/cephfs/myfile")
- unlink("/cephfs/myfile")
- open_by_handle_at()
The call to open_by_handle_at should not fail because the file still
exists and we do have a valid handle to it.
Signed-off-by: Luis Henriques
---
fs/ceph/export.c | 13 +++--
1 file changed
A misconfigured cephx can easily result in having the kernel client
flooding the logs with:
ceph: Can't lookup inode 1 (err: -13)
Change his message to debug level.
Link: https://tracker.ceph.com/issues/44546
Signed-off-by: Luis Henriques
---
Hi!
This patch should fix some harmless warnings
Luis Henriques writes:
> On Tue, Oct 22, 2019 at 08:48:56PM +0800, Yan, Zheng wrote:
>> On Mon, Oct 21, 2019 at 10:55 PM Luis Henriques wrote:
>>
>> >
>> > Jeff Layton writes:
>> >
>> > > On Thu, 2019-10-17 at 15:46 +0100, Luis Henriq
On Tue, Oct 22, 2019 at 08:48:56PM +0800, Yan, Zheng wrote:
> On Mon, Oct 21, 2019 at 10:55 PM Luis Henriques wrote:
>
> >
> > Jeff Layton writes:
> >
> > > On Thu, 2019-10-17 at 15:46 +0100, Luis Henriques wrote:
> > >> KASAN reports a us
Jeff Layton writes:
> On Thu, 2019-10-17 at 15:46 +0100, Luis Henriques wrote:
>> KASAN reports a use-after-free when running xfstest generic/531, with the
>> following trace:
>>
>> [ 293.903362] kasan_report+0xe/0x20
>> [ 293.903365] rb_
r-free will occur.
This can be fixed by protecting the rb_erase with the s_cap_lock spinlock,
which is used by ceph_send_cap_releases(), before the cap is freed.
Signed-off-by: Luis Henriques
---
fs/ceph/caps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/caps.c b/f
Hi,
Maybe this is a known issue with pstore, I didn't investigate, but it's
pretty easy to reproduce:
I've efi-pstore loaded, with a bunch of files in /sys/fs/pstore. If I
unload my backend driver (efi-pstore) and try to remove a file from
/sys/fs/pstore I'll see the following spat:
BUG:
Gregory Farnum writes:
> On Mon, Sep 9, 2019 at 4:15 AM Luis Henriques wrote:
>>
>> "Jeff Layton" writes:
>>
>> > On Mon, 2019-09-09 at 11:28 +0100, Luis Henriques wrote:
>> >> OSDs are able to perform object copies across diff
OSDs are able to perform object copies across different pools. Thus,
there's no need to prevent copy_file_range from doing remote copies if the
source and destination superblocks are different. Only return -EXDEV if
they have different fsid (the cluster ID).
Signed-off-by: Luis Henriques
"Jeff Layton" writes:
> On Mon, 2019-09-09 at 06:35 -0400, Jeff Layton wrote:
>> On Mon, 2019-09-09 at 11:28 +0100, Luis Henriques wrote:
>> > OSDs are able to perform object copies across different pools. Thus,
>> > there's no need to prevent cop
"Jeff Layton" writes:
> On Mon, 2019-09-09 at 11:28 +0100, Luis Henriques wrote:
>> OSDs are able to perform object copies across different pools. Thus,
>> there's no need to prevent copy_file_range from doing remote copies if the
>> source and destination s
OSDs are able to perform object copies across different pools. Thus,
there's no need to prevent copy_file_range from doing remote copies if the
source and destination superblocks are different. Only return -EXDEV if
they have different fsid (the cluster ID).
Signed-off-by: Luis Henriques
"Jeff Layton" writes:
> On Fri, 2019-09-06 at 17:26 +0100, Luis Henriques wrote:
>> "Jeff Layton" writes:
>>
>> > On Fri, 2019-09-06 at 14:57 +0100, Luis Henriques wrote:
>> > > OSDs are able to perform object copies across d
"Jeff Layton" writes:
> On Fri, 2019-09-06 at 14:57 +0100, Luis Henriques wrote:
>> OSDs are able to perform object copies across different pools. Thus,
>> there's no need to prevent copy_file_range from doing remote copies if the
>> source and destination s
Luis Henriques writes:
> "Jeff Layton" writes:
>
>> On Tue, 2019-07-23 at 16:50 +0100, Luis Henriques wrote:
>>> When filling an inode with info from the MDS, i_blkbits is being
>>> initialized using fl_stripe_unit, which contains the stripe unit in
>
"Jeff Layton" writes:
> On Tue, 2019-07-23 at 16:50 +0100, Luis Henriques wrote:
>> When filling an inode with info from the MDS, i_blkbits is being
>> initialized using fl_stripe_unit, which contains the stripe unit in
>> bytes. Unfortunately, this doe
an UBSAN undefined behaviour in i_blocksize():
UBSAN: Undefined behaviour in ./include/linux/fs.h:731:12
shift exponent 255 is too large for 32-bit type 'int'
Fix this by initializing i_blkbits to CEPH_BLOCK_SHIFT if fl_stripe_unit
is zero.
Signed-off-by: Luis Henriques
---
fs/ceph/inode.c | 7
Waiman Long writes:
> On 7/20/19 4:41 AM, Luis Henriques wrote:
>> "Linus Torvalds" writes:
>>
>>> On Fri, Jul 19, 2019 at 12:32 PM Waiman Long wrote:
>>>> This patch shouldn't change the behavior of the rwsem code. The code
>>>> on
Luis Henriques writes:
> Luis Henriques writes:
>
>> "Linus Torvalds" writes:
>>
>>> On Fri, Jul 19, 2019 at 12:32 PM Waiman Long wrote:
>>>>
>>>> This patch shouldn't change the behavior of the rwsem code. The code
>>>&
Luis Henriques writes:
> "Linus Torvalds" writes:
>
>> On Fri, Jul 19, 2019 at 12:32 PM Waiman Long wrote:
>>>
>>> This patch shouldn't change the behavior of the rwsem code. The code
>>> only access data within the rw_semaphore structures. I
"Linus Torvalds" writes:
> On Fri, Jul 19, 2019 at 12:32 PM Waiman Long wrote:
>>
>> This patch shouldn't change the behavior of the rwsem code. The code
>> only access data within the rw_semaphore structures. I don't know why it
>> will cause a KASAN error. I will have to reproduce it and
Waiman Long writes:
> On 7/19/19 2:45 PM, Luis Henriques wrote:
>> On Mon, May 20, 2019 at 04:59:12PM -0400, Waiman Long wrote:
>>> The rwsem->owner contains not just the task structure pointer, it also
>>> holds some flags for storing the current state of the rw
On Mon, May 20, 2019 at 04:59:12PM -0400, Waiman Long wrote:
> The rwsem->owner contains not just the task structure pointer, it also
> holds some flags for storing the current state of the rwsem. Some of
> the flags may have to be atomically updated. To reflect the new reality,
> the owner is now
simply allows ceph_buffer_put to receive a NULL buffer so
that the NULL check doesn't need to be performed in all the other patches.
IOW, it's not really required, just convenient.
(Note: maybe these patches should all be tagged for stable.)
Luis Henriques (4):
libceph: allow ceph_buffer_put() to r
Signed-off-by: Luis Henriques
---
include/linux/ceph/buffer.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/ceph/buffer.h b/include/linux/ceph/buffer.h
index 5e58bb29b1a3..11cdc7c60480 100644
--- a/include/linux/ceph/buffer.h
+++ b/include/linux/ceph
hed_held+0x74/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x142/0x1a0
? mnt_want_write+0x20/0x50
path_setxattr+0xba/0xd0
__x64_sys_lsetxattr+0x24/0x30
do_syscall_64+0x50/0x1c0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff23514359a
Signed-off-by: L
__ia32_sys_sync+0xa/0x10
do_syscall_64+0x50/0x1c0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fc6409ab617
Signed-off-by: Luis Henriques
---
fs/ceph/caps.c | 5 -
fs/ceph/snap.c | 4 +++-
fs/ceph/super.h | 2 +-
fs/ceph/xattr.c | 11 ---
4 files changed,
process_one_work+0x1b8/0x5f0
process_one_work+0x244/0x5f0
worker_thread+0x4d/0x3e0
kthread+0x105/0x140
? process_one_work+0x5f0/0x5f0
? kthread_park+0x90/0x90
ret_from_fork+0x3a/0x50
Signed-off-by: Luis Henriques
---
fs/ceph/inode.c | 7 ---
1 file changed, 4 insertions(+
ceph_drop_inode() implementation is not any different from the generic
function, thus there's no point in keeping it around.
Signed-off-by: Luis Henriques
---
fs/ceph/inode.c | 10 --
fs/ceph/super.c | 2 +-
fs/ceph/super.h | 1 -
3 files changed, 1 insertion(+), 12 deletions(-)
diff
"Jeff Layton" writes:
> On Mon, 2019-07-01 at 18:16 +0100, Luis Henriques wrote:
>> Commit e450f4d1a5d6 ("ceph: pass inclusive lend parameter to
>> filemap_write_and_wait_range()") fixed the end offset parameter used to
>> call filemap_write_and_wai
LIGN macro instead.
Fixes: e450f4d1a5d6 ("ceph: pass inclusive lend parameter to
filemap_write_and_wait_range()")
Signed-off-by: Luis Henriques
---
fs/ceph/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 183c37c0a8fc..7a57db8e
Jeff Layton writes:
> On Thu, 2019-06-27 at 15:44 +, Sage Weil wrote:
>> On Thu, 27 Jun 2019, Jeff Layton wrote:
>> > On Thu, 2019-06-27 at 14:51 +0100, Luis Henriques wrote:
>> > > Having granularity set to 1us results in having inode timestamps with a
&
Having granularity set to 1us results in having inode timestamps with a
accurancy different from the fuse client (i.e. atime, ctime and mtime will
always end with '000'). This patch normalizes this behaviour and sets the
granularity to 1.
Signed-off-by: Luis Henriques
---
fs/ceph/super.c | 2
Luis Henriques writes:
> "Yan, Zheng" writes:
>
>> On Fri, Mar 22, 2019 at 6:04 PM Luis Henriques wrote:
>>>
>>> Luis Henriques writes:
>>>
>>> > "Yan, Zheng" writes:
>>> >
>>> >> On
"Yan, Zheng" writes:
> On Fri, Mar 22, 2019 at 6:04 PM Luis Henriques wrote:
>>
>> Luis Henriques writes:
>>
>> > "Yan, Zheng" writes:
>> >
>> >> On Tue, Mar 19, 2019 at 12:22 AM Luis Henriques
>> >> wrote:
1 - 100 of 17688 matches
Mail list logo
