Searched hist:"0886196 c" (Results 1 – 7 of 7) sorted by relevance
/openbmc/linux/drivers/vfio/ |
H A D | container.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | virqfd.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
/openbmc/linux/drivers/vfio/pci/ |
H A D | vfio_pci_igd.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | vfio_pci_rdwr.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | vfio_pci_intrs.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | vfio_pci_core.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | vfio_pci_config.c | 0886196c Sun Jan 08 09:44:24 CST 2023 Jason Gunthorpe <jgg@nvidia.com> vfio: Use GFP_KERNEL_ACCOUNT for userspace persistent allocations
Use GFP_KERNEL_ACCOUNT for userspace persistent allocations.
The GFP_KERNEL_ACCOUNT option lets the memory allocator know that this is untrusted allocation triggered from userspace and should be a subject of kmem accounting, and as such it is controlled by the cgroup mechanism.
The way to find the relevant allocations was for example to look at the close_device function and trace back all the kfrees to their allocations.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230108154427.32609-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|