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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EDAFC433F5 for ; Sat, 8 Oct 2022 10:55:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229505AbiJHKzH (ORCPT ); Sat, 8 Oct 2022 06:55:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbiJHKzA (ORCPT ); Sat, 8 Oct 2022 06:55:00 -0400 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CA4F1835B for ; Sat, 8 Oct 2022 03:54:55 -0700 (PDT) Received: from [192.168.0.111] (unknown [46.242.14.200]) by mail.ispras.ru (Postfix) with ESMTPSA id 5F3554077B08; Sat, 8 Oct 2022 10:54:50 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 5F3554077B08 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1665226490; bh=RxbB1yCwkeTFutp5YWkMHM13rc/47srQLY5QYj5ZoPY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Qm/jLw0EMYsSTth59BVCDQh/y0QrX1F3Z4TktZVrMv59ytn/30coN87lZ6aGd6Xi/ g+z/AI1gxPc5JDAddMLWWRCP2DyzPzjvvYjQHGldc0EW6Cp6i5nETVy7hUuYdYyBuM owyK/v5Lya+LIuowBbbzrzlw+zATs8hvC5rONJw8= Message-ID: <3572970f-f40f-5410-651a-a5e019d328d8@ispras.ru> Date: Sat, 8 Oct 2022 13:54:49 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v2] tty: n_gsm: avoid call of sleeping functions from atomic context Content-Language: en-US To: "Starke, Daniel" Cc: Greg Kroah-Hartman , Jiri Slaby , "linux-kernel@vger.kernel.org" , Alexey Khoroshilov , Pavel Machek , lvc-project@linuxtesting.org References: <20220826193545.20363-1-pchelkin@ispras.ru> <20220827091353.30160-1-pchelkin@ispras.ru> <20220919113219.GA14632@duo.ucw.cz> <46a91b24-1c84-3ab8-2508-11720ee9ed5f@ispras.ru> From: Fedor Pchelkin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.10.2022 13:47, Daniel Starke wrote: > This patch breaks packet retransmission. Basically tx_lock and now tx_mutex > protects the transmission packet queue. This works fine as long as packets > are transmitted in a context that allows sleep. However, the retransmission > timer T2 is called from soft IRQ context and spans an additional atomic > context via control_lock within gsm_control_retransmit(). The call path > looks like this: > gsm_control_retransmit() > spin_lock_irqsave(&gsm->control_lock, flags) > gsm_control_transmit() > gsm_data_queue() > mutex_lock(&gsm->tx_mutex) // -> sleep in atomic context As far as switching to tx_mutex turns out to have its own problems, we suggest to revert it and to find another solution for the original issue. As it is described in commit 32dd59f ("tty: n_gsm: fix race condition in gsmld_write()"), the issue is that gsmld_write() may be used by the user directly and also by the n_gsm internal functions. But the proposed solution to add a spinlock around the low side tty write is not suitable since the tty write may sleep: gsmld_write(...) spin_lock_irqsave(&gsm->tx_lock, flags) tty->ops->write(...); con_write(...) do_con_write(...) console_lock() might_sleep() // -> bug So let's consider alternative approaches to avoid the race condition. We have found the only potential concurrency place: gsm->tty->ops->write() in gsmld_output() and tty->ops->write() in gsmld_write(). Is that right? Or there are some other cases? On 05.10.2022 13:47, Daniel Starke wrote: > Long story short: The patch via mutex does not solve the issue. It is only > shifted to another function. I suggest splitting the TX lock into packet > queue lock and underlying tty write mutex. > > I would have implemented the patch if I had means to verify it. Probably splitting the TX lock would be rather complex as there is gsm_data_kick() which in this way has to be protected by packet queue spinlock and at the same time it contains gsmld_output() (via gsm_send_packet()) that would require mutex protection.