> On 2022/10/18 10:45, Zhang Qilong wrote:
> > In the following case:
> > process 1 process 2
> > ->open A
> >->mmap
> > ->read # the first time
> > ->ioctl w/h F2FS_IOC_MOVE_RANGE
> > # (ra
Yangtao,
On 2022/10/18 15:46, Yangtao Li wrote:
Added a new sysfs node called gc_urgent_mid_remaining. The user can
set the trial count limit for GC urgent mid mode with this value. If
GC thread gets to the limit, the mode will turn back to GC normal mode.
Not sure, we will add gc_urgent_low_r
Chao,
> Not sure, we will add gc_urgent_low_remaining later...
> Can we share the same interface for all gc_mode? since each mode is exclusive.
> Thoughts?
Both GC urgent mid mode and GC urgent high mode run using the urgent_sleep_time
interval. If the user program does not switch back to norm
On 2022/10/18 15:32, Yang Yingliang wrote:
Inject fault while probing module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback functio
On 2022/10/20 0:17, Mukesh Ojha wrote:
commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
introduces iocb field in 'f2fs_direct_IO_enter' trace event
And it only assigns the pointer and later it accesses its field
in trace print log.
Fix it by correcting data type and memcpy t
On Oct 10, 2022 / 15:15, Jaegeuk Kim wrote:
> As f2fs becomes more resilient for GCs, let's give the marginal overprovision
> space back to user.
>
> Signed-off-by: Jaegeuk Kim
Hello Jaegeuk,
Using the dev branch of f2fs-tools repo, I observed mkfs.f2fs failure with zoned
block devices:
Hi,
On 10/20/2022 2:31 PM, Chao Yu wrote:
On 2022/10/20 0:17, Mukesh Ojha wrote:
commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
introduces iocb field in 'f2fs_direct_IO_enter' trace event
And it only assigns the pointer and later it accesses its field
in trace print log.
On 2022/10/20 17:27, Mukesh Ojha wrote:
Hi,
On 10/20/2022 2:31 PM, Chao Yu wrote:
On 2022/10/20 0:17, Mukesh Ojha wrote:
commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
introduces iocb field in 'f2fs_direct_IO_enter' trace event
And it only assigns the pointer and later i
On 10/20, Shinichiro Kawasaki wrote:
> On Oct 10, 2022 / 15:15, Jaegeuk Kim wrote:
> > As f2fs becomes more resilient for GCs, let's give the marginal
> > overprovision
> > space back to user.
> >
> > Signed-off-by: Jaegeuk Kim
>
> Hello Jaegeuk,
>
> Using the dev branch of f2fs-tools repo, I
If kset_register() fails, the refcount of kobject is not 0,
the name allocated in kobject_set_name(&kset.kobj, ...) is
leaked. Fix this by calling kset_put(), so that it will be
freed in callback function kobject_cleanup().
Cc: sta...@vger.kernel.org
Fixes: a6c40b178092 ("drm/amdgpu: Show IP disco
Inject fault while loading module (e.g. qemu_fw_cfg.ko), kset_register()
may fail in kset_create_and_add(), if it fails, but the refcount of kobject
is not decreased to 0, the name allocated in kset_create() is leaked. To fix
this by calling kset_put(), so that name can be freed in callback functio
Inject fault while loading module, kset_register() may fail, if
it fails, but the refcount of kobject is not decreased to 0, the
name allocated in kobject_set_name() is leaked. To fix this by
calling kset_put(), so that name can be freed in callback function
kobject_cleanup() and 'subdir' is freed
From: Liu Shixin
When insmod ubifs.ko, a kmemleak reported as below:
unreferenced object 0x88817fb1a780 (size 8):
comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)
hex dump (first 8 bytes):
75 62 69 66 73 00 ff ff ubifs...
backtrace:
[]
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object 0xf
The previous discussion link:
https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
kset_register() is currently used in some places without calling
kset_put() in error path, because the callers think it should be
kset internal thing to do, but the driver core can not kno
Inject fault while loading module (e.g. edac_core.ko), kset_register()
may fail in bus_register(), if it fails, but the refcount of kobject is
not decreased to 0, the name allocated in kobject_set_name() is leaked.
To fix this by calling kset_put(), so that name can be freed in callback
function ko
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object 0xf
kset_register() is currently used in some places without calling
kset_put() in error path, because the callers think it should be
kset internal thing to do, but the driver core can not know what
caller doing with that memory at times. The memory could be freed
both in kset_put() and error path of c
kset_put() can be called from drivers, add null pointer
check to make it more robust.
Signed-off-by: Yang Yingliang
---
include/linux/kobject.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 57fb972fea05..e81de8ba41a2
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object 0xf
Inject fault while loading module (e.g. pktcdvd.ko), kset_register() may
fail in __class_register(), if it fails, but the refcount of kobject is
not decreased to 0, the name allocated in kobject_set_name() is leaked.
To fix this by calling kfree_const().
unreferenced object 0x888102fa8190 (siz
Currently IPU policy for fdatasync is coupled with F2FS_IPU_FSYNC.
Fix to apply it to all IPU policy.
Signed-off-by: qixiaoyu1
---
fs/f2fs/data.c | 8 +++-
fs/f2fs/file.c | 4 +++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a71e818cd6
Syzbot reports a NULL pointer dereference issue as below:
__refcount_add include/linux/refcount.h:193 [inline]
__refcount_inc include/linux/refcount.h:250 [inline]
refcount_inc include/linux/refcount.h:267 [inline]
get_task_struct include/linux/sched/task.h:110 [inline]
kthread_stop+0x34/0x1c
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #64 from Yuriy Garin (yuriy.ga...@gmail.com) ---
Running 6.0.1-arch2-1 for a few days. So far, so good!
(Previously, this problem occurred from twice a day to once in a two days.)
There were quite a lot of changes in f2fs sources in 6
On Oct 20, 2022 / 16:18, Jaegeuk Kim wrote:
...
> Thanks, I think that fix looks good to me. I applied into the original patch.
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?h=dev&id=281d3e72370f6c39c0d57acaf37a7f0e003ddd28
Oh, happy to know that the fix is goo
Hi Mukesh,
On Wed, Oct 19, 2022 at 09:47:57PM +0530, Mukesh Ojha wrote:
> commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
> introduces iocb field in 'f2fs_direct_IO_enter' trace event
> And it only assigns the pointer and later it accesses its field
> in trace print log.
>
>
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang Yingliang wrote:
> > The previous discussion link:
> > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
>
> The very first discussion on this was here:
>
> https://www.spinics.
On 2022-10-20 22:20, Yang Yingliang wrote:
> The previous discussion link:
> https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
The very first discussion on this was here:
https://www.spinics.net/lists/dri-devel/msg368077.html
Please use this link, and not the that o
28 matches
Mail list logo
