From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.samsung.com ([203.254.224.24]:60459 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbdEQAZY (ORCPT ); Tue, 16 May 2017 20:25:24 -0400 Received: from epcas1p1.samsung.com (unknown [182.195.41.45]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20170517002521epoutp011bd6578a5f5b73ee5aff212a504a195c~-PQuxLy361934119341epoutp01S for ; Wed, 17 May 2017 00:25:21 +0000 (GMT) Mime-Version: 1.0 Subject: RE: Re: [PATCH] fs: initialize resize_wait wait queue of init task Reply-To: daeho.jeong@samsung.com From: Daeho Jeong To: Eric Dumazet , Daeho Jeong CC: "mguzik@redhat.com" , Al Viro , "linux-fsdevel@vger.kernel.org" In-Reply-To: Message-ID: <20170517002519epcms1p31ef6730545cfb4652beab890a047805a@epcms1p3> Date: Wed, 17 May 2017 00:25:19 +0000 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" References: <1494916832-9732-1-git-send-email-daeho.jeong@samsung.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > I am curious, what kind of kernel threads are using file table ? > Thanks. I don't know all the cases of that. But, in the embedded world, a lot of device drivers or kernel daemons are opening the files to just watch and read, or to write some log data.   --------- Original Message --------- Sender : Eric Dumazet  Date : 2017-05-16 23:10 (GMT+9) Title : Re: [PATCH] fs: initialize resize_wait wait queue of init task   On Mon, May 15, 2017 at 11:40 PM, Daeho Jeong  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  > 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 >   Acked-by: Eric Dumazet  Fixes: 8a81252b774b ("fs/file.c: don't acquire files->file_lock in fd_install()")