[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y+D9Gkuo1/l0Ty9W@nvidia.com>
Date: Mon, 6 Feb 2023 09:14:02 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Alistair Popple <apopple@...dia.com>
Cc: linux-mm@...ck.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, jhubbard@...dia.com,
tjmercier@...gle.com, hannes@...xchg.org, surenb@...gle.com,
mkoutny@...e.com, daniel@...ll.ch, netdev@...r.kernel.org,
linux-rdma@...r.kernel.org, rds-devel@....oracle.com
Subject: Re: [RFC PATCH 10/19] net: skb: Switch to using vm_account
On Mon, Feb 06, 2023 at 03:36:49PM +1100, Alistair Popple wrote:
> >> But then I don't really know how RDS works, Santos?
> >>
> >> Regardless, maybe the vm_account should be stored in the
> >> rds_msg_zcopy_info ?
> >
> > On first glance that looks like a better spot. Thanks for the
> > idea.
>
> That works fine for RDS but not for skbuff.
I would definately put the RDS stuff like that..
> We still need a vm_account in the struct sock or somewhere else for
> that. For example in msg_zerocopy_realloc() we only have a struct
> ubuf_info_msgzc available. We can't add a struct vm_account field to
> that because ultimately it is stored in struct sk_buff->ck[] which
> is not large enough to contain ubuf_info_msgzc + vm_account.
Well, AFAICT this is using iov_iter to get the pages and in general
iov_iter - eg as used for O_DIRECT - doesn't charge anything.
If this does somehow allow a userspace to hold pin a page for a long
time then it is already technically wrong because it doesn't use
FOLL_LONGTERM.
Arguably FOLL_LONGTERM should be the key precondition to require
accounting.
So I wonder if it should just be deleted?
Jason
Powered by blists - more mailing lists