On 22.02.21 10:38, David Hildenbrand wrote:
On 17.02.21 17:19, James Bottomley wrote:
On Tue, 2021-02-16 at 18:16 +0100, David Hildenbrand wrote:
[...]
The discussion regarding migratability only really popped up
because this is a user-visible thing and not being able to
migrate can be a
On 17.02.21 17:19, James Bottomley wrote:
On Tue, 2021-02-16 at 18:16 +0100, David Hildenbrand wrote:
[...]
The discussion regarding migratability only really popped up
because this is a user-visible thing and not being able to
migrate can be a real problem (fragmentation, ZONE_MOVABLE,
On Tue, 2021-02-16 at 18:16 +0100, David Hildenbrand wrote:
[...]
> > > The discussion regarding migratability only really popped up
> > > because this is a user-visible thing and not being able to
> > > migrate can be a real problem (fragmentation, ZONE_MOVABLE, ...).
> >
> > I think the
For the other parts, the question is what we actually want to let
user space configure.
Being able to specify "Very secure" "maximum secure" "average
secure" all doesn't really make sense to me.
Well, it doesn't to me either unless the user feels a cost/benefit, so
if max cost $100 per
On Tue 16-02-21 08:25:39, James Bottomley wrote:
> On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
> [...]
> > > > What kind of flags are we talking about and why would that be a
> > > > problem with memfd_create interface? Could you be more specific
> > > > please?
> > >
> > > You mean
On Tue, 2021-02-16 at 17:34 +0100, David Hildenbrand wrote:
> On 16.02.21 17:25, James Bottomley wrote:
> > On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
> > [...]
> > > > >What kind of flags are we talking about and why would that
> > > > > be a problem with memfd_create interface?
On 16.02.21 17:25, James Bottomley wrote:
On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
[...]
What kind of flags are we talking about and why would that be a
problem with memfd_create interface? Could you be more specific
please?
You mean what were the ioctl flags in the patch
On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
[...]
> > > What kind of flags are we talking about and why would that be a
> > > problem with memfd_create interface? Could you be more specific
> > > please?
> >
> > You mean what were the ioctl flags in the patch series linked
> > above?
On Mon 15-02-21 10:14:43, James Bottomley wrote:
> On Mon, 2021-02-15 at 10:13 +0100, Michal Hocko wrote:
> > On Sun 14-02-21 11:21:02, James Bottomley wrote:
> > > On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
> > > [...]
> > > > > And here we come to the question "what are the
On Mon, 2021-02-15 at 10:13 +0100, Michal Hocko wrote:
> On Sun 14-02-21 11:21:02, James Bottomley wrote:
> > On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
> > [...]
> > > > And here we come to the question "what are the differences that
> > > > justify a new system call?" and the
On Sun 14-02-21 11:21:02, James Bottomley wrote:
> On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
> [...]
> > > And here we come to the question "what are the differences that
> > > justify a new system call?" and the answer to this is very
> > > subjective. And as such we can
On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
[...]
> > And here we come to the question "what are the differences that
> > justify a new system call?" and the answer to this is very
> > subjective. And as such we can continue bikeshedding forever.
>
> I think this fits into the
> Am 14.02.2021 um 10:20 schrieb Mike Rapoport :
>
> On Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote:
>>> On 12.02.21 00:09, Mike Rapoport wrote:
>>> On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
On 11.02.21 12:27, Mike Rapoport wrote:
> On Thu,
On Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote:
> On 12.02.21 00:09, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> > > On 11.02.21 12:27, Mike Rapoport wrote:
> > > > On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand
On 12.02.21 00:09, Mike Rapoport wrote:
On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
On 11.02.21 12:27, Mike Rapoport wrote:
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
So let's talk about the main user-visible differences to other memfd files
On Fri 12-02-21 00:59:29, Mike Rapoport wrote:
> On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote:
[...]
> > Have a look how hugetlb proliferates through our MM APIs. I strongly
> > suspect this is strong signal that this won't be any different.
> >
> > > And even if yes, adding
On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> On 11.02.21 12:27, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
>
> So let's talk about the main user-visible differences to other memfd files
> (especially, other purely virtual
On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
> [...]
> > Sealing is anyway controlled via fcntl() and I don't think
> > MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> > prevent rogue file sealing in
On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
[...]
> Sealing is anyway controlled via fcntl() and I don't think
> MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> prevent rogue file sealing in tmpfs/hugetlbfs.
This doesn't really match my understanding. The primary
On 11.02.21 12:27, Mike Rapoport wrote:
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
On 11.02.21 09:39, Michal Hocko wrote:
On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
On Tue 09-02-21 11:09:38, Mike
On Thu, Feb 11, 2021 at 11:02:07AM +0100, David Hildenbrand wrote:
>
> Another thought regarding "doesn't have _any_ backing storage"
>
> What are the right semantics when it comes to memory accounting/commit?
>
> As secretmem does not have
> a) any backing storage
> b) cannot go to swap
>
>
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
> On 11.02.21 09:39, Michal Hocko wrote:
> > On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> > [...]
> > >
On Thu, Feb 11, 2021 at 09:39:38AM +0100, Michal Hocko wrote:
> On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> [...]
> > > > Citing my older email:
> > > >
> > > > I've
On 11.02.21 10:38, Michal Hocko wrote:
On Thu 11-02-21 10:01:32, David Hildenbrand wrote:
[...]
AFAIKS, we would need MFD_SECRET and disallow
MFD_ALLOW_SEALING and MFD_HUGETLB.
Yes for an initial version. But I do expect a request to support both
features is just a matter of time.
In
Some random thoughts regarding files.
What is the page size of secretmem memory? Sometimes we use huge pages,
sometimes we fallback to 4k pages. So I assume huge pages in general?
Unless there is an explicit request for hugetlb I would say the page
size is not really important like for any
On Thu 11-02-21 10:01:32, David Hildenbrand wrote:
[...]
> AFAIKS, we would need MFD_SECRET and disallow
> MFD_ALLOW_SEALING and MFD_HUGETLB.
Yes for an initial version. But I do expect a request to support both
features is just a matter of time.
> In addition, we could add MFD_SECRET_NEVER_MAP,
On 11.02.21 09:39, Michal Hocko wrote:
On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
[...]
Citing my older email:
I've hesitated whether to continue to use new flags to
On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
[...]
> > > Citing my older email:
> > >
> > > I've hesitated whether to continue to use new flags to memfd_create()
> > > or to
>
On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> > >
> > > OK, so IIUC this means that the model is to hand over memory from host
> > > to guest. I thought the guest
On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> > On Mon 08-02-21 23:26:05, Mike Rapoport wrote:
> > > On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> > > > On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> > [...]
> >
On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 23:26:05, Mike Rapoport wrote:
> > On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> > > On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> [...]
> > > > The file descriptor based memory has several
On Mon 08-02-21 23:26:05, Mike Rapoport wrote:
> On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> > On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
[...]
> > > The file descriptor based memory has several advantages over the
> > > "traditional" mm interfaces, such as mlock(),
On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Introduce "memfd_secret" system call with the ability to create memory
> > areas visible only in the context of the owning process and not mapped not
> >
On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Introduce "memfd_secret" system call with the ability to create memory
> areas visible only in the context of the owning process and not mapped not
> only to other processes but in the kernel page tables as well.
>
> The
From: Mike Rapoport
Introduce "memfd_secret" system call with the ability to create memory
areas visible only in the context of the owning process and not mapped not
only to other processes but in the kernel page tables as well.
The secretmem feature is off by default and the user must
35 matches
Mail list logo
