| Message ID | 1494916832-9732-1-git-send-email-daeho.jeong@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, May 15, 2017 at 11:40 PM, Daeho Jeong <daeho.jeong@samsung.com> 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@samsung.com> > Tested-by: Youngjin Gil <youngjin.gil@samsung.com> > --- > 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@google.com> 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.
> 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 <edumazet@google.com> 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 <daeho.jeong@samsung.com> 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@samsung.com> > Tested-by: Youngjin Gil <youngjin.gil@samsung.com> > --- > 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@google.com> Fixes: 8a81252b774b ("fs/file.c: don't acquire files->file_lock in fd_install()")
On Wed, May 17, 2017 at 12:25:19AM +0000, Daeho Jeong wrote: > > 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. Sure, but WTF would they want file descriptors for that? All primitives use struct file * anyway, so...
> Sure, but WTF would they want file descriptors for that? All primitives > use struct file * anyway, so... Yes, you are right. But, I cannot control all the guys in other departments and all the other 3rd party source codes. :-(
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)