Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH BUGFIX] block, bfq: fix overwrite of bfq_group pointer in
 bfq_find_set_group()
To:     Carlo Nonato <carlo.nonato95@gmail.com>
Cc:     linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        bfq-iosched@googlegroups.com, oleksandr@natalenko.name,
        Kwon Je Oh <kwonje.oh2@gmail.com>
References: <20200306122731.5945-1-carlo.nonato95@gmail.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <a5e49715-6098-41d5-f964-9e6c4ff5e602@kernel.dk>
Date:   Fri, 6 Mar 2020 07:01:16 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200306122731.5945-1-carlo.nonato95@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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