From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753452AbdIEVl4 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 5 Sep 2017 17:41:56 -0400
Received: from shards.monkeyblade.net ([184.105.139.130]:39690 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752719AbdIEVly (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 5 Sep 2017 17:41:54 -0400
Date: Tue, 05 Sep 2017 14:41:53 -0700 (PDT)
Message-Id: <20170905.144153.67687828247988369.davem@davemloft.net>
To: dhowells@redhat.com
Cc: netdev@vger.kernel.org, linux-afs@lists.infradead.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] rxrpc: Make service connection lookup always
 check for retry
From: David Miller <davem@davemloft.net>
In-Reply-To: <150453530801.20359.17059994007095255872.stgit@warthog.procyon.org.uk>
References: <150453530801.20359.17059994007095255872.stgit@warthog.procyon.org.uk>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 05 Sep 2017 14:41:54 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: David Howells <dhowells@redhat.com>
Date: Mon, 04 Sep 2017 15:28:28 +0100

> When an RxRPC service packet comes in, the target connection is looked up
> by an rb-tree search under RCU and a read-locked seqlock; the seqlock retry
> check is, however, currently skipped if we got a match, but probably
> shouldn't be in case the connection we found gets replaced whilst we're
> doing a search.
> 
> Make the lookup procedure always go through need_seqretry(), even if the
> lookup was successful.  This makes sure we always pick up on a write-lock
> event.
> 
> On the other hand, since we don't take a ref on the object, but rely on RCU
> to prevent its destruction after dropping the seqlock, I'm not sure this is
> necessary.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Applied, thanks David.