2017-11-06 18:11:51 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:14 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-08 18:51:30 +01:00
|
|
|
|
2017-02-08 18:51:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-24 07:44:08 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-06 10:07:36 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-25 14:58:42 -07:00
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2010-09-16 18:21:24 +01:00
|
|
|
|
2011-06-16 14:07:22 +02:00
|
|
|
|
2018-09-11 19:47:09 -04:00
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2018-08-16 11:47:53 -04:00
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-18 23:40:14 -07:00
|
|
|
|
2021-04-08 14:51:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-07-12 22:49:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:38:44 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:38:44 -08:00
|
|
|
|
|
|
|
|
|
2016-01-10 22:41:07 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:35:18 -08:00
|
|
|
|
2006-03-23 03:00:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2017-07-03 06:39:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2016-01-09 21:13:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-09 21:13:46 -08:00
|
|
|
|
2014-11-21 13:42:29 +01:00
|
|
|
|
2021-12-20 15:32:50 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-24 07:48:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
2010-08-24 07:48:34 +03:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-18 21:27:47 -08:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2015-03-31 15:55:59 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-03-31 15:55:58 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:12 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:09 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:18 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:55 -05:00
|
|
|
|
2023-07-12 10:58:30 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:36:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 19:40:00 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 19:40:00 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 19:40:00 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 19:40:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-26 10:36:42 -05:00
|
|
|
|
2009-06-11 12:46:41 +01:00
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
2008-09-26 10:36:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: check name length in tty_find_polling_driver()
The issue is found by a fuzzing test.
If tty_find_polling_driver() recevies an incorrect input such as
',,' or '0b', the len becomes 0 and strncmp() always return 0.
In this case, a null p->ops->poll_init() is called and it causes a kernel
panic.
Fix this by checking name length against zero in tty_find_polling_driver().
$echo ,, > /sys/module/kgdboc/parameters/kgdboc
[ 20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
uart_get_baud_rate+0xe8/0x190
[ 20.804917] Modules linked in:
[ 20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
[ 20.805469] Hardware name: linux,dummy-virt (DT)
[ 20.805732] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 20.805895] pc : uart_get_baud_rate+0xe8/0x190
[ 20.806042] lr : uart_get_baud_rate+0xc0/0x190
[ 20.806476] sp : ffffffc06acff940
[ 20.806676] x29: ffffffc06acff940 x28: 0000000000002580
[ 20.806977] x27: 0000000000009600 x26: 0000000000009600
[ 20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0
[ 20.807576] x23: 0000000000000001 x22: 0000000000000000
[ 20.807807] x21: 0000000000000001 x20: 0000000000000000
[ 20.808049] x19: ffffffc06acffac8 x18: 0000000000000000
[ 20.808277] x17: 0000000000000000 x16: 0000000000000000
[ 20.808520] x15: ffffffffffffffff x14: ffffffff00000000
[ 20.808757] x13: ffffffffffffffff x12: 0000000000000001
[ 20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f
[ 20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[ 20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[ 20.809803] x5 : 0000000080008001 x4 : 0000000000000003
[ 20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000
[ 20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0
[ 20.811005] Call trace:
[ 20.811214] uart_get_baud_rate+0xe8/0x190
[ 20.811479] serial8250_do_set_termios+0xe0/0x6f4
[ 20.811719] serial8250_set_termios+0x48/0x54
[ 20.811928] uart_set_options+0x138/0x1bc
[ 20.812129] uart_poll_init+0x114/0x16c
[ 20.812330] tty_find_polling_driver+0x158/0x200
[ 20.812545] configure_kgdboc+0xbc/0x1bc
[ 20.812745] param_set_kgdboc_var+0xb8/0x150
[ 20.812960] param_attr_store+0xbc/0x150
[ 20.813160] module_attr_store+0x40/0x58
[ 20.813364] sysfs_kf_write+0x8c/0xa8
[ 20.813563] kernfs_fop_write+0x154/0x290
[ 20.813764] vfs_write+0xf0/0x278
[ 20.813951] __arm64_sys_write+0x84/0xf4
[ 20.814400] el0_svc_common+0xf4/0x1dc
[ 20.814616] el0_svc_handler+0x98/0xbc
[ 20.814804] el0_svc+0x8/0xc
[ 20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 20.826913] Mem abort info:
[ 20.827103] ESR = 0x84000006
[ 20.827352] Exception class = IABT (current EL), IL = 16 bits
[ 20.827655] SET = 0, FnV = 0
[ 20.827855] EA = 0, S1PTW = 0
[ 20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
[ 20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000
[ 20.829195] Internal error: Oops: 84000006 [#1] SMP
[ 20.829564] Modules linked in:
[ 20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G W 4.19.0-rc7ajb #8
[ 20.830545] Hardware name: linux,dummy-virt (DT)
[ 20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO)
[ 20.831174] pc : (null)
[ 20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
[ 20.831727] sp : ffffffc06acff9b0
[ 20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000
[ 20.832267] x27: ffffff900969e16f x26: 0000000000000000
[ 20.832589] x25: ffffff900969dfb0 x24: 0000000000000000
[ 20.832906] x23: ffffffc06acffad0 x22: ffffff900969e160
[ 20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
[ 20.833559] x19: ffffff900969df90 x18: 0000000000000000
[ 20.833878] x17: 0000000000000000 x16: 0000000000000000
[ 20.834491] x15: ffffffffffffffff x14: ffffffff00000000
[ 20.834821] x13: ffffffffffffffff x12: 0000000000000001
[ 20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
[ 20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[ 20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[ 20.836111] x5 : c06419717c314100 x4 : 0000000000000007
[ 20.836419] x3 : 0000000000000000 x2 : 0000000000000000
[ 20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
[ 20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
[ 20.837396] Call trace:
[ 20.837566] (null)
[ 20.837816] serial8250_set_termios+0x48/0x54
[ 20.838089] uart_set_options+0x138/0x1bc
[ 20.838570] uart_poll_init+0x114/0x16c
[ 20.838834] tty_find_polling_driver+0x158/0x200
[ 20.839119] configure_kgdboc+0xbc/0x1bc
[ 20.839380] param_set_kgdboc_var+0xb8/0x150
[ 20.839658] param_attr_store+0xbc/0x150
[ 20.839920] module_attr_store+0x40/0x58
[ 20.840183] sysfs_kf_write+0x8c/0xa8
[ 20.840183] sysfs_kf_write+0x8c/0xa8
[ 20.840440] kernfs_fop_write+0x154/0x290
[ 20.840702] vfs_write+0xf0/0x278
[ 20.840942] __arm64_sys_write+0x84/0xf4
[ 20.841209] el0_svc_common+0xf4/0x1dc
[ 20.841471] el0_svc_handler+0x98/0xbc
[ 20.841713] el0_svc+0x8/0xc
[ 20.842057] Code: bad PC value
[ 20.842764] ---[ end trace a8835d7de79aaadf ]---
[ 20.843134] Kernel panic - not syncing: Fatal exception
[ 20.843515] SMP: stopping secondary CPUs
[ 20.844289] Kernel Offset: disabled
[ 20.844634] CPU features: 0x0,21806002
[ 20.844857] Memory Limit: none
[ 20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-08 10:39:17 +08:00
|
|
|
|
2008-09-26 10:36:42 -05:00
|
|
|
|
2009-06-11 12:46:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
2010-09-02 16:06:16 +02:00
|
|
|
|
2009-06-11 12:46:41 +01:00
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2008-04-17 20:05:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-21 10:08:15 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-21 10:04:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-03 06:39:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
|
|
|
|
|
2007-06-16 10:15:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2007-06-16 10:15:55 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:45:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-18 06:27:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-03 00:24:21 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2023-05-22 14:49:59 +01:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-18 06:27:59 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-07-03 00:24:21 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2023-05-22 14:49:59 +01:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-03 00:24:21 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-21 10:08:15 -08:00
|
|
|
|
2021-01-21 10:04:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2007-06-16 10:15:55 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-09 21:45:10 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
2021-04-08 14:51:31 +02:00
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-06 07:20:53 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-23 18:49:01 -06:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2010-06-18 14:58:07 +02:00
|
|
|
|
tty: Only hangup once
Instrumented testing shows a tty can be hungup multiple times [1].
Although concurrent hangups are properly serialized, multiple
hangups for the same tty should be prevented.
If tty has already been HUPPED, abort hangup. Note it is not
necessary to cleanup file *redirect on subsequent hangups,
as only TIOCCONS can set that value and ioctls are disabled
after hangup.
[1]
Test performed by simulating a concurrent async hangup via
tty_hangup() with a sync hangup via tty_vhangup(), while
__tty_hangup() was instrumented with:
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 26bb78c..fe8b061 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)
tty_lock(tty);
+ WARN_ON(test_bit(TTY_HUPPED, &tty->flags));
+
/* some functions below drop BTM, so we need this bit */
set_bit(TTY_HUPPING, &tty->flags);
Test result:
WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460()
Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...>
CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
Workqueue: events do_tty_hangup
0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58
ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00
ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68
Call Trace:
[<ffffffff816b553e>] dump_stack+0x19/0x1b
[<ffffffff810407e0>] warn_slowpath_common+0x70/0xa0
[<ffffffff8104082a>] warn_slowpath_null+0x1a/0x20
[<ffffffff813fb279>] __tty_hangup+0x459/0x460
[<ffffffff8107409c>] ? finish_task_switch+0xbc/0xe0
[<ffffffff813fb297>] do_tty_hangup+0x17/0x20
[<ffffffff8105fd6f>] process_one_work+0x16f/0x450
[<ffffffff8106007c>] process_scheduled_works+0x2c/0x40
[<ffffffff8106060a>] worker_thread+0x26a/0x380
[<ffffffff810603a0>] ? rescuer_thread+0x310/0x310
[<ffffffff810698a0>] kthread+0xc0/0xd0
[<ffffffff816b0000>] ? destroy_compound_page+0x65/0x92
[<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130
[<ffffffff816c495c>] ret_from_fork+0x7c/0xb0
[<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130
---[ end trace 98d9f01536cf411e ]---
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31 14:05:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: make n_tty_read() always abort if hangup is in progress
A tty is hung up by __tty_hangup() setting file->f_op to
hung_up_tty_fops, which is skipped on ttys whose write operation isn't
tty_write(). This means that, for example, /dev/console whose write
op is redirected_tty_write() is never actually marked hung up.
Because n_tty_read() uses the hung up status to decide whether to
abort the waiting readers, the lack of hung-up marking can lead to the
following scenario.
1. A session contains two processes. The leader and its child. The
child ignores SIGHUP.
2. The leader exits and starts disassociating from the controlling
terminal (/dev/console).
3. __tty_hangup() skips setting f_op to hung_up_tty_fops.
4. SIGHUP is delivered and ignored.
5. tty_ldisc_hangup() is invoked. It wakes up the waits which should
clear the read lockers of tty->ldisc_sem.
6. The reader wakes up but because tty_hung_up_p() is false, it
doesn't abort and goes back to sleep while read-holding
tty->ldisc_sem.
7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
and is now stuck in D sleep indefinitely waiting for
tty->ldisc_sem.
The following is Alan's explanation on why some ttys aren't hung up.
http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop
1. It broke the serial consoles because they would hang up and close
down the hardware. With tty_port that *should* be fixable properly
for any cases remaining.
2. The console layer was (and still is) completely broken and doens't
refcount properly. So if you turn on console hangups it breaks (as
indeed does freeing consoles and half a dozen other things).
As neither can be fixed quickly, this patch works around the problem
by introducing a new flag, TTY_HUPPING, which is used solely to tell
n_tty_read() that hang-up is in progress for the console and the
readers should be aborted regardless of the hung-up status of the
device.
The following is a sample hung task warning caused by this issue.
INFO: task agetty:2662 blocked for more than 120 seconds.
Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty #28
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
0 2662 1 0x00000086
Call Trace:
__schedule+0x267/0x890
schedule+0x36/0x80
schedule_timeout+0x23c/0x2e0
ldsem_down_write+0xce/0x1f6
tty_ldisc_lock+0x16/0x30
tty_ldisc_hangup+0xb3/0x1b0
__tty_hangup+0x300/0x410
disassociate_ctty+0x6c/0x290
do_exit+0x7ef/0xb00
do_group_exit+0x3f/0xa0
get_signal+0x1b3/0x5d0
do_signal+0x28/0x660
exit_to_usermode_loop+0x46/0x86
do_syscall_64+0x9c/0xb0
entry_SYSCALL64_slow_path+0x25/0x25
The following is the repro. Run "$PROG /dev/console". The parent
process hangs in D state.
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
#include <time.h>
#include <termios.h>
int main(int argc, char **argv)
{
struct sigaction sact = { .sa_handler = SIG_IGN };
struct timespec ts1s = { .tv_sec = 1 };
pid_t pid;
int fd;
if (argc < 2) {
fprintf(stderr, "test-hung-tty /dev/$TTY\n");
return 1;
}
/* fork a child to ensure that it isn't already the session leader */
pid = fork();
if (pid < 0) {
perror("fork");
return 1;
}
if (pid > 0) {
/* top parent, wait for everyone */
while (waitpid(-1, NULL, 0) >= 0)
;
if (errno != ECHILD)
perror("waitpid");
return 0;
}
/* new session, start a new session and set the controlling tty */
if (setsid() < 0) {
perror("setsid");
return 1;
}
fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
if (ioctl(fd, TIOCSCTTY, 1) < 0) {
perror("ioctl");
return 1;
}
/* fork a child, sleep a bit and exit */
pid = fork();
if (pid < 0) {
perror("fork");
return 1;
}
if (pid > 0) {
nanosleep(&ts1s, NULL);
printf("Session leader exiting\n");
exit(0);
}
/*
* The child ignores SIGHUP and keeps reading from the controlling
* tty. Because SIGHUP is ignored, the child doesn't get killed on
* parent exit and the bug in n_tty makes the read(2) block the
* parent's control terminal hangup attempt. The parent ends up in
* D sleep until the child is explicitly killed.
*/
sigaction(SIGHUP, &sact, NULL);
printf("Child reading tty\n");
while (1) {
char buf[1024];
if (read(fd, buf, sizeof(buf)) < 0) {
perror("read");
return 1;
}
}
return 0;
}
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-13 07:38:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2021-05-12 17:26:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-18 14:58:07 +02:00
|
|
|
|
2009-11-30 13:18:51 +00:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2013-03-06 07:20:57 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: Destroy ldisc instance on hangup
Currently, when the tty is hungup, the ldisc is re-instanced; ie., the
current instance is destroyed and a new instance is created. The purpose
of this design was to guarantee a valid, open ldisc for the lifetime of
the tty.
However, now that tty buffers are owned by and have lifetime equivalent
to the tty_port (since v3.10), any data received immediately after the
ldisc is re-instanced may cause continued driver i/o operations
concurrently with the driver's hangup() operation. For drivers that
shutdown h/w on hangup, this is unexpected and usually bad. For example,
the serial core may free the xmit buffer page concurrently with an
in-progress write() operation (triggered by echo).
With the existing stable and robust ldisc reference handling, the
cleaned-up tty_reopen(), the straggling unsafe ldisc use cleaned up, and
the preparation to properly handle a NULL tty->ldisc, the ldisc instance
can be destroyed and only re-instanced when the tty is re-opened.
If the tty was opened as /dev/console or /dev/tty0, the original behavior
of re-instancing the ldisc is retained (the 'reinit' parameter to
tty_ldisc_hangup() is true). This is required since those file descriptors
are never hungup.
This patch has neglible impact on userspace; the tty file_operations ptr
is changed to point to the hungup file operations _before_ the ldisc
instance is destroyed, so only racing file operations might now retrieve
a NULL ldisc reference (which is simply handled as if the hungup file
operation had been called instead -- see "tty: Prepare for destroying
line discipline on hangup").
This resolves a long-standing FIXME and several crash reports.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-10 22:41:06 -08:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
2009-06-11 12:50:12 +01:00
|
|
|
|
|
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
|
|
|
|
|
2014-06-16 09:17:08 -04:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
tty: Destroy ldisc instance on hangup
Currently, when the tty is hungup, the ldisc is re-instanced; ie., the
current instance is destroyed and a new instance is created. The purpose
of this design was to guarantee a valid, open ldisc for the lifetime of
the tty.
However, now that tty buffers are owned by and have lifetime equivalent
to the tty_port (since v3.10), any data received immediately after the
ldisc is re-instanced may cause continued driver i/o operations
concurrently with the driver's hangup() operation. For drivers that
shutdown h/w on hangup, this is unexpected and usually bad. For example,
the serial core may free the xmit buffer page concurrently with an
in-progress write() operation (triggered by echo).
With the existing stable and robust ldisc reference handling, the
cleaned-up tty_reopen(), the straggling unsafe ldisc use cleaned up, and
the preparation to properly handle a NULL tty->ldisc, the ldisc instance
can be destroyed and only re-instanced when the tty is re-opened.
If the tty was opened as /dev/console or /dev/tty0, the original behavior
of re-instancing the ldisc is retained (the 'reinit' parameter to
tty_ldisc_hangup() is true). This is required since those file descriptors
are never hungup.
This patch has neglible impact on userspace; the tty file_operations ptr
is changed to point to the hungup file operations _before_ the ldisc
instance is destroyed, so only racing file operations might now retrieve
a NULL ldisc reference (which is simply handled as if the hungup file
operation had been called instead -- see "tty: Prepare for destroying
line discipline on hangup").
This resolves a long-standing FIXME and several crash reports.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-10 22:41:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: make n_tty_read() always abort if hangup is in progress
A tty is hung up by __tty_hangup() setting file->f_op to
hung_up_tty_fops, which is skipped on ttys whose write operation isn't
tty_write(). This means that, for example, /dev/console whose write
op is redirected_tty_write() is never actually marked hung up.
Because n_tty_read() uses the hung up status to decide whether to
abort the waiting readers, the lack of hung-up marking can lead to the
following scenario.
1. A session contains two processes. The leader and its child. The
child ignores SIGHUP.
2. The leader exits and starts disassociating from the controlling
terminal (/dev/console).
3. __tty_hangup() skips setting f_op to hung_up_tty_fops.
4. SIGHUP is delivered and ignored.
5. tty_ldisc_hangup() is invoked. It wakes up the waits which should
clear the read lockers of tty->ldisc_sem.
6. The reader wakes up but because tty_hung_up_p() is false, it
doesn't abort and goes back to sleep while read-holding
tty->ldisc_sem.
7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
and is now stuck in D sleep indefinitely waiting for
tty->ldisc_sem.
The following is Alan's explanation on why some ttys aren't hung up.
http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop
1. It broke the serial consoles because they would hang up and close
down the hardware. With tty_port that *should* be fixable properly
for any cases remaining.
2. The console layer was (and still is) completely broken and doens't
refcount properly. So if you turn on console hangups it breaks (as
indeed does freeing consoles and half a dozen other things).
As neither can be fixed quickly, this patch works around the problem
by introducing a new flag, TTY_HUPPING, which is used solely to tell
n_tty_read() that hang-up is in progress for the console and the
readers should be aborted regardless of the hung-up status of the
device.
The following is a sample hung task warning caused by this issue.
INFO: task agetty:2662 blocked for more than 120 seconds.
Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty #28
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
0 2662 1 0x00000086
Call Trace:
__schedule+0x267/0x890
schedule+0x36/0x80
schedule_timeout+0x23c/0x2e0
ldsem_down_write+0xce/0x1f6
tty_ldisc_lock+0x16/0x30
tty_ldisc_hangup+0xb3/0x1b0
__tty_hangup+0x300/0x410
disassociate_ctty+0x6c/0x290
do_exit+0x7ef/0xb00
do_group_exit+0x3f/0xa0
get_signal+0x1b3/0x5d0
do_signal+0x28/0x660
exit_to_usermode_loop+0x46/0x86
do_syscall_64+0x9c/0xb0
entry_SYSCALL64_slow_path+0x25/0x25
The following is the repro. Run "$PROG /dev/console". The parent
process hangs in D state.
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
#include <time.h>
#include <termios.h>
int main(int argc, char **argv)
{
struct sigaction sact = { .sa_handler = SIG_IGN };
struct timespec ts1s = { .tv_sec = 1 };
pid_t pid;
int fd;
if (argc < 2) {
fprintf(stderr, "test-hung-tty /dev/$TTY\n");
return 1;
}
/* fork a child to ensure that it isn't already the session leader */
pid = fork();
if (pid < 0) {
perror("fork");
return 1;
}
if (pid > 0) {
/* top parent, wait for everyone */
while (waitpid(-1, NULL, 0) >= 0)
;
if (errno != ECHILD)
perror("waitpid");
return 0;
}
/* new session, start a new session and set the controlling tty */
if (setsid() < 0) {
perror("setsid");
return 1;
}
fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
if (ioctl(fd, TIOCSCTTY, 1) < 0) {
perror("ioctl");
return 1;
}
/* fork a child, sleep a bit and exit */
pid = fork();
if (pid < 0) {
perror("fork");
return 1;
}
if (pid > 0) {
nanosleep(&ts1s, NULL);
printf("Session leader exiting\n");
exit(0);
}
/*
* The child ignores SIGHUP and keeps reading from the controlling
* tty. Because SIGHUP is ignored, the child doesn't get killed on
* parent exit and the bug in n_tty makes the read(2) block the
* parent's control terminal hangup attempt. The parent ends up in
* D sleep until the child is explicitly killed.
*/
sigaction(SIGHUP, &sact, NULL);
printf("Child reading tty\n");
while (1) {
char buf[1024];
if (read(fd, buf, sizeof(buf)) < 0) {
perror("read");
return 1;
}
}
return 0;
}
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-13 07:38:08 -08:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2010-06-18 14:58:07 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 22:53:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2010-06-01 22:53:08 +02:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-18 14:58:07 +02:00
|
|
|
|
2008-10-13 10:40:30 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:40:30 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:40:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2017-04-12 18:37:16 -04:00
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2013-03-06 07:20:56 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-01-16 16:54:29 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-19 09:21:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-05-19 09:21:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2014-09-10 15:06:31 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
2018-06-18 16:16:26 +02:00
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
2015-03-26 23:10:27 +01:00
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
|
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
|
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-21 10:17:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-09 17:06:48 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:18 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
2021-01-21 10:08:15 -08:00
|
|
|
|
2021-01-18 13:31:30 -08:00
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-02-15 15:25:05 +01:00
|
|
|
|
2018-06-18 16:16:26 +02:00
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-17 13:33:17 +02:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:39 +02:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:56 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-08-10 11:14:57 +02:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-23 03:00:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:45:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-20 15:32:50 +02:00
|
|
|
|
2008-10-13 10:45:36 +01:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-12-20 15:32:50 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:45:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:57 +02:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2023-08-10 11:14:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2021-02-20 21:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
tty: tty_io: update timestamps on all device nodes
User space applications watch for timestamp changes on character device
files in order to determine idle time of a given terminal session. For
example, "w" program uses this information to populate the IDLE column
of its output [1]. Similarly, systemd-logind has optional feature where
it uses atime of the tty character device to determine if there was
activity on the terminal associated with the logind's session object. If
there was no activity for a configured period of time then logind will
terminate such session [2].
Now, usually (e.g. bash running on the terminal) the use of the terminal
will update timestamps (atime and mtime) on the corresponding terminal
character device. However, if access to the terminal, e.g. /dev/pts/0,
is performed through magic character device /dev/tty then such access
obviously changes the state of the terminal, however timestamps on the
device that correspond to the terminal (/dev/pts/0) are not updated.
This patch makes sure that we update timestamps on *all* character
devices that correspond to the given tty, because outside observers (w,
systemd-logind) are maybe checking these timestamps. Obviously, they can
not check timestamps on /dev/tty as that has per-process meaning.
[1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286
[2] https://github.com/systemd/systemd/blob/v252/NEWS#L477
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Message-ID: <20230613172107.78138-1-msekleta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13 19:21:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-04-26 13:48:53 +02:00
|
|
|
|
2007-07-15 23:39:43 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:39:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:39:23 +01:00
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2008-10-13 10:39:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2015-10-10 20:28:44 -04:00
|
|
|
|
2008-10-13 10:39:23 +01:00
|
|
|
|
2015-10-10 20:28:44 -04:00
|
|
|
|
2008-10-13 10:39:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2021-05-12 17:26:14 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-09 17:06:48 -07:00
|
|
|
|
2021-05-12 17:26:20 +08:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:13 -05:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2021-01-21 10:04:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-19 09:21:52 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-19 09:21:52 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2021-05-19 09:21:52 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-19 09:21:52 +02:00
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-27 14:48:26 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
2021-05-12 17:26:19 +08:00
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
2015-11-11 08:03:54 -05:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
2015-11-11 08:03:54 -05:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:39 +02:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
2015-11-11 08:03:54 -05:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-11 08:03:54 -05:00
|
|
|
|
2014-09-10 15:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-03-02 07:22:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2014-02-27 12:30:51 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 22:26:43 +02:00
|
|
|
|
2014-02-27 12:30:51 +01:00
|
|
|
|
2012-08-08 22:26:43 +02:00
|
|
|
|
2014-02-27 12:30:51 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:00 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2009-01-02 13:43:04 +00:00
|
|
|
|
2016-04-25 20:04:08 -07:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2014-11-05 12:12:51 -05:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2022-12-09 12:27:36 +01:00
|
|
|
|
2017-05-15 18:45:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-09 12:27:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:51 -05:00
|
|
|
|
2022-12-09 12:27:36 +01:00
|
|
|
|
2014-11-05 12:12:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2016-01-09 21:13:48 -08:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2008-10-13 10:44:08 +01:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
|
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-10 22:40:57 -08:00
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2016-01-10 22:40:57 -08:00
|
|
|
|
|
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
|
|
|
|
|
2012-07-14 15:31:47 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2009-09-19 13:13:33 -07:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2021-11-26 09:16:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-30 21:14:28 +01:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:48 -08:00
|
|
|
|
2012-01-30 21:14:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:00 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-30 21:14:28 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2016-01-09 21:13:49 -08:00
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-18 10:56:51 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2008-10-13 10:42:00 +01:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
|
|
|
|
|
2019-01-09 01:17:40 +00:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:47 -05:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2016-01-09 21:13:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-30 10:39:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-09 01:17:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
2019-01-09 01:17:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-01 00:24:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-18 00:52:52 +01:00
|
|
|
|
2008-10-13 10:41:51 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-18 10:56:51 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-05 13:04:21 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2008-10-13 10:42:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2017-03-30 15:39:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:29 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-07-10 21:01:22 +02:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2008-10-13 10:42:29 +01:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
2016-01-09 21:13:46 -08:00
|
|
|
|
2008-10-13 10:42:19 +01:00
|
|
|
|
2012-06-04 13:35:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-22 11:17:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-17 14:27:52 +02:00
|
|
|
|
2018-01-23 13:16:34 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-18 22:26:46 +02:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
2008-07-22 11:16:55 +01:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
2018-01-23 13:16:34 +05:30
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2008-10-13 10:42:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-09 21:13:46 -08:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2011-03-23 10:48:32 +01:00
|
|
|
|
2018-01-23 13:16:34 +05:30
|
|
|
|
2015-11-08 13:01:13 -05:00
|
|
|
|
|
|
|
|
|
2018-01-23 13:16:34 +05:30
|
|
|
|
|
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2008-10-13 10:42:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-12-04 17:00:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2015-11-08 13:01:11 -05:00
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2012-07-24 12:51:52 +01:00
|
|
|
|
2008-10-13 10:41:30 +01:00
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2008-10-13 10:41:30 +01:00
|
|
|
|
2018-12-04 17:00:36 +01:00
|
|
|
|
2008-10-13 10:41:30 +01:00
|
|
|
|
2013-03-11 16:44:35 -04:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2013-03-11 16:44:35 -04:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2013-03-11 16:44:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:57 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-11 16:44:35 -04:00
|
|
|
|
2008-10-13 10:41:30 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:36 +01:00
|
|
|
|
2014-08-08 00:26:15 +04:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2009-09-27 16:00:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2014-08-08 00:26:15 +04:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-27 16:00:42 +00:00
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
2021-05-12 17:26:18 +08:00
|
|
|
|
|
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-19 13:13:22 -07:00
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
|
|
|
|
|
2012-07-27 18:02:54 +01:00
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
|
|
|
|
|
2018-12-04 17:00:36 +01:00
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2020-11-05 13:34:32 +01:00
|
|
|
|
|
|
|
|
|
2013-06-15 09:01:00 -04:00
|
|
|
|
|
|
|
|
|
2020-11-05 13:34:32 +01:00
|
|
|
|
|
|
|
|
|
2017-12-13 09:10:48 +04:00
|
|
|
|
|
|
|
|
|
2012-07-17 17:06:57 +01:00
|
|
|
|
2014-11-21 13:42:29 +01:00
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2007-02-10 01:46:46 -08:00
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
2014-11-05 12:12:59 -05:00
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-12 22:49:08 -04:00
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-12 22:49:08 -04:00
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:59 -05:00
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
2015-07-12 22:49:08 -04:00
|
|
|
|
|
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-12 22:49:08 -04:00
|
|
|
|
2011-11-11 10:47:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 13:11:45 +02:00
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-23 23:33:59 -08:00
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 16:54:28 -06:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 16:54:28 -06:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2017-01-16 16:54:28 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-23 23:33:59 -08:00
|
|
|
|
2017-01-16 16:54:28 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-10-16 13:51:30 -04:00
|
|
|
|
2014-10-16 13:54:36 -04:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2011-11-09 21:33:24 +01:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2011-11-09 21:33:24 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-11-05 12:12:59 -05:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-11-05 12:13:01 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-16 13:54:36 -04:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:13 -05:00
|
|
|
|
2014-10-16 13:54:36 -04:00
|
|
|
|
2014-10-16 13:51:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-11-08 13:01:13 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:13 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2014-11-05 12:13:00 -05:00
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2014-11-05 12:13:01 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:12:52 -05:00
|
|
|
|
2021-05-12 17:26:18 +08:00
|
|
|
|
|
|
|
|
|
2006-02-14 13:53:00 -08:00
|
|
|
|
2014-11-05 12:12:56 -05:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2015-07-12 22:49:09 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-01-16 16:54:28 -06:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: Re-open /dev/tty without tty_mutex
Opening /dev/tty (ie., the controlling tty for the current task)
is always a re-open of the underlying tty. Because holding the
tty_lock is sufficient for safely re-opening a tty, and because
having a tty kref is sufficient for safely acquiring the tty_lock [1],
tty_open_current_tty() does not require holding tty_mutex.
Repurpose tty_open_current_tty() to perform the re-open itself and
refactor tty_open().
[1] Analysis of safely re-opening the current tty w/o tty_mutex
get_current_tty() gets a tty kref from the already kref'ed tty value of
current->signal->tty while holding the sighand lock for the current
task. This guarantees that the tty pointer returned from
get_current_tty() points to a tty which remains referenceable
while holding the kref.
Although release_tty() may run concurrently, and thus the driver
reference may be removed, release_one_tty() cannot have run, and
won't while holding the tty kref.
This, in turn, guarantees the tty_lock() can safely be acquired
(since tty->magic and tty->legacy_mutex are still a valid dereferences).
The tty_lock() also gets a tty kref to prevent the tty_unlock() from
dereferencing a released tty. Thus, the kref returned from
get_current_tty() can be released.
Lastly, the first operation of tty_reopen() is to check the tty count.
If non-zero, this ensures release_tty() is not running concurrently,
and the driver references have not been removed.
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-05 12:12:50 -05:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: Re-open /dev/tty without tty_mutex
Opening /dev/tty (ie., the controlling tty for the current task)
is always a re-open of the underlying tty. Because holding the
tty_lock is sufficient for safely re-opening a tty, and because
having a tty kref is sufficient for safely acquiring the tty_lock [1],
tty_open_current_tty() does not require holding tty_mutex.
Repurpose tty_open_current_tty() to perform the re-open itself and
refactor tty_open().
[1] Analysis of safely re-opening the current tty w/o tty_mutex
get_current_tty() gets a tty kref from the already kref'ed tty value of
current->signal->tty while holding the sighand lock for the current
task. This guarantees that the tty pointer returned from
get_current_tty() points to a tty which remains referenceable
while holding the kref.
Although release_tty() may run concurrently, and thus the driver
reference may be removed, release_one_tty() cannot have run, and
won't while holding the tty kref.
This, in turn, guarantees the tty_lock() can safely be acquired
(since tty->magic and tty->legacy_mutex are still a valid dereferences).
The tty_lock() also gets a tty kref to prevent the tty_unlock() from
dereferencing a released tty. Thus, the kref returned from
get_current_tty() can be released.
Lastly, the first operation of tty_reopen() is to check the tty count.
If non-zero, this ensures release_tty() is not running concurrently,
and the driver references have not been removed.
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-05 12:12:50 -05:00
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tty: Re-open /dev/tty without tty_mutex
Opening /dev/tty (ie., the controlling tty for the current task)
is always a re-open of the underlying tty. Because holding the
tty_lock is sufficient for safely re-opening a tty, and because
having a tty kref is sufficient for safely acquiring the tty_lock [1],
tty_open_current_tty() does not require holding tty_mutex.
Repurpose tty_open_current_tty() to perform the re-open itself and
refactor tty_open().
[1] Analysis of safely re-opening the current tty w/o tty_mutex
get_current_tty() gets a tty kref from the already kref'ed tty value of
current->signal->tty while holding the sighand lock for the current
task. This guarantees that the tty pointer returned from
get_current_tty() points to a tty which remains referenceable
while holding the kref.
Although release_tty() may run concurrently, and thus the driver
reference may be removed, release_one_tty() cannot have run, and
won't while holding the tty kref.
This, in turn, guarantees the tty_lock() can safely be acquired
(since tty->magic and tty->legacy_mutex are still a valid dereferences).
The tty_lock() also gets a tty kref to prevent the tty_unlock() from
dereferencing a released tty. Thus, the kref returned from
get_current_tty() can be released.
Lastly, the first operation of tty_reopen() is to check the tty count.
If non-zero, this ensures release_tty() is not running concurrently,
and the driver references have not been removed.
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-05 12:12:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:52 -08:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2019-05-10 12:22:57 +08:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2017-05-15 18:45:32 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2019-05-10 12:22:57 +08:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
2019-12-17 08:50:40 +01:00
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2020-12-18 11:42:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2019-11-20 15:17:08 +00:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-25 20:04:08 -07:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-20 08:22:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
|
|
|
|
|
2016-03-31 17:47:07 -07:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 16:56:36 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 21:33:19 +01:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2019-11-20 15:17:08 +00:00
|
|
|
|
2008-10-13 10:42:49 +01:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2011-11-09 21:33:21 +01:00
|
|
|
|
2016-01-09 21:13:45 -08:00
|
|
|
|
2016-01-09 21:13:53 -08:00
|
|
|
|
2016-01-09 21:13:45 -08:00
|
|
|
|
|
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-12 11:32:43 +02:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2011-11-09 21:33:24 +01:00
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2015-07-12 22:49:09 -04:00
|
|
|
|
2011-03-31 15:35:31 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:19 -05:00
|
|
|
|
2015-07-12 22:49:09 -04:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2010-06-01 22:53:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-01 22:53:02 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-01 22:53:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:26:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-19 08:46:27 -05:00
|
|
|
|
2009-11-30 13:18:29 +00:00
|
|
|
|
2016-01-09 21:13:52 -08:00
|
|
|
|
2017-04-12 18:37:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 09:10:50 -06:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2017-07-03 06:39:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-07-03 22:25:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
|
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2014-11-05 12:26:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2008-04-30 00:53:30 -07:00
|
|
|
|
2008-06-19 16:04:53 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2008-06-19 16:04:53 -06:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-06-19 16:04:53 -06:00
|
|
|
|
2013-06-15 07:28:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
|
|
|
|
|
2013-06-15 07:28:28 -04:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-16 22:05:57 -05:00
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
2010-02-07 10:11:23 -08:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
2014-08-22 11:27:32 -04:00
|
|
|
|
2010-02-07 10:11:23 -08:00
|
|
|
|
2014-08-22 11:27:32 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-19 16:04:53 -06:00
|
|
|
|
2010-06-01 22:53:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2016-01-09 21:45:11 -08:00
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
|
|
|
|
|
2016-01-09 21:45:11 -08:00
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
|
|
|
|
|
2008-06-19 16:04:53 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-11-06 19:46:35 -08:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2023-07-10 02:26:45 +02:00
|
|
|
|
2022-10-22 11:29:49 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-09 09:23:33 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
|
|
|
|
|
2021-08-23 08:06:41 +08:00
|
|
|
|
2019-01-20 10:46:58 +01:00
|
|
|
|
|
|
|
|
|
2021-08-23 08:06:41 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-29 02:00:40 -07:00
|
|
|
|
|
|
|
|
|
tty: Fix lock order in tty_do_resize()
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-24 16:43:51 -04:00
|
|
|
|
2006-09-29 02:00:40 -07:00
|
|
|
|
tty: Fix lock order in tty_do_resize()
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-24 16:43:51 -04:00
|
|
|
|
2006-09-29 02:00:40 -07:00
|
|
|
|
2021-05-12 17:26:16 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
tty: Fix lock order in tty_do_resize()
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-24 16:43:51 -04:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2006-09-29 02:00:03 -07:00
|
|
|
|
2008-04-30 00:53:30 -07:00
|
|
|
|
2014-10-16 14:59:45 -04:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:53:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2006-09-29 02:00:03 -07:00
|
|
|
|
tty: Fix lock order in tty_do_resize()
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-24 16:43:51 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-04 14:55:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2008-08-15 10:39:38 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-19 11:41:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-29 12:28:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-27 14:48:26 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-01-10 22:41:04 -08:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-10 22:41:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2016-01-10 22:41:04 -08:00
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
|
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2005-06-25 14:58:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-22 11:18:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:14:39 +02:00
|
|
|
|
2008-07-22 11:18:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2011-02-14 16:26:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-04-07 11:52:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2011-02-14 16:26:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2011-02-14 16:26:50 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-16 21:56:54 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-16 21:56:54 +01:00
|
|
|
|
2021-04-07 11:52:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-16 21:56:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-16 21:56:54 +01:00
|
|
|
|
|
|
|
|
|
2011-02-14 16:26:50 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:52:02 +02:00
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-16 18:21:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-16 18:21:24 +01:00
|
|
|
|
|
|
|
|
|
2020-12-18 11:42:45 +01:00
|
|
|
|
2010-09-16 18:21:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:52:05 +02:00
|
|
|
|
2014-11-06 16:56:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:52:05 +02:00
|
|
|
|
2014-11-06 16:56:33 +01:00
|
|
|
|
2021-04-07 11:52:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:52:05 +02:00
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
2018-09-12 07:46:51 -04:00
|
|
|
|
2021-04-07 11:52:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
2018-09-12 07:46:51 -04:00
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
|
|
|
|
|
2014-11-06 16:56:33 +01:00
|
|
|
|
|
|
|
|
|
2014-10-16 14:59:41 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-11 12:48:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:53:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-11 12:48:02 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-22 11:18:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:38:46 +01:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2009-01-02 13:43:17 +00:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-24 23:43:22 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2012-10-24 23:43:22 +04:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2016-01-10 22:40:55 -08:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2011-02-17 18:39:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-03 12:48:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2010-12-03 12:48:23 +01:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2008-07-22 11:18:03 +01:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2008-07-22 11:18:03 +01:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2011-02-14 16:26:14 +00:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 16:26:50 +00:00
|
|
|
|
2010-09-16 18:21:24 +01:00
|
|
|
|
2018-09-12 18:37:18 -04:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 12:13:09 -05:00
|
|
|
|
2007-05-12 10:36:55 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2014-11-06 16:56:33 +01:00
|
|
|
|
2018-09-12 07:46:51 -04:00
|
|
|
|
2018-09-11 21:53:32 -04:00
|
|
|
|
2018-09-12 07:46:51 -04:00
|
|
|
|
2017-08-24 15:13:29 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-12 18:37:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2014-11-05 12:26:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2021-11-22 10:45:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-27 15:23:12 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
2020-07-23 17:32:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:52:05 +02:00
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-24 10:20:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
2020-02-24 10:20:44 -08:00
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
tty: fix fu_list abuse
tty: fix fu_list abuse
tty code abuses fu_list, which causes a bug in remount,ro handling.
If a tty device node is opened on a filesystem, then the last link to the inode
removed, the filesystem will be allowed to be remounted readonly. This is
because fs_may_remount_ro does not find the 0 link tty inode on the file sb
list (because the tty code incorrectly removed it to use for its own purpose).
This can result in a filesystem with errors after it is marked "clean".
Taking idea from Christoph's initial patch, allocate a tty private struct
at file->private_data and put our required list fields in there, linking
file and tty. This makes tty nodes behave the same way as other device nodes
and avoid meddling with the vfs, and avoids this bug.
The error handling is not trivial in the tty code, so for this bugfix, I take
the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
This is not a problem because our allocator doesn't fail small allocs as a rule
anyway. So proper error handling is left as an exercise for tty hackers.
[ Arguably filesystem's device inode would ideally be divorced from the
driver's pseudo inode when it is opened, but in practice it's not clear whether
that will ever be worth implementing. ]
Cc: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-18 04:37:36 +10:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-11 19:47:09 -04:00
|
|
|
|
2019-06-03 23:07:12 +02:00
|
|
|
|
2018-09-11 19:47:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-06 10:07:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-11 19:47:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-27 16:59:05 -05:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
2018-09-12 11:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2014-11-05 12:26:25 -05:00
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-10 22:41:01 -08:00
|
|
|
|
|
|
|
|
|
2008-07-16 21:53:12 +01:00
|
|
|
|
2021-11-22 10:45:29 +01:00
|
|
|
|
2018-09-13 22:12:15 -04:00
|
|
|
|
2021-11-22 10:45:29 +01:00
|
|
|
|
|
|
|
|
|
2007-05-10 22:22:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-21 22:32:06 -04:00
|
|
|
|
|
|
|
|
|
2021-01-19 10:49:19 -08:00
|
|
|
|
2012-08-21 22:32:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:17 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-10 01:44:34 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-28 16:11:02 -08:00
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
2021-11-18 08:19:10 +01:00
|
|
|
|
tty: Fix ->session locking
Currently, locking of ->session is very inconsistent; most places
protect it using the legacy tty mutex, but disassociate_ctty(),
__do_SAK(), tiocspgrp() and tiocgsid() don't.
Two of the writers hold the ctrl_lock (because they already need it for
->pgrp), but __proc_set_tty() doesn't do that yet.
On a PREEMPT=y system, an unprivileged user can theoretically abuse
this broken locking to read 4 bytes of freed memory via TIOCGSID if
tiocgsid() is preempted long enough at the right point. (Other things
might also go wrong, especially if root-only ioctls are involved; I'm
not sure about that.)
Change the locking on ->session such that:
- tty_lock() is held by all writers: By making disassociate_ctty()
hold it. This should be fine because the same lock can already be
taken through the call to tty_vhangup_session().
The tricky part is that we need to shorten the area covered by
siglock to be able to take tty_lock() without ugly retry logic; as
far as I can tell, this should be fine, since nothing in the
signal_struct is touched in the `if (tty)` branch.
- ctrl_lock is held by all writers: By changing __proc_set_tty() to
hold the lock a little longer.
- All readers that aren't holding tty_lock() hold ctrl_lock: By
adding locking to tiocgsid() and __do_SAK(), and expanding the area
covered by ctrl_lock in tiocspgrp().
Cc: stable@kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-03 02:25:05 +01:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2006-12-13 00:35:09 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-28 16:11:02 -08:00
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
2015-11-08 13:01:14 -05:00
|
|
|
|
|
|
|
|
|
2018-07-20 15:59:17 -05:00
|
|
|
|
2007-02-12 00:53:00 -08:00
|
|
|
|
2015-11-08 13:01:14 -05:00
|
|
|
|
|
|
|
|
|
2006-03-28 16:11:02 -08:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:14 -05:00
|
|
|
|
|
|
|
|
|
2021-11-18 08:19:10 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-21 22:32:06 -04:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:14 -05:00
|
|
|
|
|
|
|
|
|
2021-11-18 08:19:10 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-28 16:11:02 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tty: Fix ->session locking
Currently, locking of ->session is very inconsistent; most places
protect it using the legacy tty mutex, but disassociate_ctty(),
__do_SAK(), tiocspgrp() and tiocgsid() don't.
Two of the writers hold the ctrl_lock (because they already need it for
->pgrp), but __proc_set_tty() doesn't do that yet.
On a PREEMPT=y system, an unprivileged user can theoretically abuse
this broken locking to read 4 bytes of freed memory via TIOCGSID if
tiocgsid() is preempted long enough at the right point. (Other things
might also go wrong, especially if root-only ioctls are involved; I'm
not sure about that.)
Change the locking on ->session such that:
- tty_lock() is held by all writers: By making disassociate_ctty()
hold it. This should be fine because the same lock can already be
taken through the call to tty_vhangup_session().
The tricky part is that we need to shorten the area covered by
siglock to be able to take tty_lock() without ugly retry logic; as
far as I can tell, this should be fine, since nothing in the
signal_struct is touched in the `if (tty)` branch.
- ctrl_lock is held by all writers: By changing __proc_set_tty() to
hold the lock a little longer.
- All readers that aren't holding tty_lock() hold ctrl_lock: By
adding locking to tiocgsid() and __do_SAK(), and expanding the area
covered by ctrl_lock in tiocspgrp().
Cc: stable@kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-03 02:25:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-10 01:44:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-09 18:22:49 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 17:26:15 +08:00
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2010-08-09 18:22:49 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-07-10 21:01:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-07-10 21:01:22 +02:00
|
|
|
|
|
|
|
|
|
2022-03-22 14:41:41 -07:00
|
|
|
|
2014-07-10 21:01:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:37:26 +01:00
|
|
|
|
2018-04-05 19:40:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
|
|
|
|
|
2012-08-08 16:30:13 +01:00
|
|
|
|
2013-06-15 09:14:31 -04:00
|
|
|
|
2013-06-15 09:14:23 -04:00
|
|
|
|
tty: Fix lock order in tty_do_resize()
Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
'tty: Convert termios_mutex to termios_rwsem' and
'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.
The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.
Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.
[1] Lockdep report
======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
(&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b797>] down_read+0x47/0x5c
[<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #1 (console_lock){+.+.+.}:
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff810430a7>] console_lock+0x77/0x80
[<ffffffff8146b2a1>] con_flush_chars+0x31/0x50
[<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0
[<ffffffff814541b9>] tty_write+0x159/0x2e0
[<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0
[<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0
[<ffffffff811abec5>] SyS_write+0x55/0xa0
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
-> #0 (&tty->termios_rwsem){++++..}:
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Chain exists of:
&tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(&tty->termios_rwsem);
*** DEADLOCK ***
7 locks held by modprobe/277:
#0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0
#1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm]
#3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60
#5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320
#6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0
stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012
ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
[<ffffffff81755f19>] dump_stack+0x19/0x1b
[<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c
[<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30
[<ffffffff810b775e>] ? mark_held_locks+0xae/0x120
[<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[<ffffffff810b6d62>] lock_acquire+0x92/0x1f0
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff8175b724>] down_write+0x44/0x70
[<ffffffff81452656>] ? tty_do_resize+0x36/0xe0
[<ffffffff81452656>] tty_do_resize+0x36/0xe0
[<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0
[<ffffffff8146c99f>] vc_resize+0x1f/0x30
[<ffffffff813e4535>] fbcon_init+0x385/0x5a0
[<ffffffff8146a4bc>] visual_init+0xbc/0x120
[<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320
[<ffffffff8146cfa1>] do_take_over_console+0x61/0x70
[<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0
[<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820
[<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110
[<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0
[<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320
[<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
[<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0
[<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290
[<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
[<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau]
[<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau]
[<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm]
[<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff813b13db>] local_pci_probe+0x4b/0x80
[<ffffffff813b1701>] pci_device_probe+0x111/0x120
[<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0
[<ffffffff81497bab>] __driver_attach+0xab/0xb0
[<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0
[<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814971fe>] driver_attach+0x1e/0x20
[<ffffffff81496cc1>] bus_add_driver+0x111/0x290
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff814982b7>] driver_register+0x77/0x170
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffff813b0454>] __pci_register_driver+0x64/0x70
[<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm]
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a000>] ? 0xffffffffa0229fff
[<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau]
[<ffffffff810002ea>] do_one_initcall+0xea/0x1a0
[<ffffffff810c54cb>] load_module+0x123b/0x1bf0
[<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0
[<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810c5f57>] SyS_init_module+0xd7/0x120
[<ffffffff817677c2>] system_call_fastpath+0x16/0x1b
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-24 16:43:51 -04:00
|
|
|
|
2013-06-15 07:04:48 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2006-03-23 03:00:31 -08:00
|
|
|
|
2021-05-05 11:19:06 +02:00
|
|
|
|
2021-05-05 11:19:05 +02:00
|
|
|
|
2016-01-09 21:35:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-13 14:38:58 -07:00
|
|
|
|
2008-10-13 10:42:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-09 18:22:49 +04:00
|
|
|
|
2014-07-10 21:01:22 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:54:13 -07:00
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-07 13:08:37 +00:00
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
2015-05-19 16:06:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-07 13:08:37 +00:00
|
|
|
|
2015-05-19 16:06:53 +01:00
|
|
|
|
2015-09-07 13:08:37 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-22 18:36:53 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-07 22:19:37 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 23:17:47 +02:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:21 -05:00
|
|
|
|
2012-09-06 23:17:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2017-03-30 15:39:36 +02:00
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-11-08 13:01:15 -05:00
|
|
|
|
|
|
|
|
|
2006-04-22 18:36:53 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-22 18:36:53 +02:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2012-09-06 23:17:47 +02:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
|
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 15:39:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2017-03-30 15:39:34 +02:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-06 03:17:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
|
|
|
|
|
2006-08-27 01:24:01 -07:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2015-05-19 16:06:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-04 05:56:32 -03:00
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:00 +01:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 22:26:43 +02:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
|
|
|
|
|
2020-07-23 17:34:22 -05:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-19 16:06:53 +01:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-07 21:47:42 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
2015-05-19 16:06:53 +01:00
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
2012-06-04 13:35:36 +02:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-20 15:45:21 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-06-04 13:35:35 +02:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-08 22:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-08 00:27:12 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-08 00:27:12 -07:00
|
|
|
|
2008-02-08 04:18:47 -08:00
|
|
|
|
|
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:42:09 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-04 13:35:35 +02:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
2012-08-08 22:26:42 +02:00
|
|
|
|
2010-09-05 22:32:22 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-26 09:16:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-03-02 07:22:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-08 00:27:12 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-08 00:27:12 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:36:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 10:41:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-23 13:25:20 +01:00
|
|
|
|
2009-09-18 23:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-16 17:27:21 +01:06
|
|
|
|
2022-11-16 17:27:45 +01:06
|
|
|
|
2022-11-16 17:27:21 +01:06
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-16 17:27:45 +01:06
|
|
|
|
|
|
|
|
|
2011-01-09 16:39:14 +01:00
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-16 17:27:45 +01:06
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-27 12:30:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 15:07:35 -08:00
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
2022-11-16 17:27:45 +01:06
|
|
|
|
|
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 11:07:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-22 11:29:48 -07:00
|
|
|
|
2022-10-22 11:29:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-22 11:29:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-06 16:34:43 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-03-02 12:46:11 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-02 19:58:50 +02:00
|
|
|
|
2015-02-05 11:07:42 +01:00
|
|
|
|
|
|
|
|
|
2010-12-01 18:51:05 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 10:41:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
