Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Niklas Cassel <Niklas.Cassel@wdc.com>
To:     Bart Van Assche <bvanassche@acm.org>
CC:     Jens Axboe <axboe@kernel.dk>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        Paolo Valente <paolo.valente@linaro.org>,
        Ming Lei <ming.lei@redhat.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Revert "mq-deadline: Fix request accounting"
Thread-Topic: [PATCH 2/2] Revert "mq-deadline: Fix request accounting"
Thread-Index: AQHXo/O2L+LBuS/YJECb1WaT3ju4YKuYrlyAgAAUmwA=
Date:   Tue, 7 Sep 2021 16:28:49 +0000
Message-ID: <YTeTQGrw41k08hgf@x1-carbon>
References: <20210907142145.112096-1-Niklas.Cassel@wdc.com>
 <20210907142145.112096-3-Niklas.Cassel@wdc.com>
 <fdd5ab2a-af90-69bd-2d37-c5060ce68de4@acm.org>
In-Reply-To: <fdd5ab2a-af90-69bd-2d37-c5060ce68de4@acm.org>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WML/CqWsYBlbM5MkbUHNN921O/s3ZCFJj0b+GiSQ91HlhT/qCf0F97QiiM4h?=
 =?us-ascii?Q?UyxnG6yJeDUv+xMaxUBZL0TRQl881wWUQ5wnO7HD3GYwuyAf+pP4vejnPeoO?=
 =?us-ascii?Q?RwapyLLRhBxVceZ4xCqwmwC2pmt/7O8a33T5RytnXp0RSuX9IVj/TNytdW/Y?=
 =?us-ascii?Q?EPRC4rNT9F1Uj0lFRdt4R5tmdZHjo2fWAyky8SUHzmOEWpn8dAFkvEUpMhLg?=
 =?us-ascii?Q?QD9/N2GnLVH7C7KD5vfT3H3tY8DQsmZ5/HxRN/v7PE/Yqv27WWVFIgSisTps?=
 =?us-ascii?Q?UA8zsGwdyX6960dNfIMF4tObw5yXFt2sHWQRMYBiR1yfWFwNmZ1TBA3Cpt6V?=
 =?us-ascii?Q?sFoFgvnKXrfXnVWNxclwa/QcuD2IpqeSxJcO+JZ3KU9pK72J6IJpUIh82t4x?=
 =?us-ascii?Q?dTv3JUU84HrcjLUmVDHuocY3eAUzD1HhcNuwWznXq273VbIAljUAv4vpGm+T?=
 =?us-ascii?Q?163LLWzJnA26AVuf4LUbZTXrcTyEg13BBRb+P5vRp/3QBiV13NszLnSakud1?=
 =?us-ascii?Q?TydZ7gLtu5A9vBds3B/NVBY5FWPilBrFdhWl6g4a1LiVZerzf7RmlrUciJgp?=
 =?us-ascii?Q?AOFmRJO32BGYvDNXnafvgl9I7DxajsWMDSY/yHf1ovFu+IyMdeMRLSvKgHZ4?=
 =?us-ascii?Q?q/GPbT1qAuWzVfLulw0dJ70wL3DFywEF3tZ6PPFXzKFlhP6rLnUdDHzpuROf?=
 =?us-ascii?Q?saq0YgQJNkPdMpJn9JVb4fTDdsAtQHRIyjDHBUvnuxtRDkrPKolgUERwdI3p?=
 =?us-ascii?Q?z/0G3zZu6ABMVS/OPvUHb2B0lI4z6x3E2adDWmGhWYJaHtjiKqOhcY8fokCp?=
 =?us-ascii?Q?eelaw2yQx4JVWcJnAM3/dYr8NBrUmbxEnPlIXuLXpIl1ejBoTNg650XoGB46?=
 =?us-ascii?Q?L0lD5vBXXZy14siW6mpVL3ZKOh3th2RT5TmIFN+aH2NjMhdkV9U6oo0xp35P?=
 =?us-ascii?Q?HSGBuXGNU2HPib4NTpR9++Ons6SA03XpnLOdtMxNJkNdx71bGQlVWcv2lTnx?=
 =?us-ascii?Q?L1YsuMTQ0fieCXUFSiOEovQetjfnI7aCIta2X/GipAskoummzgUssMruLInr?=
 =?us-ascii?Q?qVwcdnGw7Cwb5WFPJCe4ZAtfN51pFVjirZZ7zUQ0V6dowG3CAuyYlSrZ47GT?=
 =?us-ascii?Q?M8yvTCpniQA4xOnZ9+k+sjQ5Bnd7IWvxEHRbbEZUioU0wKhmrcwVQwx0fnpf?=
 =?us-ascii?Q?/mD/hSCi2JuUfXwNjSPX0tmCnDbswmtU81N0toS551m1fNpUw9f0TNKBh+9T?=
 =?us-ascii?Q?jF+bV4/abXSJeJGyjLSEH6u7RE6IwYY+qpnZuc+5uq+z4iPIFHV7G47N7XOL?=
 =?us-ascii?Q?QyvrA9B2Ax1L22Ll95315xb8reSLH6M7zQXEPvAVBkOpXg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8EC5349786523C4D957D251C3B9C2955@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR04MB7158.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 04b03ff2-1279-43b0-72e8-08d9721c92c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2021 16:28:49.5359
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BfWOEdgFM+evmfKJ+hORLDiiVUBaAJehUVpa09aNvSmVeebXNGeW+4UTHJiRrCyfmjgOh/KAaFwA35KPqVZ5iw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR04MB7382
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 07, 2021 at 08:15:03AM -0700, Bart Van Assche wrote:
> On 9/7/21 7:21 AM, Niklas Cassel wrote:
> > blk-mq will no longer call the I/O scheduler .finish_request() callback
> > for requests that were never inserted to the I/O scheduler.
>=20
> I do not agree. Even with patch 1/2 from this series applied, finish_requ=
est()
> will still be called for requests inserted by blk_insert_cloned_request()
> although these requests are never inserted to the I/O scheduler.
>=20
> Bart.

Hello Bart,


Looking at blk_mq_free_request(),
e->type->ops.finish_request() will only be called if RQF_ELVPRIV
is set.

blk_insert_cloned_request() doesn't seem to allocate a request
itself, but instead takes an already cloned request.

So I guess it depends on how the supplied request was cloned.

I would assume if the original request doesn't have RQF_ELVPRIV set,
then neither will the cloned request?

I tried to look at blk_rq_prep_clone(), which seems to be a common
cloning function, but I don't see req->rq_flags being copied
(except for RQF_SPECIAL_PAYLOAD).

Anyway, I don't see how .finish_request() will be called in relation
to blk_insert_cloned_request(). Could you please help me out and
give me an example of a call chain where this can happen?


Kind regards,
Niklas=