* Re: [PATCH] brd: make rd_size static
From: Jens Axboe @ 2017-03-11 22:29 UTC (permalink / raw)
To: Jason Yan, linux-block; +Cc: miaoxie, zhaohongjiang
In-Reply-To: <1489131159-840-1-git-send-email-yanaijie@huawei.com>
On 03/10/2017 12:32 AM, Jason Yan wrote:
> Fixes the following sparse warning:
>
> drivers/block/brd.c:411:15: warning: symbol 'rd_size' was not declared.
> Should it be static?
If you do a search on this topic, you'll find others that attempted
to do the same. Arm uses it for tag parsing, for some reason, your
patch below would break it.
It'd be great if this was fixed up for real, though.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 0/4 v2] block: Fixes for bdi handling
From: Jens Axboe @ 2017-03-11 22:27 UTC (permalink / raw)
To: Jan Kara
Cc: Tejun Heo, linux-block, Dan Williams, Omar Sandoval, Arthur Marsh,
linux-scsi
In-Reply-To: <20170310102205.GA12421@quack2.suse.cz>
On 03/10/2017 03:22 AM, Jan Kara wrote:
> On Thu 09-03-17 09:41:01, Jens Axboe wrote:
>> On 03/09/2017 03:16 AM, Jan Kara wrote:
>>> Hi!
>>>
>>> this is a second revision of the series fixing the most urgent bugs that were
>>> introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
>>> del_gendisk()" and by 0dba1314d4f8 "scsi, block: fix duplicate bdi name
>>> registration crashes". In fact before these commits we had a different set of
>>> problems in the code but they were less visible :).
>>
>> It was rather urgent to get those fixes in, so I already sent them off.
>> Not a huge deal, but it would be nice to add the atomic init fix as a
>> separate patch later on.
>
> OK, actually my followup fixes remove the counter completely so I guess we
> can just leave it as is.
Yes, if that's the case, then there's little point in an incremental
cleanup.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3] don't forget to call pd_online_fn when activate policy
From: Jens Axboe @ 2017-03-11 22:25 UTC (permalink / raw)
To: Zhou Chengming; +Cc: linux-block, linux-kernel, miaoxie
In-Reply-To: <1489203980-46134-1-git-send-email-zhouchengming1@huawei.com>
On 03/10/2017 08:46 PM, Zhou Chengming wrote:
> When we activate policy on the request_queue, we will create policy_date
> for all the existing blkgs of the request_queue, so we should call
> pd_init_fn() and pd_online_fn() on these newly created policy_data.
I'm not looking at this until you tell me that you have runtime
tested it. I'm assuming you originally ran into some issue
with the lack of calling pd_online_fn?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
From: Jens Axboe @ 2017-03-11 3:59 UTC (permalink / raw)
To: zhouchengming; +Cc: linux-block, linux-kernel, miaoxie
In-Reply-To: <58C3731B.1050200@huawei.com>
> On Mar 10, 2017, at 8:46 PM, zhouchengming <zhouchengming1@huawei.com> wro=
te:
>=20
>> On 2017/3/10 23:12, Jens Axboe wrote:
>>> On 03/08/2017 07:20 PM, Zhou Chengming wrote:
>>> When we activate policy on the request_queue, we will create policy_date=
>>> for all the existing blkgs of the request_queue, so we should call
>>> pd_init_fn() and pd_online_fn() on these newly created policy_data.
>>>=20
>>> Signed-off-by: Zhou Chengming<zhouchengming1@huawei.com>
>>> ---
>>> block/blk-cgroup.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>=20
>>> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
>>> index 8ba0af7..0dd9e76 100644
>>> --- a/block/blk-cgroup.c
>>> +++ b/block/blk-cgroup.c
>>> @@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q=
,
>>> pd->plid =3D pol->plid;
>>> if (pol->pd_init_fn)
>>> pol->pd_init_fn(pd);
>>> +
>>> + if (pol->pd_online_fn) {
>>> + spin_lock(blkg->blkcg->lock);
>>> + pol->pd_online_fn(pd);
>>> + spin_unlock(blkg->blkcg->lock);
>>> + }
>>=20
>> You didn't even compile this, did you?
>>=20
>=20
> Sorry for my carelessness. It's a very minor change, so I didn't compile..=
.
> I will send a patch-v3 that I have compiled. Sorry again..
I don't care how trivial it seems. You always ALWAYS compile and test. Alway=
s. Don't ever send untested patches again, and not even compiling is unforgi=
vable.=20
^ permalink raw reply
* [PATCH v3] don't forget to call pd_online_fn when activate policy
From: Zhou Chengming @ 2017-03-11 3:46 UTC (permalink / raw)
To: axboe; +Cc: linux-block, linux-kernel, miaoxie, zhouchengming1
When we activate policy on the request_queue, we will create policy_date
for all the existing blkgs of the request_queue, so we should call
pd_init_fn() and pd_online_fn() on these newly created policy_data.
Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
---
block/blk-cgroup.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 8ba0af7..1eba1d2 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
pd->plid = pol->plid;
if (pol->pd_init_fn)
pol->pd_init_fn(pd);
+
+ if (pol->pd_online_fn) {
+ spin_lock(&blkg->blkcg->lock);
+ pol->pd_online_fn(pd);
+ spin_unlock(&blkg->blkcg->lock);
+ }
}
__set_bit(pol->plid, q->blkcg_pols);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
From: zhouchengming @ 2017-03-11 3:46 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, linux-kernel, miaoxie
In-Reply-To: <54047101-8ad6-a4fd-dda6-25c2551a3a3c@kernel.dk>
On 2017/3/10 23:12, Jens Axboe wrote:
> On 03/08/2017 07:20 PM, Zhou Chengming wrote:
>> When we activate policy on the request_queue, we will create policy_date
>> for all the existing blkgs of the request_queue, so we should call
>> pd_init_fn() and pd_online_fn() on these newly created policy_data.
>>
>> Signed-off-by: Zhou Chengming<zhouchengming1@huawei.com>
>> ---
>> block/blk-cgroup.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
>> index 8ba0af7..0dd9e76 100644
>> --- a/block/blk-cgroup.c
>> +++ b/block/blk-cgroup.c
>> @@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
>> pd->plid = pol->plid;
>> if (pol->pd_init_fn)
>> pol->pd_init_fn(pd);
>> +
>> + if (pol->pd_online_fn) {
>> + spin_lock(blkg->blkcg->lock);
>> + pol->pd_online_fn(pd);
>> + spin_unlock(blkg->blkcg->lock);
>> + }
>
> You didn't even compile this, did you?
>
Sorry for my carelessness. It's a very minor change, so I didn't compile...
I will send a patch-v3 that I have compiled. Sorry again..
^ permalink raw reply
* Re: [dm-devel] dm-crypt: fix lost ioprio when queuing crypto bios from task with ioprio
From: Eric Wheeler @ 2017-03-11 1:08 UTC (permalink / raw)
To: Mike Snitzer
Cc: Jens Axboe, dm-devel, linux-block, linux-bcache, Mikulas Patocka,
Alasdair Kergon, Shaohua Li, kent.overstreet, Vivek Goyal
In-Reply-To: <20170105165518.GA7376@redhat.com>
On Thu, 5 Jan 2017, Mike Snitzer wrote:
> On Thu, Dec 29 2016 at 11:08pm -0500,
> Eric Wheeler <dm-devel@lists.ewheeler.net> wrote:
>
> > On Sat, 17 Dec 2016, Mike Snitzer wrote:
> > > On Fri, Dec 16 2016 at 5:29pm -0500,
> > > Eric Wheeler <dm-devel@lists.ewheeler.net> wrote:
> > > > On Wed, 14 Dec 2016, Eric Wheeler wrote:
> > > > > Since dm-crypt queues writes (and sometimes reads) to a different kernel
> > > > > thread (workqueue), the bios will dispatch from tasks with different
> > > > > io_context->ioprio settings than the submitting task, thus giving
> > > > > incorrect ioprio hints to the io scheduler.
> > > >
> > > > The motivation of this patch is for ioprio-driven writebackup/bypass
> > > > hinting inside bcache when bcache is under dm-crypt which Jens is picking
> > > > up for 4.10:
> > > > https://lkml.org/lkml/2016/12/6/607
> > >
> > > I now see your commits:
> > > b71de4659fba4e42c7 bcache: introduce per-process ioprio-based bypass/writeback hints
> > > 82e7192711c3855038 bcache: documentation for ioprio cache hinting
> > >
> > > You'd think this is the type of thing that you'd have proposed to a
> > > wider audience.
> >
> > ( Its not really relevant to this bugfix, but please see this thread since
> > you were curious about a wider audience discussion:
> > https://www.redhat.com/archives/dm-devel/2016-July/msg00556.html )
> >
> > The note above in the previous email was intended to explain how we
> > discovered the dm-crypt problem, purely as an example use case. The
> > stable commit note discusses the real issue: lost elevator hints.
> >
> > This commit fixes elevator ioprio hints passing through dm-crypt and is
> > not intended to address dm-cache, nor enable a bcache feature.
> >
> > All impementations using ioprio hints beneath dm-crypt would
> > benefit---most importantly, _CFQ_ !
> >
> > As it is, all ioprio hints passing through dm-crypt are lost to the
> > elevator; the elevator looses those useful bits because of queuing to
> > another thread for crypto operations.
>
> How did you test the change?
We discovered this by noticing that bcache never receives bios marked with
ioprios that were submitted for writing by dm-crypt, but this seems to be
an issue with dm-crypt specifically. Bcache gets ioprio information from
upper-level drivers submitting from the original process context just
fine. If the information is lost to bcache, it is certainly lost to the IO
scheduler. Of course if ioprios are mapped between processes in some other
way that I am missing, then please point that out for me.
Interestingly, before bio_ioprio was split out from bi_rw in about
4.2-4.4, dm-crypt reads were marked fine because they do not usually get
punted to another thread and complete from the submitting process. After
splitting bi_ioprio out of bi_rw, reads broke because the simple cloning
assignment of dst_bio->bi_rw = src_bio->bi_rw loses the priority bits. Of
course this continues now that bi_rw has been pulled and changed into
bi_opf.
I suspect there are other places where bi_rw assignments lost bi_ioprio
assignments long ago, and this probably needs some research and
fixup---but that is a separate issue from the dm-crypt issue.
> Or put differently: what is the easiest test to run against a dm-crypt
> device to verify that ioprio is being passed through?
You would probably need to modify dm-crypt just before it calls
generic_make_request on the way out of writing bio's after encrypting
either in kcryptd_crypt_write_io_submit or dmcrypt_write and calling
something like WARN_ONCE if ioprio_valid(bio_prio(bio)).
Then set your IO priority using ionice on some process writing with direct
IO to the mapper device and see if you get any warnings:
ionice -c3 dd bs=1 of=/dev/mapper/cryptotest if=/dev/zero oflag=direct count=1
My guess is that you will not since bios are cloned without copying ioprio
information and submitted from processes different from those of the
calling thread.
I am curious what you find on your end, please let me know if you have any
questions and thank you for your help!
--
Eric Wheeler
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: NeilBrown @ 2017-03-11 0:47 UTC (permalink / raw)
To: Lars Ellenberg
Cc: Jens Axboe, Jack Wang, LKML, Kent Overstreet, Pavel Machek,
Mike Snitzer, Mikulas Patocka, linux-raid,
device-mapper development, linux-block
In-Reply-To: <CANr6vz8EbRWXq7igGCzRy9JC1Nt=MMma0h8M6nxHQtwiMDa5aQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
On Fri, Mar 10 2017, Lars Ellenberg wrote:
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
>> */
>> blk_qc_t generic_make_request(struct bio *bio)
>> {
>> - struct bio_list bio_list_on_stack;
>> + /*
>> + * bio_list_on_stack[0] contains bios submitted by the current
>> + * make_request_fn.
>> + * bio_list_on_stack[1] contains bios that were submitted before
>> + * the current make_request_fn, but that haven't been processed
>> + * yet.
>> + */
>> + struct bio_list bio_list_on_stack[2];
>> blk_qc_t ret = BLK_QC_T_NONE;
>
> May I suggest that, if you intend to assign something that is not a
> plain &(struct bio_list), but a &(struct bio_list[2]),
> you change the task member so it is renamed (current->bio_list vs
> current->bio_lists, plural, is what I did last year).
> Or you will break external modules, silently, and horribly (or,
> rather, they won't notice, but break the kernel).
> Examples of such modules would be DRBD, ZFS, quite possibly others.
>
This is exactly what I didn't in my first draft (bio_list -> bio_lists),
but then I reverted that change because it didn't seem to be worth the
noise.
It isn't much noise, sched.h, bcache/btree.c, md/dm-bufio.c, and
md/raid1.c get minor changes.
But as I'm hoping to get rid of all of those uses, renaming before
removing seemed pointless ... though admittedly that is what I did for
bioset_create().... I wondered about that too.
The example you give later:
struct bio_list *tmp = current->bio_list;
current->bio_list = NULL;
submit_bio()
current->bio_list = tmp;
won't cause any problem. Whatever lists the parent generic_make_request
is holding onto will be untouched during the submit_bio() call, and will
be exactly as it expects them when this caller returns.
If some out-of-tree code does anything with ->bio_list that makes sense
with the previous code, then it will still make sense with the new
code. However there will be a few bios that it didn't get too look at.
These will all be bios that were submitted by a device further up the
stack (closer to the filesystem), so they *should* be irrelevant.
I could probably come up with some weird behaviour that might have
worked before but now wouldn't quite work the same way. But just fixing
bugs can sometimes affect an out-of-tree driver in a strange way because
it was assuming those bugs.
I hope that I'll soon be able to remove punt_bios_to_rescuer and
flush_current_bio_list, after which current->bio_list can really be
just a list again. I don't think it is worth changing the name for a
transient situation.
But thanks for the review - it encouraged me to think though the
consequences again and I'm now more confident.
I actually now think that change probably wasn't necessary. It is
safer though. It ensures that current functionality isn't removed
without a clear justification.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 06/16] mmc: core: replace waitqueue with worker
From: Jens Axboe @ 2017-03-10 22:05 UTC (permalink / raw)
To: Adrian Hunter, Linus Walleij
Cc: linux-mmc@vger.kernel.org, Ulf Hansson, Paolo Valente,
Chunyan Zhang, Baolin Wang, linux-block, Christoph Hellwig,
Arnd Bergmann
In-Reply-To: <3fc89f9f-fbcf-113d-3644-b6c9dae003f0@intel.com>
On 03/10/2017 07:21 AM, Adrian Hunter wrote:
>> Essentially I take out that thread and replace it with this one worker
>> introduced in this very patch. I agree the driver can block in many ways
>> and that is why I need to have it running in process context, and this
>> is what the worker introduced here provides.
>
> The last time I looked at the blk-mq I/O scheduler code, it pulled up to
> qdepth requests from the I/O scheduler and left them on a local list while
> running ->queue_rq(). That means blocking in ->queue_rq() leaves some
> number of requests in limbo (not issued but also not in the I/O scheduler)
> for that time.
Look again, if we're not handling the requeued dispatches, we pull one
at the time from the scheduler.
--
Jens Axboe
^ permalink raw reply
* Re: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
From: Bart Van Assche @ 2017-03-10 19:37 UTC (permalink / raw)
To: Chaitanya Kulkarni, lsf-pc@lists.linux-foundation.org
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <CO2PR04MB2184DB653C04FB620B41435486670@CO2PR04MB2184.namprd04.prod.outlook.com>
On Tue, 2017-01-10 at 22:40 +0000, Chaitanya Kulkarni wrote:
> Participants:-
> ------------------
> I'd like to invite developers from different subsystems to discuss an app=
roach towards=A0
> a unified testing methodology for storage stack and device drivers belong=
s to=A0
> different subsystems.
>=20
> Topics for Discussion:-
> ------------------------------
> As a part of discussion following are some of the key points which we can=
focus on:-
> 1. What are the common components of the kernel used by the various subsy=
stems?
> 2. What are the potential target drivers which can benefit from this appr=
oach?=A0
> =A0 (e.g. NVMe, NVMe Over Fabric, Open Channel Solid State Drives etc.)
> 3. What are the desired features that can be implemented in this Framewor=
k?
> =A0 (code coverage, unit tests, stress testings, regression, generating C=
occinelle reports etc.)=A0
> 4. Desirable Report generation mechanism?
> 5. Basic performance validation?
> 6. Whether QEMU can be used to emulate some of the H/W functionality to c=
reate a test=A0
> =A0 platform? (Optional subsystem specific)
Regarding existing test software: the SRP test software is a thorough test =
of
the Linux block layer, SCSI core, dm-mpath driver, dm core, SRP initiator a=
nd
target drivers and also of the asynchronous I/O subsystem. This test suite
includes experimental support for the NVMeOF drivers. This test suite suppo=
rts
the rdma_rxe driver which means that an Ethernet adapter is sufficient to r=
un
these tests.
Note: the focus of this test suite is the regular I/O path and device remov=
al.
This test suite neither replaces the libiscsi tests nor xfstests.
See also https://github.com/bvanassche/srp-test.
Bart.=
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Lars Ellenberg @ 2017-03-10 18:51 UTC (permalink / raw)
To: Jack Wang
Cc: Mikulas Patocka, Mike Snitzer, NeilBrown, Jens Axboe, LKML,
Kent Overstreet, Pavel Machek, linux-raid,
device-mapper development, linux-block
In-Reply-To: <153a6cff-c553-0d18-e15b-4f3defc3a42b@profitbricks.com>
On Fri, Mar 10, 2017 at 04:07:58PM +0100, Jack Wang wrote:
> On 10.03.2017 15:55, Mikulas Patocka wrote:
> > On Fri, 10 Mar 2017, Mike Snitzer wrote:
> >> On Fri, Mar 10 2017 at 7:34am -0500,
> >> Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
> >>
> >>>> --- a/block/blk-core.c
> >>>> +++ b/block/blk-core.c
> >>>> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
> >>>> */
> >>>> blk_qc_t generic_make_request(struct bio *bio)
> >>>> {
> >>>> - struct bio_list bio_list_on_stack;
> >>>> + /*
> >>>> + * bio_list_on_stack[0] contains bios submitted by the current
> >>>> + * make_request_fn.
> >>>> + * bio_list_on_stack[1] contains bios that were submitted before
> >>>> + * the current make_request_fn, but that haven't been processed
> >>>> + * yet.
> >>>> + */
> >>>> + struct bio_list bio_list_on_stack[2];
> >>>> blk_qc_t ret = BLK_QC_T_NONE;
> >>>
> >>> May I suggest that, if you intend to assign something that is not a
> >>> plain &(struct bio_list), but a &(struct bio_list[2]),
> >>> you change the task member so it is renamed (current->bio_list vs
> >>> current->bio_lists, plural, is what I did last year).
> >>> Or you will break external modules, silently, and horribly (or,
> >>> rather, they won't notice, but break the kernel).
> >>> Examples of such modules would be DRBD, ZFS, quite possibly others.
> > It's better to make external modules not compile than to silently
> > introduce bugs in them. So yes, I would rename that.
> >
> > Mikulas
>
> Agree, better rename current->bio_list to current->bio_lists
>
> Regards,
> Jack
Thank you.
(I don't know if some one does, but...)
Thing is: *IF* some external thing messes with
current->bio_list in "interesting" ways, and not just the
"I don't care, one level of real recursion fixes this for me"
pattern of
struct bio_list *tmp = current->bio_list;
current->bio_list = NULL;
submit_bio()
current->bio_list = tmp;
you get a chance of stack corruption,
without even as much as a compiler warning.
Which is why I wrote https://lkml.org/lkml/2016/7/8/469
...
Instead, I suggest to distinguish between recursive calls to
generic_make_request(), and pushing back the remainder part in
blk_queue_split(), by pointing current->bio_lists to a
struct recursion_to_iteration_bio_lists {
struct bio_list recursion;
struct bio_list queue;
}
By providing each q->make_request_fn() with an empty "recursion"
bio_list, then merging any recursively submitted bios to the
head of the "queue" list, we can make the recursion-to-iteration
logic in generic_make_request() process deepest level bios first,
and "sibling" bios of the same level in "natural" order.
...
Cheers,
Lars
^ permalink raw reply
* Re: blk_integrity_revalidate() clears BDI_CAP_STABLE_WRITES
From: Ilya Dryomov @ 2017-03-10 16:49 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Jens Axboe, Sagi Grimberg, Mike Snitzer, linux-nvme,
Christoph Hellwig, linux-block, Ceph Development, Dan Williams
In-Reply-To: <yq1zih4pdhn.fsf@oracle.com>
On Thu, Mar 2, 2017 at 4:24 AM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Ilya" == Ilya Dryomov <idryomov@gmail.com> writes:
>
> Ilya,
>
> Ilya> Given the above, I'm not sure what the baseline is --
> Ilya> blk_integrity code isn't invoked for data-only lbafs. Could nvme
> Ilya> folks please look at this? rbd regression caused by integrity
> Ilya> revalidate change goes back to 4.4 and I'd really like to get it
> Ilya> fixed. The proposed patch is attached to my earlier reply on
> Ilya> linux-block.
>
> I've had a couple of fires to attend to this week. I'll try and give
> your patch a spin on my FC setup tomorrow or Friday.
Hi Martin,
Ping... Did you get a chance to try it?
Thanks,
Ilya
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Mike Snitzer @ 2017-03-10 15:35 UTC (permalink / raw)
To: Jack Wang
Cc: Mikulas Patocka, Lars Ellenberg, NeilBrown, Jens Axboe, LKML,
Kent Overstreet, Pavel Machek, linux-raid,
device-mapper development, linux-block
In-Reply-To: <153a6cff-c553-0d18-e15b-4f3defc3a42b@profitbricks.com>
On Fri, Mar 10 2017 at 10:07am -0500,
Jack Wang <jinpu.wang@profitbricks.com> wrote:
>
>
> On 10.03.2017 15:55, Mikulas Patocka wrote:
> >
> >
> > On Fri, 10 Mar 2017, Mike Snitzer wrote:
> >
> >> On Fri, Mar 10 2017 at 7:34am -0500,
> >> Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
> >>
> >>>> --- a/block/blk-core.c
> >>>> +++ b/block/blk-core.c
> >>>> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
> >>>> */
> >>>> blk_qc_t generic_make_request(struct bio *bio)
> >>>> {
> >>>> - struct bio_list bio_list_on_stack;
> >>>> + /*
> >>>> + * bio_list_on_stack[0] contains bios submitted by the current
> >>>> + * make_request_fn.
> >>>> + * bio_list_on_stack[1] contains bios that were submitted before
> >>>> + * the current make_request_fn, but that haven't been processed
> >>>> + * yet.
> >>>> + */
> >>>> + struct bio_list bio_list_on_stack[2];
> >>>> blk_qc_t ret = BLK_QC_T_NONE;
> >>>
> >>> May I suggest that, if you intend to assign something that is not a
> >>> plain &(struct bio_list), but a &(struct bio_list[2]),
> >>> you change the task member so it is renamed (current->bio_list vs
> >>> current->bio_lists, plural, is what I did last year).
> >>> Or you will break external modules, silently, and horribly (or,
> >>> rather, they won't notice, but break the kernel).
> >>> Examples of such modules would be DRBD, ZFS, quite possibly others.
> >>
> >> drbd is upstream -- so what is the problem? (if you are having to
> >> distribute drbd independent of the upstream drbd then why is drbd
> >> upstream?)
> >>
> >> As for ZFS, worrying about ZFS kABI breakage is the last thing we should
> >> be doing.
> >
> > It's better to make external modules not compile than to silently
> > introduce bugs in them. So yes, I would rename that.
> >
> > Mikulas
>
> Agree, better rename current->bio_list to current->bio_lists
Fine, normally wouldn't do so but I'm not so opposed that we need to get
hung up on this detail. If Neil and Jens agree then so be it.
^ permalink raw reply
* Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
From: Jens Axboe @ 2017-03-10 15:12 UTC (permalink / raw)
To: Zhou Chengming; +Cc: linux-block, linux-kernel, miaoxie
In-Reply-To: <1489026008-161611-1-git-send-email-zhouchengming1@huawei.com>
On 03/08/2017 07:20 PM, Zhou Chengming wrote:
> When we activate policy on the request_queue, we will create policy_date
> for all the existing blkgs of the request_queue, so we should call
> pd_init_fn() and pd_online_fn() on these newly created policy_data.
>
> Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
> ---
> block/blk-cgroup.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 8ba0af7..0dd9e76 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
> pd->plid = pol->plid;
> if (pol->pd_init_fn)
> pol->pd_init_fn(pd);
> +
> + if (pol->pd_online_fn) {
> + spin_lock(blkg->blkcg->lock);
> + pol->pd_online_fn(pd);
> + spin_unlock(blkg->blkcg->lock);
> + }
You didn't even compile this, did you?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Jack Wang @ 2017-03-10 15:07 UTC (permalink / raw)
To: Mikulas Patocka, Mike Snitzer
Cc: Lars Ellenberg, NeilBrown, Jens Axboe, LKML, Kent Overstreet,
Pavel Machek, linux-raid, device-mapper development, linux-block
In-Reply-To: <alpine.LRH.2.02.1703100953280.9054@file01.intranet.prod.int.rdu2.redhat.com>
On 10.03.2017 15:55, Mikulas Patocka wrote:
>
>
> On Fri, 10 Mar 2017, Mike Snitzer wrote:
>
>> On Fri, Mar 10 2017 at 7:34am -0500,
>> Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
>>
>>>> --- a/block/blk-core.c
>>>> +++ b/block/blk-core.c
>>>> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
>>>> */
>>>> blk_qc_t generic_make_request(struct bio *bio)
>>>> {
>>>> - struct bio_list bio_list_on_stack;
>>>> + /*
>>>> + * bio_list_on_stack[0] contains bios submitted by the current
>>>> + * make_request_fn.
>>>> + * bio_list_on_stack[1] contains bios that were submitted before
>>>> + * the current make_request_fn, but that haven't been processed
>>>> + * yet.
>>>> + */
>>>> + struct bio_list bio_list_on_stack[2];
>>>> blk_qc_t ret = BLK_QC_T_NONE;
>>>
>>> May I suggest that, if you intend to assign something that is not a
>>> plain &(struct bio_list), but a &(struct bio_list[2]),
>>> you change the task member so it is renamed (current->bio_list vs
>>> current->bio_lists, plural, is what I did last year).
>>> Or you will break external modules, silently, and horribly (or,
>>> rather, they won't notice, but break the kernel).
>>> Examples of such modules would be DRBD, ZFS, quite possibly others.
>>
>> drbd is upstream -- so what is the problem? (if you are having to
>> distribute drbd independent of the upstream drbd then why is drbd
>> upstream?)
>>
>> As for ZFS, worrying about ZFS kABI breakage is the last thing we should
>> be doing.
>
> It's better to make external modules not compile than to silently
> introduce bugs in them. So yes, I would rename that.
>
> Mikulas
Agree, better rename current->bio_list to current->bio_lists
Regards,
Jack
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Mikulas Patocka @ 2017-03-10 14:55 UTC (permalink / raw)
To: Mike Snitzer
Cc: Lars Ellenberg, NeilBrown, Jens Axboe, Jack Wang, LKML,
Kent Overstreet, Pavel Machek, linux-raid,
device-mapper development, linux-block
In-Reply-To: <20170310143822.GA23879@redhat.com>
On Fri, 10 Mar 2017, Mike Snitzer wrote:
> On Fri, Mar 10 2017 at 7:34am -0500,
> Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
>
> > > --- a/block/blk-core.c
> > > +++ b/block/blk-core.c
> > > @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
> > > */
> > > blk_qc_t generic_make_request(struct bio *bio)
> > > {
> > > - struct bio_list bio_list_on_stack;
> > > + /*
> > > + * bio_list_on_stack[0] contains bios submitted by the current
> > > + * make_request_fn.
> > > + * bio_list_on_stack[1] contains bios that were submitted before
> > > + * the current make_request_fn, but that haven't been processed
> > > + * yet.
> > > + */
> > > + struct bio_list bio_list_on_stack[2];
> > > blk_qc_t ret = BLK_QC_T_NONE;
> >
> > May I suggest that, if you intend to assign something that is not a
> > plain &(struct bio_list), but a &(struct bio_list[2]),
> > you change the task member so it is renamed (current->bio_list vs
> > current->bio_lists, plural, is what I did last year).
> > Or you will break external modules, silently, and horribly (or,
> > rather, they won't notice, but break the kernel).
> > Examples of such modules would be DRBD, ZFS, quite possibly others.
>
> drbd is upstream -- so what is the problem? (if you are having to
> distribute drbd independent of the upstream drbd then why is drbd
> upstream?)
>
> As for ZFS, worrying about ZFS kABI breakage is the last thing we should
> be doing.
It's better to make external modules not compile than to silently
introduce bugs in them. So yes, I would rename that.
Mikulas
> So Nack from me on this defensive make-work for external modules.
>
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Mike Snitzer @ 2017-03-10 14:38 UTC (permalink / raw)
To: Lars Ellenberg
Cc: NeilBrown, Jens Axboe, Jack Wang, LKML, Kent Overstreet,
Pavel Machek, Mikulas Patocka, linux-raid,
device-mapper development, linux-block
In-Reply-To: <CANr6vz8EbRWXq7igGCzRy9JC1Nt=MMma0h8M6nxHQtwiMDa5aQ@mail.gmail.com>
On Fri, Mar 10 2017 at 7:34am -0500,
Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
> > */
> > blk_qc_t generic_make_request(struct bio *bio)
> > {
> > - struct bio_list bio_list_on_stack;
> > + /*
> > + * bio_list_on_stack[0] contains bios submitted by the current
> > + * make_request_fn.
> > + * bio_list_on_stack[1] contains bios that were submitted before
> > + * the current make_request_fn, but that haven't been processed
> > + * yet.
> > + */
> > + struct bio_list bio_list_on_stack[2];
> > blk_qc_t ret = BLK_QC_T_NONE;
>
> May I suggest that, if you intend to assign something that is not a
> plain &(struct bio_list), but a &(struct bio_list[2]),
> you change the task member so it is renamed (current->bio_list vs
> current->bio_lists, plural, is what I did last year).
> Or you will break external modules, silently, and horribly (or,
> rather, they won't notice, but break the kernel).
> Examples of such modules would be DRBD, ZFS, quite possibly others.
drbd is upstream -- so what is the problem? (if you are having to
distribute drbd independent of the upstream drbd then why is drbd
upstream?)
As for ZFS, worrying about ZFS kABI breakage is the last thing we should
be doing.
So Nack from me on this defensive make-work for external modules.
^ permalink raw reply
* Re: [PATCH 06/16] mmc: core: replace waitqueue with worker
From: Adrian Hunter @ 2017-03-10 14:21 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-mmc@vger.kernel.org, Ulf Hansson, Paolo Valente,
Chunyan Zhang, Baolin Wang, linux-block, Jens Axboe,
Christoph Hellwig, Arnd Bergmann
In-Reply-To: <CACRpkdYOyEs8vxmPt1kGiKJrw8+16DyD8Nn=ke6mgxPaCQynCw@mail.gmail.com>
On 10/03/17 00:49, Linus Walleij wrote:
> On Wed, Feb 22, 2017 at 2:29 PM, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 09/02/17 17:33, Linus Walleij wrote:
>>> The waitqueue in the host context is there to signal back from
>>> mmc_request_done() through mmc_wait_data_done() that the hardware
>>> is done with a command, and when the wait is over, the core
>>> will typically submit the next asynchronous request that is pending
>>> just waiting for the hardware to be available.
>>>
>>> This is in the way for letting the mmc_request_done() trigger the
>>> report up to the block layer that a block request is finished.
>>>
>>> Re-jig this as a first step, remvoving the waitqueue and introducing
>>> a work that will run after a completed asynchronous request,
>>> finalizing that request, including retransmissions, and eventually
>>> reporting back with a completion and a status code to the
>>> asynchronous issue method.
>>>
>>> This had the upside that we can remove the MMC_BLK_NEW_REQUEST
>>> status code and the "new_request" state in the request queue
>>> that is only there to make the state machine spin out
>>> the first time we send a request.
>>>
>>> Introduce a workqueue in the host for handling just this, and
>>> then a work and completion in the asynchronous request to deal
>>> with this mechanism.
>>>
>>> This is a central change that let us do many other changes since
>>> we have broken the submit and complete code paths in two, and we
>>> can potentially remove the NULL flushing of the asynchronous
>>> pipeline and report block requests as finished directly from
>>> the worker.
>>
>> This needs more thought. The completion should go straight to the mmc block
>> driver from the ->done() callback. And from there straight back to the
>> block layer if recovery is not needed. We want to stop using
>> mmc_start_areq() altogether because we never want to wait - we always want
>> to issue (if possible) and return.
>
> I don't quite follow this. Isn't what you request exactly what
> patch 15/16 "mmc: queue: issue requests in massive parallel"
> is doing?
There is the latency for the worker that runs mmc_finalize_areq() and then
another latency to wake up the worker that is running mmc_start_areq().
That is 2 wake-ups instead of 1.
As a side note, ideally we would be able to issue the next request from the
interrupt or soft interrupt context of the completion (i.e. 0 wake-ups
between requests), but we would probably have to look at the host API to
support that.
>
> The whole patch series leads up to that.
>
>> The core API to use is __mmc_start_req() but the block driver should
>> populate mrq->done with its own handler. i.e. change __mmc_start_req()
>>
>> - mrq->done = mmc_wait_done;
>> + if (!mrq->done)
>> + mrq->done = mmc_wait_done;
>>
>> mrq->done() would complete the request (e.g. via blk_complete_request()) if
>> it has no errors (and doesn't need polling), and wake up the queue thread to
>> finish up everything else and start the next request.
>
> I think this is what it does at the end of the patch series, patch 15/16.
> I have to split it somehow...
>
>> For the blk-mq port, the queue thread should also be retained, partly
>> because it solves some synchronization problems, but mostly because, at this
>> stage, we anyway don't have solutions for all the different ways the driver
>> can block.
>> (as listed here https://marc.info/?l=linux-mmc&m=148336571720463&w=2 )
>
> Essentially I take out that thread and replace it with this one worker
> introduced in this very patch. I agree the driver can block in many ways
> and that is why I need to have it running in process context, and this
> is what the worker introduced here provides.
The last time I looked at the blk-mq I/O scheduler code, it pulled up to
qdepth requests from the I/O scheduler and left them on a local list while
running ->queue_rq(). That means blocking in ->queue_rq() leaves some
number of requests in limbo (not issued but also not in the I/O scheduler)
for that time.
Maybe blk-mq should offer a pull interface to I/O scheduler users?
^ permalink raw reply
* Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
From: kbuild test robot @ 2017-03-10 12:44 UTC (permalink / raw)
To: Zhou Chengming
Cc: kbuild-all, axboe, linux-block, linux-kernel, miaoxie,
zhouchengming1
In-Reply-To: <1489026008-161611-1-git-send-email-zhouchengming1@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
Hi Zhou,
[auto build test ERROR on block/for-next]
[also build test ERROR on v4.11-rc1 next-20170309]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zhou-Chengming/don-t-forget-to-call-pd_online_fn-when-activate-policy/20170310-140301
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
block/blk-cgroup.c: In function 'blkcg_activate_policy':
>> block/blk-cgroup.c:1261:14: error: incompatible type for argument 1 of 'spin_lock'
spin_lock(blkg->blkcg->lock);
^~~~
In file included from include/linux/rcupdate.h:38:0,
from include/linux/rculist.h:10,
from include/linux/pid.h:4,
from include/linux/sched.h:13,
from include/linux/ioprio.h:4,
from block/blk-cgroup.c:17:
include/linux/spinlock.h:297:29: note: expected 'spinlock_t * {aka struct spinlock *}' but argument is of type 'spinlock_t {aka struct spinlock}'
static __always_inline void spin_lock(spinlock_t *lock)
^~~~~~~~~
>> block/blk-cgroup.c:1263:16: error: incompatible type for argument 1 of 'spin_unlock'
spin_unlock(blkg->blkcg->lock);
^~~~
In file included from include/linux/rcupdate.h:38:0,
from include/linux/rculist.h:10,
from include/linux/pid.h:4,
from include/linux/sched.h:13,
from include/linux/ioprio.h:4,
from block/blk-cgroup.c:17:
include/linux/spinlock.h:337:29: note: expected 'spinlock_t * {aka struct spinlock *}' but argument is of type 'spinlock_t {aka struct spinlock}'
static __always_inline void spin_unlock(spinlock_t *lock)
^~~~~~~~~~~
vim +/spin_lock +1261 block/blk-cgroup.c
1255 pd->blkg = blkg;
1256 pd->plid = pol->plid;
1257 if (pol->pd_init_fn)
1258 pol->pd_init_fn(pd);
1259
1260 if (pol->pd_online_fn) {
> 1261 spin_lock(blkg->blkcg->lock);
1262 pol->pd_online_fn(pd);
> 1263 spin_unlock(blkg->blkcg->lock);
1264 }
1265 }
1266
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38803 bytes --]
^ permalink raw reply
* Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
From: Lars Ellenberg @ 2017-03-10 12:34 UTC (permalink / raw)
To: NeilBrown
Cc: Jens Axboe, Jack Wang, LKML, Kent Overstreet, Pavel Machek,
Mike Snitzer, Mikulas Patocka, linux-raid,
device-mapper development, linux-block
In-Reply-To: <87varhg14d.fsf@notabene.neil.brown.name>
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
> */
> blk_qc_t generic_make_request(struct bio *bio)
> {
> - struct bio_list bio_list_on_stack;
> + /*
> + * bio_list_on_stack[0] contains bios submitted by the current
> + * make_request_fn.
> + * bio_list_on_stack[1] contains bios that were submitted before
> + * the current make_request_fn, but that haven't been processed
> + * yet.
> + */
> + struct bio_list bio_list_on_stack[2];
> blk_qc_t ret = BLK_QC_T_NONE;
May I suggest that, if you intend to assign something that is not a
plain &(struct bio_list), but a &(struct bio_list[2]),
you change the task member so it is renamed (current->bio_list vs
current->bio_lists, plural, is what I did last year).
Or you will break external modules, silently, and horribly (or,
rather, they won't notice, but break the kernel).
Examples of such modules would be DRBD, ZFS, quite possibly others.
Thanks,
Lars
^ permalink raw reply
* Re: [PATCH 0/4 v2] block: Fixes for bdi handling
From: Jan Kara @ 2017-03-10 10:22 UTC (permalink / raw)
To: Jens Axboe
Cc: Jan Kara, Tejun Heo, linux-block, Dan Williams, Omar Sandoval,
Arthur Marsh, linux-scsi
In-Reply-To: <7177cebf-8a9b-10d4-e991-5e43f4303ffc@kernel.dk>
On Thu 09-03-17 09:41:01, Jens Axboe wrote:
> On 03/09/2017 03:16 AM, Jan Kara wrote:
> > Hi!
> >
> > this is a second revision of the series fixing the most urgent bugs that were
> > introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
> > del_gendisk()" and by 0dba1314d4f8 "scsi, block: fix duplicate bdi name
> > registration crashes". In fact before these commits we had a different set of
> > problems in the code but they were less visible :).
>
> It was rather urgent to get those fixes in, so I already sent them off.
> Not a huge deal, but it would be nice to add the atomic init fix as a
> separate patch later on.
OK, actually my followup fixes remove the counter completely so I guess we
can just leave it as is.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH RFC 22/39] mmc: block: Prepare CQE data
From: Adrian Hunter @ 2017-03-10 8:29 UTC (permalink / raw)
To: Linus Walleij, linux-block, Paolo Valente, Jens Axboe
Cc: Ulf Hansson, linux-mmc, Alex Lemberg, Mateusz Nowak,
Yuliy Izrailov, Jaehoon Chung, Dong Aisheng, Das Asutosh,
Zhangfei Gao, Dorfman Konstantin, David Griego, Sahitya Tummala,
Harjani Ritesh, Venu Byravarasu
In-Reply-To: <CACRpkdbjmUWw=ZPsVGGCS=6bsho=qw=OQVaE3p4AJWuccyGXag@mail.gmail.com>
On 10/03/17 00:39, Linus Walleij wrote:
> On Fri, Mar 3, 2017 at 1:22 PM, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 15/02/17 15:49, Linus Walleij wrote:
>>> On Fri, Feb 10, 2017 at 1:55 PM, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>
>>>> Enhance mmc_blk_data_prep() to support CQE requests.
>>>>
>>>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>>>
>>> Hey:
>>>
>>>> +#include <linux/ioprio.h>
>>> (...)
>>>> + if (IOPRIO_PRIO_CLASS(req_get_ioprio(req)) == IOPRIO_CLASS_RT)
>>>> + brq->data.flags |= MMC_DATA_PRIO;
>>>
>>> What is this?
>>
>> It is the command queue priority.
>>
>> The command queue supports 2 priorities: "high" (1) and "simple" (0). The
>> eMMC will give "high" priority tasks priority over "simple" priority tasks.
>>
>> So here we give priority to IOPRIO_CLASS_RT which seems appropriate.
>
> So if I understand correctly, you are obtaining the block layer scheduling
> priorities, that can (only?) be set by ionice has from the command line?
AFAICS it is the ioprio_set() system call .
>
> We need to discuss this with the block maintainers.
>
> I'm not so sure about the future of this. The IOPRIO is only used with the CFQ
> scheduler, only two other sites in the kernel use this and MQ and its schedulers
> surely does not have ionice handling as far as I know.
>
> The BFQ does not use it, AFAIK it is using different heuristics to prioritize
> block traffic, and that does not include using ionice hints.
>
> Is ionice:ing something we're really going to do going forward?
> Should this be repurposed so that the block scheduler use this prio to
> communicate to the driver layer to prioritize certain traffic?
That seems like a separate issue. At the moment, I/O priorities are what we
have, and giving priority to RT seems appropriate.
^ permalink raw reply
* [PATCH] brd: make rd_size static
From: Jason Yan @ 2017-03-10 7:32 UTC (permalink / raw)
To: axboe, linux-block; +Cc: miaoxie, zhaohongjiang, Jason Yan
Fixes the following sparse warning:
drivers/block/brd.c:411:15: warning: symbol 'rd_size' was not declared.
Should it be static?
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
drivers/block/brd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 3adc32a..e5d9f35 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -408,7 +408,7 @@ static int rd_nr = CONFIG_BLK_DEV_RAM_COUNT;
module_param(rd_nr, int, S_IRUGO);
MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
-unsigned long rd_size = CONFIG_BLK_DEV_RAM_SIZE;
+static unsigned long rd_size = CONFIG_BLK_DEV_RAM_SIZE;
module_param(rd_size, ulong, S_IRUGO);
MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
--
2.5.0
^ permalink raw reply related
* [PATCH 3/5] blk: make the bioset rescue_workqueue optional.
From: NeilBrown @ 2017-03-10 6:00 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-block, Mike Snitzer, LKML, linux-raid,
device-mapper development, Mikulas Patocka, Pavel Machek,
Jack Wang, Lars Ellenberg, Kent Overstreet
In-Reply-To: <148912539296.4002.219258660543808741.stgit@noble>
This patch converts bioset_create() and bioset_create_nobvec()
to not create a workqueue so alloctions will never trigger
punt_bios_to_rescuer().
It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued()
which preserve the old behaviour.
*All* callers of bioset_create() and bioset_create_nobvec() are
converted to the _rescued() version, so that no change in behaviour
is experienced.
It is hoped that most, if not all, biosets can end up being the
non-rescued version.
Signed-off-by: NeilBrown <neilb@suse.com>
---
block/bio.c | 30 +++++++++++++++++++++++++-----
block/blk-core.c | 2 +-
drivers/block/drbd/drbd_main.c | 2 +-
drivers/md/bcache/super.c | 4 ++--
drivers/md/dm-crypt.c | 2 +-
drivers/md/dm-io.c | 2 +-
drivers/md/dm.c | 5 +++--
drivers/md/md.c | 2 +-
drivers/md/raid5-cache.c | 2 +-
drivers/target/target_core_iblock.c | 2 +-
fs/block_dev.c | 2 +-
fs/btrfs/extent_io.c | 4 ++--
fs/xfs/xfs_super.c | 2 +-
include/linux/bio.h | 2 ++
14 files changed, 43 insertions(+), 20 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index e75878f8b14a..3790c3f376b6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -362,6 +362,8 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
struct bio_list punt, nopunt;
struct bio *bio;
+ if (!WARN_ON_ONCE(!bs->rescue_workqueue))
+ return;
/*
* In order to guarantee forward progress we must punt only bios that
* were allocated from this bio_set; otherwise, if there was a bio on
@@ -472,7 +474,8 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs)
if (current->bio_list &&
(!bio_list_empty(¤t->bio_list[0]) ||
- !bio_list_empty(¤t->bio_list[1])))
+ !bio_list_empty(¤t->bio_list[1])) &&
+ bs->rescue_workqueue)
gfp_mask &= ~__GFP_DIRECT_RECLAIM;
p = mempool_alloc(bs->bio_pool, gfp_mask);
@@ -1941,7 +1944,8 @@ EXPORT_SYMBOL(bioset_free);
static struct bio_set *__bioset_create(unsigned int pool_size,
unsigned int front_pad,
- bool create_bvec_pool)
+ bool create_bvec_pool,
+ bool create_rescue_workqueue)
{
unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec);
struct bio_set *bs;
@@ -1972,6 +1976,9 @@ static struct bio_set *__bioset_create(unsigned int pool_size,
goto bad;
}
+ if (!create_rescue_workqueue)
+ return bs;
+
bs->rescue_workqueue = alloc_workqueue("bioset", WQ_MEM_RECLAIM, 0);
if (!bs->rescue_workqueue)
goto bad;
@@ -1997,10 +2004,16 @@ static struct bio_set *__bioset_create(unsigned int pool_size,
*/
struct bio_set *bioset_create(unsigned int pool_size, unsigned int front_pad)
{
- return __bioset_create(pool_size, front_pad, true);
+ return __bioset_create(pool_size, front_pad, true, false);
}
EXPORT_SYMBOL(bioset_create);
+struct bio_set *bioset_create_rescued(unsigned int pool_size, unsigned int front_pad)
+{
+ return __bioset_create(pool_size, front_pad, true, true);
+}
+EXPORT_SYMBOL(bioset_create_rescued);
+
/**
* bioset_create_nobvec - Create a bio_set without bio_vec mempool
* @pool_size: Number of bio to cache in the mempool
@@ -2012,10 +2025,17 @@ EXPORT_SYMBOL(bioset_create);
*/
struct bio_set *bioset_create_nobvec(unsigned int pool_size, unsigned int front_pad)
{
- return __bioset_create(pool_size, front_pad, false);
+ return __bioset_create(pool_size, front_pad, false, false);
}
EXPORT_SYMBOL(bioset_create_nobvec);
+struct bio_set *bioset_create_nobvec_rescued(unsigned int pool_size,
+ unsigned int front_pad)
+{
+ return __bioset_create(pool_size, front_pad, false, true);
+}
+EXPORT_SYMBOL(bioset_create_nobvec_rescued);
+
#ifdef CONFIG_BLK_CGROUP
/**
@@ -2130,7 +2150,7 @@ static int __init init_bio(void)
bio_integrity_init();
biovec_init_slabs();
- fs_bio_set = bioset_create(BIO_POOL_SIZE, 0);
+ fs_bio_set = bioset_create_rescued(BIO_POOL_SIZE, 0);
if (!fs_bio_set)
panic("bio: can't allocate bios\n");
diff --git a/block/blk-core.c b/block/blk-core.c
index fae7966e1f98..430c82f646eb 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -712,7 +712,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
if (q->id < 0)
goto fail_q;
- q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
+ q->bio_split = bioset_create_rescued(BIO_POOL_SIZE, 0);
if (!q->bio_split)
goto fail_id;
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 92c60cbd04ee..2c69c2ab0fff 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2166,7 +2166,7 @@ static int drbd_create_mempools(void)
goto Enomem;
/* mempools */
- drbd_md_io_bio_set = bioset_create(DRBD_MIN_POOL_PAGES, 0);
+ drbd_md_io_bio_set = bioset_create_rescued(DRBD_MIN_POOL_PAGES, 0);
if (drbd_md_io_bio_set == NULL)
goto Enomem;
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 85e3f21c2514..6cb30792f0ed 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -786,7 +786,7 @@ static int bcache_device_init(struct bcache_device *d, unsigned block_size,
minor *= BCACHE_MINORS;
- if (!(d->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
+ if (!(d->bio_split = bioset_create_rescued(4, offsetof(struct bbio, bio))) ||
!(d->disk = alloc_disk(BCACHE_MINORS))) {
ida_simple_remove(&bcache_minor, minor);
return -ENOMEM;
@@ -1520,7 +1520,7 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
sizeof(struct bbio) + sizeof(struct bio_vec) *
bucket_pages(c))) ||
!(c->fill_iter = mempool_create_kmalloc_pool(1, iter_size)) ||
- !(c->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
+ !(c->bio_split = bioset_create_rescued(4, offsetof(struct bbio, bio))) ||
!(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
!(c->moving_gc_wq = alloc_workqueue("bcache_gc",
WQ_MEM_RECLAIM, 0)) ||
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 389a3637ffcc..91a2d637d44f 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1936,7 +1936,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
goto bad;
}
- cc->bs = bioset_create(MIN_IOS, 0);
+ cc->bs = bioset_create_rescued(MIN_IOS, 0);
if (!cc->bs) {
ti->error = "Cannot allocate crypt bioset";
goto bad;
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index 03940bf36f6c..fe1241c196b1 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -58,7 +58,7 @@ struct dm_io_client *dm_io_client_create(void)
if (!client->pool)
goto bad;
- client->bios = bioset_create(min_ios, 0);
+ client->bios = bioset_create_rescued(min_ios, 0);
if (!client->bios)
goto bad;
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index dfb75979e455..41b1f033841f 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1002,7 +1002,8 @@ static void flush_current_bio_list(struct blk_plug_cb *cb, bool from_schedule)
while ((bio = bio_list_pop(&list))) {
struct bio_set *bs = bio->bi_pool;
- if (unlikely(!bs) || bs == fs_bio_set) {
+ if (unlikely(!bs) || bs == fs_bio_set ||
+ !bs->rescue_workqueue) {
bio_list_add(¤t->bio_list[i], bio);
continue;
}
@@ -2577,7 +2578,7 @@ struct dm_md_mempools *dm_alloc_md_mempools(struct mapped_device *md, unsigned t
BUG();
}
- pools->bs = bioset_create_nobvec(pool_size, front_pad);
+ pools->bs = bioset_create_nobvec_rescued(pool_size, front_pad);
if (!pools->bs)
goto out;
diff --git a/drivers/md/md.c b/drivers/md/md.c
index d7d2bb51a58d..e5f08a195837 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5220,7 +5220,7 @@ int md_run(struct mddev *mddev)
}
if (mddev->bio_set == NULL) {
- mddev->bio_set = bioset_create(BIO_POOL_SIZE, 0);
+ mddev->bio_set = bioset_create_rescued(BIO_POOL_SIZE, 0);
if (!mddev->bio_set)
return -ENOMEM;
}
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 3f307be01b10..c95c6c046395 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -2831,7 +2831,7 @@ int r5l_init_log(struct r5conf *conf, struct md_rdev *rdev)
if (!log->io_pool)
goto io_pool;
- log->bs = bioset_create(R5L_POOL_SIZE, 0);
+ log->bs = bioset_create_rescued(R5L_POOL_SIZE, 0);
if (!log->bs)
goto io_bs;
diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index d316ed537d59..5bf3392195c6 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -93,7 +93,7 @@ static int iblock_configure_device(struct se_device *dev)
return -EINVAL;
}
- ib_dev->ibd_bio_set = bioset_create(IBLOCK_BIO_POOL_SIZE, 0);
+ ib_dev->ibd_bio_set = bioset_create_rescued(IBLOCK_BIO_POOL_SIZE, 0);
if (!ib_dev->ibd_bio_set) {
pr_err("IBLOCK: Unable to create bioset\n");
goto out;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2eca00ec4370..c0ca5f0d0369 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -436,7 +436,7 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
static __init int blkdev_init(void)
{
- blkdev_dio_pool = bioset_create(4, offsetof(struct blkdev_dio, bio));
+ blkdev_dio_pool = bioset_create_rescued(4, offsetof(struct blkdev_dio, bio));
if (!blkdev_dio_pool)
return -ENOMEM;
return 0;
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 28e81922a21c..34aa8893790a 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -173,8 +173,8 @@ int __init extent_io_init(void)
if (!extent_buffer_cache)
goto free_state_cache;
- btrfs_bioset = bioset_create(BIO_POOL_SIZE,
- offsetof(struct btrfs_io_bio, bio));
+ btrfs_bioset = bioset_create_rescued(BIO_POOL_SIZE,
+ offsetof(struct btrfs_io_bio, bio));
if (!btrfs_bioset)
goto free_buffer_cache;
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 890862f2447c..f4c4d6f41d91 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -1756,7 +1756,7 @@ MODULE_ALIAS_FS("xfs");
STATIC int __init
xfs_init_zones(void)
{
- xfs_ioend_bioset = bioset_create(4 * MAX_BUF_PER_PAGE,
+ xfs_ioend_bioset = bioset_create_rescued(4 * MAX_BUF_PER_PAGE,
offsetof(struct xfs_ioend, io_inline_bio));
if (!xfs_ioend_bioset)
goto out;
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 8e521194f6fc..05730603fcf1 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -379,7 +379,9 @@ static inline struct bio *bio_next_split(struct bio *bio, int sectors,
}
extern struct bio_set *bioset_create(unsigned int, unsigned int);
+extern struct bio_set *bioset_create_rescued(unsigned int, unsigned int);
extern struct bio_set *bioset_create_nobvec(unsigned int, unsigned int);
+extern struct bio_set *bioset_create_nobvec_rescued(unsigned int, unsigned int);
extern void bioset_free(struct bio_set *);
extern mempool_t *biovec_create_pool(int pool_entries);
^ permalink raw reply related
* [PATCH 2/5] blk: remove bio_set arg from blk_queue_split()
From: NeilBrown @ 2017-03-10 6:00 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-block, Mike Snitzer, LKML, linux-raid,
device-mapper development, Mikulas Patocka, Pavel Machek,
Jack Wang, Lars Ellenberg, Kent Overstreet
In-Reply-To: <148912539296.4002.219258660543808741.stgit@noble>
blk_queue_split() is always called with the last arg being q->bio_split,
where 'q' is the first arg.
Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
q->bio_split.
This is inconsistent and unnecessary. Remove the last arg and always use
q->bio_split inside blk_queue_split()
Signed-off-by: NeilBrown <neilb@suse.com>
---
block/blk-core.c | 2 +-
block/blk-merge.c | 7 +++----
block/blk-mq.c | 4 ++--
drivers/block/drbd/drbd_req.c | 2 +-
drivers/block/pktcdvd.c | 2 +-
drivers/block/ps3vram.c | 2 +-
drivers/block/rsxx/dev.c | 2 +-
drivers/block/umem.c | 2 +-
drivers/block/zram/zram_drv.c | 2 +-
drivers/lightnvm/rrpc.c | 2 +-
drivers/md/md.c | 2 +-
drivers/s390/block/dcssblk.c | 2 +-
drivers/s390/block/xpram.c | 2 +-
include/linux/blkdev.h | 3 +--
14 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index d772c221cc17..fae7966e1f98 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1635,7 +1635,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, struct bio *bio)
*/
blk_queue_bounce(q, &bio);
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio->bi_error = -EIO;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2afa262425d1..ce8838aff7f7 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -188,8 +188,7 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
return do_split ? new : NULL;
}
-void blk_queue_split(struct request_queue *q, struct bio **bio,
- struct bio_set *bs)
+void blk_queue_split(struct request_queue *q, struct bio **bio)
{
struct bio *split, *res;
unsigned nsegs;
@@ -197,14 +196,14 @@ void blk_queue_split(struct request_queue *q, struct bio **bio,
switch (bio_op(*bio)) {
case REQ_OP_DISCARD:
case REQ_OP_SECURE_ERASE:
- split = blk_bio_discard_split(q, *bio, bs, &nsegs);
+ split = blk_bio_discard_split(q, *bio, q->bio_split, &nsegs);
break;
case REQ_OP_WRITE_ZEROES:
split = NULL;
nsegs = (*bio)->bi_phys_segments;
break;
case REQ_OP_WRITE_SAME:
- split = blk_bio_write_same_split(q, *bio, bs, &nsegs);
+ split = blk_bio_write_same_split(q, *bio, q->bio_split, &nsegs);
break;
default:
split = blk_bio_segment_split(q, *bio, q->bio_split, &nsegs);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 159187a28d66..e582d7f7511e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1502,7 +1502,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
return BLK_QC_T_NONE;
}
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if (!is_flush_fua && !blk_queue_nomerges(q) &&
blk_attempt_plug_merge(q, bio, &request_count, &same_queue_rq))
@@ -1624,7 +1624,7 @@ static blk_qc_t blk_sq_make_request(struct request_queue *q, struct bio *bio)
return BLK_QC_T_NONE;
}
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if (!is_flush_fua && !blk_queue_nomerges(q)) {
if (blk_attempt_plug_merge(q, bio, &request_count, NULL))
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 652114ae1a8a..f6ed6f7f5ab2 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1554,7 +1554,7 @@ blk_qc_t drbd_make_request(struct request_queue *q, struct bio *bio)
struct drbd_device *device = (struct drbd_device *) q->queuedata;
unsigned long start_jif;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
start_jif = jiffies;
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 66d846ba85a9..98394d034c29 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2414,7 +2414,7 @@ static blk_qc_t pkt_make_request(struct request_queue *q, struct bio *bio)
blk_queue_bounce(q, &bio);
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
pd = q->queuedata;
if (!pd) {
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 456b4fe21559..48072c0c1010 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -606,7 +606,7 @@ static blk_qc_t ps3vram_make_request(struct request_queue *q, struct bio *bio)
dev_dbg(&dev->core, "%s\n", __func__);
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
spin_lock_irq(&priv->lock);
busy = !bio_list_empty(&priv->list);
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index f81d70b39d10..8c8024f616ae 100644
--- a/drivers/block/rsxx/dev.c
+++ b/drivers/block/rsxx/dev.c
@@ -151,7 +151,7 @@ static blk_qc_t rsxx_make_request(struct request_queue *q, struct bio *bio)
struct rsxx_bio_meta *bio_meta;
int st = -EINVAL;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
might_sleep();
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index c141cc3be22b..c8d8a2f16f8e 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -529,7 +529,7 @@ static blk_qc_t mm_make_request(struct request_queue *q, struct bio *bio)
(unsigned long long)bio->bi_iter.bi_sector,
bio->bi_iter.bi_size);
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
spin_lock_irq(&card->lock);
*card->biotail = bio;
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index dceb5edd1e54..49d8bf37c4ef 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -880,7 +880,7 @@ static blk_qc_t zram_make_request(struct request_queue *queue, struct bio *bio)
{
struct zram *zram = queue->queuedata;
- blk_queue_split(queue, &bio, queue->bio_split);
+ blk_queue_split(queue, &bio);
if (!valid_io_request(zram, bio->bi_iter.bi_sector,
bio->bi_iter.bi_size)) {
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index e00b1d7b976f..701fa2fafbb2 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -999,7 +999,7 @@ static blk_qc_t rrpc_make_rq(struct request_queue *q, struct bio *bio)
struct nvm_rq *rqd;
int err;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if (bio_op(bio) == REQ_OP_DISCARD) {
rrpc_discard(rrpc, bio);
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 548d1b8014f8..d7d2bb51a58d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -253,7 +253,7 @@ static blk_qc_t md_make_request(struct request_queue *q, struct bio *bio)
unsigned int sectors;
int cpu;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if (mddev == NULL || mddev->pers == NULL) {
bio_io_error(bio);
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index 415d10a67b7a..10ece6f3c7eb 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -829,7 +829,7 @@ dcssblk_make_request(struct request_queue *q, struct bio *bio)
unsigned long source_addr;
unsigned long bytes_done;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
bytes_done = 0;
dev_info = bio->bi_bdev->bd_disk->private_data;
diff --git a/drivers/s390/block/xpram.c b/drivers/s390/block/xpram.c
index b9d7e755c8a3..a48f0d40c1d2 100644
--- a/drivers/s390/block/xpram.c
+++ b/drivers/s390/block/xpram.c
@@ -190,7 +190,7 @@ static blk_qc_t xpram_make_request(struct request_queue *q, struct bio *bio)
unsigned long page_addr;
unsigned long bytes;
- blk_queue_split(q, &bio, q->bio_split);
+ blk_queue_split(q, &bio);
if ((bio->bi_iter.bi_sector & 7) != 0 ||
(bio->bi_iter.bi_size & 4095) != 0)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 5a7da607ca04..8f98b4e2b9e6 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -933,8 +933,7 @@ extern int blk_insert_cloned_request(struct request_queue *q,
struct request *rq);
extern int blk_rq_append_bio(struct request *rq, struct bio *bio);
extern void blk_delay_queue(struct request_queue *, unsigned long);
-extern void blk_queue_split(struct request_queue *, struct bio **,
- struct bio_set *);
+extern void blk_queue_split(struct request_queue *, struct bio **);
extern void blk_recount_segments(struct request_queue *, struct bio *);
extern int scsi_verify_blk_ioctl(struct block_device *, unsigned int);
extern int scsi_cmd_blk_ioctl(struct block_device *, fmode_t,
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox