From: Sasha Levin <levinsasha928@gmail.com>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Jiri Slaby <jirislaby@gmail.com>,
gregkh@linuxfoundation.org, alan@linux.intel.com,
linux-kernel@vger.kernel.org, Dave Jones <davej@redhat.com>
Subject: Re: [PATCH 21/21] TTY: move tty buffers to tty_port
Date: Fri, 30 Nov 2012 18:52:09 -0500 [thread overview]
Message-ID: <50B946A9.9070306@gmail.com> (raw)
In-Reply-To: <1354046255.2444.10.camel@thor>
On 11/27/2012 02:57 PM, Peter Hurley wrote:
> On Sat, 2012-11-03 at 20:53 -0400, Sasha Levin wrote:
>> On 11/03/2012 07:06 PM, Sasha Levin wrote:
>>> On 11/03/2012 11:55 AM, Jiri Slaby wrote:
>>>> On 11/03/2012 03:03 AM, Sasha Levin wrote:
>>>>> On 11/02/2012 12:18 PM, Jiri Slaby wrote:
>>>>>> On 11/02/2012 05:07 PM, Sasha Levin wrote:
>>>>>>> On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>>>>> On 10/31/2012 04:59 PM, Sasha Levin wrote:
>>>>>>>>> So you probably want a lot more than 100k syscalls, why limit it at
>>>>>>>>> all actually?
>>>>>>>>
>>>>>>>> I unset the limit but I still can't reproduce...
>>>>>>>>
>>>>>>>>> I've attached my .config for the guest kernel as reference.
>>>>>>>>
>>>>>>>> Even using this config does not help to reproduce that.
>>>>>>>>
>>>>>>>> Do you use some special trinity params?
>>>>>>>
>>>>>>> Not really:
>>>>>>>
>>>>>>> ./trinity -m --quiet --dangerous -l off
>>>>>>
>>>>>> Oh, you run that as root??
>>>>>>
>>>>>>> Can I add something to my kernel to provide more info when it happens?
>>>>>>
>>>>>> Maybe the attached patch can tell us more...
>>>>>>
>>>>>
>>>>> Nope, I see the warnings mentioned before, without the new 'HUH' warnings.
>>>>
>>>> Actually it does. It is exactly as you wrote some time earlier. The work
>>>> is scheduled after is was cancelled and should not trigger anymore. Or,
>>>> it is scheduled before it is supposed to do. Could you try the attached
>>>> patch and report what happens with that patch?
>>>>
>>>> PS I can't reproduce by whatever I tried.
>>>>
>>>> thanks,
>>>>
>>>
>>> Interesting...
>>>
>>> [ 388.783955] tty is bad=0 ops= (null)Pid: 6480, comm: kworker/1:2 Tainted: G W
>>> 3.7.0-rc3-next-20121102-sasha-00002-gbb570e0-dirty #111
>>
>> So after fuzzing for a while I'm also seeing these:
>>
>> [ 603.533932] tty is bad=-2 ops= (null)Pid: 37, comm: kworker/4:0 Tainted: G W 3.7.0-rc3-next-20121102-sasha-000
>> 02-gbb570e0-dirty #112
>
> Hi Sasha,
>
> Assuming this access-after-free is still reproducible for you, would you
> be willing to try the patch below? I tried to reproduce this and
> couldn't (with multiple cores and with just single core).
>
> It would distinguish between case A (that the buf work is not being
> cancelled) and case B (that the buf work is being scheduled after the
> port has already been freed). It should BUG in case B, which would also
> expose the call chain. It won't help at all in case A though :\
>
> Regards,
> Peter Hurley
>
> -- >% --
> Subject: [PATCH -next] tty: debug: Narrow possible causes of access-after-free
>
>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
> drivers/tty/pty.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index be6a373..893fe69 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -409,6 +409,7 @@ static void pty_cleanup(struct tty_struct *tty)
> {
> tty->port->itty = NULL;
> tty_port_put(tty->port);
> + tty->port = NULL;
> }
>
> /* Traditional BSD devices */
>
Still reproducible, I'm still seeing this with the patch above applied:
[ 1315.419759] ------------[ cut here ]------------
[ 1315.420611] WARNING: at drivers/tty/tty_buffer.c:476 flush_to_ldisc+0x60/0x200()
[ 1315.423098] tty is NULL
[ 1315.423885] Pid: 727, comm: kworker/0:1 Tainted: G W 3.7.0-rc7-next-20121130-sasha-00015-g06fcc7a-dirty #2
[ 1315.427278] Call Trace:
[ 1315.428064] [<ffffffff81c32ae0>] ? flush_to_ldisc+0x60/0x200
[ 1315.429898] [<ffffffff8110dc56>] warn_slowpath_common+0x86/0xb0
[ 1315.431155] [<ffffffff8110dce1>] warn_slowpath_fmt+0x41/0x50
[ 1315.433087] [<ffffffff81c32ae0>] flush_to_ldisc+0x60/0x200
[ 1315.434972] [<ffffffff811319e9>] process_one_work+0x3b9/0x780
[ 1315.436797] [<ffffffff81131898>] ? process_one_work+0x268/0x780
[ 1315.438660] [<ffffffff81c32a80>] ? __tty_buffer_request_room+0x180/0x180
[ 1315.440772] [<ffffffff8113239a>] worker_thread+0x2ca/0x400
[ 1315.442012] [<ffffffff811320d0>] ? rescuer_thread+0x2e0/0x2e0
[ 1315.443821] [<ffffffff8113d0a3>] kthread+0xe3/0xf0
[ 1315.445362] [<ffffffff811824be>] ? put_lock_stats.isra.16+0xe/0x40
[ 1315.447331] [<ffffffff8113cfc0>] ? insert_kthread_work+0x90/0x90
[ 1315.449254] [<ffffffff83cb107c>] ret_from_fork+0x7c/0xb0
[ 1315.450246] [<ffffffff8113cfc0>] ? insert_kthread_work+0x90/0x90
[ 1315.455389] ---[ end trace 63e808312c27e968 ]---
Thanks,
Sasha
next prev parent reply other threads:[~2012-11-30 23:59 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 20:26 [PATCH 00/21] TTY buffer in tty_port and other stuff Jiri Slaby
2012-10-18 20:26 ` [PATCH 01/21] TTY: devpts, don't care about TTY in devpts_get_tty Jiri Slaby
2012-10-18 20:26 ` [PATCH 02/21] TTY: devpts, return created inode from devpts_pty_new Jiri Slaby
2012-10-18 20:26 ` [PATCH 03/21] TTY: devpts, do not set driver_data Jiri Slaby
2012-10-18 20:26 ` [PATCH 04/21] TTY: devpts, document devpts inode operations Jiri Slaby
2012-10-18 20:26 ` [PATCH 05/21] TTY: move devpts kill to pty Jiri Slaby
2012-10-18 20:26 ` [PATCH 06/21] TTY: vt, fix paste_selection ldisc handling Jiri Slaby
2012-10-18 20:26 ` [PATCH 07/21] TTY: ldisc, wait for idle ldisc in release Jiri Slaby
2012-10-18 20:26 ` [PATCH 08/21] TTY: hci_ldisc, remove invalid check in open Jiri Slaby
2012-10-18 20:47 ` Marcel Holtmann
2012-10-18 20:26 ` [PATCH 09/21] TTY: n_tty, simplify read_buf+echo_buf allocation Jiri Slaby
2012-10-18 20:26 ` [PATCH 10/21] TTY: n_tty, remove bogus checks Jiri Slaby
2012-10-18 20:26 ` [PATCH 11/21] TTY: audit, stop accessing tty->icount Jiri Slaby
2012-10-18 20:26 ` [PATCH 12/21] TTY: n_tty, add ldisc data to n_tty Jiri Slaby
2012-10-18 20:26 ` [PATCH 13/21] TTY: move ldisc data from tty_struct: simple members Jiri Slaby
2012-10-18 20:26 ` [PATCH 14/21] TTY: move ldisc data from tty_struct: bitmaps Jiri Slaby
2012-10-18 20:26 ` [PATCH 15/21] TTY: move ldisc data from tty_struct: read_* and echo_* and canon_* stuff Jiri Slaby
2012-10-18 20:26 ` [PATCH 16/21] TTY: move ldisc data from tty_struct: locks Jiri Slaby
2012-10-18 20:26 ` [PATCH 17/21] TTY: n_tty, propagate n_tty_data Jiri Slaby
2012-10-18 20:26 ` [PATCH 18/21] TTY: move TTY_FLUSH* flags to tty_port Jiri Slaby
2012-10-18 20:26 ` [PATCH 19/21] TTY: tty_buffer, cache pointer to tty->buf Jiri Slaby
2012-10-18 20:26 ` [PATCH 20/21] TTY: add port -> tty link Jiri Slaby
2012-10-18 20:26 ` [PATCH 21/21] TTY: move tty buffers to tty_port Jiri Slaby
2012-10-25 18:02 ` Sasha Levin
2012-10-25 18:08 ` Greg KH
2012-10-31 12:53 ` Jiri Slaby
2012-10-31 15:30 ` Sasha Levin
2012-10-31 15:32 ` Jiri Slaby
2012-10-31 15:59 ` Sasha Levin
2012-11-02 15:51 ` Jiri Slaby
2012-11-02 16:07 ` Sasha Levin
2012-11-02 16:18 ` Jiri Slaby
2012-11-02 16:23 ` Sasha Levin
2012-11-03 2:03 ` Sasha Levin
2012-11-03 15:55 ` Jiri Slaby
2012-11-03 23:06 ` Sasha Levin
2012-11-04 0:53 ` Sasha Levin
2012-11-27 19:57 ` Peter Hurley
2012-11-30 23:52 ` Sasha Levin [this message]
2012-12-01 14:59 ` flush_to_ldisc accesses tty after free (was: [PATCH 21/21] TTY: move tty buffers to tty_port) Peter Hurley
2012-12-01 20:06 ` Peter Hurley
2012-12-02 19:57 ` Peter Hurley
2012-12-04 19:21 ` Ilya Zykov
2012-10-31 20:10 ` [PATCH 21/21] TTY: move tty buffers to tty_port Sasha Levin
2012-10-18 21:12 ` [PATCH 00/21] TTY buffer in tty_port and other stuff Greg KH
2012-10-22 14:57 ` Alan Cox
2012-10-22 23:59 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50B946A9.9070306@gmail.com \
--to=levinsasha928@gmail.com \
--cc=alan@linux.intel.com \
--cc=davej@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome