From: NeilBrown <neilb@suse.com>
To: Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>,
James Simmons <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
lustre <lustre-devel@lists.lustre.org>
Subject: [PATCH 10/14] staging: lustre: use kmalloc for allocating ksock_tx
Date: Tue, 09 Jan 2018 12:19:38 +1100 [thread overview]
Message-ID: <151546077852.9776.2149131708167902397.stgit@noble> (raw)
In-Reply-To: <151546052331.9776.7408338350463291753.stgit@noble>
The size of the data structure is primarily controlled
by the iovec size, which is limited to 256.
Entries in this vector are 12 bytes, so the whole
will always fit in a page.
So it is safe to use kmalloc (kvmalloc not needed).
So replace LIBCFS_ALLOC with kmalloc.
Signed-off-by: NeilBrown <neilb@suse.com>
---
.../staging/lustre/lnet/klnds/socklnd/socklnd.c | 2 +-
.../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index dc63ed2ceb97..7dba949a95a7 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -2282,7 +2282,7 @@ ksocknal_free_buffers(void)
list_for_each_entry_safe(tx, temp, &zlist, tx_list) {
list_del(&tx->tx_list);
- LIBCFS_FREE(tx, tx->tx_desc_size);
+ kfree(tx);
}
} else {
spin_unlock(&ksocknal_data.ksnd_tx_lock);
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index 994b6693c6b7..11fd3a36424f 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -46,7 +46,7 @@ ksocknal_alloc_tx(int type, int size)
}
if (!tx)
- LIBCFS_ALLOC(tx, size);
+ tx = kzalloc(size, GFP_NOFS);
if (!tx)
return NULL;
@@ -102,7 +102,7 @@ ksocknal_free_tx(struct ksock_tx *tx)
spin_unlock(&ksocknal_data.ksnd_tx_lock);
} else {
- LIBCFS_FREE(tx, tx->tx_desc_size);
+ kfree(tx);
}
}
next prev parent reply other threads:[~2018-01-09 1:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 1:19 [PATCH 00/14] staging:lustre: convert most LIBCFS*ALLOC to k*malloc - V2 NeilBrown
2018-01-09 1:19 ` [PATCH 09/14] staging: lustre: lnet-route: use kmalloc for small allocation NeilBrown
2018-01-09 1:19 ` [PATCH 11/14] staging: lustre: cfs_percpt_alloc: use kvmalloc(GFP_KERNEL) NeilBrown
2018-01-09 1:19 ` [PATCH 13/14] staging: lustre: replace LIBCFS_CPT_ALLOC() NeilBrown
2018-01-09 1:19 ` [PATCH 14/14] staging: lustre: remove LIBCFS_ALLOC, LIBCFS_FREE and related macros NeilBrown
2018-01-09 1:19 ` [PATCH 01/14] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc NeilBrown
2018-01-09 1:19 ` [PATCH 04/14] staging: lustre: lnet: use kmalloc/kvmalloc in router_proc NeilBrown
2018-01-09 1:19 ` [PATCH 02/14] staging: lustre: lnet: switch to cpumask_var_t NeilBrown
2018-01-09 1:19 ` [PATCH 12/14] staging: lustre: opencode LIBCFS_ALLOC_ATOMIC calls NeilBrown
2018-01-09 1:19 ` [PATCH 03/14] staging: lustre: lnet: selftest: don't allocate small strings NeilBrown
2018-01-09 1:19 ` NeilBrown [this message]
2018-01-09 1:19 ` [PATCH 06/14] staging: lustre: Convert more LIBCFS_ALLOC allocation to direct GFP_KERNEL NeilBrown
2018-01-09 1:19 ` [PATCH 07/14] staging: lustre: more LIBCFS_ALLOC conversions to GFP_KERNEL allocations NeilBrown
2018-01-09 1:19 ` [PATCH 08/14] staging: lustre: more " NeilBrown
2018-01-09 1:19 ` [PATCH 05/14] staging: lustre: change some LIBCFS_ALLOC calls to k?alloc(GFP_KERNEL) NeilBrown
2018-01-09 15:00 ` [PATCH 00/14] staging:lustre: convert most LIBCFS*ALLOC to k*malloc - V2 Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=151546077852.9776.2149131708167902397.stgit@noble \
--to=neilb@suse.com \
--cc=andreas.dilger@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®