From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933990AbcBDVsP (ORCPT <rfc822;w@1wt.eu>);
	Thu, 4 Feb 2016 16:48:15 -0500
Received: from mail-pa0-f50.google.com ([209.85.220.50]:36566 "EHLO
	mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932809AbcBDVsL (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 4 Feb 2016 16:48:11 -0500
Subject: Re: tty: tty_struct memory leak
To: Dmitry Vyukov <dvyukov@google.com>
References: <CACT4Y+a3PnypWWL1dbaXmUq0fmJ0qRU6c4Prd5+VwvVXmRR8Qw@mail.gmail.com>
 <CACT4Y+ZMb_HssmyqaWQ9PMqLn7Enoniw_fuTZhb00PiLa_UHuw@mail.gmail.com>
 <56B28CCB.1070909@hurleysoftware.com>
 <CACT4Y+ZDxVoYMZtnWZuK31XFwJaTBjjrjWvB_orPHuWrgLJQjw@mail.gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>, LKML <linux-kernel@vger.kernel.org>,
        syzkaller <syzkaller@googlegroups.com>,
        Kostya Serebryany <kcc@google.com>,
        Alexander Potapenko <glider@google.com>,
        Sasha Levin <sasha.levin@oracle.com>
From: Peter Hurley <peter@hurleysoftware.com>
Message-ID: <56B3C718.4030602@hurleysoftware.com>
Date: Thu, 4 Feb 2016 13:48:08 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CACT4Y+ZDxVoYMZtnWZuK31XFwJaTBjjrjWvB_orPHuWrgLJQjw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 02/04/2016 02:48 AM, Dmitry Vyukov wrote:
> On Thu, Feb 4, 2016 at 12:27 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> Hi Dmitry,
>>
>> On 02/03/2016 08:26 AM, Dmitry Vyukov wrote:
>>> On Wed, Feb 3, 2016 at 5:10 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>>> Hello,
>>>>
>>>> The following program causes tty_struct memory leak:
>>>>
>>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>>> #include <pthread.h>
>>>> #include <stdint.h>
>>>> #include <string.h>
>>>> #include <sys/syscall.h>
>>>> #include <unistd.h>
>>>>
>>>> int main()
>>>> {
>>>>   alarm(1);
>>>>   syscall(SYS_open, "/dev/ircomm7", 0x12d401ul, 0, 0, 0);
>>>>   return 0;
>>>> }
>>
>> Going to need more information than this because the reproducer
>> above does not generate a tty_struct memory leak.
>>
>> Here's what I did:
>>
>> Enabled tty debugging and added patch below [1] to show kfree(tty), then:
>>
>> $ sudo modprobe ircomm
>> $ ./reproducer
>>
>> Here's what I got:
>>
>> [ 1436.864342] tty_ldisc_open: ircomm ircomm7: ffff8802aa3b3410: opened
>> [ 1436.864352] tty_open: ircomm ircomm7: opening (count=1)
>> [ 1437.863994] tty_open: ircomm ircomm7: open error -512, releasing
>> [ 1437.864051] tty_release: ircomm ircomm7: releasing (count=1)
>> [ 1437.864055] tty_wait_until_sent: ircomm ircomm7: wait until sent, timeout=7500
>> [ 1437.864110] tty_release: ircomm ircomm7: final close
>> [ 1437.864120] tty_ldisc_close: ircomm ircomm7: ffff8802aa3b3410: closed
>> [ 1437.864124] tty_ldisc_release: ircomm ircomm7: released
>> [ 1437.864130] tty_release: ircomm ircomm7: release
>> [ 1437.864148] release_one_tty: ircomm ircomm7: freeing structure
>>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Note that release_one_tty() ends in kfree(tty)
> 
> 
> There seems to be some race, please try this one:

Yes, I see the bug now, thanks.


> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> 
> void work()
> {
>   alarm(1);
>   syscall(SYS_open, "/dev/ircomm7", 0x12d401ul, 0, 0, 0);
> }
> 
> int main() {
>   int running, status;
> 
>   for (;;) {
>     while (running < 32) {
>       if (fork() == 0) {
>         work();
>         exit(0);
>       }
>       running++;
>     }
>     if (wait(&status) > 0)
>       running--;
>   }
> }
> 
> 
> If I sample /proc/slabinfo while it runs:
> 
> # cat /proc/slabinfo | egrep "^kmalloc-2048"
> 
> Number of allocated objects constantly grow.
>