Hi,
On 5/10/2024 7:19 PM, Miklos Szeredi wrote:
> On Fri, 26 Apr 2024 at 16:38, Hou Tao wrote:
>> From: Hou Tao
>>
>> When invoking virtio_fs_enqueue_req() through kworker, both the
>> allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
>> Con
On 4/26/2024 10:39 PM, Hou Tao wrote:
> From: Hou Tao
>
> When trying to insert a 10MB kernel module kept in a virtio-fs with cache
> disabled, the following warning was reported:
>
> [ cut here ]
> WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:45
From: Hou Tao
Hi,
The patch set aims to fix the warning related to an abnormal size
parameter of kmalloc() in virtiofs. Patch #1 fixes it by introducing
use_pages_for_kvec_io option in fuse_conn and enabling it in virtiofs.
Beside the abnormal size parameter for kmalloc, the gfp parameter
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtio-fs with cache
disabled, the following warning was reported:
[ cut here ]
WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ..
Modules linked in:
CPU: 1 PID: 404 Comm: insmod Not tainted
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of the sg array may be greater than PAGE_SIZE, use
GFP_NOFS instead of GFP_ATOMIC to lower the possibility of memory
On 4/23/2024 4:06 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 09, 2024 at 09:48:08AM +0800, Hou Tao wrote:
>> Hi,
>>
>> On 4/8/2024 3:45 PM, Michael S. Tsirkin wrote:
>>> On Wed, Feb 28, 2024 at 10:41:20PM +0800, Hou Tao wrote:
>>>> From: Hou Tao
Hi,
On 4/8/2024 3:45 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 28, 2024 at 10:41:20PM +0800, Hou Tao wrote:
>> From: Hou Tao
>>
>> Hi,
>>
>> The patch set aims to fix the warning related to an abnormal size
>> parameter of kmalloc() in virtiof
Hi,
On 3/1/2024 10:24 PM, Miklos Szeredi wrote:
> On Wed, 28 Feb 2024 at 15:41, Hou Tao wrote:
>> From: Hou Tao
>>
>> Factor out more common methods for bounce buffer of fuse args:
>>
>> 1) virtio_fs_argbuf_setup_sg: set-up sgs for bounce buffer
>> 2)
Hi,
On 3/1/2024 9:42 PM, Miklos Szeredi wrote:
> On Wed, 28 Feb 2024 at 15:40, Hou Tao wrote:
>
>> So instead of limiting both the values of max_read and max_write in
>> kernel, capping the maximal length of kvec iter IO by using max_pages in
>> fuse_direct_io() just lik
Hi,
On 2/29/2024 11:01 PM, Brian Foster wrote:
> On Wed, Feb 28, 2024 at 10:41:24PM +0800, Hou Tao wrote:
>> From: Hou Tao
>>
>> When reading a file kept in virtiofs from kernel (e.g., insmod a kernel
>> module), if the cache of virtiofs is disabled, the read buffer wi
From: Hou Tao
To prevent unnecessary request for large contiguous physical memory
chunk, use bounce buffer backed by scattered pages for ITER_KVEC
direct-io read/write when the total size of its args is greater than
PAGE_SIZE.
Signed-off-by: Hou Tao
---
fs/fuse/virtio_fs.c | 78
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of the sg array may be greater than PAGE_SIZE, use
GFP_NOFS instead of GFP_ATOMIC to lower the possibility of memory
From: Hou Tao
When reading a file kept in virtiofs from kernel (e.g., insmod a kernel
module), if the cache of virtiofs is disabled, the read buffer will be
passed to virtiofs through out_args[0].value instead of pages. Because
virtiofs can't get the pages for the read buffer
From: Hou Tao
Factor out more common methods for bounce buffer of fuse args:
1) virtio_fs_argbuf_setup_sg: set-up sgs for bounce buffer
2) virtio_fs_argbuf_copy_from_in_arg: copy each in-arg to bounce buffer
3) virtio_fs_argbuf_out_args_offset: calc the start offset of out-arg
4
From: Hou Tao
The bounce buffer for fuse args in virtiofs will be extended to support
scatterd pages later. Therefore, move the allocation and the free of
argbuf out of the copy procedures and factor them into
virtio_fs_argbuf_{new|free}() helpers.
Signed-off-by: Hou Tao
---
fs/fuse
From: Hou Tao
Hi,
The patch set aims to fix the warning related to an abnormal size
parameter of kmalloc() in virtiofs. The warning occurred when attempting
to insert a 10MB sized kernel module kept in a virtiofs with cache
disabled. As analyzed in patch #1, the root cause is that the length
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtio-fs with cache
disabled, the following warning was reported:
[ cut here ]
WARNING: CPU: 2 PID: 439 at mm/page_alloc.c:4544 ..
Modules linked in:
CPU: 2 PID: 439 Comm: insmod Not tainted
Hi,
On 2/23/2024 5:42 PM, Miklos Szeredi wrote:
> On Wed, 3 Jan 2024 at 11:58, Hou Tao wrote:
>> From: Hou Tao
>>
>> When trying to insert a 10MB kernel module kept in a virtiofs with cache
>> disabled, the following warning was reported:
>
Hi,
On 2/23/2024 3:49 AM, Michael S. Tsirkin wrote:
> On Wed, Jan 03, 2024 at 06:59:29PM +0800, Hou Tao wrote:
>> From: Hou Tao
>>
>> When trying to insert a 10MB kernel module kept in a virtiofs with cache
>> disabled, the following warning was reported:
>>
Hi,
On 1/11/2024 6:34 AM, Bernd Schubert wrote:
>
>
> On 1/10/24 02:16, Hou Tao wrote:
>> Hi,
>>
>> On 1/9/2024 9:11 PM, Bernd Schubert wrote:
>>>
>>>
>>> On 1/3/24 11:59, Hou Tao wrote:
>>>> From: Hou Tao
>>>>
>
Hi,
On 1/9/2024 9:11 PM, Bernd Schubert wrote:
>
>
> On 1/3/24 11:59, Hou Tao wrote:
>> From: Hou Tao
>>
>> When trying to insert a 10MB kernel module kept in a virtiofs with cache
>> disabled, the following warning was reported:
>>
>> --
n 05, 2024 at 03:17:19PM -0500, Vivek Goyal wrote:
>>>>> On Fri, Jan 05, 2024 at 06:53:05PM +0800, Hou Tao wrote:
>>>>>> From: Hou Tao
>>>>>>
>>>>>> When invoking virtio_fs_enqueue_req() through kworker, both the
>>>>>&
On 1/6/2024 4:21 AM, Matthew Wilcox wrote:
> On Fri, Jan 05, 2024 at 03:17:19PM -0500, Vivek Goyal wrote:
>> On Fri, Jan 05, 2024 at 06:53:05PM +0800, Hou Tao wrote:
>>> From: Hou Tao
>>>
>>> When invoking virtio_fs_enqueue_req() through kworker, bot
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of both the sg array and the bounce buffer may be
greater than PAGE_SIZE, use GFP_NOFS instead of GFP_ATOMIC to lower
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of both the sg array and the bounce buffer may be
greater than PAGE_SIZE, use GFP_NOFS instead of GFP_ATOMIC to lower
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtiofs with cache
disabled, the following warning was reported:
[ cut here ]
WARNING: CPU: 2 PID: 439 at mm/page_alloc.c:4544 ..
Modules linked in:
CPU: 2 PID: 439 Comm: insmod Not tainted
Hi,
On 12/25/2023 7:36 PM, Philo Lu wrote:
> On 2023/12/23 21:02, Philo Lu wrote:
>>
>>
>> On 2023/12/23 19:22, Hou Tao wrote:
>>> Hi,
>>>
>>> On 12/22/2023 8:21 PM, Philo Lu wrote:
>>>> BPF_MAP_TYPE_RELAY is implemented based on relay i
Hi,
On 12/22/2023 8:21 PM, Philo Lu wrote:
> map_update_elem is used to create relay files and bind them with the
> relay channel, which is created with BPF_MAP_CREATE. This allows users
> to set a custom directory name. It must be used with key=NULL and
> flag=0.
>
> Here is an example:
> ```
>
Hi,
On 12/22/2023 8:21 PM, Philo Lu wrote:
> BPF_MAP_TYPE_RELAY is implemented based on relay interface, which
> creates per-cpu buffer to transfer data. Each buffer is essentially a
> list of fix-sized sub-buffers, and is exposed to user space as files in
> debugfs. attr->max_entries is used as
Hi,
On 12/21/2023 1:50 AM, Yonghong Song wrote:
>
> On 12/20/23 1:19 AM, Hou Tao wrote:
>> Hi,
>>
>> On 12/14/2023 11:40 AM, xingwei lee wrote:
>>> Hello I found a bug in net/bpf in the lastest upstream linux and
>>> comfired in the lastest net tree
Hi,
On 12/14/2023 11:40 AM, xingwei lee wrote:
> Hello I found a bug in net/bpf in the lastest upstream linux and
> comfired in the lastest net tree and lastest net bpf titled BUG:
> unable to handle kernel paging request in bpf_probe_read_compat_str
>
> If you fix this issue, please add the
Hi,
On 12/11/2023 4:12 PM, xingwei lee wrote:
> Sorry for containing HTML part, repeat the mail
> Hello I found a bug in net/bpf in the lastest upstream linux and
> lastest net tree.
> WARNING: kmalloc bug in bpf_uprobe_multi_link_attach
>
> kernel: net 28a7cb045ab700de5554193a1642917602787784
>
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 0d7202876bcb968a68f5608b9ff7a824fbc7e94d
Gitweb:
https://git.kernel.org/tip/0d7202876bcb968a68f5608b9ff7a824fbc7e94d
Author:Hou Tao
AuthorDate:Thu, 24 Sep 2020 22:18:54 +08:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: e5ace37d83af459bd491847df570b6763c602344
Gitweb:
https://git.kernel.org/tip/e5ace37d83af459bd491847df570b6763c602344
Author:Hou Tao
AuthorDate:Fri, 18 Sep 2020 19:44:24 +08:00
Committer
Hi,
On 2020/10/29 0:29, Casey Schaufler wrote:
> On 10/27/2020 7:06 PM, Chen Jun wrote:
>> From: Chen Jun
>>
>> Kmemleak will report a problem after using
>> "echo 1 > /sys/fs/selinux/disable" to disable selinux on runtime.
>
> Runtime disable of SELinux has been deprecated. It would be
>
called.
Signed-off-by: Hou Tao
---
v2: add init_called field in lock_torture_cxt instead of reusing
cxt->cur_ops for error handling
kernel/locking/locktorture.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/kernel/locking/locktorture.
Hi Will & Ard,
+to Ard Biesheuvel for the "regression" caused by
91fc957c9b1d6
("arm64/bpf: don't allocate BPF JIT programs in module memory")
On 2020/9/17 16:48, Will Deacon wrote:
> On Wed, Sep 16, 2020 at 08:32:20PM +0800, Hou Tao wrote:
>>> Subject: loc
ule exits.
>>
>> Also needs to call exit hook if lock_torture_init() fails half-way,
>> so use ctx->cur_ops != NULL to signal that init hook has been called.
>
> Good catch, but please see below for comments and questions.
>
>> Signe
Hi Paul,
On 2020/9/19 1:59, Paul E. McKenney wrote:
> On Fri, Sep 18, 2020 at 07:44:24PM +0800, Hou Tao wrote:
>> When do locktorture for exclusive lock which doesn't have readlock
>> support, the following module parameters will be considered as valid:
>>
>&g
reject these parameters by returning
-EINVAL during module init.
Signed-off-by: Hou Tao
---
kernel/locking/locktorture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 9cfa5e89cff7f..bebdf98e6cd78 100644
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: e6b1a44eccfcab5e5e280be376f65478c3b2c7a2
Gitweb:
https://git.kernel.org/tip/e6b1a44eccfcab5e5e280be376f65478c3b2c7a2
Author:Hou Tao
AuthorDate:Tue, 15 Sep 2020 22:07:50 +08:00
Committer
Hi Paul,
On 2020/9/18 0:58, Paul E. McKenney wrote:
> On Thu, Sep 17, 2020 at 09:59:09PM +0800, Hou Tao wrote:
>> To ensure there is always at least one locking thread.
>>
>> Signed-off-by: Hou Tao
>> ---
>> kernel/locking/locktorture.c | 3 ++-
>> 1 fi
Hou Tao (2):
locktorture: doesn't check nreaders_stress when no readlock support
locktorture: call percpu_free_rwsem() to do percpu-rwsem cleanup
kernel/locking/locktorture.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
--
2.25.0.4.g0ad7144999
To ensure there is always at least one locking thread.
Signed-off-by: Hou Tao
---
kernel/locking/locktorture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 9cfa5e89cff7f..bebdf98e6cd78 100644
--- a/kernel
ned-off-by: Hou Tao
---
kernel/locking/locktorture.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index bebdf98e6cd78..e91033e9b6f95 100644
--- a/kernel/locking/locktorture.c
+++ b/ker
wsem: Use this_cpu_{inc,dec}() for read_count
> From: Hou Tao
> Date: Tue, 15 Sep 2020 22:07:50 +0800
>
> From: Hou Tao
>
> The __this_cpu*() accessors are (in general) IRQ-unsafe which, given
> that percpu-rwsem is a blocking primitive, should be just fine.
>
&
it by using the IRQ-safe helper this_cpu_inc|dec() for
operations on read_count.
Another plausible fix is to state that percpu-rwsem can NOT be
used under IRQ context and convert all users which may
use it under IRQ context.
Signed-off-by: Hou Tao
---
include/linux/percpu-rwsem.h | 8
kernel
Hi,
Cc +Richard +David
On 2020/1/6 16:04, zhangyi (F) wrote:
> After commit 4fdcfab5b553 ("jffs2: fix use-after-free on symlink
> traversal"), it expose a freeing uninitialized memory problem due to
> this commit move the operaion of freeing f->target to
> jffs2_i_callback(), which may not be
Reviewed-by: Hou Tao
On 2020/6/19 17:06, Zhe Li wrote:
> The log of UAF problem is listed below.
> BUG: KASAN: use-after-free in jffs2_rmdir+0xa4/0x1cc [jffs2] at addr c1f165fc
> Read of size 4 by task rm/8283
> ===
Hi,
On 2020/6/9 12:07, Josh Snyder wrote:
> Previously, io_ticks could be under-counted. Consider these I/Os along
> the time axis (in jiffies):
>
> t 012345678
> io1||
> io2|---|
>
> Under the old approach, io_ticks would count up to 6, like so:
>
> t
Hi Richard,
On 2019/9/20 22:38, Richard Weinberger wrote:
> On Fri, Sep 20, 2019 at 4:14 PM Xiaoming Ni wrote:
>> I still think this is easier to understand:
>> Free the memory allocated by the current function in the failed branch
>
> Please note that jffs2 is in "odd fixes only" maintenance
It's just code clean-up.
Signed-off-by: Hou Tao
---
drivers/md/raid1.c | 39 ++-
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 1755d2233e4d..d73ed94764c1 100644
--- a/drivers/md/raid1.c
+++ b
Using a sector_t as the return value is misleading, because
raise_barrier() only return 0 or -EINTR.
Also add comments for the return values of raise_barrier().
Signed-off-by: Hou Tao
---
drivers/md/raid1.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid1
ping ?
On 2019/4/19 16:48, Hou Tao wrote:
> After extending the size of dentry from 192-bytes to 208-bytes
> under aarch64, we got oops during the running of xfstests generic/429:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0002
>
_flags & d_inode
are consistent, and lookup_slow() use inode lock to ensure that, so only
the REF-walk path in lookup_fast() is problematic.
Fixing it by adding a paired smp_rmb/smp_wmb between the reading/writing
of d_inode & d_flags to ensure the consistency.
Signed-off-by: Hou Tao
---
fs/dca
arly when any stage of fsync fails.
Signed-off-by: Hou Tao
---
fs/fat/file.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/fat/file.c b/fs/fat/file.c
index b3bed32946b1..0e3ed79fcc3f 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -193,12 +193,17 @@ static
Hi,
Cc Andrew for patch inclusion
On 2019/4/6 0:27, Matthew Wilcox wrote:
> On Fri, Apr 05, 2019 at 02:52:17PM +0800, Hou Tao wrote:
>> We have got KASAN splat when tried to set /proc/sys/fs/file-max:
>
> Matteo Croce already has a patch in-flight for this.
>
>
Yes,
to be set the minimal value of file-max to be 1,
so one_ul can be used instead, but I'm not sure whether or not a file-max
with a value of zero has special purpose (e.g., prohibit the file-related
activities of all no-privileged users).
Signed-off-by: Hou Tao
---
kernel/sysctl.c | 2 +-
1 file
ping ?
On 2019/3/1 18:09, Hou Tao wrote:
> ping ?
>
> On 2019/2/25 17:03, Hou Tao wrote:
>> Taking an extra file reference before call vfs_poll(), else
>> the file may be released by aio_poll_wake() if an expected
>> event is triggered immediately (e.g., by the close o
ping ?
On 2019/2/25 17:03, Hou Tao wrote:
> Taking an extra file reference before call vfs_poll(), else
> the file may be released by aio_poll_wake() if an expected
> event is triggered immediately (e.g., by the close of a
> pair of pipes) after the return of vfs_poll(), and we may
ll of jffs2_set_inocache_state() under
erase_completion_lock, else the inocache may be leaked because
jffs2_del_ino_cache() invoked by jffs2_remove_node_refs_from_ino_list()
may find the state of inocache is still INO_STATE_CHECKING and will
not free the inocache.
Cc: sta...@vger.kernel.org
edly pushing back a jeb (has newly-creating
inodes) and picking up a new jeb (also has newly-creating inodes
and may be the same jeb) when there are many file creation threads.
Fixes: e72e6497e748 ("jffs2: Fix NFS race by using insert_inode_locked()")
Cc: sta...@vger.kernel.org
Reported-by
des in use")
Cc: sta...@vger.kernel.org
Signed-off-by: Hou Tao
---
fs/jffs2/readinode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index 389ea53ea487..0bae0583106e 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
So jffs2_do_clear_inode() could mark all flash nodes used by
the inode as obsolete and GC procedure will reclaim these
flash nodes, else these flash spaces will not be reclaimable
forever.
Cc: sta...@vger.kernel.org
Signed-off-by: Hou Tao
---
fs/jffs2/dir.c | 28
1
, and then removing these files, and repeating.
Comments are welcome.
Hou
Hou Tao (2):
jffs2: reset pino_nlink to 0 when inode creation failed
jffs2: handle INO_STATE_CLEARING in jffs2_do_read_inode()
fs/jffs2/dir.c | 28
fs/jffs2/readinode.c | 1 +
2
ping ?
On 2019/2/10 17:47, Hou Tao wrote:
> Now splice() on O_DIRECT-opened fat file will return -EFAULT, that is
> because the default .splice_write, namely default_file_splice_write(),
> will construct an ITER_KVEC iov_iter and dio_refill_pages() in dio path
> can not handle
iter_file_splice_write().
Spotted by xfs-tests generic/091.
Signed-off-by: Hou Tao
---
fs/fat/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 13935ee99e1e..b3bed32946b1 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -214,6 +214,7 @@ const struct file_operations
Hi,
On 2019/1/9 10:38, Dominique Martinet wrote:
> Hou Tao wrote on Wed, Jan 09, 2019:
>> Use inode->i_lock to protect i_size_write(), else i_size_read() in
>> generic_fillattr() may loop infinitely when multiple processes invoke
>> v9fs_vfs_getattr() or v9fs_vfs_getat
c>] (vfs_getattr_nosec) from [<802b895c>] (vfs_getattr+0x44/0x48)
[<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec)
[<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78)
[<802b93e0>] (sys_lstat64) from [<80101000>] (
On 2018/12/16 0:23, Richard Weinberger wrote:
> The rtime compressor assumes that at least two bytes are
> compressed.
> If we try to compress just one byte, the loop condition will
> wrap around and an out-of-bounds write happens.
>
> Cc:
> Signed-off-by: Richard Weinberger
> ---
>
P_FS)) && oc->chosen &&
> + oc->chosen != (void *)-1UL && oc->chosen != current) {
> + put_task_struct(oc->chosen);
> + return true;
> + }
> +
> /* Found nothing?!?! */
> if (!oc
Hi,
On 2018/12/15 22:38, Matthew Wilcox wrote:
> On Tue, Dec 04, 2018 at 10:08:40AM +0800, Hou Tao wrote:
>> There is no need to disable __GFP_FS in ->readpage:
>> * It's a read-only fs, so there will be no dirty/writeback page and
>> there will be no deadlock against
ping ?
On 2018/12/13 10:18, Hou Tao wrote:
> ping ?
>
> On 2018/12/6 9:14, Hou Tao wrote:
>> ping ?
>>
>> On 2018/12/4 10:08, Hou Tao wrote:
>>> There is no need to disable __GFP_FS in ->readpage:
>>> * It's a read-o
ping ?
On 2018/12/9 14:35, Hou Tao wrote:
> ping ?
>
> On 2018/10/20 20:08, Hou Tao wrote:
>> Now MTD emulated by UBI volumn doesn't allocate wbuf_verify in
>> jffs2_ubivol_setup(), because UBI can do the verifcation itself,
>> so when CONFIG_JFFS2_FS_WBUF_VERIFY
ping ?
On 2018/12/9 14:21, Hou Tao wrote:
> For xattr modification, we do not write a new jffs2_raw_xref with
> delete marker into flash, so if a xattr is modified then removed,
> and the old xref & xdatum are not erased by GC, after reboot or
> remount, the new xattr x
On 2018/12/14 5:53, Richard Weinberger wrote:
> On Sun, Dec 9, 2018 at 7:52 AM Boris Brezillon
> wrote:
>>
>> On Sat, 20 Oct 2018 19:07:53 +0800
>> Hou Tao wrote:
>>
>>> When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid
>>
ping ?
On 2018/12/6 9:14, Hou Tao wrote:
> ping ?
>
> On 2018/12/4 10:08, Hou Tao wrote:
>> There is no need to disable __GFP_FS in ->readpage:
>> * It's a read-only fs, so there will be no dirty/writeback page and
>> there will be no deadlock against the cal
ping ?
On 2018/10/20 19:07, Hou Tao wrote:
> When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid
> because these fields will be reused as xref->ino or xref->xid,
> so access xref->ic->ino or xref->xd->xid will lead to Oops.
>
&
ping ?
On 2018/10/20 20:08, Hou Tao wrote:
> Now MTD emulated by UBI volumn doesn't allocate wbuf_verify in
> jffs2_ubivol_setup(), because UBI can do the verifcation itself,
> so when CONFIG_JFFS2_FS_WBUF_VERIFY is enabled and a MTD device
> emulated by UBI volumn is used, a Oop
get the overwritten xattr instead of
non-existent error when reading the removed xattr.
Fix it by writing the deletion mark for xattr overwrite.
Fixes: 8a13695cbe4e ("[JFFS2][XATTR] rid unnecessary writing of delete marker.")
Signed-off-by: Hou Tao
---
fs/jffs
ping ?
On 2018/12/4 10:08, Hou Tao wrote:
> There is no need to disable __GFP_FS in ->readpage:
> * It's a read-only fs, so there will be no dirty/writeback page and
> there will be no deadlock against the caller's locked page
> * It just allocates one page, so compaction will
ping ?
On 2018/12/4 10:08, Hou Tao wrote:
> There is no need to disable __GFP_FS in ->readpage:
> * It's a read-only fs, so there will be no dirty/writeback page and
> there will be no deadlock against the caller's locked page
> * It just allocates one page, so compaction will
ion of inode will be fine
And no __GFP_FS may lead to hang in __alloc_pages_slowpath() if a
squashfs page fault occurs in the context of a memory hogger, because
the hogger will not be killed due to the logic in __alloc_pages_may_oom().
Signed-off-by: Hou Tao
---
fs/squashfs/file.c |
ion of inode will be fine
And no __GFP_FS may lead to hang in __alloc_pages_slowpath() if a
squashfs page fault occurs in the context of a memory hogger, because
the hogger will not be killed due to the logic in __alloc_pages_may_oom().
Signed-off-by: Hou Tao
---
fs/squashfs/file.c |
3ad30970ff..cae4ecda3c50 100644
> --- a/fs/jffs2/super.c
> +++ b/fs/jffs2/super.c
> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
> struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>
> #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> - cancel_delayed_work_sync(
3ad30970ff..cae4ecda3c50 100644
> --- a/fs/jffs2/super.c
> +++ b/fs/jffs2/super.c
> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
> struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>
> #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> - cancel_delayed_work_sync(
using it in jffs2_verify_write().
Cc: sta...@vger.kernel.org
Fixes: 0029da3bf430 ("JFFS2: add UBI support")
Signed-off-by: Hou Tao
---
fs/jffs2/wbuf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index c6821a509481..3de45f4559d1 10064
using it in jffs2_verify_write().
Cc: sta...@vger.kernel.org
Fixes: 0029da3bf430 ("JFFS2: add UBI support")
Signed-off-by: Hou Tao
---
fs/jffs2/wbuf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index c6821a509481..3de45f4559d1 10064
When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid
because these fields will be reused as xref->ino or xref->xid,
so access xref->ic->ino or xref->xd->xid will lead to Oops.
Fix the problem by checking whether or not it is a dead xref.
Signed-off-by
necessary writing of delete marker.")
Signed-off-by: Hou Tao
---
fs/jffs2/xattr.c | 61 +++-
fs/jffs2/xattr.h | 8 +++-
2 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c
index da3e18503c6
When jffs2_xattr_ref is dead, xref->ic or xref->xd will be invalid
because these fields will be reused as xref->ino or xref->xid,
so access xref->ic->ino or xref->xd->xid will lead to Oops.
Fix the problem by checking whether or not it is a dead xref.
Signed-off-by
necessary writing of delete marker.")
Signed-off-by: Hou Tao
---
fs/jffs2/xattr.c | 61 +++-
fs/jffs2/xattr.h | 8 +++-
2 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c
index da3e18503c6
On 2018/10/16 14:41, Richard Weinberger wrote:
> On Tue, Oct 16, 2018 at 7:53 AM Hou Tao wrote:
>>
>> ping ?
>>
>> On 2018/10/6 17:09, Hou Tao wrote:
>>> When an invalid mount option is passed to jffs2, jffs2_parse_options()
>>> will fail and jffs2_
On 2018/10/16 14:41, Richard Weinberger wrote:
> On Tue, Oct 16, 2018 at 7:53 AM Hou Tao wrote:
>>
>> ping ?
>>
>> On 2018/10/6 17:09, Hou Tao wrote:
>>> When an invalid mount option is passed to jffs2, jffs2_parse_options()
>>> will fail and jffs2_
ping ?
On 2018/10/6 17:09, Hou Tao wrote:
> When an invalid mount option is passed to jffs2, jffs2_parse_options()
> will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
> be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
>
> Fix it by rem
ping ?
On 2018/10/6 17:09, Hou Tao wrote:
> When an invalid mount option is passed to jffs2, jffs2_parse_options()
> will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
> be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
>
> Fix it by rem
.
Cc: sta...@kernel.org
Signed-off-by: Hou Tao
---
fs/jffs2/super.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 87bdf0f4cba1..902a7dd10e5c 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -285,10 +285,8 @@ static int
.
Cc: sta...@kernel.org
Signed-off-by: Hou Tao
---
fs/jffs2/super.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 87bdf0f4cba1..902a7dd10e5c 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -285,10 +285,8 @@ static int
Hi all,
We are testing the patches for Spectre and Meltdown under OS derived from RH7.2,
and hit by a hard LOCKUP panic under a x86_64 host environment.
The hard LOCKUP can be reproduced, and it will gone if we disable ibpb by
writing 0 to ibpb_enabled file, and it will appear again when we
Hi all,
We are testing the patches for Spectre and Meltdown under OS derived from RH7.2,
and hit by a hard LOCKUP panic under a x86_64 host environment.
The hard LOCKUP can be reproduced, and it will gone if we disable ibpb by
writing 0 to ibpb_enabled file, and it will appear again when we
1 - 100 of 140 matches
Mail list logo
