On Tue, Jul 01 2025, Achill Gilgenast wrote:
> On Mon Jun 23, 2025 at 1:53 PM CEST, Achill Gilgenast wrote:
>> On Sun Jun 22, 2025 at 8:36 PM CEST, Andrew Morton wrote:
>>> On Sun, 22 Jun 2025 03:45:49 +0200 Achill Gilgenast
>>> wrote:
>>>
Some libc's like musl libc don't provide execinfo.h
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.posix_acl_acc
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
/0x2e0
[<08f727ce>] do_init_module+0x5c/0x260
[<3cdedab6>] __do_sys_finit_module+0xb5/0x120
[<ad2f48c6>] do_syscall_64+0x33/0x40
[<0000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Cc: sta...@vger.kernel.org
Signed-off-
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
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
/0x2e0
[<08f727ce>] do_init_module+0x5c/0x260
[<3cdedab6>] __do_sys_finit_module+0xb5/0x120
[<ad2f48c6>] do_syscall_64+0x33/0x40
[<0000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Cc: sta...@vger.kernel.org
Signed-off-by: Lu
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 5.12.0-rc3+
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.
>
>
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
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 fstes
en
setting 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
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(+),
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
psg47cyhfjwnw7zs...@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
psg47cyhfjwnw7zs...@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
- c
psg47cyhfjwnw7zs...@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 NUL
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
psg47cyhfjwnw7zs...@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 firs
ux-fsdevel/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
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 go
ernel.org/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 require
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 won't
"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
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. Thi
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, bu
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
to returning -EXDEV when 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(
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-1
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_iterate_s
: 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
d 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/cep
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'
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
>> t
dcd71458e ("ceph: allow rename 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 52
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: L
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 d51c3f2fd
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
ommit. Hopefully 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!
> > >
>
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 fs/sysf
nly 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 c
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 wrote:
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 war
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 use-afte
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_
use-after-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/ce
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: unable
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 Henr
"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 copy_
"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 destinat
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 Henr
"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 destinat
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 doesn'
xff, causing 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
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
>>>&g
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 structure
"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 figur
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
atch 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_bu
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
ame_lookup+0xc9/0x140
? rcu_read_lock_sched_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
rs+0x8f/0xf0
ksys_sync+0x4f/0xb0
__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 |
owpath+0x4d/0x2a0
ceph_con_workfn+0xc97/0x2ec0
? 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.
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(-)
"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
use PAGE_ALIGN 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
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/s
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
1 - 100 of 7910 matches
Mail list logo
