linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: alexander.kozhevnikov@huawei-partners.com
Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
	linux-security-module@vger.kernel.org,
	jamorris@linux.microsoft.com, selinux@vger.kernel.org,
	stephen.smalley.work@gmail.com, artem.kuzin@huawei.com,
	hw.likun@huawei.com, xiujianfeng@huawei.com,
	yusongping@huawei.com, hukeping@huawei.com
Subject: Re: [PATCH] [RFC] SELINUX: Remove obsolete deferred inode security init list.
Date: Fri, 9 Dec 2022 16:06:01 -0500	[thread overview]
Message-ID: <CAHC9VhSogM2_WrOWTEJAeWz3Pw39fU5L3ioR8425Kxq-W7LiNw@mail.gmail.com> (raw)
In-Reply-To: <ed961349-0996-1e71-a624-cf55d893b2e2@huawei-partners.com>

On Thu, Dec 8, 2022 at 7:29 AM Alexander Kozhevnikov
<alexander.kozhevnikov@huawei-partners.com> wrote:
>      Hi, Paul,
>
> Finally, I hope that I've got answers on all questions which were found
> open on previous attempt:
> 1) RCU accesses. There was a bug in printout code (isec pointers were
> messed up with inode pointers), unfortunately. Now the picture is clear.
> All inodes which were accessed on RCU-walk mode got another access in
> Ref-walk mode right after and got successfully initialized. This is
> exactly as VFS manual suggested.
> 2) Inodes which are left without initialization are coupled with
> directories which are mount points for some other filesystems and
> according to VFS path lookup logic this dentries are substituted by
> root dentries from underlying filesystems by handling mount points
> during link_path_walk(). So this inodes do not have a chance to be
> accessed until this mount points exist. As those generally are special
> filesystems like /sys/fs/cgroup (very good example) there is almost no
> chance for unmount of them.
> The chain of events is quite simple: upper directory created, inode
> added to deferred list, another filesystem mounted to this directory,
> inode is not accessible anymore.
> So, hope that this time I have quite good explanation of the story.

Thanks for the update Alexander.  It sounds like the VFS RCU fallback
is working properly, which should address my worry about revalidating
inodes while in a critical section.

I would suggest updating your patchset based on the previous feedback
and reposting.

-- 
paul-moore.com

      parent reply	other threads:[~2022-12-09 21:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-14 11:18 [PATCH] [RFC] SELINUX: Remove obsolete deferred inode security init list Konstantin Meskhidze
2022-11-14 17:45 ` Paul Moore
2022-11-14 18:09   ` Paul Moore
     [not found]     ` <ef77d0d1-5003-9147-6ba7-ef08a5109ce0@huawei-partners.com>
     [not found]       ` <ed961349-0996-1e71-a624-cf55d893b2e2@huawei-partners.com>
2022-12-09 21:06         ` Paul Moore [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHC9VhSogM2_WrOWTEJAeWz3Pw39fU5L3ioR8425Kxq-W7LiNw@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=alexander.kozhevnikov@huawei-partners.com \
    --cc=artem.kuzin@huawei.com \
    --cc=hukeping@huawei.com \
    --cc=hw.likun@huawei.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=konstantin.meskhidze@huawei.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=xiujianfeng@huawei.com \
    --cc=yusongping@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).