[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a5e49715-6098-41d5-f964-9e6c4ff5e602@kernel.dk>
Date: Fri, 6 Mar 2020 07:01:16 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Carlo Nonato <carlo.nonato95@...il.com>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
bfq-iosched@...glegroups.com, oleksandr@...alenko.name,
Kwon Je Oh <kwonje.oh2@...il.com>
Subject: Re: [PATCH BUGFIX] block, bfq: fix overwrite of bfq_group pointer in
bfq_find_set_group()
On 3/6/20 5:27 AM, Carlo Nonato wrote:
> The bfq_find_set_group() function takes as input a blkcg (which represents
> a cgroup) and retrieves the corresponding bfq_group, then it updates the
> bfq internal group hierarchy (see comments inside the function for why
> this is needed) and finally it returns the bfq_group.
> In the hierarchy update cycle, the pointer holding the correct bfq_group
> that has to be returned is mistakenly used to traverse the hierarchy
> bottom to top, meaning that in each iteration it gets overwritten with the
> parent of the current group. Since the update cycle stops at root's
> children (depth = 2), the overwrite becomes a problem only if the blkcg
> describes a cgroup at a hierarchy level deeper than that (depth > 2). In
> this case the root's child that happens to be also an ancestor of the
> correct bfq_group is returned. The main consequence is that processes
> contained in a cgroup at depth greater than 2 are wrongly placed in the
> group described above by BFQ.
>
> This commits fixes this problem by using a different bfq_group pointer in
> the update cycle in order to avoid the overwrite of the variable holding
> the original group reference.
Applied, thanks.
--
Jens Axboe
Powered by blists - more mailing lists