[Cluster-devel] [PATCH] dlm: NULL check before kmem_cache_destroy is not needed
kmem_cache_destroy(NULL) is safe, so removes NULL check before
freeing the mem. This patch also fix ifnullfree.cocci warnings.
Signed-off-by: Wen Yang
CC: Julia Lawall
CC: Christine Caulfield
CC: David Teigland
CC: cluster-devel@redhat.com
CC: linux-ker...@vger.kernel.org
---
fs/dlm/memory.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/dlm/memory.c b/fs/dlm/memory.c
index 7cd24bccd4fe..37be29f21d04 100644
--- a/fs/dlm/memory.c
+++ b/fs/dlm/memory.c
@@ -38,10 +38,8 @@ int __init dlm_memory_init(void)
void dlm_memory_exit(void)
{
- if (lkb_cache)
- kmem_cache_destroy(lkb_cache);
- if (rsb_cache)
- kmem_cache_destroy(rsb_cache);
+ kmem_cache_destroy(lkb_cache);
+ kmem_cache_destroy(rsb_cache);
}
char *dlm_allocate_lvb(struct dlm_ls *ls)
@@ -86,8 +84,7 @@ void dlm_free_lkb(struct dlm_lkb *lkb)
struct dlm_user_args *ua;
ua = lkb->lkb_ua;
if (ua) {
- if (ua->lksb.sb_lvbptr)
- kfree(ua->lksb.sb_lvbptr);
+ kfree(ua->lksb.sb_lvbptr);
kfree(ua);
}
}
--
2.19.1
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On Wed, Nov 28, 2018 at 06:44:00AM -0700, Jens Axboe wrote: > On 11/25/18 7:17 PM, Ming Lei wrote: > > Hi, > > > > This patchset brings multi-page bvec into block layer: > > > > 1) what is multi-page bvec? > > > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > > which are physically contiguous instead of one single page used in linux > > kernel for long time. > > > > 2) why is multi-page bvec introduced? > > > > Kent proposed the idea[1] first. > > > > As system's RAM becomes much bigger than before, and huge page, transparent > > huge page and memory compaction are widely used, it is a bit easy now > > to see physically contiguous pages from fs in I/O. On the other hand, from > > block layer's view, it isn't necessary to store intermediate pages into > > bvec, > > and it is enough to just store the physicallly contiguous 'segment' in each > > io vector. > > > > Also huge pages are being brought to filesystem and swap [2][6], we can > > do IO on a hugepage each time[3], which requires that one bio can transfer > > at least one huge page one time. Turns out it isn't flexiable to change > > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > > as much bigger, such as 512, which requires at least two 4K pages for > > holding > > the bvec table. > > I'm pretty happy with this patchset at this point, looks like it just > needs a respin to address the last comments. My only concern is whether I will address the last comment from Omar on patch of '[PATCH V12 01/20] btrfs: remove various bio_offset arguments', we may use the approach in V11 simply. > it's a good idea to target this for 4.21, or if we should wait until > 4.22. 4.21 has a fairly substantial amount of changes in terms of block > already, it's not the best timing for something of this magnitude too. Yeah, I understand. > > I'm going back and forth on those one a bit. Any concerns with > pushing this to 4.22? My only one concern is about the warning of "blk_cloned_rq_check_limits: over max segments limit" on dm multipath, and seems Ewan and Mike is waiting for this fix. thanks, Ming
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On 11/28/18 6:30 PM, Ming Lei wrote: >> I'm going back and forth on those one a bit. Any concerns with >> pushing this to 4.22? > > My only one concern is about the warning of > "blk_cloned_rq_check_limits: over max segments limit" on dm multipath, > and seems Ewan and Mike is waiting for this fix. Not familiar with this issue, can you post a link to it? I'd be fine working around anything until 4.22, it's not going to be a new issue. -- Jens Axboe
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On Wed, Nov 28, 2018 at 07:20:51PM -0700, Jens Axboe wrote: > On 11/28/18 6:30 PM, Ming Lei wrote: > >> I'm going back and forth on those one a bit. Any concerns with > >> pushing this to 4.22? > > > > My only one concern is about the warning of > > "blk_cloned_rq_check_limits: over max segments limit" on dm multipath, > > and seems Ewan and Mike is waiting for this fix. > > Not familiar with this issue, can you post a link to it? I'd be fine > working around anything until 4.22, it's not going to be a new issue. https://marc.info/?t=15330342572=1=2 thanks, Ming
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On 11/25/18 7:17 PM, Ming Lei wrote: > Hi, > > This patchset brings multi-page bvec into block layer: > > 1) what is multi-page bvec? > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > which are physically contiguous instead of one single page used in linux > kernel for long time. > > 2) why is multi-page bvec introduced? > > Kent proposed the idea[1] first. > > As system's RAM becomes much bigger than before, and huge page, transparent > huge page and memory compaction are widely used, it is a bit easy now > to see physically contiguous pages from fs in I/O. On the other hand, from > block layer's view, it isn't necessary to store intermediate pages into bvec, > and it is enough to just store the physicallly contiguous 'segment' in each > io vector. > > Also huge pages are being brought to filesystem and swap [2][6], we can > do IO on a hugepage each time[3], which requires that one bio can transfer > at least one huge page one time. Turns out it isn't flexiable to change > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > as much bigger, such as 512, which requires at least two 4K pages for holding > the bvec table. I'm pretty happy with this patchset at this point, looks like it just needs a respin to address the last comments. My only concern is whether it's a good idea to target this for 4.21, or if we should wait until 4.22. 4.21 has a fairly substantial amount of changes in terms of block already, it's not the best timing for something of this magnitude too. I'm going back and forth on those one a bit. Any concerns with pushing this to 4.22? -- Jens Axboe
