Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230704182442.1015301-1-Liam.Howlett@oracle.com>
In-Reply-To: <20230704182442.1015301-1-Liam.Howlett@oracle.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 4 Jul 2023 11:36:06 -0700
Message-ID: <CAHk-=wjUp5+tcsHG89ieuwa0wUtSWWBWRt8xOsoZ1nskZbbk-g@mail.gmail.com>
Subject: Re: [PATCH] mm/mmap: Clean up validate_mm() calls
To:     "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Oliver Sang <oliver.sang@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 4 Jul 2023 at 11:25, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> validate_mm() calls are too spread out and duplicated in numerous
> locations.  Also, now that the stack write is done under the write lock,
> it is not necessary to validate the mm prior to write operations.

So while I applied the fixes directly since I was doing all the
write-locking stuff (and asked for the locking cleanup), I'm hoping
these kinds of cleanups will now go back to normal and go through
Andrew.

I do have a question related to the write locking: now that we should
always hold the mmap lock for writing when doing any modifications,
can the "lock_is_held()" assertions be tightened?

Right now it's "any locking", but for actual modification it should
probably be using

     lockdep_is_held_type(mt->ma_external_lock, 1)

but there's just one 'mt_lock_is_held()' function (presumably because
the internal lock is always just a spinlock that doesn't have the
reader/writer distinction).

              Linus