Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5618190pxj; Wed, 23 Jun 2021 05:31:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAC/OAoG+fI/upf2tpxWShZpcGgYLeNXXwBm9ype3z6Dy3Mk8s8mBd31nk5h1MAUuIGx/Z X-Received: by 2002:a5d:858b:: with SMTP id f11mr4605161ioj.156.1624451483560; Wed, 23 Jun 2021 05:31:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624451483; cv=none; d=google.com; s=arc-20160816; b=EhsUEr3RYgH109iVwEUNotCRJfkJaKKNKq3ml2NFSac/JIMM3wJ3TH7Jx+SdPayNPR pRXHodIynDdX3vmCTphpzJKQIKJJUEazJmWzJ4zQDJYOF7kn57QJ24lydv5C8EwUgoHM Dt0BTQxOpJMZbvVq60sRXOyryZ1i0WvMqB3dJlhW5ePX1X1+Yvq8q5aCWimnUi/cbJtc 2/s8UWyRts8eGnATnH6+gdVJu/WsHyDvOsRlq8cTe5sS0cABz4OrRPA3I1bMfF9wKcQv Ut2O4TEfYk/orLYwTv2O2wazuTUYg9Q86XkFATVbqqNAnIrSaTCkOBMsG836jcOM3BBT OeRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ssvhA+PgEBaynzMTZvUVS0KXcuA4k/mPLSoeYnB9qB0=; b=02rICgNLXFWoNRLSwyGeGdp6n8hlxDUsnPh4MaiSNOpJoku6Qumt7tmpBxP2xEEvvl IT4VlDRO+8BeeeXABGXMp9WmDGji3AodC5TBqQVKv/W1J/TUI40Gc+9sMirwFQLfgOC8 zIDYa0b+xlHaFoETGJaYUqgrQGpd3Xz7o9vlABbzVhsN28J7goYtcdYisEdsbXaMOPJJ OxH4/yGcJ8x2ya4k9XxeWHTn0sRrKr5LIq9WFtSKxlolgO2xvtYNfw96ml5GOjG0QFJG MQ68YtXoFteL7RNE1gerF4QlAvGVrVJbgR+uiIBQhdxXQnFTE2RTT/gB8zIqdPXxHMWS /sbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q11si22300372ilo.33.2021.06.23.05.31.10; Wed, 23 Jun 2021 05:31:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231193AbhFWMbn (ORCPT + 99 others); Wed, 23 Jun 2021 08:31:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231461AbhFWMbe (ORCPT ); Wed, 23 Jun 2021 08:31:34 -0400 Received: from smtp-42ae.mail.infomaniak.ch (smtp-42ae.mail.infomaniak.ch [IPv6:2001:1600:4:17::42ae]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48924C08C5F1 for ; Wed, 23 Jun 2021 05:26:55 -0700 (PDT) Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4G92ZP0TT1zMprpm; Wed, 23 Jun 2021 14:26:53 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4G92ZN3lv2zlmrrs; Wed, 23 Jun 2021 14:26:52 +0200 (CEST) Subject: Re: [PATCH v2 27/29] docs: userspace-api: landlock.rst: avoid using ReST :doc:`foo` markup To: Mauro Carvalho Chehab , Jonathan Corbet , Linux Doc Mailing List Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org References: <24888a9c5da3c505b2bc274fcd83be348dbaf972.1623824363.git.mchehab+huawei@kernel.org> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <7ebe5a4d-8835-6737-c006-3d065e50dc8a@digikod.net> Date: Wed, 23 Jun 2021 14:26:43 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <24888a9c5da3c505b2bc274fcd83be348dbaf972.1623824363.git.mchehab+huawei@kernel.org> Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/06/2021 08:27, Mauro Carvalho Chehab wrote: > The :doc:`foo` tag is auto-generated via automarkup.py. > So, use the filename at the sources, instead of :doc:`foo`. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/userspace-api/landlock.rst | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) Acked-by: Micka?l Sala?n Like others, I think it would be nice to explain the reason of this change in the commit message, and why it is better than the current way to do it. > > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst > index 62c9361a3c7f..f35552ff19ba 100644 > --- a/Documentation/userspace-api/landlock.rst > +++ b/Documentation/userspace-api/landlock.rst > @@ -145,7 +145,8 @@ Bind mounts and OverlayFS > > Landlock enables to restrict access to file hierarchies, which means that these > access rights can be propagated with bind mounts (cf. > -:doc:`/filesystems/sharedsubtree`) but not with :doc:`/filesystems/overlayfs`. > +Documentation/filesystems/sharedsubtree.rst) but not with > +Documentation/filesystems/overlayfs.rst. > > A bind mount mirrors a source file hierarchy to a destination. The destination > hierarchy is then composed of the exact same files, on which Landlock rules can > @@ -170,8 +171,8 @@ Inheritance > > Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain > restrictions from its parent. This is similar to the seccomp inheritance (cf. > -:doc:`/userspace-api/seccomp_filter`) or any other LSM dealing with task's > -:manpage:`credentials(7)`. For instance, one process's thread may apply > +Documentation/userspace-api/seccomp_filter.rst) or any other LSM dealing with > +task's :manpage:`credentials(7)`. For instance, one process's thread may apply > Landlock rules to itself, but they will not be automatically applied to other > sibling threads (unlike POSIX thread credential changes, cf. > :manpage:`nptl(7)`). > @@ -278,7 +279,7 @@ Memory usage > ------------ > > Kernel memory allocated to create rulesets is accounted and can be restricted > -by the :doc:`/admin-guide/cgroup-v1/memory`. > +by the Documentation/admin-guide/cgroup-v1/memory.rst. > > Questions and answers > ===================== > @@ -303,7 +304,7 @@ issues, especially when untrusted processes can manipulate them (cf. > Additional documentation > ======================== > > -* :doc:`/security/landlock` > +* Documentation/security/landlock.rst > * https://landlock.io > > .. Links >