Received: by 10.213.65.68 with SMTP id h4csp748337imn; Fri, 23 Mar 2018 15:19:41 -0700 (PDT) X-Google-Smtp-Source: AG47ELt38ZDwdxWlVw5gDDIH2jKqB+Lb9IdoR33vwMgdBnLUzTFw/wGOBEVpjmncHudJLK7qwE4y X-Received: by 10.99.43.70 with SMTP id r67mr11323990pgr.422.1521843581520; Fri, 23 Mar 2018 15:19:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521843581; cv=none; d=google.com; s=arc-20160816; b=T610QheQsVzqNbpLzjfrw5m5zzguR3s1HqZflXS6aKbGAk4iw6gjeqDESZ7lvpl8y8 ECzfiHNTDGWMaAwwCfQ7WBvzNZLXltSj/OnpMC2QBCTwym+n/0oHgNCidhxZn0llfnzF N8ea4PzIDDzwSJ2NClSKNhu3K6oIFkIOHfCE7ZOX+mGvgNIdS2BiWJpyx3oZ0knZyPTm ls9NcgVHfiOmRQ2KxFOd3YWY70hCoXFuaTi9QinKfi9YRMoWHImreOeL9AU+1xWQlsDs vMNRABcl9dZhVM2Zj44Us3U/gcLXrPY57JL3naISh1QJqANjbJgdINEPLwgLa4rjLerQ AHXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:cc:to:from :date:arc-authentication-results; bh=eeXlEnwmRhHAKfBhztyN42sOShEA6MQ727wwL12Ga4Y=; b=dWueZmDRt0GxnS39h31/8kyCJChztiNsKMzUvulxEo/sU9okYK5Yq7RxG6YfHQz//k VwbqyMMnRkLsQEsNOW76oDD6EqUMrZTd9r9MotCWcLJEu7z/wkMZv8Ed12bxP3J6PnPL uEY+o0HTa2jjmP6PYueqtp3XbNQcPYZi571pW78UONAQ3ikHyh9PRpAVaCvn+aqjKgk3 akq95wEwMGonvROZZqLlPbPKjYjuxZZMpXVqWzGYY4ZiqlW4STEtJVPLw/mfiD5Gvv5B XLYFVZwK8pJeNJesfJgEJEh9nQZTlg9JsyNaeNUw/EdxLBeEFpmLFvWDGIEpq1/Gi/e5 c0tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q17si7240706pfg.298.2018.03.23.15.19.27; Fri, 23 Mar 2018 15:19:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218AbeCWWS1 (ORCPT + 99 others); Fri, 23 Mar 2018 18:18:27 -0400 Received: from mail.CARNet.hr ([161.53.123.6]:44892 "EHLO mail.carnet.hr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751541AbeCWWS0 (ORCPT ); Fri, 23 Mar 2018 18:18:26 -0400 Received: from cnzgrivvl-t440p.carpriv.carnet.hr ([161.53.12.131]:46408 helo=gavran.carpriv.carnet.hr) by mail.carnet.hr with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ezV0v-0002Su-BP; Fri, 23 Mar 2018 23:18:21 +0100 Received: by gavran.carpriv.carnet.hr (Postfix, from userid 1000) id 359DB25055; Fri, 23 Mar 2018 23:18:21 +0100 (CET) Date: Fri, 23 Mar 2018 23:18:21 +0100 From: Valentin Vidic To: Marcus Wolf Cc: Greg Kroah-Hartman , Simon =?iso-8859-1?Q?Sandstr=F6m?= , Marcus Wolf , Luca =?iso-8859-1?Q?S=F6the?= , Marcin Ciupak , Michael Panzlaff , Derek Robson , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Message-ID: <20180323221821.GP31333@gavran.carpriv.carnet.hr> References: <20180323094725.4904-1-Valentin.Vidic@CARNet.hr> <20180323114254.GL31333@gavran.carpriv.carnet.hr> <9442615c-5606-328a-f8cc-ad389af55ee3@smarthome-wolf.de> <20180323180027.GM31333@gavran.carpriv.carnet.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180323180027.GM31333@gavran.carpriv.carnet.hr> User-Agent: Mutt/1.9.3 (2018-01-21) X-SA-Exim-Connect-IP: 161.53.12.131 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on rigel.CARNet.hr X-Spam-Level: X-Spam-Status: No, score=-2.9 required=10.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 Subject: Re: [PATCH] staging: pi433: add descriptions for mutex locks X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 23, 2018 at 07:00:27PM +0100, Valentin Vidic wrote: > You are right, here is what kfifo.h says: > > /* > * Note about locking : There is no locking required until only * one reader > * and one writer is using the fifo and no kfifo_reset() will be * called > * kfifo_reset_out() can be safely used, until it will be only called > * in the reader thread. > * For multiple writer and one reader there is only a need to lock the writer. > * And vice versa for only one writer and multiple reader there is only a need > * to lock the reader. > */ > > In the case of pi433 there is only one reader (pi433_tx_thread) and > there is no need for a lock there. But the char device (pi433_write) > might have multiple writers so we leave the mutex just in that function? Ah, but there is a kfifo_reset call in pi433_write that requires a mutex for both readers and writers: "Usage of kfifo_reset is dangerous. It should be only called when the fifo is exclusived locked or when it is secured that no other thread is accessing the fifo." Also kfifo_reset_out would probably not help here: "The usage of kfifo_reset_out is safe until it will be only called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as kfifo_reset." But I have an idea to remove this kfifo_reset call in pi433_write handling partial message writes: kfifo_reset(&device->tx_fifo); // TODO: maybe find a solution, not to discard already stored, valid entries The writer could acquire the lock and than use kfifo_avail to check if there is enough space to write the whole message. What do you think? -- Valentin