From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout4.samsung.com ([203.254.224.34]:40593 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbdEPGuc (ORCPT ); Tue, 16 May 2017 02:50:32 -0400 Received: from epcas1p1.samsung.com (unknown [182.195.41.45]) by mailout4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OQ101K4V97J9520@mailout4.samsung.com> for linux-fsdevel@vger.kernel.org; Tue, 16 May 2017 15:40:31 +0900 (KST) From: Daeho Jeong To: edumazet@google.com, mguzik@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org Cc: Daeho Jeong Subject: [PATCH] fs: initialize resize_wait wait queue of init task Date: Tue, 16 May 2017 15:40:32 +0900 Message-id: <1494916832-9732-1-git-send-email-daeho.jeong@samsung.com> References: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 Tested-by: Youngjin Gil --- 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