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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 94CEFC32751 for ; Wed, 31 Jul 2019 18:58:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 684CA214DA for ; Wed, 31 Jul 2019 18:58:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pzLaZSqD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730675AbfGaS6d (ORCPT ); Wed, 31 Jul 2019 14:58:33 -0400 Received: from mail-lf1-f68.google.com ([209.85.167.68]:42762 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726817AbfGaS6c (ORCPT ); Wed, 31 Jul 2019 14:58:32 -0400 Received: by mail-lf1-f68.google.com with SMTP id s19so48213216lfb.9; Wed, 31 Jul 2019 11:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dfwzkRB1EXz9VJ9dIrQ8xrDksaj8jIaBGeToAqjBxZk=; b=pzLaZSqD+v/3JZCkSsk26AW9Eo6y04oP3JAgPhEImxaH9ddeYCWVvB8eE6kmMjRI4d rt4DHIZa2LTcO2qPndNHSZAro2OhrMCdzmtPEK31DeOSt5fIwBfaagONkrDkPNzNWm0X FAtWHZ7xW728jw5/yPivXHvK5zD0DGH8EcceObQX16TopnjWoONXiYxTYxwYLy5d6ksa hJ2RX8Xp/YkcGwbbesTaUJd4lP/xgmxynw9hxATOBhfhZDkYWNnjsnX1pcx1kbl+lR0J xI+0wdN0jW31N0gb918hny0FGKON0xDN90qzGd49fef5J2qL/OdsiyB1Wp9+Ivy3NLQ8 eYhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dfwzkRB1EXz9VJ9dIrQ8xrDksaj8jIaBGeToAqjBxZk=; b=rB+OfkQXxo3EQtJKPKbtvhCt/QiuoYY6q9q2/InI5+24ptVVv3oQknuOoapHGRFBmX mJySKLvcStxY2EKHoieL42dhLsbcjSIvUJHi5EyNWcS4heMohzGdNND+OjuXGDK+Ew4z X57QnLbvTBjSDel2msX+trogPFoNBQK7I7wuw5JwxKIfRWCpkfnXBccP529OGwlqK6Xw Xbv6RDOZgMqUnsF7IUfz8EQUgOgM3ccF5z8R8xERe8rgt8M6KXnnWBJHDP2XgOjYXqPW 2Nqftpi7KrUKTXHXB3qSyXLLVnz8pJ1r5Q/CDqt2ieAmYmK6m0yD1xSKNFRzkBSTYfuL j+iA== X-Gm-Message-State: APjAAAXX3cfxGQYmm2fhOeAFfY1PzfLvgCnxExYPA/PobJ6yr5Urnfmf XrBe3p2uiFPNB/KrciZ+xGk8flr6VtH4/ELucNI= X-Google-Smtp-Source: APXvYqyFQ94uSoTGnAuzPo6MIkxbHzT0H4KE5R2Xg4xbuewViQmMLg86l+y4c8ByxzzHkTp9v1x+8LRm7BJJaEoAHVg= X-Received: by 2002:ac2:4351:: with SMTP id o17mr38095219lfl.100.1564599510043; Wed, 31 Jul 2019 11:58:30 -0700 (PDT) MIME-Version: 1.0 References: <20190721213116.23476-1-mic@digikod.net> <20190721213116.23476-7-mic@digikod.net> <20190727014048.3czy3n2hi6hfdy3m@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 31 Jul 2019 11:58:18 -0700 Message-ID: Subject: Re: [PATCH bpf-next v10 06/10] bpf,landlock: Add a new map type: inode To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , LKML , Alexander Viro , Alexei Starovoitov , Andrew Morton , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , John Johansen , Jonathan Corbet , Kees Cook , Michael Kerrisk , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Stephen Smalley , Tejun Heo , Tetsuo Handa , Thomas Graf , Tycho Andersen , Will Drewry , Kernel Hardening , Linux API , Linux-Fsdevel , LSM List , Network Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 31, 2019 at 11:46 AM Micka=C3=ABl Sala=C3=BCn wrote: > >> + for (i =3D 0; i < htab->n_buckets; i++) { > >> + head =3D select_bucket(htab, i); > >> + hlist_nulls_for_each_entry_safe(l, n, head, hash_node) { > >> + landlock_inode_remove_map(*((struct inode **)l->k= ey), map); > >> + } > >> + } > >> + htab_map_free(map); > >> +} > > > > user space can delete the map. > > that will trigger inode_htab_map_free() which will call > > landlock_inode_remove_map(). > > which will simply itereate the list and delete from the list. > > landlock_inode_remove_map() removes the reference to the map (being > freed) from the inode (with an RCU lock). I'm going to ignore everything else for now and focus only on this bit, since it's fundamental issue to address before this discussion can go any further. rcu_lock is not a spin_lock. I'm pretty sure you know this. But you're arguing that it's somehow protecting from the race I mentioned above?