lkml.org 
[lkml]   [2020]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: [PATCH] early init: open /dev/console with O_LARGEFILE
On Wed, Jan 1, 2020 at 10:32 AM Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> Also, this shouldn't impact the current issue I think, but won't doing
> filp_open followed by 3 f_dupfd's cause the file->f_count to become 4
> but with only 3 open fd's? Don't we have to do an fd_install for the
> first one and only 2 f_dupfd's?

I think *this* is the real reason for the odd regression.

Because we're leaking a file count, the original /dev/console stays
open, and we end up never calling file->f_op->release().

So we don't call tty_release() on that original /dev/console open, and
one effect of that is that we never then call session_clear_tty(),
which should make sure that all the processes in that session ID have
their controlling tty (signal->tty pointer) cleared.

And if that original controlling tty wasn't cleared, then subsequent
calls to set the controlling tty won't do anything, and who knows what
odd session leader confusion we might have.

youling, can you check if - instead of the revert - this simple 'add
an fput' fixes your warning.

I'm not saying that the revert is wrong at this point, but honestly,
I'd like to avoid the "we revert because we didn't understand what
went wrong". It would be good to go "Aaaahhhh, _that_ was the
problem".

Linus
init/main.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/init/main.c b/init/main.c
index 1ecfd43ed464..7b3accbd2211 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1171,6 +1171,8 @@ void console_on_rootfs(void)
if (f_dupfd(i, file, 0) != i)
goto err_out;
}
+ /* put the original ref from filp_open, f_dupfd() has installed new ones */
+ fput(file);

return;
\
 
 \ /
  Last update: 2020-01-01 22:41    [W:0.090 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site