linux-kernel - Re: [PATCH 11/11] blkcg: implement per-blkg request allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120427154841.GA16237@redhat.com>
Date:	Fri, 27 Apr 2012 11:48:41 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Jeff Moyer <jmoyer@...hat.com>, axboe@...nel.dk,
	ctalbott@...gle.com, rni@...gle.com, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, containers@...ts.linux-foundation.org,
	fengguang.wu@...el.com, hughd@...gle.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 11/11] blkcg: implement per-blkg request allocation

On Fri, Apr 27, 2012 at 08:45:02AM -0700, Tejun Heo wrote:
> On Fri, Apr 27, 2012 at 11:40:34AM -0400, Vivek Goyal wrote:
> > On Fri, Apr 27, 2012 at 08:02:17AM -0700, Tejun Heo wrote:
> > > Hello,
> > > 
> > > On Fri, Apr 27, 2012 at 10:54:01AM -0400, Jeff Moyer wrote:
> > > > > This patch implements per-blkg request_list.  Each blkg has its own
> > > > > request_list and any IO allocates its request from the matching blkg
> > > > > making blkcgs completely isolated in terms of request allocation.
> > > > 
> > > > So, nr_requests is now actually nr_requests * # of blk cgroups.  Is that
> > > > right?  Are you at all concerned about the amount of memory that can be
> > > > tied up as the number of cgroups increases?
> > > 
> > > Yeah, I thought about it and I don't think there's a single good
> > > solution here.  The other extreme would be splitting nr_requests by
> > > the number of cgroups but that seems even worse - each cgroup should
> > > be able to hit maximum throughput.  Given that a lot of workloads tend
> > > to regulate themselves before hitting nr_requests, I think it's best
> > > to leave it as-is and treat each cgroup as having separate channel for
> > > now.  It's a configurable parameter after all.
> > 
> > So on a slow device a malicious application can easily create thousands
> > of group, queue up tons of IO and create unreclaimable memory easily?
> > Sounds little scary. 
> 
> Malicious application may just jack up nr_requests.

Not an unpriviliged malicious application. In typical cgroup scenario, we
can allow unpriviliged users to create child cgroups so that it can
further subdivide its resources to its children group. (ex. put firefox
in one cgroup, open office in another group etc.).

So it is not same as jack up nr_requests.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/