On Sat 07-11-15 23:07:09, Vladimir Davydov wrote:
> This patch marks those kmem allocations that are known to be easily
> triggered from userspace as __GFP_ACCOUNT, which makes them accounted to
> memcg. For the list, see below:
>
> - threadinfo
> - task_struct
> - task_delay_info
> - pid
> - cred
> - mm_struct
> - vm_area_struct and vm_region (nommu)
> - anon_vma and anon_vma_chain
> - signal_struct
> - sighand_struct
> - fs_struct
> - files_struct
> - fdtable and fdtable->full_fds_bits
> - dentry and external_name
> - inode for all filesystems. This is the most tedious part, because
> most filesystems overwrite the alloc_inode method. Looks like using
> __GFP_ACCOUNT in alloc_inode is going to become a new rule, like
> passing SLAB_RECLAIM_ACCOUNT on inode cache creation.
I am wondering whether using a helper function to allocate an inode
cache would help in that regards. It would limit __GFP_ACCOUNT
penetration into fs code.
pipe buffers are trivial to abuse (e.g. via fd passing) so we want to
cap those as well. The following should do the trick AFAICS.
---
diff --git a/fs/pipe.c b/fs/pipe.c
index 8865f7963700..c4b7e8c08362 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -590,7 +590,7 @@ struct pipe_inode_info *alloc_pipe_info(void)
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
- pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL);
+ pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL | __GFP_ACCOUNT);
if (pipe->bufs) {
init_waitqueue_head(&pipe->wait);
pipe->r_counter = pipe->w_counter = 1;
@@ -971,7 +971,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe,
unsigned long nr_pages)
if (nr_pages < pipe->nrbufs)
return -EBUSY;
- bufs = kcalloc(nr_pages, sizeof(*bufs), GFP_KERNEL | __GFP_NOWARN);
+ bufs = kcalloc(nr_pages, sizeof(*bufs), GFP_KERNEL | __GFP_NOWARN |
__GFP_ACCOUNT);
if (unlikely(!bufs))
return -ENOMEM;
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
