[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <310071c8-04b7-4996-a496-614c2bdb8163@eideticom.com>
Date: Thu, 4 Jul 2024 14:43:04 -0600
From: Martin Oliveira <martin.oliveira@...eticom.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-rdma@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
Artemy Kovalyov <artemyko@...dia.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
Michael Guralnik <michaelgur@...dia.com>,
Mike Marciniszyn <mike.marciniszyn@...el.com>, Tejun Heo <tj@...nel.org>,
John Hubbard <jhubbard@...dia.com>, Dan Williams <dan.j.williams@...el.com>,
David Sloan <david.sloan@...eticom.com>
Subject: Re: [PATCH v3 1/3] kernfs: remove page_mkwrite() from
vm_operations_struct
On 2024-07-04 11:02, Matthew Wilcox wrote:> Seems to me we should actually _handle_ that, not do something wrong.
> eg:
>
> if (vma->vm_ops) {
> if (vma->vm_ops->close)
> goto out_put;
> if (WARN_ON(vma->vm_ops->page_mkwrite))
> goto out_put;
> }
Good point.
> or maybe this doesn't need to be a WARN at all? After all, there
> isn't one for having a ->close method, so why is page_mkwrite special?
Hmm yeah, they should probably be treated the same.
Maybe ->close should be converted to WARN as well? It would be easier to
catch an error this way than chasing the EINVAL, but I'm OK either way.
Thanks,
Martin
Powered by blists - more mailing lists