From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp05.au.ibm.com ([202.81.31.147]:58302 "EHLO e23smtp05.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754693AbbKYGe6 (ORCPT ); Wed, 25 Nov 2015 01:34:58 -0500 Received: from localhost by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Nov 2015 16:34:55 +1000 Subject: Re: [PATCH] TTY: n_gsm, fix false positive WARN_ON To: Jiri Slaby , Greg Kroah-Hartman References: <1448384067-27300-1-git-send-email-jslaby@suse.cz> Cc: dvyukov@google.com, linux-kernel@vger.kernel.org, Alan Cox , stable From: xinhui Message-ID: <56555613.1040502@linux.vnet.ibm.com> Date: Wed, 25 Nov 2015 14:32:51 +0800 MIME-Version: 1.0 In-Reply-To: <1448384067-27300-1-git-send-email-jslaby@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: hi, Jiri This warning should blame on commit 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()"). When gsm driver failed to activate one mux,there is memory leak. So I call this ->cleanup() to do the cleanup work. Seems I did not consider all cases. I have one confusion. As there is field gsm->num to store the index of gsm_mux[]. so in gsm_cleanup_mux(), why we still use for-loop to find this mux? In error handle path, for example, the call trace in this patch, as we failed to activate it and the gsm->num is invalid(and the value is 0). we can just modify the codes like below: if(gsm_mux[gsm->num] == gsm) ....other work else return; I think it would work, and the logic is correct. Or I just miss something important? thanks xinhui On 2015/11/25 00:54, Jiri Slaby wrote: > Dmitry reported, that the current cleanup code in n_gsm can trigger a > warning: > WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0() > ... > Call Trace: > ... > [] warn_slowpath_null+0x29/0x30 kernel/panic.c:490 > [] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048 > [] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386 > [] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447 > [] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567 > [< inline >] tiocsetd drivers/tty/tty_io.c:2650 > [] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883 > ... > > But this is a legal path when open fails to find a space in the > gsm_mux array and tries to clean up. So make it a standard test > instead of a warning. > > Reported-by: "Dmitry Vyukov" > Cc: Alan Cox > Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com > Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") > Cc: stable > Signed-off-by: Jiri Slaby > --- > drivers/tty/n_gsm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c > index c3fe026d3168..9aff37186246 100644 > --- a/drivers/tty/n_gsm.c > +++ b/drivers/tty/n_gsm.c > @@ -2045,7 +2045,9 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm) > } > } > spin_unlock(&gsm_mux_lock); > - WARN_ON(i == MAX_MUX); > + /* open failed before registering => nothing to do */ > + if (i == MAX_MUX) > + return; > > /* In theory disconnecting DLCI 0 is sufficient but for some > modems this is apparently not the case. */ >