Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp318097rwb; Thu, 1 Dec 2022 02:35:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf56IhWp2YzHnEyDEPo/dem9qxl7adKQxqSml5SkTbEYlBvY2rKbmhxlsrXiGeII4VkwGrgp X-Received: by 2002:a17:906:60d0:b0:78d:3f87:1725 with SMTP id f16-20020a17090660d000b0078d3f871725mr4923169ejk.492.1669890919260; Thu, 01 Dec 2022 02:35:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669890919; cv=none; d=google.com; s=arc-20160816; b=0YIO5+6H1ILNEspXDJ6Msa9o8KbWISUn3nDuWoqZW0RQFa4qFq+LaQaCUfFMbij2l5 Dg+ONlsXOZr7iNKfy/sh5okvz21cyE2EWj4FCQQ3OfCxvfPJaN7Y3QTfurVda+5satLx qOqRk4O/jGsROrRD7yYJvQyUZWHHl7ZvPNMsphZwnkANB8VBM/Yn1xWS/XbMnamyBgvD L7g1fhua5ZzGA1+NHj0WSMQNcwRkW6exlzoinZWu5s47dfqhIlU27RsbwhO6s4NBn/5B n+08iMhbZY2x/VHOmHP9Jc9mOOtPy5eNdVwtfU/bxaOV1+2SsDhCdf7eGJq7FVWMsek8 zr9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=HK6pnCi1qP8FFtMs45m05rOGYvqXTvxdOjuW/EuRruE=; b=KDXIvyAK+ZI9/+o3fFR5YDQpLpAtC/sT/QAxqblQ1cfRej3ogHcdwpKa4dsvKvIqVD Bt6bc+P8U3+YZCJYJiyjM0+6k+deaBAD5MfTEGvwCr1f/aLY9rXK6Tynrtx/IRfj3Q2k XcvazYCpNCMSruhRSqRVPMXr5ZIeUOrZGrXUUNJsnZG6H8Osqh1wnuY2Op42FULTOwwu BM0JufxZRfrEAkBRThLiFkQ8TC+ZL9zVdp4ooaEWZ6xugvYfhqPvP652k1yR4ma7gGIm nSYXqiQMp5mAPluEOtP02XfxjXA6qlNbHuxUBF6fPmWzB/wZEFcOXVNIjmk8Z0CyFqDB 1/Rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=NxrdHspK; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id du10-20020a17090772ca00b0079330b37fb6si3408958ejc.880.2022.12.01.02.34.59; Thu, 01 Dec 2022 02:35:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=NxrdHspK; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229831AbiLAKNo (ORCPT + 82 others); Thu, 1 Dec 2022 05:13:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229660AbiLAKNm (ORCPT ); Thu, 1 Dec 2022 05:13:42 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30CA84E6B0; Thu, 1 Dec 2022 02:13:39 -0800 (PST) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C9BC11FD68; Thu, 1 Dec 2022 10:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669889617; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HK6pnCi1qP8FFtMs45m05rOGYvqXTvxdOjuW/EuRruE=; b=NxrdHspKyAj8UHpz/Lx5228Q9gSwTfKblU+hpaFVDzHXNTPxcbg/My1NUxNzXcJNdnMtH4 wmIGrKXGoN5ug8EHCbKfCBfIWZZqe38Q7nW5QCC9n4/P0YXap7XxjkiogrXTLaWr7erOcs m8HIj7DZTw2Zse2xGBZH9p7Cm7pHOt0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669889617; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HK6pnCi1qP8FFtMs45m05rOGYvqXTvxdOjuW/EuRruE=; b=Tv+TFKMVJqS7anEln+zoivlMe9cY38Lal8ihZOtRCNaNknRxo7pu6kzp5EP2BZbvoEBdJS Pcj/xKFM2pttjhBA== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 5EB751320E; Thu, 1 Dec 2022 10:13:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id vJPFFVF+iGOHJQAAGKfGzw (envelope-from ); Thu, 01 Dec 2022 10:13:37 +0000 Date: Thu, 1 Dec 2022 11:13:35 +0100 From: Petr Vorel To: "Jiri Slaby (SUSE)" Cc: dario.binacchi@amarulasolutions.com, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Richard Palethorpe , Petr Vorel , Wolfgang Grandegger , Marc Kleine-Budde , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-can@vger.kernel.org, netdev@vger.kernel.org, stable@vger.kernel.org, Max Staudt , ltp@lists.linux.it Subject: Re: [PATCH] can: slcan: fix freed work crash Message-ID: Reply-To: Petr Vorel References: <20221201073426.17328-1-jirislaby@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221201073426.17328-1-jirislaby@kernel.org> X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Cc LTP mailing list. Jiri, thanks a lot for quick fix! Kind regards, Petr > The LTP test pty03 is causing a crash in slcan: > BUG: kernel NULL pointer dereference, address: 0000000000000008 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] PREEMPT SMP NOPTI > CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 > Workqueue: 0x0 (events) > RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) > Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e > RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 > RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 > RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 > RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 > R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 > R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 > FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 > Call Trace: > > worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) > kthread (/home/rich/kernel/linux/kernel/kthread.c:376) > ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) > Apparently, the slcan's tx_work is freed while being scheduled. While > slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), > slcan_close() (tty side) does not. So when the netdev is never set UP, > but the tty is stuffed with bytes and forced to wakeup write, the work > is scheduled, but never flushed. > So add an additional flush_work() to slcan_close() to be sure the work > is flushed under all circumstances. > The Fixes commit below moved flush_work() from slcan_close() to > slcan_netdev_close(). What was the rationale behind it? Maybe we can > drop the one in slcan_netdev_close()? > I see the same pattern in can327. So it perhaps needs the very same fix. > Fixes: cfcb4465e992 ("can: slcan: remove legacy infrastructure") > Link: https://bugzilla.suse.com/show_bug.cgi?id=1205597 > Reported-by: Richard Palethorpe > Tested-by: Petr Vorel > Cc: Dario Binacchi > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: "David S. Miller" > Cc: Eric Dumazet > Cc: Jakub Kicinski > Cc: Paolo Abeni > Cc: linux-can@vger.kernel.org > Cc: netdev@vger.kernel.org > Cc: stable@vger.kernel.org > Cc: Max Staudt > Signed-off-by: Jiri Slaby (SUSE) > --- > drivers/net/can/slcan/slcan-core.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > diff --git a/drivers/net/can/slcan/slcan-core.c b/drivers/net/can/slcan/slcan-core.c > index fbb34139daa1..f4db77007c13 100644 > --- a/drivers/net/can/slcan/slcan-core.c > +++ b/drivers/net/can/slcan/slcan-core.c > @@ -864,12 +864,14 @@ static void slcan_close(struct tty_struct *tty) > { > struct slcan *sl = (struct slcan *)tty->disc_data; > - /* unregister_netdev() calls .ndo_stop() so we don't have to. > - * Our .ndo_stop() also flushes the TTY write wakeup handler, > - * so we can safely set sl->tty = NULL after this. > - */ > unregister_candev(sl->dev); > + /* > + * The netdev needn't be UP (so .ndo_stop() is not called). Hence make > + * sure this is not running before freeing it up. > + */ > + flush_work(&sl->tx_work); > + > /* Mark channel as dead */ > spin_lock_bh(&sl->lock); > tty->disc_data = NULL;