From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EA2AC43460 for ; Fri, 16 Apr 2021 08:35:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78B2161166 for ; Fri, 16 Apr 2021 08:35:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240517AbhDPIgN (ORCPT ); Fri, 16 Apr 2021 04:36:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:35008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240487AbhDPIgK (ORCPT ); Fri, 16 Apr 2021 04:36:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E63046117A; Fri, 16 Apr 2021 08:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618562145; bh=3fqUinZK9zKoBF4djR3n5P+LR2PK0OAFRag8ham6HF0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ELQ7Hx/RT6vhndZPrvCgO3jKinPLP8Rc3MaaJz0gMxb97SVX8SCldaQygzA5WgR9Q v8/E8WVkd4gpYLheYvc6RfUWI/wqrm+W3UF4SXBRAeqziZOv3lMrrR0jQSxq+Lz1pa p4XnQyIBCxf7JEL9jGWysRBtqqESZKKd6LD4DMBKw7hjKiQ+lC5U4C6ob+SpoImel2 CARPpFP/IU1EiHc0APCQR2ivvGUD08Nnyb1xVa1L3rtFxeBXBEDHdOysA+JN7cwFfH eHlPOHSYTphO6WJJsmJJ7dP4Bu8PU4P83JR4YNncfVEaOgg7NkVdFcW+7y/n8AAFb6 q2aIry6J8dyKg== Received: from johan by xi.lan with local (Exim 4.93.0.4) (envelope-from ) id 1lXJx3-0001HE-Hr; Fri, 16 Apr 2021 10:35:45 +0200 Date: Fri, 16 Apr 2021 10:35:45 +0200 From: Johan Hovold To: dillon min Cc: Greg KH , jirislaby@kernel.org, Maxime Coquelin , Alexandre TORGUE , kernel test robot , linux-serial@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Linux ARM , Linux Kernel Mailing List , kbuild-all@lists.01.org, clang-built-linux@googlegroups.com, Gerald Baeza , Erwan Le Ray Subject: Re: [PATCH v2] serial: stm32: optimize spin lock usage Message-ID: References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote: > Hi Johan, Erwan > > It seems still a bit of a problem in the current version, not deadlock > but access register at the same time. > > For driver , we should consider it running under smp, let's think > about it for this case: > > static void stm32_usart_console_write(struct console *co, const char *s, > unsigned int cnt) > { > ..... > local_irq_save(flags); > if (port->sysrq) > locked = 0; > ..... > access register cr1, tdr, isr > ..... > > local_irq_restore(flags); > } > > if port->sysrq is 1, stm32_usart_console_write() just disable local > irq response by local_irq_save(), at the time of access register cr1, > tdr, isr. an TXE interrupt raised, for other cores(I know stm32 > mpu/mcu do not have multi cores, just assume it has), it still has a > chance to handle interrupt. Then there is no lock to protect the uart > register. Right, the sysrq handling is a bit of a hack. > changes to below, should be more safe: > > ..... > if (port->sysrq || oops_in_progress) > locked = spin_trylock_irqsave(&port->lock, flags); Except that the lock debugging code would detect the attempt at recursive locking here and complain loudly on UP. If you really want to fix this, we have uart_unlock_and_check_sysrq() which can be used to defer sysrq processing until the interrupt handler has released the lock. > else > spin_lock_irqsave(&port->lock, flags); > > .... > > if (locked) > spin_unlock_irqrestore(&port->lock, flags); Johan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99D8AC433B4 for ; Fri, 16 Apr 2021 09:04:52 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 142756113B for ; Fri, 16 Apr 2021 09:04:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 142756113B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TRj2cOc6YjEJLmn7l/g4uYarWWKAKbNq3tZdLF//bGI=; b=aTljEgOlckXz5tvwrGF1m5EZQ cgVvjDPxVbQmvTSbqRVN9l5GfyQFISV6ju3I6G34QewqWjvSDj8B+YfcLNoAVcXncPExFRdKUunkK YGl428WOikbNn9OyG2ywLstkYHFxTRlOv2DC8QXhAJnhKASnGSa8zI5T9C/+VLJpdNWaPsZr+DaRr 4mKjQAA0ItTvSzj0HyprLaH7ggKyFTAxnvq1V7oZY9oviFlE4IMoVEgyZB9autPa/5UOrFnmxYQPx 1hQ43OLqR87UkSUmHdunDZEGq5os/U/NY0X0id0HVQLscQavCT+NsXy3q95dcgr9zfc/bdo9os1XC uATbam9YQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lXKMY-001T8J-TW; Fri, 16 Apr 2021 09:02:07 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lXJx7-001NU0-Jr for linux-arm-kernel@desiato.infradead.org; Fri, 16 Apr 2021 08:35:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=y5ByVKQ/qgWV5Woi56knm7JWxtUEy/rq27wAHzVR4MU=; b=sRvsbgGjPhoXr93odAhi8DpbMV Sdl4f9+cRvIY1mVpkC5To245IaEeu9nPAoLn0OwbMFtnQ4Gi7iheFSPzH/jkiP6OvVREoXPmgJsIe Kg7WHAuOU3wfgf/F4IAYbU3ggmO3Hwhn720xoYJJ/q6bbqVHWdlUfO4iNLF3dYw6JyHGmEJkRYPGq 5KqNhrQa5zFbOkCLATinfh97fa5qau7ZRA+RTMwGMUSm1sckF6Ef903MWu57QevweZuQfngeYsKuL EUeOUsl9WGVHspYnn10jtJxViEqIw/9tZFXdHWM8I7GFZ8WwJYwIugkAo2IMkhL9HVouZt0g/TE11 AD4RkR+g==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lXJx5-009CMd-1H for linux-arm-kernel@lists.infradead.org; Fri, 16 Apr 2021 08:35:48 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E63046117A; Fri, 16 Apr 2021 08:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618562145; bh=3fqUinZK9zKoBF4djR3n5P+LR2PK0OAFRag8ham6HF0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ELQ7Hx/RT6vhndZPrvCgO3jKinPLP8Rc3MaaJz0gMxb97SVX8SCldaQygzA5WgR9Q v8/E8WVkd4gpYLheYvc6RfUWI/wqrm+W3UF4SXBRAeqziZOv3lMrrR0jQSxq+Lz1pa p4XnQyIBCxf7JEL9jGWysRBtqqESZKKd6LD4DMBKw7hjKiQ+lC5U4C6ob+SpoImel2 CARPpFP/IU1EiHc0APCQR2ivvGUD08Nnyb1xVa1L3rtFxeBXBEDHdOysA+JN7cwFfH eHlPOHSYTphO6WJJsmJJ7dP4Bu8PU4P83JR4YNncfVEaOgg7NkVdFcW+7y/n8AAFb6 q2aIry6J8dyKg== Received: from johan by xi.lan with local (Exim 4.93.0.4) (envelope-from ) id 1lXJx3-0001HE-Hr; Fri, 16 Apr 2021 10:35:45 +0200 Date: Fri, 16 Apr 2021 10:35:45 +0200 From: Johan Hovold To: dillon min Cc: Greg KH , jirislaby@kernel.org, Maxime Coquelin , Alexandre TORGUE , kernel test robot , linux-serial@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Linux ARM , Linux Kernel Mailing List , kbuild-all@lists.01.org, clang-built-linux@googlegroups.com, Gerald Baeza , Erwan Le Ray Subject: Re: [PATCH v2] serial: stm32: optimize spin lock usage Message-ID: References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210416_013547_127398_1292DAF2 X-CRM114-Status: GOOD ( 19.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote: > Hi Johan, Erwan > > It seems still a bit of a problem in the current version, not deadlock > but access register at the same time. > > For driver , we should consider it running under smp, let's think > about it for this case: > > static void stm32_usart_console_write(struct console *co, const char *s, > unsigned int cnt) > { > ..... > local_irq_save(flags); > if (port->sysrq) > locked = 0; > ..... > access register cr1, tdr, isr > ..... > > local_irq_restore(flags); > } > > if port->sysrq is 1, stm32_usart_console_write() just disable local > irq response by local_irq_save(), at the time of access register cr1, > tdr, isr. an TXE interrupt raised, for other cores(I know stm32 > mpu/mcu do not have multi cores, just assume it has), it still has a > chance to handle interrupt. Then there is no lock to protect the uart > register. Right, the sysrq handling is a bit of a hack. > changes to below, should be more safe: > > ..... > if (port->sysrq || oops_in_progress) > locked = spin_trylock_irqsave(&port->lock, flags); Except that the lock debugging code would detect the attempt at recursive locking here and complain loudly on UP. If you really want to fix this, we have uart_unlock_and_check_sysrq() which can be used to defer sysrq processing until the interrupt handler has released the lock. > else > spin_lock_irqsave(&port->lock, flags); > > .... > > if (locked) > spin_unlock_irqrestore(&port->lock, flags); Johan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7011744106105369185==" MIME-Version: 1.0 From: Johan Hovold To: kbuild-all@lists.01.org Subject: Re: [PATCH v2] serial: stm32: optimize spin lock usage Date: Fri, 16 Apr 2021 10:35:45 +0200 Message-ID: In-Reply-To: List-Id: --===============7011744106105369185== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote: > Hi Johan, Erwan > = > It seems still a bit of a problem in the current version, not deadlock > but access register at the same time. > = > For driver , we should consider it running under smp, let's think > about it for this case: > = > static void stm32_usart_console_write(struct console *co, const char *s, > unsigned int cnt) > { > ..... > local_irq_save(flags); > if (port->sysrq) > locked =3D 0; > ..... > access register cr1, tdr, isr > ..... > = > local_irq_restore(flags); > } > = > if port->sysrq is 1, stm32_usart_console_write() just disable local > irq response by local_irq_save(), at the time of access register cr1, > tdr, isr. an TXE interrupt raised, for other cores(I know stm32 > mpu/mcu do not have multi cores, just assume it has), it still has a > chance to handle interrupt. Then there is no lock to protect the uart > register. Right, the sysrq handling is a bit of a hack. > changes to below, should be more safe: > = > ..... > if (port->sysrq || oops_in_progress) > locked =3D spin_trylock_irqsave(&port->lock, flags); Except that the lock debugging code would detect the attempt at recursive locking here and complain loudly on UP. If you really want to fix this, we have uart_unlock_and_check_sysrq() which can be used to defer sysrq processing until the interrupt handler has released the lock. > else > spin_lock_irqsave(&port->lock, flags); > = > .... > = > if (locked) > spin_unlock_irqrestore(&port->lock, flags); Johan --===============7011744106105369185==--