Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Mon, 13 Mar 2023 10:25:19 +0100
Message-Id: <CR55BD4YCDR1.22R5TLYJW6YS0@vincent-arch>
Subject: Re: [RFC PATCH v1 1/1] linux: mm_types: allow to modified the
 vm_flags in vm_area_struct
From:   "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To:     "Andrew Morton" <akpm@linux-foundation.org>
Cc:     <linux-kernel@vger.kernel.org>, <jgg@ziepe.ca>,
        <Liam.Howlett@oracle.com>, <jhubbard@nvidia.com>,
        <david@redhat.com>, <willy@infradead.org>,
        <linux-kernel-mentees@lists.linuxfoundation.org>,
        "Suren Baghdasaryan" <surenb@google.com>
References: <20230312224250.425727-1-vincenzopalazzodev@gmail.com>
 <20230312175703.d8d8e0192387dfa9592ee8e5@linux-foundation.org>
In-Reply-To: <20230312175703.d8d8e0192387dfa9592ee8e5@linux-foundation.org>
Precedence: bulk

On Mon Mar 13, 2023 at 1:57 AM CET, Andrew Morton wrote:
> On Sun, 12 Mar 2023 23:42:50 +0100 Vincenzo Palazzo <vincenzopalazzodev@g=
mail.com> wrote:
>
> > With 6.3-rc1 is not possible to build the following drivers
>
> Well, let's cc Suren who actually wrote bc292ab00f6c ("mm: introduce
> vma->vm_flags wrapper functions").
>
> > - nvidia, that the compilation returns the following errors
> >=20
> > - vboxhost/7.0.6_OSE where the build fails with the following errors
> >=20
> > ...
> >
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -497,7 +497,7 @@ struct vm_area_struct {
> >  	 * To modify use vm_flags_{init|reset|set|clear|mod} functions.
> >  	 */
> >  	union {
> > -		const vm_flags_t vm_flags;
> > +		vm_flags_t vm_flags;
> >  		vm_flags_t __private __vm_flags;
> >  	};
>
> These out-of-tree drivers should be converted to use the wrappers which
> bc292ab00f6c added.  Their maintainers have a couple of months to do
> this before bc292ab00f6c is released in 6.3.

Yeah I thought about that! nvidia update as soon as the 6.3 is out, not sur=
e
about vboxhost. But let the driver update to this new feature make sense.

>
> It's unfortunate.  I guess it would be better if we were to find a way
> to permit these drivers to compile OK but to generate warnings, as an
> interim thing for six months or so.  Perhaps there's some clever way.

Yeah it is! Regarding giving the possiblity to compile ok (and
preserving the previous behavior) look like an interesting thought for=20
kernel API, but am I think that it this is difficult to do?

The real things that I'm missing with the new wrapper API
is the meaning of the new `vm_flags_t vm_flags`, before the=20
field was only one and it was getting modified, but now the real
value is the private one `__vm_flags`, so what is the meaning of=20
the new `vm_flags`?

I feel that this question is stupid but I can not avoid do it, otherwise=20
my mind think about it till I will not find an answer :)

P.S: regaring the warning at compile time the __deprecated looks a good
fit to generate error message, but to me in this particular case do not.

Thanks,

Vincent.