On Mon, May 15, 2017 at 11:40 PM, Daeho Jeong <daeho.jeong@xxxxxxxxxxx> wrote:
> We don't initialize resize_wait of init task now and all the kernel
> threads share this uninitialized resize_wait wait queue because they
> are sharing the file table of init task. Therefore, when expanding
> this file table shared by the kernel threads, we encounter kernel panic
> by accessing the NULL resize_wait wait queue.
>
> Signed-off-by: Daeho Jeong <daeho.jeong@xxxxxxxxxxx>
> Tested-by: Youngjin Gil <youngjin.gil@xxxxxxxxxxx>
> ---
> fs/file.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/file.c b/fs/file.c
> index ad6f094f2eff..74748c32e07a 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -475,6 +475,7 @@ struct files_struct init_files = {
> .full_fds_bits = init_files.full_fds_bits_init,
> },
> .file_lock = __SPIN_LOCK_UNLOCKED(init_files.file_lock),
> + .resize_wait = __WAIT_QUEUE_HEAD_INITIALIZER(init_files.resize_wait),
> };
>
> static unsigned int find_next_fd(struct fdtable *fdt, unsigned int start)
> --
> 2.11.0
>
Acked-by: Eric Dumazet <edumazet@xxxxxxxxxx>
Fixes: 8a81252b774b ("fs/file.c: don't acquire files->file_lock in
fd_install()")
I am curious, what kind of kernel threads are using file table ?
Thanks.
