Re: [Xen-devel] [PATCH] xen/blkback: fix memory leaks
On 8/11/19 10:23 AM, Wenwen Wang wrote: > In read_per_ring_refs(), after 'req' and related memory regions are > allocated, xen_blkif_map() is invoked to map the shared frame, irq, and > etc. However, if this mapping process fails, no cleanup is performed, > leading to memory leaks. To fix this issue, invoke the cleanup before > returning the error. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-5.1 to your 'for-5.1/block' branch.
On 3/5/19 7:25 PM, Konrad Rzeszutek Wilk wrote: > Hi Jens, > > Apologies for doing it right at the merge window time. This patchset has been > brewing > for quite a while. > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-5.1 > > This patchset makes the backend more robust by reading a negotiation > variable only once and not twice. Pulled, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 00/10] block: enable multi-page bvec for passthrough IO
On 3/17/19 4:01 AM, Ming Lei wrote: > Hi, > > Now the whole IO stack is capable of handling multi-page bvec, and it has > been enabled in the normal FS IO path. However, it isn't done for > passthrough IO. > > Without enabling multi-bvec for passthough IO, we won't go ahead for > optimizing related IO paths, such as bvec merging, bio_add_pc_page > simplification. > > This patch enables multi-page bvec for passthrough IO. Turns out > bio_add_pc_page() is simpliefied a lot, especially the physical segment > number of passthrough bio is always same with bio.bi_vcnt. Also the > bvec merging inside bio is killed. > > blktests(block/029) is added for covering passthough IO path, and this > patchset does pass the new block/029 test. > > https://marc.info/?l=linux-block&m=155175063417139&w=2 Merged for 5.2, thanks Ming. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkback: Avoid unmapping unmapped grant pages
On 11/26/19 8:36 AM, SeongJae Park wrote:
From: SeongJae Park
For each I/O request, blkback first maps the foreign pages for the
request to its local pages. If an allocation of a local page for the
mapping fails, it should unmap every mapping already made for the
request.
However, blkback's handling mechanism for the allocation failure does
not mark the remaining foreign pages as unmapped. Therefore, the unmap
function merely tries to unmap every valid grant page for the request,
including the pages not mapped due to the allocation failure. On a
system that fails the allocation frequently, this problem leads to
following kernel crash.
[ 372.012538] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 372.012546] IP: [] gnttab_unmap_refs.part.7+0x1c/0x40
[ 372.012557] PGD 16f3e9067 PUD 16426e067 PMD 0
[ 372.012562] Oops: 0002 [#1] SMP
[ 372.012566] Modules linked in: act_police sch_ingress cls_u32
...
[ 372.012746] Call Trace:
[ 372.012752] [] gnttab_unmap_refs+0x34/0x40
[ 372.012759] [] xen_blkbk_unmap+0x83/0x150 [xen_blkback]
...
[ 372.012802] [] dispatch_rw_block_io+0x970/0x980
[xen_blkback]
...
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
This commit fixes this problem by marking the grant pages of the given
request that didn't mapped due to the allocation failure as invalid.
Fixes: c6cc142dac52 ("xen-blkback: use balloon pages for all mappings")
Queued up with Roger's reviewed-by.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.15
On 3/8/18 9:19 AM, Konrad Rzeszutek Wilk wrote: > Hi Jens, > > Please git pull the following branch for your for-linus branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-4.15 > > It has one simple fix for the multi-queue support not showing up after a block > device was detached/re-attached. > > The patch was originally posted in Dec 22nd but with the Spectre/Meltdown > circus I forgot about it until now. > > Thank you! > > drivers/block/xen-blkfront.c | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) > > Bhavesh Davda (1): > xen-blkfront: move negotiate_mq to cover all cases of new VBDs Pulled, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: remove unused macros
On 7/25/18 12:42 AM, Juergen Gross wrote: > Remove some macros not used anywhere. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-blkfront: use true and false for boolean values
On 8/4/18 6:08 PM, Gustavo A. R. Silva wrote: > Return statements in functions returning bool should use true or false > instead of an integer value. > > This code was detected with the help of Coccinelle. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions
On 5/23/18 2:05 PM, Joe Perches wrote: > Convert the S_ symbolic permissions to their octal equivalents as > using octal and not symbolic permissions is preferred by many as more > readable. > > see: https://lkml.org/lkml/2016/8/2/1945 > > Done with automated conversion via: > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace > > Miscellanea: > > o Wrapped modified multi-line calls to a single line where appropriate > o Realign modified multi-line calls to open parenthesis Honestly, I see this as pretty needless churn. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions
On 5/23/18 4:35 PM, Joe Perches wrote: > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: >> On 5/23/18 2:05 PM, Joe Perches wrote: >>> Convert the S_ symbolic permissions to their octal equivalents as >>> using octal and not symbolic permissions is preferred by many as more >>> readable. >>> >>> see: https://lkml.org/lkml/2016/8/2/1945 >>> >>> Done with automated conversion via: >>> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace >>> >>> Miscellanea: >>> >>> o Wrapped modified multi-line calls to a single line where appropriate >>> o Realign modified multi-line calls to open parenthesis >> >> Honestly, I see this as pretty needless churn. > > btw: > > There is currently a mixture of symbolic and octal > permissions uses in block and drivers/block > > ie: 94 octal and 146 symbolic uses. > > If this is applied, all would become octal. That does help justify the change. My main worry here is creating unnecessary conflicts, which is always annoying. But it's even more annoying when the change creating the conflict isn't really that important at all. Case in point, the patch doesn't apply to the for-4.18/block branch that it should go into... -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions
On 5/24/18 7:01 AM, Joe Perches wrote: > On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote: >> On 5/23/18 4:35 PM, Joe Perches wrote: >>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: >>>> On 5/23/18 2:05 PM, Joe Perches wrote: >>>>> Convert the S_ symbolic permissions to their octal equivalents as >>>>> using octal and not symbolic permissions is preferred by many as more >>>>> readable. >>>>> >>>>> see: https://lkml.org/lkml/2016/8/2/1945 >>>>> >>>>> Done with automated conversion via: >>>>> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace >>>>> >>>>> >>>>> Miscellanea: >>>>> >>>>> o Wrapped modified multi-line calls to a single line where appropriate >>>>> o Realign modified multi-line calls to open parenthesis >>>> >>>> Honestly, I see this as pretty needless churn. >>> >>> btw: >>> >>> There is currently a mixture of symbolic and octal >>> permissions uses in block and drivers/block >>> >>> ie: 94 octal and 146 symbolic uses. >>> >>> If this is applied, all would become octal. >> >> That does help justify the change. My main worry here is creating >> unnecessary conflicts, which is always annoying. But it's even more >> annoying when the change creating the conflict isn't really that >> important at all. Case in point, the patch doesn't apply to the >> for-4.18/block branch that it should go into... > > Done against most recent -next as it's basically impossible > to do anything against multiple private trees. > > Also, the script that generated the patch is in the changelog > so it's simple to rerun. Alright, applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.19 for 4.19..
On 8/27/18 10:19 AM, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Would you be OK pulling the following branch: > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-4.19 > > which has a fix for flushing out persistent pages at a deterministic rate. > > Thanks to the L1TF I did not manage to send this email until today - but > hopefully it won't be an issue to push it to Linus after -rc1? > > It is based on your 'b86d865cb1ca (for-4.19/block) blkcg: Make > blkg_root_lookup() > work for queues in bypass mode' branch. Pulled, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] clean up physical merging helpers
On 9/15/18 1:03 AM, Christoph Hellwig wrote: > Jens, any comments? > > On Tue, Sep 04, 2018 at 12:14:18PM -0700, Christoph Hellwig wrote: >> Hi Jens, >> >> this series moves various helpers related to merging based on physical >> addresses from the public headers into block/, moves the Xen special >> case from arch hooks into common code, cleans up the code a bit, and >> removes not nessecary includes from the block headers. > ---end quoted text--- > It's a good cleanup, I like it. Would prefer if the arm/xen folks could ack the first bits, and 13/13 should probably just to in differently. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] clean up physical merging helpers
On 9/20/18 12:29 AM, Christoph Hellwig wrote: > On Sat, Sep 15, 2018 at 08:47:13AM -0600, Jens Axboe wrote: >>>> this series moves various helpers related to merging based on physical >>>> addresses from the public headers into block/, moves the Xen special >>>> case from arch hooks into common code, cleans up the code a bit, and >>>> removes not nessecary includes from the block headers. >>> ---end quoted text--- >>> >> >> It's a good cleanup, I like it. Would prefer if the arm/xen folks could >> ack the first bits, > > Konread, can you look at the series (or delegate). > >> and 13/13 should probably just to in differently. > > I can't parse this setence. The irony is thick :-) Anyway, s/to/go for that sentence. I don't mind carrying it if Konrad is happy with it, but it could go in separately after this series is merged. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] clean up physical merging helpers
On 9/25/18 2:30 PM, Christoph Hellwig wrote: > Hi Jens, > > this series moves Xen special handling of block merges from arch hooks > into common code. A previous version has been reviewed by Boris. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer
On 9/27/18 1:12 AM, Juergen Gross wrote:
> On 22/09/18 21:55, Boris Ostrovsky wrote:
>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> added support for purging persistent grants when they are not in use. As
>> part of the purge, the grants were removed from the grant buffer, This
>> eventually causes the buffer to become empty, with BUG_ON triggered in
>> get_free_grant(). This can be observed even on an idle system, within
>> 20-30 minutes.
>>
>> We should keep the grants in the buffer when purging, and only free the
>> grant ref.
>>
>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> Signed-off-by: Boris Ostrovsky
>
> Reviewed-by: Juergen Gross
Since Konrad is out, I'm going to queue this up for 4.19.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer
On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
> On 27/09/18 16:26, Jens Axboe wrote:
>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>> added support for purging persistent grants when they are not in use. As
>>>> part of the purge, the grants were removed from the grant buffer, This
>>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>>> get_free_grant(). This can be observed even on an idle system, within
>>>> 20-30 minutes.
>>>>
>>>> We should keep the grants in the buffer when purging, and only free the
>>>> grant ref.
>>>>
>>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>> Signed-off-by: Boris Ostrovsky
>>>
>>> Reviewed-by: Juergen Gross
>>
>> Since Konrad is out, I'm going to queue this up for 4.19.
>>
>
> Hi Boris/Juergen.
>
> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch from
> Boris pulled on top.
> Unfortunately it made a VM hang (probably because it's rootFS is shuffled
> from under it's feet
> and it gave these in dom0 dmesg:
>
> [ 9251.696090] xen-blkback: requesting a grant already in use
> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
> [ 9251.715781] xen-blkback: requesting a grant already in use
> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
> [ 9251.735698] xen-blkback: requesting a grant already in use
> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>
> The VM was a HVM with 4 vcpu's and 2 phy disks:
> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi)
> persistent grants
> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi)
> persistent grants
>
>
> Currently i have been running 4.19-rc5 with xen-next on top and commit
> a46b53672b2c reverted, for a couple of days. That seems to run stable
> for me (since it's a small box so i'm not hit by what a46b53672b2c
> tried to fix.
>
> If you can come up with a debug patch i can give that a spin tomorrow
> evening or in the weekend, so we are hopefully still in time for the
> 4.19 release.
At this late in the game, might make more sense to simply revert the
buggy commit. Especially since what is currently out there doesn't fix
the issue for you.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer
On 9/27/18 1:06 PM, Boris Ostrovsky wrote:
> On 9/27/18 2:56 PM, Jens Axboe wrote:
>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>> On 27/09/18 16:26, Jens Axboe wrote:
>>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>> added support for purging persistent grants when they are not in use. As
>>>>>> part of the purge, the grants were removed from the grant buffer, This
>>>>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>>>>> get_free_grant(). This can be observed even on an idle system, within
>>>>>> 20-30 minutes.
>>>>>>
>>>>>> We should keep the grants in the buffer when purging, and only free the
>>>>>> grant ref.
>>>>>>
>>>>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>> Signed-off-by: Boris Ostrovsky
>>>>> Reviewed-by: Juergen Gross
>>>> Since Konrad is out, I'm going to queue this up for 4.19.
>>>>
>>> Hi Boris/Juergen.
>>>
>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch
>>> from Boris pulled on top.
>>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled
>>> from under it's feet
>
> What do you mean by "rootFS is shuffled from under it's feet " ?
>
>>> and it gave these in dom0 dmesg:
>>>
>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>>
>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi)
>>> persistent grants
>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi)
>>> persistent grants
>>>
>>>
>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>> tried to fix.
>>>
>>> If you can come up with a debug patch i can give that a spin tomorrow
>>> evening or in the weekend, so we are hopefully still in time for the
>>> 4.19 release.
>> At this late in the game, might make more sense to simply revert the
>> buggy commit. Especially since what is currently out there doesn't fix
>> the issue for you.
>
> If decision is to revert then I think the whole series needs to be
> reverted.
Yes, definitely.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer
On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
> On 27/09/18 21:06, Boris Ostrovsky wrote:
>> On 9/27/18 2:56 PM, Jens Axboe wrote:
>>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>>> On 27/09/18 16:26, Jens Axboe wrote:
>>>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>>>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>>>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>>> added support for purging persistent grants when they are not in use. As
>>>>>>> part of the purge, the grants were removed from the grant buffer, This
>>>>>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>>>>>> get_free_grant(). This can be observed even on an idle system, within
>>>>>>> 20-30 minutes.
>>>>>>>
>>>>>>> We should keep the grants in the buffer when purging, and only free the
>>>>>>> grant ref.
>>>>>>>
>>>>>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>>>>>> Signed-off-by: Boris Ostrovsky
>>>>>> Reviewed-by: Juergen Gross
>>>>> Since Konrad is out, I'm going to queue this up for 4.19.
>>>>>
>>>> Hi Boris/Juergen.
>>>>
>>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch
>>>> from Boris pulled on top.
>>>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled
>>>> from under it's feet
>>
>> What do you mean by "rootFS is shuffled from under it's feet " ?
>
> Assumption that block-front getting borked and either a kernel crash or
> rootfs becoming mounted readonly. Didn't (try) to check though.
>
>>>> and it gave these in dom0 dmesg:
>>>>
>>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>>>
>>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi)
>>>> persistent grants
>>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi)
>>>> persistent grants
>>>>
>>>>
>>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>>> tried to fix.
>>>>
>>>> If you can come up with a debug patch i can give that a spin tomorrow
>>>> evening or in the weekend, so we are hopefully still in time for the
>>>> 4.19 release.
>>> At this late in the game, might make more sense to simply revert the
>>> buggy commit. Especially since what is currently out there doesn't fix
>>> the issue for you.
>
> Don't know if Boris or Juergen have a hunch about the issue, if not
> perhaps a revert is the best.
Anyone? Unless I hear otherwise, I'll revert the series tomorrow.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 9/28/18 1:28 AM, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
I'll apply this for 4.19, and if things unexpectedly don't work out,
we can always revert the series next week.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.20
On 10/22/18 1:31 PM, Konrad Rzeszutek Wilk wrote: > > Hi Jens, > > Please git pull the following branch: > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-4.20 > > which has exactly one tiny patch fixing an NULL pointer issue (also has > stable tree CCed). > > Thank you! > > drivers/block/xen-blkfront.c | 3 +++ > 1 file changed, 3 insertions(+) > > Vasilis Liaskovitis (2): > xen/blkfront: avoid NULL blkfront_info dereference on device removal Pulled, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] block: refactor duplicated macros
On 3/10/20 6:22 PM, Matteo Croce wrote: > The macros PAGE_SECTORS, PAGE_SECTORS_SHIFT and SECTOR_MASK are defined > several times in different flavours across the whole tree. > Define them just once in a common header. > > While at it, replace replace "PAGE_SHIFT - 9" with "PAGE_SECTORS_SHIFT" too > and rename SECTOR_MASK to PAGE_SECTORS_MASK. Applied, thanks. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: cleanup updating the size of block devices v3
On 11/16/20 7:56 AM, Christoph Hellwig wrote: > Hi Jens, > > this series builds on top of the work that went into the last merge window, > and make sure we have a single coherent interfac for updating the size of a > block device. > > Changes since v2: > - rebased to the set_capacity_revalidate_and_notify in mainline > - keep the loop_set_size function > - fix two mixed up acks Applied 1-23 for 5.11, thanks. -- Jens Axboe
Re: [PATCH] xen/blkfront: speed up purge_persistent_grants()
On Fri, 11 Mar 2022 11:35:27 +0100, Juergen Gross wrote: > purge_persistent_grants() is scanning the grants list for persistent > grants being no longer in use by the backend. When having found such a > grant, it will be set to "invalid" and pushed to the tail of the list. > > Instead of pushing it directly to the end of the list, add it first to > a temporary list, avoiding to scan those entries again in the main > list traversal. After having finished the scan, append the temporary > list to the grant list. > > [...] Applied, thanks! [1/1] xen/blkfront: speed up purge_persistent_grants() commit: 85d9abcd7331566781b93ff46e4bccd4806ef2b2 Best regards, -- Jens Axboe
Re: [PATCH] xen-blkback: remove redundant assignment to variable i
On Thu, 17 Mar 2022 23:46:46 +, Colin Ian King wrote: > Variable i is being assigned a value that is never read, it is being > re-assigned later in a for-loop. The assignment is redundant and can > be removed. > > Cleans up clang scan build warning: > drivers/block/xen-blkback/blkback.c:934:14: warning: Although the value > stored to 'i' is used in the enclosing expression, the value is never > actually read from 'i' [deadcode.DeadStores] > > [...] Applied, thanks! [1/1] xen-blkback: remove redundant assignment to variable i commit: 93b4e74789dbdefcffc7baac107069e74d98513c Best regards, -- Jens Axboe
Re: [PATCH 1/1] xen/blkfront: fix comment for need_copy
On Thu, 17 Mar 2022 15:09:30 -0700, Dongli Zhang wrote: > The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to > copy the written data to persistent page. > > ".need_copy = rq_data_dir(req) && info->feature_persistent," > > Applied, thanks! [1/1] xen/blkfront: fix comment for need_copy commit: 08719dd9176b4c55f547bd11812fd6cc35907d37 Best regards, -- Jens Axboe
Re: use block_device based APIs in block layer consumers v3
On Fri, 15 Apr 2022 06:52:31 +0200, Christoph Hellwig wrote:
> this series cleanups up the block layer API so that APIs consumed
> by file systems are (almost) only struct block_devic based, so that
> file systems don't have to poke into block layer internals like the
> request_queue.
>
> I also found a bunch of existing bugs related to partition offsets
> and discard so these are fixed while going along.
>
> [...]
Applied, thanks!
[01/27] target: remove an incorrect unmap zeroes data deduction
commit: 179d8609d8424529e95021df939ed7b0b82b37f1
[02/27] target: pass a block_device to target_configure_unmap_from_queue
commit: 817e8b51eb3d927ce6d56ecf9f48bc3c5b26168b
[03/27] target: fix discard alignment on partitions
commit: 968786b9ef56e75e0109158a4936ea962c1e
[04/27] drbd: remove assign_p_sizes_qlim
commit: 40349d0e16cedd0de561f59752c3249780fb749b
[05/27] drbd: use bdev based limit helpers in drbd_send_sizes
commit: 7a38acce229685968b770d1d9e64e01396b93643
[06/27] drbd: use bdev_alignment_offset instead of queue_alignment_offset
commit: c6f23b1a05441a26f765e59dd95e8ba7354f9388
[07/27] drbd: cleanup decide_on_discard_support
commit: 998e9cbcd615e5e6a7baa69e673ee845f812744e
[08/27] btrfs: use bdev_max_active_zones instead of open coding it
commit: c1e7b24416400ef13ff92a1c60c336c9a2834d7b
[09/27] ntfs3: use bdev_logical_block_size instead of open coding it
commit: f09dac9afb8e3ce4b6485dbc091a9b9c742db023
[10/27] mm: use bdev_is_zoned in claim_swapfile
commit: 9964e674559b02619fee2012a56839624143d02e
[11/27] block: add a bdev_nonrot helper
commit: 10f0d2a517796b8f6dc04fb0cc3e49003ae6b0bc
[12/27] block: add a bdev_write_cache helper
commit: 08e688fdb8f7e862092ae64cee20bc8b463d1046
[13/27] block: add a bdev_fua helper
commit: a557e82e5a01826f902bd94fc925c03f253cb712
[14/27] block: add a bdev_stable_writes helper
commit: 36d254893aa6a6e204075c3cce94bb572ac32c04
[15/27] block: add a bdev_max_zone_append_sectors helper
commit: 2aba0d19f4d8c8929b4b3b94a9cfde2aa20e6ee2
[16/27] block: use bdev_alignment_offset in part_alignment_offset_show
commit: 64dcc7c2717395b7c83ffb10f040d3be795d03c1
[17/27] block: use bdev_alignment_offset in disk_alignment_offset_show
commit: 640f2a23911b8388989547f89d055afbb910b88e
[18/27] block: move bdev_alignment_offset and queue_limit_alignment_offset out
of line
commit: 89098b075cb74a80083bc4ed6b71d0ee18b6898f
[19/27] block: remove queue_discard_alignment
commit: 4e1462ffe8998749884d61f91be251a7a8719677
[20/27] block: use bdev_discard_alignment in part_discard_alignment_show
commit: f0f975a4dde890bfe25ce17bf07a6495453988a4
[21/27] block: move {bdev,queue_limit}_discard_alignment out of line
commit: 5c4b4a5c6f11c869a57c6bd977143430bc9dc43d
[22/27] block: refactor discard bio size limiting
commit: e3cc28ea28b5f8794db2aed24f8a0282ad2e85a2
[23/27] block: add a bdev_max_discard_sectors helper
commit: cf0fbf894bb543f472f682c486be48298eccf199
[24/27] block: remove QUEUE_FLAG_DISCARD
commit: 70200574cc229f6ba038259e8142af2aa09e6976
[25/27] block: add a bdev_discard_granularity helper
commit: 7b47ef52d0a2025fd1408a8a0990933b8e1e510f
[26/27] block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
commit: 44abff2c0b970ae3d310b97617525dc01f248d7c
[27/27] direct-io: remove random prefetches
commit: c22198e78d523c8fa079bbb70b2523bb6aa51849
Best regards,
--
Jens Axboe
Re: (subset) [PATCH 0/9] block: reviewed add_disk() error handling set
On Fri, 15 Oct 2021 16:30:19 -0700, Luis Chamberlain wrote: > Jens, > > I had last split up patches into 7 groups, but at this point now > most changes are merged except a few more drivers. Instead of creating > a new patch set for each of the 7 groups I'm creating 3 new groups of > patches now: > > [...] Applied, thanks! [3/9] dm: add add_disk() error handling commit: e7089f65dd51afeda5eb760506b5950d95f9ec29 [4/9] bcache: add error handling support for add_disk() commit: 2961c3bbcaec0ed7fb7b9a465b3796f37f2294e5 [5/9] xen-blkfront: add error handling support for add_disk() commit: 293a7c528803321479593d42d0898bb5a9769db1 [6/9] m68k/emu/nfblock: add error handling support for add_disk() commit: 21fd880d3da7564bab68979417cab7408e4f9642 [7/9] um/drivers/ubd_kern: add error handling support for add_disk() commit: 66638f163a2b5c5b462ca38525129b14a20117eb [8/9] rnbd: add error handling support for add_disk() commit: 2e9e31bea01997450397d64da43b6675e0adb9e3 [9/9] mtd: add add_disk() error handling commit: 83b863f4a3f0de4ece7802d9121fed0c3e64145f Best regards, -- Jens Axboe
Re: improve the bio allocation interface v2
On Mon, 24 Jan 2022 10:10:48 +0100, Christoph Hellwig wrote: > this series is posted early because it has wide-ranging changes and could use > some > early ACKs before -rc1. > > It changes the interface to the bio allocators to always pass a block_device > and > the operation, which is information needed for every bio submitted through > bio_submit. This means the fields can be directly initialized in bio_init > instead > of first being zeroed and thus should help to micro-optimize even better than > the > __bio_set_dev that Pavel proposed while also cleaning up code. > > [...] Applied, thanks! [01/19] fs: remove mpage_alloc commit: d5f68a42da7a4516e7503c281a54a58727f07dc3 [02/19] nilfs2: remove nilfs_alloc_seg_bio commit: f0d911927b3c7cf5f9edb5941d0287144a602d0d [03/19] nfs/blocklayout: remove bl_alloc_init_bio commit: 5d2ca2132f889bc2c90d6d07fc9fc129cfee8955 [04/19] ntfs3: remove ntfs_alloc_bio commit: 39146b6f66ba5c107d5c5758a17f290846165b4d [05/19] dm: bio_alloc can't fail if it is allowed to sleep commit: 53db984e004c7116ce69e2f4a163664453336ae1 [06/19] dm-crypt: remove clone_init commit: 3f868c09ea8f40f800c4c644c072d91c9eee0d71 [07/19] dm-snap: use blkdev_issue_flush instead of open coding it commit: eba33b8ef1b90d8996eceb0569c06a4f784ef2b5 [08/19] dm-thin: use blkdev_issue_flush instead of open coding it commit: 28d7d128aad5cd2178b158900d58365d1fd3de94 [09/19] drbd: bio_alloc can't fail if it is allow to sleep commit: 4b1dc86d1857f1007865cab759f2285280692eee [10/19] rnbd-srv: simplify bio mapping in process_rdma commit: 1fe0640ff94feae6d21417e2f4f2829b882274b1 [11/19] rnbd-srv: remove struct rnbd_dev_blk_io commit: d7b78de2b1552e3e7ce3a069f075cc2729aa5c34 [12/19] xen-blkback: bio_alloc can't fail if it is allow to sleep commit: 7d8d0c658d48705fca35238a8ff601b7c5cbc0de [13/19] block: move blk_next_bio to bio.c commit: 3b005bf6acf009abd700e2c652c86e5c209cf63d [14/19] block: pass a block_device and opf to blk_next_bio commit: 0a3140ea0fae377c9eaa031b7db1670ae422ed47 [15/19] block: pass a block_device and opf to bio_alloc_bioset commit: 609be1066731fea86436f5f91022f82e592ab456 [16/19] block: pass a block_device and opf to bio_alloc_kiocb commit: b77c88c2100ce6a5ec8126c13599b5a7f6663e32 [17/19] block: pass a block_device and opf to bio_alloc commit: 07888c665b405b1cd3577ddebfeb74f4717a84c4 [18/19] block: pass a block_device and opf to bio_init commit: 49add4966d79244013fce35f95c6833fae82b8b1 [19/19] block: pass a block_device and opf to bio_reset commit: a7c50c940477bae89fb2b4f51bd969a2d95d7512 Best regards, -- Jens Axboe
Re: [RFC PATCH 00/30] Code tagging framework and applications
On 9/1/22 7:04 PM, Roman Gushchin wrote: > On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote: >> On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote: >>> I'd suggest to run something like iperf on a fast hardware. And maybe some >>> io_uring stuff too. These are two places which were historically most >>> sensitive >>> to the (kernel) memory accounting speed. >> >> I'm getting wildly inconsistent results with iperf. >> >> io_uring-echo-server and rust_echo_bench gets me: >> Benchmarking: 127.0.0.1:12345 >> 50 clients, running 512 bytes, 60 sec. >> >> Without alloc tagging: 120547 request/sec >> With:116748 request/sec >> >> https://github.com/frevib/io_uring-echo-server >> https://github.com/haraldh/rust_echo_bench >> >> How's that look to you? Close enough? :) > > Yes, this looks good (a bit too good). > > I'm not that familiar with io_uring, Jens and Pavel should have a better idea > what and how to run (I know they've workarounded the kernel memory accounting > because of the performance in the past, this is why I suspect it might be an > issue here as well). io_uring isn't alloc+free intensive on a per request basis anymore, it would not be a good benchmark if the goal is to check for regressions in that area. -- Jens Axboe
Re: [RFC PATCH 00/30] Code tagging framework and applications
On 9/2/22 1:48 PM, Kent Overstreet wrote: > On Fri, Sep 02, 2022 at 06:02:12AM -0600, Jens Axboe wrote: >> On 9/1/22 7:04 PM, Roman Gushchin wrote: >>> On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote: >>>> On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote: >>>>> I'd suggest to run something like iperf on a fast hardware. And maybe some >>>>> io_uring stuff too. These are two places which were historically most >>>>> sensitive >>>>> to the (kernel) memory accounting speed. >>>> >>>> I'm getting wildly inconsistent results with iperf. >>>> >>>> io_uring-echo-server and rust_echo_bench gets me: >>>> Benchmarking: 127.0.0.1:12345 >>>> 50 clients, running 512 bytes, 60 sec. >>>> >>>> Without alloc tagging: 120547 request/sec >>>> With: 116748 request/sec >>>> >>>> https://github.com/frevib/io_uring-echo-server >>>> https://github.com/haraldh/rust_echo_bench >>>> >>>> How's that look to you? Close enough? :) >>> >>> Yes, this looks good (a bit too good). >>> >>> I'm not that familiar with io_uring, Jens and Pavel should have a better >>> idea >>> what and how to run (I know they've workarounded the kernel memory >>> accounting >>> because of the performance in the past, this is why I suspect it might be an >>> issue here as well). >> >> io_uring isn't alloc+free intensive on a per request basis anymore, it >> would not be a good benchmark if the goal is to check for regressions in >> that area. > > Good to know. The benchmark is still a TCP benchmark though, so still useful. > > Matthew suggested > while true; do echo 1 >/tmp/foo; rm /tmp/foo; done > > I ran that on tmpfs, and the numbers with and without alloc tagging were > statistically equal - there was a fair amount of variation, it wasn't a super > controlled test, anywhere from 38-41 seconds with 10 iterations (and alloc > tagging was some of the faster runs). > > But with memcg off, it ran in 32-33 seconds. We're piggybacking on the same > mechanism memcg uses for stashing per-object pointers, so it looks like that's > the bigger cost. I've complained about memcg accounting before, the slowness of it is why io_uring works around it by caching. Anything we account we try NOT do in the fast path because of it, the slowdown is considerable. You care about efficiency now? I thought that was relegated to irrelevant 10M IOPS cases. -- Jens Axboe
Re: [RFC PATCH 00/30] Code tagging framework and applications
On 9/2/22 2:05 PM, Kent Overstreet wrote: > On Fri, Sep 02, 2022 at 01:53:53PM -0600, Jens Axboe wrote: >> I've complained about memcg accounting before, the slowness of it is why >> io_uring works around it by caching. Anything we account we try NOT do >> in the fast path because of it, the slowdown is considerable. > > I'm with you on that, it definitely raises an eyebrow. > >> You care about efficiency now? I thought that was relegated to >> irrelevant 10M IOPS cases. > > I always did, it's just not the only thing I care about. It's not the only thing anyone cares about. -- Jens Axboe
Re: [PATCH] xen-blkfront: sanitize the removal state machine
On 7/15/21 8:17 AM, Christoph Hellwig wrote: > xen-blkfront has a weird protocol where close message from the remote > side can be delayed, and where hot removals are treated somewhat > differently from regular removals, all leading to potential NULL > pointer removals, and a del_gendisk from the block device release > method, which will deadlock. Fix this by just performing normal hot > removals even when the device is opened like all other Linux block > drivers. Applied, thanks. -- Jens Axboe
Re: [PATCH] xen-blkfront: Remove redundant assignment to variable err
On 8/6/21 5:06 AM, Colin King wrote: > From: Colin Ian King > > The variable err is being assigned a value that is never read, the > assignment is redundant and can be removed. Added for 5.15, thanks. -- Jens Axboe
Re: simplify gendisk and request_queue allocation for blk-mq based drivers
On 6/2/21 12:53 AM, Christoph Hellwig wrote: > Hi all, > > this series is the scond part of cleaning up lifetimes and allocation of > the gendisk and request_queue structure. It adds a new interface to > allocate the disk and queue together for blk based drivers, and uses that > in all drivers that do not have any caveats in their gendisk and > request_queue lifetime rules. Applied, thanks. -- Jens Axboe
Re: [PATCH] xen-blkfront: fix sector_size propagation to the block layer
On Tue, 25 Jun 2024 07:52:38 +0200, Christoph Hellwig wrote: > Ensure that info->sector_size and info->physical_sector_size are set > before the call to blkif_set_queue_limits by doing away with the > local variables and arguments that propagate them. > > Thanks to Marek Marczykowski-Górecki and Jürgen Groß for root causing > the issue. > > [...] Applied, thanks! [1/1] xen-blkfront: fix sector_size propagation to the block layer commit: 98d34c087249d39838874b83e17671e7d5eb1ca7 Best regards, -- Jens Axboe
Re: [PATCH] xen/blkback: add missing MODULE_DESCRIPTION() macro
On Sun, 02 Jun 2024 17:37:28 -0700, Jeff Johnson wrote: > make allmodconfig && make W=1 C=1 reports: > WARNING: modpost: missing MODULE_DESCRIPTION() in > drivers/block/xen-blkback/xen-blkback.o > > Add the missing invocation of the MODULE_DESCRIPTION() macro. > > Applied, thanks! [1/1] xen/blkback: add missing MODULE_DESCRIPTION() macro commit: 4c33e39f6201ab130719d44d6f6f25ec02e1b306 Best regards, -- Jens Axboe
Re: convert the SCSI ULDs to the atomic queue limits API v2
On Fri, 31 May 2024 09:47:55 +0200, Christoph Hellwig wrote: > this series converts the SCSI upper level drivers to the atomic queue > limits API. > > The first patch is a bug fix for ubd that later patches depend on and > might be worth picking up for 6.10. > > The second patch changes the max_sectors calculation to take the optimal > I/O size into account so that sd, nbd and rbd don't have to mess with > the user max_sector value. I'd love to see a careful review from the > nbd and rbd maintainers for this one! > > [...] Applied, thanks! [01/14] ubd: refactor the interrupt handler commit: 5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6 [02/14] ubd: untagle discard vs write zeroes not support handling commit: 31ade7d4fdcf382beb8cb229a1f5d77e0f239672 [03/14] rbd: increase io_opt again commit: a00d4bfce7c6d7fa4712b8133ec195c9bd142ae6 [04/14] block: take io_opt and io_min into account for max_sectors commit: a23634644afc2f7c1bac98776440a1f3b161819e [05/14] sd: simplify the ZBC case in provisioning_mode_store commit: b3491b0db165c0cbe25874da66d97652c03db654 [06/14] sd: add a sd_disable_discard helper commit: b0dadb86a90bd5a7b723f9d3a6cf69da9b596496 [07/14] sd: add a sd_disable_write_same helper commit: 9972b8ce0d4ba373901bdd1e15e4de58fcd7f662 [08/14] sd: simplify the disable case in sd_config_discard commit: d15b9bd42cd3b2077812d4bf32f532a9bd5c4914 [09/14] sd: factor out a sd_discard_mode helper commit: f1e8185fc12c699c3abf4f39b1ff5d7793da3a95 [10/14] sd: cleanup zoned queue limits initialization commit: 9c1d339a1bf45f4d3a2e77bbf24b0ec51f02551c [11/14] sd: convert to the atomic queue limits API commit: 804e498e0496d889090f32f812b5ce1a4f2aa63e [12/14] sr: convert to the atomic queue limits API commit: 969f17e10f5b732c05186ee0126c8a08166d0cda [13/14] block: remove unused queue limits API commit: 1652b0bafeaa8281ca9a805d81e13d7647bd2f44 [14/14] block: add special APIs for run-time disabling of discard and friends commit: 73e3715ed14844067c5c598e72777641004a7f60 Best regards, -- Jens Axboe
Re: move features flags into queue_limits v2
On Mon, 17 Jun 2024 08:04:27 +0200, Christoph Hellwig wrote: > this is the third and last major series to convert settings to > queue_limits for this merge window. After a bunch of prep patches to > get various drivers in shape, it moves all the queue_flags that specify > driver controlled features into the queue limits so that they can be > set atomically and are separated from the blk-mq internal flags. > > Note that I've only Cc'ed the maintainers for drivers with non-mechanical > changes as the Cc list is already huge. > > [...] Applied, thanks! [01/26] xen-blkfront: don't disable cache flushes when they fail commit: dd9300e9eaeeb212f77ffeb72d1d8756107f1f1f [02/26] sd: remove sd_is_zoned commit: be60e7700e6df1e16a2f60f45bece08e6140a46d [03/26] sd: move zone limits setup out of sd_read_block_characteristics commit: 308ad58af49d6c4c3b7a36b98972cc9db4d7b36a [04/26] loop: stop using loop_reconfigure_limits in __loop_clr_fd commit: c9055b44abe60da69aa4ee4fdcb78ee7fe75 [05/26] loop: always update discard settings in loop_reconfigure_limits commit: ae0d40ff49642651f969883ef9fc79d69c1632d7 [06/26] loop: regularize upgrading the block size for direct I/O commit: a17ece76bcfe7b86327b19cae1652d7c62068a30 [07/26] loop: also use the default block size from an underlying block device commit: 4ce37fe0938b02b7b947029c40b72d76a22a3882 [08/26] loop: fold loop_update_rotational into loop_reconfigure_limits commit: 97dd4a43d69b74a114be466d6887e257971adfe9 [09/26] virtio_blk: remove virtblk_update_cache_mode commit: bbe5c84122b35c37f2706872fe34da66f0854b56 [10/26] nbd: move setting the cache control flags to __nbd_set_size commit: 6b377787a306253111404325aee98005b361e59a [11/26] block: freeze the queue in queue_attr_store commit: af2814149883e2c1851866ea2afcd8eadc040f79 [12/26] block: remove blk_flush_policy commit: 70905f8706b62113ae32c8df721384ff6ffb6c6a [13/26] block: move cache control settings out of queue->flags commit: 1122c0c1cc71f740fa4d5f14f239194e06a1d5e7 [14/26] block: move the nonrot flag to queue_limits commit: bd4a633b6f7c3c6b6ebc1a07317643270e751a94 [15/26] block: move the add_random flag to queue_limits commit: 39a9f1c334f9f27b3b3e6d0005c10ed667268346 [16/26] block: move the io_stat flag setting to queue_limits commit: cdb2497918cc2929691408bac87b58433b45b6d3 [17/26] block: move the stable_writes flag to queue_limits commit: 1a02f3a73f8c670eddeb44bf52a75ae7f67cfc11 [18/26] block: move the synchronous flag to queue_limits commit: aadd5c59c910427c0464c217d5ed588ff14e2502 [19/26] block: move the nowait flag to queue_limits commit: f76af42f8bf13d2620084f305f01691de9238fc7 [20/26] block: move the dax flag to queue_limits commit: f467fee48da4500786e145489787b37adae317c3 [21/26] block: move the poll flag to queue_limits commit: 8023e144f9d6e35f8786937e2f0c2fea0aba6dbc [22/26] block: move the zoned flag into the features field commit: b1fc937a55f5735b98d9dceae5bb6ba262501f56 [23/26] block: move the zone_resetall flag to queue_limits commit: a52758a39768f441e468a41da6c15a59d6d6011a [24/26] block: move the pci_p2pdma flag to queue_limits commit: 9c1e42e3c876c66796eda23e79836a4d92613a61 [25/26] block: move the skip_tagset_quiesce flag to queue_limits commit: 8c8f5c85b20d0a7dc0ab9b2a17318130d69ceb5a [26/26] block: move the bounce flag into the features field commit: 339d3948c07b4aa2940aeb874294a7d6782cec16 Best regards, -- Jens Axboe
Re: move features flags into queue_limits v2
On 6/19/24 8:18 AM, Jens Axboe wrote:
>
> On Mon, 17 Jun 2024 08:04:27 +0200, Christoph Hellwig wrote:
>> this is the third and last major series to convert settings to
>> queue_limits for this merge window. After a bunch of prep patches to
>> get various drivers in shape, it moves all the queue_flags that specify
>> driver controlled features into the queue limits so that they can be
>> set atomically and are separated from the blk-mq internal flags.
>>
>> Note that I've only Cc'ed the maintainers for drivers with non-mechanical
>> changes as the Cc list is already huge.
>>
>> [...]
>
> Applied, thanks!
Please check for-6.11/block, as I pulled in the changes to the main
block branch and that threw some merge conflicts mostly due to Damien's
changes in for-6.11/block. While fixing those up, I also came across
oddities like:
(limits->features & limits->features & BLK_FEAT_ZONED)) {
which don't make much sense and hence I changed them to
(limits->features & BLK_FEAT_ZONED)) {
--
Jens Axboe
Re: fix and cleanup discard_alignment handling
On Mon, 18 Apr 2022 06:53:03 +0200, Christoph Hellwig wrote: > the somewhat confusing name of the discard_alignment queue limit, that > really is an offset for the discard granularity mislead a lot of driver > authors to set it to an incorrect value. This series tries to fix up > all these cases. > > Diffstat: > arch/um/drivers/ubd_kern.c |1 - > drivers/block/loop.c |1 - > drivers/block/nbd.c|3 --- > drivers/block/null_blk/main.c |1 - > drivers/block/rnbd/rnbd-srv-dev.h |2 +- > drivers/block/virtio_blk.c |7 --- > drivers/block/xen-blkback/xenbus.c |4 ++-- > drivers/md/dm-zoned-target.c |2 +- > drivers/md/raid5.c |1 - > drivers/nvme/host/core.c |1 - > drivers/s390/block/dasd_fba.c |1 - > 11 files changed, 8 insertions(+), 16 deletions(-) > > [...] Applied, thanks! [01/11] ubd: don't set the discard_alignment queue limit commit: 07c6e92a8478770a7302f7dde72f03a5465901bd [02/11] nbd: don't set the discard_alignment queue limit commit: 4a04d517c56e0616c6f69afc226ee2691e543712 [03/11] null_blk: don't set the discard_alignment queue limit commit: fb749a87f4536d2fa86ea135ae4eff1072903438 [04/11] virtio_blk: fix the discard_granularity and discard_alignment queue limits commit: 62952cc5bccd89b76d710de1d0b43244af0f2903 [05/11] dm-zoned: don't set the discard_alignment queue limit commit: 44d583702f4429763c558624fac763650a1f05bf [06/11] raid5: don't set the discard_alignment queue limit commit: 3d50d368c92ade2f98a3d0d28b842a57c35284e9 [07/11] dasd: don't set the discard_alignment queue limit commit: c3f765299632727fa5ea5a0acf118665227a4f1a [08/11] loop: remove a spurious clear of discard_alignment commit: 4418bfd8fb9602d9cd8747c3ad52fdbaa02e2ffd [09/11] nvme: remove a spurious clear of discard_alignment commit: 4e7f0ece41e1be8f876f320a0972a715daec0a50 [10/11] rnbd-srv: use bdev_discard_alignment commit: 18292faa89d2bff3bdd33ab9c065f45fb6710e47 [11/11] xen-blkback: use bdev_discard_alignment commit: c899b23533866910c90ef4386b501af50270d320 Best regards, -- Jens Axboe
Re: improve the bio allocation interface
On 1/18/22 12:19 AM, Christoph Hellwig wrote: > Hi Jens, > > this series is posted early because it has wide-ranging changes and > could use some early ACKs before -rc1. > > It changes the interface to the bio allocators to always pass a > block_device and the operation, which is information needed for every > bio submitted through bio_submit. This means the fields can be > directly initialized in bio_init instead of first being zeroed and > thus should help to micro-optimize even better than the __bio_set_dev > that Pavel proposed while also cleaning up code. Looks pretty straight forward from the block core point of view. Didn't look too closely at the fs/driver changes yet. -- Jens Axboe
Re: (subset) [PATCH io_uring-next/net-next v2 0/4] implement io_uring notification (ubuf_info) stacking
On Fri, 19 Apr 2024 12:08:38 +0100, Pavel Begunkov wrote: > Please, don't take directly, conflicts with io_uring. > > To have per request buffer notifications each zerocopy io_uring send > request allocates a new ubuf_info. However, as an skb can carry only > one uarg, it may force the stack to create many small skbs hurting > performance in many ways. > > [...] Applied, thanks! [3/4] io_uring/notif: simplify io_notif_flush() commit: 5a569469b973cb7a6c58192a37dfb8418686e518 [4/4] io_uring/notif: implement notification stacking commit: 6fe4220912d19152a26ce19713ab232f4263018d Best regards, -- Jens Axboe
Re: convert xen-blkfront to atomic queue limit updates v2
On Wed, 21 Feb 2024 13:58:41 +0100, Christoph Hellwig wrote: > this series converts xen-blkfront to the new atomic queue limits update > API in the block tree. I don't have a Xen setup so this is compile > tested only. > > Changes since v1: > - constify the info argument to blkif_set_queue_limits > - remove a spurious word from a commit message > > [...] Applied, thanks! [1/4] xen-blkfront: set max_discard/secure erase limits to UINT_MAX commit: 4a718d7dbab873bc24034fc865d3a5442632d1fd [2/4] xen-blkfront: rely on the default discard granularity commit: 738be136327a56e5a67e1942a2c318fb91914a3f [3/4] xen-blkfront: don't redundantly set max_sements in blkif_recover commit: 4f81b87d91be2a00195f85847d040c2276cac2ae [4/4] xen-blkfront: atomically update queue limits commit: ba3f67c1163812b5d7ec33705c31edaa30ce6c51 Best regards, -- Jens Axboe
Re: [PATCH v2 00/10] block: second batch of add_disk() error handling conversions
On 9/27/21 4:00 PM, Luis Chamberlain wrote: > This is the second series of driver conversions for add_disk() > error handling. You can find this set and the rest of the 7th set of > driver conversions on my 20210927-for-axboe-add-disk-error-handling > branch [0]. Applied 1, thanks. -- Jens Axboe
Re: [PATCH v4 0/29] block: Make blkdev_get_by_*() return handle
On Wed, Sep 27, 2023 at 3:34?AM Jan Kara wrote: > > Hello, > > this is a v3 of the patch series which implements the idea of > blkdev_get_by_*() v4? > calls returning bdev_handle which is then passed to blkdev_put() [1]. This > makes the get and put calls for bdevs more obviously matching and allows us to > propagate context from get to put without having to modify all the users > (again!). In particular I need to propagate used open flags to blkdev_put() to > be able count writeable opens and add support for blocking writes to mounted > block devices. I'll send that series separately. > > The series is based on Btrfs tree's for-next branch [2] as of today as the > series depends on Christoph's changes to btrfs device handling. Patches have > passed some reasonable testing - I've tested block changes, md, dm, bcache, > xfs, btrfs, ext4, swap. More testing or review is always welcome. Thanks! I've > pushed out the full branch to: > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git bdev_handle > > to ease review / testing. Christian, can you pull the patches to your tree > to get some exposure in linux-next as well? Thanks! For the block bits: Acked-by: Jens Axboe -- Jens Axboe
Re: [PATCH 00/11] Rid W=1 warnings from Block
On 3/12/21 3:55 AM, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. Applied 2-11, 1 is already in the my tree. -- Jens Axboe
Re: [PATCH] block: remove unused parameter
On Thu, 13 Mar 2025 09:23:18 +0530, Anuj Gupta wrote: > request_queue param is not used by blk_rq_map_sg and __blk_rq_map_sg. > remove it. > > Applied, thanks! [1/1] block: remove unused parameter commit: 61667cb6644f6fb01eb8baa928e381c016b5ed7b Best regards, -- Jens Axboe
