On Fri, Aug 16, 2024 at 1:53 PM Roberto Sassu
wrote:
>
> On Tue, 2024-08-06 at 15:36 +0200, Mateusz Guzik wrote:
> > The EVM_NEW_FILE flag is unset if the file already existed at the time
> > of open and this can be checked without looking at i_writecount.
>
> Agreed. EVM_
On Thu, Sep 19, 2024 at 04:14:05AM +0530, Neeraj Upadhyay wrote:
> On 9/18/2024 12:48 PM, Linus Torvalds wrote:
> > On Tue, 17 Sept 2024 at 16:34, Boqun Feng wrote:
> >>
> >> This series introduces hazard pointers [1] to kernel space. A TL;DR
> >> description of hazard pointers is "a scalable refc
probe lookup will be sufficient, or maybe some
other hackery is viable without messing with fences in
vma_start_write.
--
Mateusz Guzik
On Thu, Aug 15, 2024 at 10:45:45AM -0700, Suren Baghdasaryan wrote:
> >From all the above, my understanding of your objection is that
> checking mmap_lock during our speculation is too coarse-grained and
> you would prefer to use the VMA seq counter to check that the VMA we
> are working on is unch
On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote:
> On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote:
> >
> > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote:
> > > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely a
On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote:
> Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access
> vma->vm_file->f_inode lockless only under rcu_read_lock() protection,
> attempting uprobe look up speculatively.
>
> We rely on newly added mmap_lock_speculation
On Mon, Aug 12, 2024 at 09:29:16PM -0700, Andrii Nakryiko wrote:
> Add RCU protection for file struct's backing memory by adding
> SLAB_TYPESAFE_BY_RCU flag to files_cachep. This will allow to locklessly
> access struct file's fields under RCU lock protection without having to
> take much more expe
profile.
Signed-off-by: Mateusz Guzik
---
The context is that I'm writing a patch which removes one lockref
get/put cycle on parallel open. An operational WIP reduces ping-pong in
that area and made do_dentry_open skyrocket along with evm_file_release,
due to i_writecount access. With the
On Fri, Jul 26, 2024 at 8:39 PM Mateusz Guzik wrote:
>
> On Fri, Jul 26, 2024 at 8:02 PM Paul E. McKenney wrote:
> >
> > On Fri, Jul 26, 2024 at 03:54:28PM +0200, Christian Brauner wrote:
> > > Hey,
> > >
> > > I could use some help with understanding
-> evict() can mess with the inode and
result in the iput() call in iget_locked(), which then will invoke
evict() again. And I'm not particularly confident the routine +
everything it calls is idempotent.
That's from a quick poke around, maybe I missed something.
syzkaller claims to have a reproducer. Trivial usage in my debug vm
does not result in anything, so I may need to grab their entire setup
to reproduce.
I'm going to look into it.
--
Mateusz Guzik
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=a4469a0d19b64bf518c12e8c24c81ec513a45e7d
commit a4469a0d19b64bf518c12e8c24c81ec513a45e7d
Author: Mateusz Guzik
AuthorDate: 2024-07-17 19:07:07 +
Commit: Mateusz Guzik
CommitDate: 2024-07-17 21:45
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=a4469a0d19b64bf518c12e8c24c81ec513a45e7d
commit a4469a0d19b64bf518c12e8c24c81ec513a45e7d
Author: Mateusz Guzik
AuthorDate: 2024-07-17 19:07:07 +
Commit: Mateusz Guzik
CommitDate: 2024-07-17 21:45
On Mon, Jul 15, 2024 at 8:33 PM Mateusz Guzik wrote:
>
> On Mon, Jul 15, 2024 at 8:21 PM John Baldwin wrote:
> >
> > On 7/15/24 13:59, Mateusz Guzik wrote:
> > > On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
> > >>
> > >> On 7/11/24 07:0
On Mon, Jul 15, 2024 at 8:33 PM Mateusz Guzik wrote:
>
> On Mon, Jul 15, 2024 at 8:21 PM John Baldwin wrote:
> >
> > On 7/15/24 13:59, Mateusz Guzik wrote:
> > > On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
> > >>
> > >> On 7/11/24 07:0
On Mon, Jul 15, 2024 at 8:21 PM John Baldwin wrote:
>
> On 7/15/24 13:59, Mateusz Guzik wrote:
> > On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
> >>
> >> On 7/11/24 07:07, Mateusz Guzik wrote:
> >>> The branch main has been updated by mjg:
> &
On Mon, Jul 15, 2024 at 8:21 PM John Baldwin wrote:
>
> On 7/15/24 13:59, Mateusz Guzik wrote:
> > On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
> >>
> >> On 7/11/24 07:07, Mateusz Guzik wrote:
> >>> The branch main has been updated by mjg:
> &
On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
>
> On 7/11/24 07:07, Mateusz Guzik wrote:
> > The branch main has been updated by mjg:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=87ee63bac69dc49291f55590b8baa57cad6c7d85
> >
> > commi
On Mon, Jul 15, 2024 at 6:22 PM John Baldwin wrote:
>
> On 7/11/24 07:07, Mateusz Guzik wrote:
> > The branch main has been updated by mjg:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=87ee63bac69dc49291f55590b8baa57cad6c7d85
> >
> > commi
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=87ee63bac69dc49291f55590b8baa57cad6c7d85
commit 87ee63bac69dc49291f55590b8baa57cad6c7d85
Author: Mateusz Guzik
AuthorDate: 2024-07-11 00:17:27 +
Commit: Mateusz Guzik
CommitDate: 2024-07-11 11:06
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=87ee63bac69dc49291f55590b8baa57cad6c7d85
commit 87ee63bac69dc49291f55590b8baa57cad6c7d85
Author: Mateusz Guzik
AuthorDate: 2024-07-11 00:17:27 +
Commit: Mateusz Guzik
CommitDate: 2024-07-11 11:06
The branch stable/13 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8b5eb0cf6c4f586f891fef7fb067beb343826435
commit 8b5eb0cf6c4f586f891fef7fb067beb343826435
Author: Mateusz Guzik
AuthorDate: 2024-07-08 17:57:39 +
Commit: Mateusz Guzik
CommitDate: 2024-07-10
The branch stable/13 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1f0f120183db12e680107a0553a8de2d854aa757
commit 1f0f120183db12e680107a0553a8de2d854aa757
Author: Mateusz Guzik
AuthorDate: 2024-07-08 12:24:41 +
Commit: Mateusz Guzik
CommitDate: 2024-07-10
The branch stable/14 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=72f8b18b8d93bee8f6ca6ed0dfa160db18424807
commit 72f8b18b8d93bee8f6ca6ed0dfa160db18424807
Author: Mateusz Guzik
AuthorDate: 2024-07-08 17:57:39 +
Commit: Mateusz Guzik
CommitDate: 2024-07-10
The branch stable/14 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b7f6841e00d53f1aee65a8cce4f98c239ae4cf75
commit b7f6841e00d53f1aee65a8cce4f98c239ae4cf75
Author: Mateusz Guzik
AuthorDate: 2024-07-08 12:24:41 +
Commit: Mateusz Guzik
CommitDate: 2024-07-10
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0a487207227badcbfbec029103ac7e2d5291bd30
commit 0a487207227badcbfbec029103ac7e2d5291bd30
Author: Mateusz Guzik
AuthorDate: 2024-07-08 17:57:39 +
Commit: Mateusz Guzik
CommitDate: 2024-07-08 18:17
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0a487207227badcbfbec029103ac7e2d5291bd30
commit 0a487207227badcbfbec029103ac7e2d5291bd30
Author: Mateusz Guzik
AuthorDate: 2024-07-08 17:57:39 +
Commit: Mateusz Guzik
CommitDate: 2024-07-08 18:17
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0a9aa6fdf58468945240e86bf16c268acc8c1776
commit 0a9aa6fdf58468945240e86bf16c268acc8c1776
Author: Mateusz Guzik
AuthorDate: 2024-07-08 12:24:41 +
Commit: Mateusz Guzik
CommitDate: 2024-07-08 12:40
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0a9aa6fdf58468945240e86bf16c268acc8c1776
commit 0a9aa6fdf58468945240e86bf16c268acc8c1776
Author: Mateusz Guzik
AuthorDate: 2024-07-08 12:24:41 +
Commit: Mateusz Guzik
CommitDate: 2024-07-08 12:40
On Sun, Jun 23, 2024 at 3:22 AM Xi Ruoyao wrote:
>
> On Sun, 2024-06-23 at 03:07 +0200, Mateusz Guzik wrote:
> > On Sun, Jun 23, 2024 at 2:59 AM Xi Ruoyao wrote:
> > >
> > > On Sat, 2024-06-22 at 15:41 -0700, Linus Torvalds wrote:
> > >
> > > >
int ret;
struct filename *name;
+ if (flags == AT_EMPTY_PATH && filename == NULL)
+ return do_statx_by_fd(...);
+
name = getname_flags(filename, getname_statx_lookup_flags(flags));
ret = do_statx(dfd, name, flags, mask, buffer);
putname(name);
and so on
Personally I would prefer if fstatx was added instead, fwiw most
massaging in the area will be the same regardless.
--
Mateusz Guzik
+cc Linus
On Sat, Jun 22, 2024 at 06:56:08PM +0800, Xi Ruoyao wrote:
> It's cheap to check if the path is empty in the userspace, but expensive
> to check if a userspace string is empty from the kernel. So using statx
> and AT_EMPTY_PATH to implement fstat is slower than a "native" fstat
> call.
% [kernel] [k] clear_bhb_loop
apparmor_file_open is eliminated from the profile with the patch.
Throughput (ops/s):
before: 6092196
after: 8309726 (+36%)
Signed-off-by: Mateusz Guzik
---
I think this is a worthwhile touch up regardless of what happens with
label refcouting in the long run
On Thu, Jun 20, 2024 at 09:26:00AM -0700, John Johansen wrote:
> On 6/20/24 06:15, Mateusz Guzik wrote:
> > It can be done in the common case.
> > > A 24-way open1_processes from will-it-scale (separate file open) shows:
> >29.37% [kernel] [k] apparmo
.
When benchmarking on a 24-core vm using will-it-scale's open1_process
("Separate file open"), the results are (ops/s):
before: 6092196
after: 8309726 (+36%)
Signed-off-by: Mateusz Guzik
---
v2:
- reword the commit message
If you want any changes made to it can you just do t
On Thu, Jun 20, 2024 at 8:23 PM Neeraj Upadhyay wrote:
>
>
>
> On 6/20/2024 10:45 PM, Mateusz Guzik wrote:
> > apparmor: try to avoid refing the label in apparmor_file_open
> >
> > If the label is not stale (which is the common case), the fact that the
> > pass
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b6196537b0125c50f25bd64ed60e1cdd635ecd34
commit b6196537b0125c50f25bd64ed60e1cdd635ecd34
Author: Mateusz Guzik
AuthorDate: 2024-06-20 17:48:52 +
Commit: Mateusz Guzik
CommitDate: 2024-06-20 17:55
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b6196537b0125c50f25bd64ed60e1cdd635ecd34
commit b6196537b0125c50f25bd64ed60e1cdd635ecd34
Author: Mateusz Guzik
AuthorDate: 2024-06-20 17:48:52 +
Commit: Mateusz Guzik
CommitDate: 2024-06-20 17:55
inode_init_always started setting the field to 0.
Signed-off-by: Mateusz Guzik
---
fs/bcachefs/fs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index 514bf83ebe29..f9044da417ac 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -230,7 +230,6
inode_init_always started setting the field to 0.
Signed-off-by: Mateusz Guzik
---
fs/xfs/xfs_icache.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
index d31a2c1ac00a..088ac200b026 100644
--- a/fs/xfs/xfs_icache.c
+++ b/fs/xfs
iant that i_state == 0 to begin with, but
achieving that would require dealing with all filesystem alloc handlers
one by one.
In the meantime drop the misleading locking and move i_state zeroing to
inode_init_always so that others don't need to deal with it by hand.
Signed-off-by: Mateusz
This is in preparation for the routine starting to zero the field.
De facto coded by Dave Chinner, see:
https://lore.kernel.org/linux-fsdevel/zmgtagglol33w...@dread.disaster.area/
Signed-off-by: Mateusz Guzik
---
fs/xfs/xfs_icache.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/xfs
As requested by Jan this is a 4-part series.
I diffed this against fs-next + my inode hash patch v3 as it adds one
i_state = 0 case. Should that hash thing not be accepted this bit is
trivially droppable from the patch.
Mateusz Guzik (4):
xfs: preserve i_state around inode_init_always in
On Mon, Jun 10, 2024 at 8:50 PM Kent Overstreet
wrote:
>
> On Mon, Jun 10, 2024 at 08:44:37PM +0200, Mateusz Guzik wrote:
> > On Mon, Jun 10, 2024 at 8:13 PM Kent Overstreet
> > wrote:
> > >
> > > On Sat, Jun 08, 2024 at 11:24:37AM +0200, Mateusz Guzik wrote
On Mon, Jun 10, 2024 at 8:13 PM Kent Overstreet
wrote:
>
> On Sat, Jun 08, 2024 at 11:24:37AM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 07, 2024 at 02:10:05PM -0400, Kent Overstreet wrote:
> > > Does the following patch help? I think the hammering on the key cache
> &g
On Fri, Jun 07, 2024 at 02:10:05PM -0400, Kent Overstreet wrote:
> Does the following patch help? I think the hammering on the key cache
> lock may be correlated with the key cache being mostly empty (and it
> looks like the shrinker code is behaving badly and trying very hard to
> free from a most
On Fri, Jun 7, 2024 at 9:37 PM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 09:15:31PM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 7, 2024 at 8:43 PM Kent Overstreet
> > wrote:
> > >
> > > On Fri, Jun 07, 2024 at 08:28:07PM +0200, Mateusz Guzik wr
On Fri, Jun 7, 2024 at 8:43 PM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 08:28:07PM +0200, Mateusz Guzik wrote:
> > Well I did a quick skim through, it's probably a no-go:
> > 1. uses bit locks which i'm told would be problematic vs lockdep and
> > rt
On Fri, Jun 7, 2024 at 8:21 PM Mateusz Guzik wrote:
>
> On Fri, Jun 7, 2024 at 8:10 PM Kent Overstreet
> wrote:
> >
> > On Fri, Jun 07, 2024 at 07:59:10PM +0200, Mateusz Guzik wrote:
> > > On Fri, Jun 7, 2024 at 7:53 PM Kent Overstreet
> > > wrote:
> &
On Fri, Jun 7, 2024 at 8:10 PM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 07:59:10PM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 7, 2024 at 7:53 PM Kent Overstreet
> > wrote:
> > >
> > > On Fri, Jun 07, 2024 at 06:51:05PM +0200, Mateusz Guzik wrote:
&g
On Fri, Jun 7, 2024 at 7:53 PM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 06:51:05PM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 7, 2024 at 6:28 PM Mateusz Guzik wrote:
> > >
> > > On Fri, Jun 7, 2024 at 6:07 PM Kent Overstreet
> > > wrote:
> &
On Fri, Jun 7, 2024 at 6:28 PM Mateusz Guzik wrote:
>
> On Fri, Jun 7, 2024 at 6:07 PM Kent Overstreet
> wrote:
> >
> > On Fri, Jun 07, 2024 at 12:10:34PM +0200, Mateusz Guzik wrote:
> > > On Fri, Jun 7, 2024 at 11:13 AM Kent Overstreet
> > > wrote:
> &
On Fri, Jun 7, 2024 at 6:07 PM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 12:10:34PM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 7, 2024 at 11:13 AM Kent Overstreet
> > wrote:
> > >
> > > On Fri, Jun 07, 2024 at 08:50:40AM +0200, Mateusz Guzik wro
On Fri, Jun 7, 2024 at 11:13 AM Kent Overstreet
wrote:
>
> On Fri, Jun 07, 2024 at 08:50:40AM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 7, 2024 at 2:31 AM Kent Overstreet
> > wrote:
> > >
> > > On Thu, Jun 06, 2024 at 08:40:50PM +0200, Mateusz Guzik wrote:
&
On Fri, Jun 7, 2024 at 2:31 AM Kent Overstreet
wrote:
>
> On Thu, Jun 06, 2024 at 08:40:50PM +0200, Mateusz Guzik wrote:
> > So I tried out bcachefs again and it once more fails to complete
> > parallel creation of 20 mln files -- processes doing the work use cpu
>
f7f01 __GI___libc_open+0x51
(/usr/lib/x86_64-linux-gnu/libc.so.6)
342f3439332f3032 [unknown] ([unknown])
the bcachefs thing is fs/bcachefs/btree_key_cache.c:871
ext4 and btrfs did not have any trouble. Read the old e-mail below for
repro instructions.
On Sun, Nov 5, 2023 at 1:38 P
On Tue, May 28, 2024 at 2:03 PM Rasmus Villemoes
wrote:
>
> On 28/05/2024 12.37, Mateusz Guzik wrote:
> > I misplaced a closing ) in a patch using unlikely() and broke the
> > comparison, see [1] for context.
> >
> > The fix was:
> > - if (un
oe-lkp/pywb7wcml44gzgidn7mtwwr23mybbilakckchk4777wfibtruj@n4yiwwpvglf7/T/#t
--
Mateusz Guzik
from open1_processes -t 20 ("Separate file open/close")
from will-it-scale on Sapphire Rapids (ops/s):
before: 12539898
after: 25575494 (+103%)
v2:
- add a comment justifying rcu usage, submitted by Eric Biggers
- whack spurious IS_ENCRYPTED check from the refed case
Signed-off-by: Mat
from open1_processes -t 20 ("Separate file open/close") from
will-it-scale on Sapphire Rapids (ops/s):
before: 12539898
after: 25575494 (+103%)
Arguably a vfs helper would be nice here.
Signed-off-by: Mateusz Guzik
---
fs/crypto/hooks.c | 23 +--
1 file changed, 17
on
It does react to -9 though.
--
Mateusz Guzik
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b0aaf8beb12609f8a94575ee21f849474bf7e03a
commit b0aaf8beb12609f8a94575ee21f849474bf7e03a
Author: Mateusz Guzik
AuthorDate: 2024-03-18 10:48:10 +
Commit: Mateusz Guzik
CommitDate: 2024-03-18 10:49
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b0aaf8beb12609f8a94575ee21f849474bf7e03a
commit b0aaf8beb12609f8a94575ee21f849474bf7e03a
Author: Mateusz Guzik
AuthorDate: 2024-03-18 10:48:10 +
Commit: Mateusz Guzik
CommitDate: 2024-03-18 10:49
:18:11 +
>>
>> The author should be Kajetan :(
>
> Indeed it should. My apologies to Kajetan. And Igor as well, although he
> probably got the better end of the deal.
>
You can revert and commit the correct version.
--
Mateusz Guzik
:18:11 +
>>
>> The author should be Kajetan :(
>
> Indeed it should. My apologies to Kajetan. And Igor as well, although he
> probably got the better end of the deal.
>
You can revert and commit the correct version.
--
Mateusz Guzik
On 2/3/24, David Chisnall wrote:
> On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>>
>> Binary startup is very slow, for example execve of a hello world
>> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
>> compared to a native one. As such perf-wis
d chroot on FreeBSD is faster by a factor of 2
compared to a native one. As such perf-wise this looks like a step in
the wrong direction.
Is there a problem making it so that libc ends up unchanged, but all
the bits are available separately in libsys if one does not want libc?
--
Mateusz Guzik
atile void *base, int word);
> +int suword32(volatile void *base, int32_t word);
> +int suword64(volatile void *base, int64_t word);
> uint32_t casuword32(volatile uint32_t *base, uint32_t oldval, uint32_t
> newval);
> u_long casuword(volatile u_long *p, u_long oldval, u_long newval);
> int casueword32(volatile uint32_t *base, uint32_t oldval, uint32_t
> *oldvalp,
>
--
Mateusz Guzik
atile void *base, int word);
> +int suword32(volatile void *base, int32_t word);
> +int suword64(volatile void *base, int64_t word);
> uint32_t casuword32(volatile uint32_t *base, uint32_t oldval, uint32_t
> newval);
> u_long casuword(volatile u_long *p, u_long oldval, u_long newval);
> int casueword32(volatile uint32_t *base, uint32_t oldval, uint32_t
> *oldvalp,
>
--
Mateusz Guzik
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3358108a38f0efc7e7a143aeda80c941946fef77
commit 3358108a38f0efc7e7a143aeda80c941946fef77
Author: Mateusz Guzik
AuthorDate: 2023-12-29 18:51:56 +
Commit: Mateusz Guzik
CommitDate: 2023-12-29 18:52
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3358108a38f0efc7e7a143aeda80c941946fef77
commit 3358108a38f0efc7e7a143aeda80c941946fef77
Author: Mateusz Guzik
AuthorDate: 2023-12-29 18:51:56 +
Commit: Mateusz Guzik
CommitDate: 2023-12-29 18:52
The branch stable/14 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=746b0f70a229586b28a2e74eb940cd8854f361e6
commit 746b0f70a229586b28a2e74eb940cd8854f361e6
Author: Mateusz Guzik
AuthorDate: 2023-11-19 22:23:20 +
Commit: Mateusz Guzik
CommitDate: 2023-11-29
On 11/28/23, Gleb Smirnoff wrote:
> Mateusz,
>
> On Tue, Nov 28, 2023 at 04:35:40PM +, Mateusz Guzik wrote:
> M> Add DEBUG_POISON_POINTER
> M>
> M> If you have a pointer which you know points to stale data, you can
> M> fill it with junk so tha
On 11/28/23, Gleb Smirnoff wrote:
> Mateusz,
>
> On Tue, Nov 28, 2023 at 04:35:40PM +, Mateusz Guzik wrote:
> M> Add DEBUG_POISON_POINTER
> M>
> M> If you have a pointer which you know points to stale data, you can
> M> fill it with junk so tha
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e1e847374bcc287ca97e6cb16cb5e07a697cf055
commit e1e847374bcc287ca97e6cb16cb5e07a697cf055
Author: Mateusz Guzik
AuthorDate: 2023-11-28 15:23:25 +
Commit: Mateusz Guzik
CommitDate: 2023-11-28 16:33
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e1e847374bcc287ca97e6cb16cb5e07a697cf055
commit e1e847374bcc287ca97e6cb16cb5e07a697cf055
Author: Mateusz Guzik
AuthorDate: 2023-11-28 15:23:25 +
Commit: Mateusz Guzik
CommitDate: 2023-11-28 16:33
On Mon, Nov 20, 2023 at 03:11:31PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a -2.9% regression of will-it-scale.per_thread_ops
> on:
>
>
> commit: 0ede61d8589cc2d93aa78230d74ac58b5b8d0244 ("file: convert to
> SLAB_TYPESAFE_BY_RCU")
> https://git.kernel.org/c
The branch stable/13 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e6d025c5c57dbcf4f7b078c9d42533e5839af932
commit e6d025c5c57dbcf4f7b078c9d42533e5839af932
Author: Alvin Chen
AuthorDate: 2023-11-20 05:55:35 +
Commit: Mateusz Guzik
CommitDate: 2023-11-24 19
The branch stable/14 has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=94bddd2ab75fd59fb25c7e162b3b335679bc518a
commit 94bddd2ab75fd59fb25c7e162b3b335679bc518a
Author: Alvin Chen
AuthorDate: 2023-11-20 05:55:35 +
Commit: Mateusz Guzik
CommitDate: 2023-11-24 17
Request polled shutdown. */
> - psc->reg->oqueue_intr_mask = 0x;
> -}
> -
> mfa = iop_get_mfa(psc->iop);
> msg = (struct i2o_bsa_cache_flush_message *)(psc->iop->ibase + mfa);
> bzero(msg, sizeof(struct i2o_bsa_cache_flush_message));
> @@ -199
Request polled shutdown. */
> - psc->reg->oqueue_intr_mask = 0x;
> -}
> -
> mfa = iop_get_mfa(psc->iop);
> msg = (struct i2o_bsa_cache_flush_message *)(psc->iop->ibase + mfa);
> bzero(msg, sizeof(struct i2o_bsa_cache_flush_message));
> @@ -199
On Mon, Nov 20, 2023 at 03:11:31PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a -2.9% regression of will-it-scale.per_thread_ops
> on:
>
>
> commit: 0ede61d8589cc2d93aa78230d74ac58b5b8d0244 ("file: convert to
> SLAB_TYPESAFE_BY_RCU")
> https://git.kernel.org/c
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e0d0f0930ee22af7bf38d28d8590d4e6c822871d
commit e0d0f0930ee22af7bf38d28d8590d4e6c822871d
Author: Alvin Chen
AuthorDate: 2023-11-20 05:55:35 +
Commit: Mateusz Guzik
CommitDate: 2023-11-20 05:57:25
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e0d0f0930ee22af7bf38d28d8590d4e6c822871d
commit e0d0f0930ee22af7bf38d28d8590d4e6c822871d
Author: Alvin Chen
AuthorDate: 2023-11-20 05:55:35 +
Commit: Mateusz Guzik
CommitDate: 2023-11-20 05:57:25
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=305a2676ae93fb50a623024d51039415521cb2da
commit 305a2676ae93fb50a623024d51039415521cb2da
Author: Mateusz Guzik
AuthorDate: 2023-11-19 22:23:20 +
Commit: Mateusz Guzik
CommitDate: 2023-11-19 22:25
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=305a2676ae93fb50a623024d51039415521cb2da
commit 305a2676ae93fb50a623024d51039415521cb2da
Author: Mateusz Guzik
AuthorDate: 2023-11-19 22:23:20 +
Commit: Mateusz Guzik
CommitDate: 2023-11-19 22:25
otal workaround, the real bug is that root dir gets
modified to begin with and there will be other cases prone to cause
the same problem.
More importantly, is not this a regression from security pov?
--
Mateusz Guzik
otal workaround, the real bug is that root dir gets
modified to begin with and there will be other cases prone to cause
the same problem.
More importantly, is not this a regression from security pov?
--
Mateusz Guzik
On 11/14/23, Paul Moore wrote:
> On Tue, Nov 14, 2023 at 5:33 AM Mateusz Guzik wrote:
>> On 11/14/23, Artem Savkov wrote:
>> > On Tue, Oct 24, 2023 at 07:59:18PM +0200, Mateusz Guzik wrote:
>> >> For the thread to start executing ->mm has to be set.
>> &
On 11/14/23, Rick Macklem wrote:
> On Tue, Nov 14, 2023 at 10:46 AM Alexander Motin wrote:
>>
>> On 14.11.2023 12:44, Alexander Motin wrote:
>> > On 14.11.2023 12:39, Mateusz Guzik wrote:
>> >> One of the vnodes is probably not zfs, I suspect this will do i
On 11/14/23, Alexander Motin wrote:
> On 14.11.2023 12:44, Alexander Motin wrote:
>> On 14.11.2023 12:39, Mateusz Guzik wrote:
>>> One of the vnodes is probably not zfs, I suspect this will do it
>>> (untested):
>>>
>>> diff --git a/sys/contrib/openz
On 11/14/23, Alexander Motin wrote:
> On 14.11.2023 12:39, Mateusz Guzik wrote:
>> One of the vnodes is probably not zfs, I suspect this will do it
>> (untested):
>>
>> diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
>> b/sys/cont
in critical section or under mutex
> cpuid = 2
> time = 1699966486
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> vpanic() at vpanic+0x1a0
> panic() at panic+0x48
> data_abort() at data_abort+0x2fc
> handle_el1h_sync() at handle_el1h_sync+0x18
> --- exception, esr 0x9604
> rms_rlock() at rms_rlock+0x1c
> zfs_clone_range() at zfs_clone_range+0x68
> zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
> null_bypass() at null_bypass+0x118
> vn_copy_file_range() at vn_copy_file_range+0x1c0
> kern_copy_file_range() at kern_copy_file_range+0x36c
> sys_copy_file_range() at sys_copy_file_range+0x8c
> do_el0_sync() at do_el0_sync+0x634
> handle_el0_sync() at handle_el0_sync+0x48
> --- exception, esr 0x5600
> KDB: enter: panic
> [ thread pid 3620 tid 100911 ]
> Stopped at kdb_enter+0x48: str xzr, [x19, #768]
> db>
>
> This happens as soon as I start poudriere in a jenkins-agent jail.
>
> AFAIK this includes the two recent vn_copy_file_range changes of
> Konstantin.
>
> Next I will install a GENERIC kernel instead of GENERIC-NODEBUG.
>
One of the vnodes is probably not zfs, I suspect this will do it (untested):
diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
index 107cd69c756c..e799a7091b8e 100644
--- a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
+++ b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
@@ -6270,6 +6270,11 @@ zfs_freebsd_copy_file_range(struct
vop_copy_file_range_args *ap)
goto bad_write_fallback;
}
}
+
+ if (invp->v_mount->mnt_vfc != outvp->v_mount->mnt_vfc) {
+ goto bad_write_fallback;
+ }
+
if (invp == outvp) {
if (vn_lock(outvp, LK_EXCLUSIVE) != 0) {
goto bad_write_fallback;
--
Mateusz Guzik
_mount->mnt_vfc->vfc_name,
> - outvp->v_mount->mnt_vfc->vfc_name) == 0)
> + if (inmp == outmp || strcmp(inmp->mnt_vfc->vfc_name,
> + outmp->mnt_vfc->vfc_name) == 0)
> error = VOP_COPY_FILE_RANGE(invp, inoffp, outvp, outoffp,
> lenp, flags, incred, outcred, fsize_td);
> else
>
>
->mnt_vfc is global per filesystem code, so this strcmp does not make
any sense. mere comparison to mnt_vfc will do it.
--
Mateusz Guzik
_mount->mnt_vfc->vfc_name,
> - outvp->v_mount->mnt_vfc->vfc_name) == 0)
> + if (inmp == outmp || strcmp(inmp->mnt_vfc->vfc_name,
> + outmp->mnt_vfc->vfc_name) == 0)
> error = VOP_COPY_FILE_RANGE(invp, inoffp, outvp, outoffp,
> lenp, flags, incred, outcred, fsize_td);
> else
>
>
->mnt_vfc is global per filesystem code, so this strcmp does not make
any sense. mere comparison to mnt_vfc will do it.
--
Mateusz Guzik
On 11/14/23, Artem Savkov wrote:
> On Tue, Oct 24, 2023 at 07:59:18PM +0200, Mateusz Guzik wrote:
>> For the thread to start executing ->mm has to be set.
>>
>> Although I do find it plausible there maybe a corner case during
>> kernel bootstrap and it may be tha
On 11/7/23, Kent Overstreet wrote:
> On Sun, Nov 05, 2023 at 01:38:49PM +0100, Mateusz Guzik wrote:
>> Setup is a 24 core vm + 24G of ram, running debian 12 with top of
>> master as of writing this e-mail, commit being:
>> commit 1c41041124bd14dd6610da256a3da4e5b74ce6b1 (HEAD
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=733a66841d70c6934f073d227db10678d6ef5226
commit 733a66841d70c6934f073d227db10678d6ef5226
Author: Mateusz Guzik
AuthorDate: 2023-11-06 15:38:06 +
Commit: Mateusz Guzik
CommitDate: 2023-11-06 15:39
The branch main has been updated by mjg:
URL:
https://cgit.FreeBSD.org/src/commit/?id=733a66841d70c6934f073d227db10678d6ef5226
commit 733a66841d70c6934f073d227db10678d6ef5226
Author: Mateusz Guzik
AuthorDate: 2023-11-06 15:38:06 +
Commit: Mateusz Guzik
CommitDate: 2023-11-06 15:39
On 11/6/23, Kent Overstreet wrote:
> On Sun, Nov 05, 2023 at 11:16:15PM +0100, Mateusz Guzik wrote:
>> On 11/5/23, Mateusz Guzik wrote:
>> > On 11/5/23, Kent Overstreet wrote:
>> >> On Sun, Nov 05, 2023 at 09:27:15PM +0100, Mateusz Guzik wrote:
>> &g
On 11/5/23, Mateusz Guzik wrote:
> On 11/5/23, Kent Overstreet wrote:
>> On Sun, Nov 05, 2023 at 09:27:15PM +0100, Mateusz Guzik wrote:
>>> On 11/5/23, Kent Overstreet wrote:
>>> > On Sun, Nov 05, 2023 at 08:57:53PM +0100, Mateusz Guzik wrote:
>>>
1 - 100 of 1100 matches
Mail list logo
