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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 604C2C43219 for ; Sun, 28 Apr 2019 14:58:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A6CE206A3 for ; Sun, 28 Apr 2019 14:58:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FkS4Ii4c" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbfD1O57 (ORCPT ); Sun, 28 Apr 2019 10:57:59 -0400 Received: from mail-pf1-f178.google.com ([209.85.210.178]:42976 "EHLO mail-pf1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726374AbfD1O56 (ORCPT ); Sun, 28 Apr 2019 10:57:58 -0400 Received: by mail-pf1-f178.google.com with SMTP id w25so4062865pfi.9 for ; Sun, 28 Apr 2019 07:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=waMIfXogJBcBMNml4iETpbmvT0kEgzeVwh6HfaAnJKc=; b=FkS4Ii4cVrz2/2EzK0RRqujH2IOpIYZ3kyEtqMmyE0S10Tg36QAteTENXehxXvioRy sgqXNbkBroJh3FlP+FzoD7jqJ3sMNyAntzrwc2xaWR2GrWzrZ7Xy9I/AFV7HN6bExDZI x4nZzqjvf20YlIkgkGa/VBPwj9WZbErC4qSKSWsfeZy4giGlUSrWVGV6qCBXKHoyNT89 GzCdIFxxgdUPHsP5HHOeJMyiirXbcqiiAW3eyCZc/nSrw1CbxxbY7WNMvUUEibHeX8wj xQtEn8d8yiyAA0fCxqqLC6bAp8jnkpplKWOcecjBWX3IwEUkmqBKn15scWezRLiBc8mO Qomw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=waMIfXogJBcBMNml4iETpbmvT0kEgzeVwh6HfaAnJKc=; b=bri/saoD3S8I8uqeiJnNwar1nQOGAxf87YZwqUD9+aywYxMLBxy9GT1jwi3CdAzYy3 yKhFAx//kSz9TFxyLyqmKvBFLVCeozh2OMlT9BwLUUlJCo/DS90sPpXEvj/cFXb90WAy /wfHIwZ7eLoWHXaXUhTeYbw53GFZaDui7SAkxFbr5JI3X5EApUXOx1s2cwl2+pnyu+/v lLScst/SKHDJQHDWwfF+COMzKuhbQHIoAN+7Kb/BMPwWpcYU4zr1PETi84lxAsmemRBl hR4RrLu4WiOhwV+Nf54PO7Wf+HnrN5GyzU4Vq0PIuGjLEFbT+jFVeMBF5vw1wTkhsvBh 53ug== X-Gm-Message-State: APjAAAVZ0IakMW+fycDuceN5VChNvtjywCFgF7EuIRP04BjvM8dNYlDg abNFqYt60O1YsI5uNzdB8xVDJwh+ X-Google-Smtp-Source: APXvYqwI0v1i2/3KNPNwkfxWRXDJZCiN+POvnc25zZqBkyDHkXYYacTCBV9/Zl1VK7jCqj5bRERAjg== X-Received: by 2002:a63:c243:: with SMTP id l3mr23873108pgg.448.1556463477515; Sun, 28 Apr 2019 07:57:57 -0700 (PDT) Received: from [192.168.86.235] (c-73-241-150-70.hsd1.ca.comcast.net. [73.241.150.70]) by smtp.gmail.com with ESMTPSA id a129sm47011106pfa.152.2019.04.28.07.57.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Apr 2019 07:57:56 -0700 (PDT) Subject: Re: About ip6_dst_destroy() To: David Ahern , Networking References: <3e01083c-ba34-e515-bb3d-d85a98f90e61@gmail.com> From: Eric Dumazet Message-ID: <024f5668-9ba3-5a1a-14d3-6cb722804965@gmail.com> Date: Sun, 28 Apr 2019 07:57:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 4/27/19 8:22 PM, David Ahern wrote: > On 4/27/19 5:56 PM, Eric Dumazet wrote: >> David >> >> I am staring at ip6_dst_destroy() and the last part makes really no sense to me. >> >> How rcu_read_lock()/rcu_read_unnlock() can help in a writer side ??? >> >> Changlog of a68886a691804d3f6d479ebf6825480fbafb6a00 ("net/ipv6: Make from in rt6_info rcu protected") >> does not make sense either. >> >> >> There is a race window when a FIB entry is deleted and the 'from' on the >> pcpu route is dropped and the pcpu route hits a cookie check. Handle >> this race using rcu on from. >> >> > > A FIB entry (fib6_info) is deleted, but resources are not cleaned up as > there are outstanding references to the entry. Specifically, the > references are the 'from' on pcpu routes. Commit (93531c6743157) added > code to release those references as otherwise there is nothing that > forces it. Further testing hit the condition noted in a68886a69180. > > I presume you are asking about ip6_dst_destroy vs all of the other > 'from' references because of the fib6_info_release - which would result > in an underflow when it is released twice. I guess something like a > rmb() / wmb() pair is needed for this case. I do not see how rmb/wmb pair will help. Writers need to use a stronger synchronization between themselves. This can be some spinlock, a xchg() or cmpxchg() The problem here is that nothing prevent ip6_dst_destroy() being called concurrently with another writer like fib6_drop_pcpu_from() fib6_drop_pcpu_from() uses &table->tb6_lock, which is not held in ip6_dst_destroy() I will submit a patch switching all writers to xchg()