Hi,
在 2024/01/25 15:57, Yu Kuai 写道:
Hi,
在 2024/01/25 15:51, Xiao Ni 写道:
On Wed, Jan 24, 2024 at 5:19 PM Yu Kuai wrote:
The new heleprs will be used in dm-raid in later patches to fix
regressions and prevent calling md_reap_sync_thread() directly.
Signed-off-by: Yu Kuai
---
drivers/md/md
Hello, Linus.
On Thu, Jan 25, 2024 at 11:51:28AM -0800, Linus Torvalds wrote:
...
> So we could have a per-cpu 'atomic_wq' that things can be scheduled
> on, and that runs from softirqs just like tasklets, and shares the
> workqueue queueing infrastructure but doesn't use the workqueue
> threads.
Hi Xiao,
On Thu, Jan 25, 2024 at 5:33 AM Xiao Ni wrote:
>
> Hi all
>
> I build the kernel 6.7.0-rc8 with this patch set. The lvm2 regression
> test result:
I believe the patchset is built on top of upstream (6.8-rc1). There are
quite some md and dm changes between 6.7-rc8 and 6.8-rc1. Could
you
On 1/26/24 07:04, Mikulas Patocka wrote:
>
>
> On Thu, 25 Jan 2024, Linus Torvalds wrote:
>
>> On Thu, 25 Jan 2024 at 10:30, Mikulas Patocka wrote:
>>>
>>> There's a problem with the tasklet API - there is no reliable way how to
>>> free a structure that contains tasklet_struct. The problem is
On Thu, Jan 25, 2024 at 7:51 PM Linus Torvalds
wrote:
>
> On Thu, 25 Jan 2024 at 10:30, Mikulas Patocka wrote:
> >
> > There's a problem with the tasklet API - there is no reliable way how to
> > free a structure that contains tasklet_struct. The problem is that the
> > function tasklet_action_co
On Thu, 25 Jan 2024, Linus Torvalds wrote:
> On Thu, 25 Jan 2024 at 10:30, Mikulas Patocka wrote:
> >
> > There's a problem with the tasklet API - there is no reliable way how to
> > free a structure that contains tasklet_struct. The problem is that the
> > function tasklet_action_common calls
On Thu, 25 Jan 2024 at 10:30, Mikulas Patocka wrote:
>
> There's a problem with the tasklet API - there is no reliable way how to
> free a structure that contains tasklet_struct. The problem is that the
> function tasklet_action_common calls task_unlock(t) after it called the
> callback. If the ca
Hi
There's a problem with the tasklet API - there is no reliable way how to
free a structure that contains tasklet_struct. The problem is that the
function tasklet_action_common calls task_unlock(t) after it called the
callback. If the callback does something that frees tasklet_struct,
task_unlock
On Wed, Jan 17, 2024 at 5:56 PM Yu Kuai wrote:
>
[...]
> >
> >
> > Signed-off-by: Mikulas Patocka
> > Fixes: ca294b34aaf3 ("md/raid1: support read error check")
>
> LGTM
> Reviewed-by: Yu Kuai
Applied patch 7 to md-6.8 branch.
Thanks,
Song
Now that all callers pass in GFP_KERNEL to blkdev_zone_mgmt() and use
memalloc_no{io,fs}_{save,restore}() to define the allocation scope, we can
drop the gfp_mask parameter from blkdev_zone_mgmt() as well as
blkdev_zone_reset_all() and blkdev_zone_reset_all_emulated().
Signed-off-by: Johannes Thum
Guard the calls to blkdev_zone_mgmt() with a memalloc_nofs scope.
This helps us getting rid of the GFP_NOFS argument to blkdev_zone_mgmt();
Signed-off-by: Johannes Thumshirn
---
fs/f2fs/segment.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/segment
Guard the calls to blkdev_zone_mgmt() with a memalloc_noio scope.
This helps us getting rid of the GFP_NOIO argument to blkdev_zone_mgmt();
Signed-off-by: Johannes Thumshirn
---
drivers/md/dm-zoned-metadata.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-z
Add a memalloc_nofs scope around all calls to blkdev_zone_mgmt(). This
allows us to further get rid of the GFP_NOFS argument for
blkdev_zone_mgmt().
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/zoned.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
di
Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
zonefs_zone_mgmt().
As as zonefs_zone_mgmt() and zonefs_inode_zone_mgmt() are never called
from a place that can recurse back into the filesystem on memory reclaim,
it is save to call blkdev_zone_mgmt() with GFP_KERNEL.
Link: h
Fueled by the LSFMM discussion on removing GFP_NOFS initiated by Willy,
I've looked into the sole GFP_NOFS allocation in zonefs. As it turned out,
it is only done for zone management commands and can be removed.
After digging into more callers of blkdev_zone_mgmt() I came to the
conclusion that th
Hi all
I build the kernel 6.7.0-rc8 with this patch set. The lvm2 regression
test result:
### failed: [ndev-vanilla] shell/integrity.sh
### failed: [ndev-vanilla] shell/lvchange-partial-raid10.sh
### failed: [ndev-vanilla] shell/lvchange-raid-transient-failures.sh
### faile
Hi,
在 2024/01/25 19:52, Xiao Ni 写道:
On Thu, Jan 25, 2024 at 7:42 PM Yu Kuai wrote:
Hi,
在 2024/01/25 19:35, Xiao Ni 写道:
Hi all
This is the result of lvm2 tests:
make check
### 426 tests: 319 passed, 74 skipped, 0 timed out, 5 warned, 28
failed in 56:04.914
Are you testing with this patc
On Thu, Jan 25, 2024 at 7:42 PM Yu Kuai wrote:
>
> Hi,
>
> 在 2024/01/25 19:35, Xiao Ni 写道:
> > Hi all
> >
> > This is the result of lvm2 tests:
> > make check
> > ### 426 tests: 319 passed, 74 skipped, 0 timed out, 5 warned, 28
> > failed in 56:04.914
>
> Are you testing with this patchset? 28 f
Hi,
在 2024/01/25 19:35, Xiao Ni 写道:
Hi all
This is the result of lvm2 tests:
make check
### 426 tests: 319 passed, 74 skipped, 0 timed out, 5 warned, 28
failed in 56:04.914
Are you testing with this patchset? 28 failed is much more than my
test result in following:
### 426 tests: 346 passe
Hi,
在 2024/01/25 19:35, Xiao Ni 写道:
Hi all
This is the result of lvm2 tests:
make check
### 426 tests: 319 passed, 74 skipped, 0 timed out, 5 warned, 28
failed in 56:04.914
Are you testing with this patchset? 28 failed is much more than my
test result in following:
make[1]: *** [Makefile:
Hi all
This is the result of lvm2 tests:
make check
### 426 tests: 319 passed, 74 skipped, 0 timed out, 5 warned, 28
failed in 56:04.914
make[1]: *** [Makefile:138: check] Error 1
make[1]: Leaving directory '/root/lvm2/test'
make: *** [Makefile:89: check] Error 2
Do you know where to check whic
21 matches
Mail list logo
