Message ID | 20230506105054.0155139b3d3a7f249ead37be@linux-foundation.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] dmapool updates for 6.4-rc1 | expand |
On Sat, May 6, 2023 at 10:50 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > Reinstate the dmapool changes which were accidentally removed by > 2d55c16c0c54 ("dmapool: create/destroy cleanup"). Hmm. So this series is exactly the same as def8574308ed..2d55c16c0c54, except for not having that last broken one. Which is fine, but I'm a bit surprised. Why? Because it's also missing the _real_ "dmapool: create/destroy cleanup" patch, ie this one: https://lore.kernel.org/linux-mm/20230126215125.4069751-13-kbusch@meta.com/ and I realize you somehow corrupted it last time, but I did expect it to show up (perhaps folded into another patch, but in _some_ form). Anyway, I've pulled this, but I think the end result of all this confusion was still a tad broken. Linus
The pull request you sent on Sat, 6 May 2023 10:50:54 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-stable-2023-05-06-10-49
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc4354c6e5c21257cf4a50b32f7c11c7d65c55b3
Thank you!
On Sat, 6 May 2023 11:53:16 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, May 6, 2023 at 10:50 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > Reinstate the dmapool changes which were accidentally removed by > > 2d55c16c0c54 ("dmapool: create/destroy cleanup"). > > Hmm. So this series is exactly the same as def8574308ed..2d55c16c0c54, > except for not having that last broken one. > > Which is fine, but I'm a bit surprised. Why? > > Because it's also missing the _real_ "dmapool: create/destroy cleanup" > patch, ie this one: > > https://lore.kernel.org/linux-mm/20230126215125.4069751-13-kbusch@meta.com/ > > and I realize you somehow corrupted it last time, but I did expect it > to show up (perhaps folded into another patch, but in _some_ form). > > Anyway, I've pulled this, but I think the end result of all this > confusion was still a tad broken. > Yes, it's just a little cleanup so I figured I'd restore the non-messed-up patches that make functional changes and hold this one off for the next merge window. From: Keith Busch <kbusch@kernel.org> Subject: dmapool: create/destroy cleanup Date: Thu, 26 Jan 2023 13:51:25 -0800 Set the 'empty' bool directly from the result of the function that determines its value instead of adding additional logic. Link: https://lkml.kernel.org/r/20230126215125.4069751-13-kbusch@meta.com Fixes: 2d55c16c0c54 ("dmapool: create/destroy cleanup") Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: Matthew Wilcox <willy@infradead.org> Cc: Tony Battersby <tonyb@cybernetics.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- mm/dmapool.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) --- a/mm/dmapool.c~dmapool-create-destroy-cleanup +++ a/mm/dmapool.c @@ -226,7 +226,7 @@ struct dma_pool *dma_pool_create(const c { struct dma_pool *retval; size_t allocation; - bool empty = false; + bool empty; if (!dev) return NULL; @@ -276,8 +276,7 @@ struct dma_pool *dma_pool_create(const c */ mutex_lock(&pools_reg_lock); mutex_lock(&pools_lock); - if (list_empty(&dev->dma_pools)) - empty = true; + empty = list_empty(&dev->dma_pools); list_add(&retval->pools, &dev->dma_pools); mutex_unlock(&pools_lock); if (empty) { @@ -361,7 +360,7 @@ static struct dma_page *pool_alloc_page( void dma_pool_destroy(struct dma_pool *pool) { struct dma_page *page, *tmp; - bool empty = false, busy = false; + bool empty, busy = false; if (unlikely(!pool)) return; @@ -369,8 +368,7 @@ void dma_pool_destroy(struct dma_pool *p mutex_lock(&pools_reg_lock); mutex_lock(&pools_lock); list_del(&pool->pools); - if (list_empty(&pool->dev->dma_pools)) - empty = true; + empty = list_empty(&pool->dev->dma_pools); mutex_unlock(&pools_lock); if (empty) device_remove_file(pool->dev, &dev_attr_pools);