LIBCFS_ALLOC
LIBCFS_ALLOC_ATOMIC
LIBCFS_ALLOC_POST
LIBCFS_CPT_ALLOC
LIBCFS_FREE
are no longer used, and so are removed.
Signed-off-by: NeilBrown
---
.../lustre/include/linux/libcfs/libcfs_private.h | 51
1 file changed, 51 deletions(-)
diff --git a/drivers/staging
cptab->ctb_nparts * sizeof(cptab->ctb_parts[0]));
- }
+ kvfree(cptab->ctb_parts);
kfree(cptab->ctb_nodemask);
free_cpumask_var(cptab->ctb_cpumask);
@@ -136,15 +129,17 @@ cfs_cpt_table_alloc(unsigned int ncpt)
!cptab->ct
,
return -EINVAL;
}
- LIBCFS_ALLOC(*hdr_pp, hdr.ioc_len);
+ *hdr_pp = kvmalloc(hdr.ioc_len, GFP_KERNEL);
if (!*hdr_pp)
return -ENOMEM;
@@ -164,7 +164,7 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
return 0
All usages of the form
LIBCFS_ALLOC(variable, sizeof(variable))
or
LIBCFS_ALLOC(variable, sizeof(variable's-type))
are changed to
variable = kzalloc(sizeof(...), GFP_NOFS);
Similarly, all
LIBCFS_FREE(variable, sizeof(variable))
become
kfree(variable);
None of these need the vm
When an allocation happens from process context rather than
filesystem context, it is best to use GFP_KERNEL rather than
LIBCFS_ALLOC() which always uses GFP_NOFS.
This include initialization during, or prior to, mount,
and code run from separate worker threads.
So for some of these cases, switch
On Mon, Jan 08 2018, Greg Kroah-Hartman wrote:
> On Mon, Dec 18, 2017 at 11:46:30AM +1100, NeilBrown wrote:
>> All usages of the form
>> LIBCFS_ALLOC(variable, sizeof(variable))
>> or
>> LIBCFS_ALLOC(variable, sizeof(variable's-type))
>>
>> a
On Mon, Dec 18, 2017 at 11:46:30AM +1100, NeilBrown wrote:
> All usages of the form
> LIBCFS_ALLOC(variable, sizeof(variable))
> or
> LIBCFS_ALLOC(variable, sizeof(variable's-type))
>
> are changed to
> variable = kzalloc(sizeof(...), GFP_NOFS);
>
> Similarl
Hi NeilBrown,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20171221]
[cannot apply to v4.15-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi NeilBrown,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20171220]
[cannot apply to v4.15-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
ht
Hi NeilBrown,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20171219]
[cannot apply to v4.15-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
ht
return -EINVAL;
}
- LIBCFS_ALLOC(*hdr_pp, hdr.ioc_len);
+ *hdr_pp = kvmalloc(hdr.ioc_len, GFP_KERNEL);
if (!*hdr_pp)
return -ENOMEM;
@@ -164,7 +164,7 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
return 0;
free:
- LIBC
{
\
} \
} while (0)
-/**
- * default allocator
- */
-#define LIBCFS_ALLOC(ptr, size)
\
-do { \
- LASSERT(!in_interrupt
cptab->ctb_nparts * sizeof(cptab->ctb_parts[0]));
- }
+ kvfree(cptab->ctb_parts);
if (cptab->ctb_nodemask)
kfree(cptab->ctb_nodemask);
@@ -140,15 +133,17 @@ cfs_cpt_table_alloc(unsigned int ncpt)
!cptab->ctb_node
,
return -EINVAL;
}
- LIBCFS_ALLOC(*hdr_pp, hdr.ioc_len);
+ *hdr_pp = kvmalloc(hdr.ioc_len, GFP_KERNEL);
if (!*hdr_pp)
return -ENOMEM;
@@ -164,7 +164,7 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
return 0
When an allocation happens from process context rather than
filesystem context, it is best to use GFP_KERNEL rather than
LIBCFS_ALLOC() which always uses GFP_NOFS.
This include initialization during, or prior to, mount,
and code run from separate worker threads.
So for some of these cases, switch
All usages of the form
LIBCFS_ALLOC(variable, sizeof(variable))
or
LIBCFS_ALLOC(variable, sizeof(variable's-type))
are changed to
variable = kzalloc(sizeof(...), GFP_NOFS);
Similarly, all
LIBCFS_FREE(variable, sizeof(variable))
become
kfree(variable);
None of these need the vm
From: Frank Zago
LIBCFS_ALLOC already zero out the memory allocated, so there is no
need to zero out the memory again.
Signed-off-by: Frank Zago
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5304
Reviewed-on: http://review.whamcloud.com/11012
Reviewed-by: Patrick Farrell
Reviewed-by
From: Frank Zago
LIBCFS_ALLOC already zero out the memory allocated, so there is no
need to zero out the memory again.
Signed-off-by: Frank Zago
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5304
Reviewed-on: http://review.whamcloud.com/11012
Reviewed-by: Patrick Farrell
Reviewed-by
nother argument is
>>that kzalloc is a well known function that people and bug-finding tools
>>understand, so it is better to use it whenever possible.
>>
>>Some of the other structures contain a lot more fields, as well as small
>>arrays. They are probably acceptabl
small
>arrays. They are probably acceptable for kzalloc too, but I wouldn't know
>the exact dividing line.
The reason I bring this up is to discuss sorting this out. Once long ago we had
just LIBCFS_ALLOC. For some reason before my time OBD_ALLOC got spawned
off of that. Currently LI
On 2015/06/28, 12:52 AM, "Julia Lawall" wrote:
>It is not clear that all of the uses of LIBCFS_ALLOC really risk needing
>vmalloc. For example:
>
>lnet/klnds/socklnd/socklnd.c, function ksocknal_accept:
>
>ksock_connreq_t *cr;
>...
>LIBCFS_ALLOC(cr,
All that you are saying is true and stuff that Julia and I have
discussed before. For this call site though we are not allocating 32k,
we're allocating 4 pointers so libcfs_kvzalloc() doesn't make sense.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Tue, 30 Jun 2015, Simmons, James A. wrote:
> >Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even
> >a tiny sliver of RAM isn't going to work. It's easier to use
> >libcfs_kvzalloc() everywhere, but it's probably the wrong thing.
>
> The original reason we have the vmal
>Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even
>a tiny sliver of RAM isn't going to work. It's easier to use
>libcfs_kvzalloc() everywhere, but it's probably the wrong thing.
The original reason we have the vmalloc water mark wasn't so much the
issue of memory exhausti
Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even
a tiny sliver of RAM isn't going to work. It's easier to use
libcfs_kvzalloc() everywhere, but it's probably the wrong thing.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
It is not clear that all of the uses of LIBCFS_ALLOC really risk needing
vmalloc. For example:
lnet/klnds/socklnd/socklnd.c, function ksocknal_accept:
ksock_connreq_t *cr;
...
LIBCFS_ALLOC(cr, sizeof(*cr));
The definition of ksock_connreq_t is:
typedef struct ksock_connreq {
struct
On Jun 23, 2015, at 2:23 AM, Julia Lawall wrote:
> It seems that libcfs_kvzalloc doesn't use any particular threshold or
> switchingbetween kzalloc and vmalloc, so can be replaced by ths function
> too?
If you mean to replace all instances of LIBCFS_ALLOC with libcfs_kvzalloc (
It seems that libcfs_kvzalloc doesn't use any particular threshold or
switchingbetween kzalloc and vmalloc, so can be replaced by ths function
too?
thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
On Sat, Jun 14, 2014 at 05:29:51PM +1000, Vitaly Osipov wrote:
> Joe Perches mentioned on driverdev-devel that memset after LIBCFS_ALLOC
> is not necessary as it is already done during LIBCFS_ALLOC_POST. This
> commit removes these unnecessary memsets. Based on the results of running
Joe Perches mentioned on driverdev-devel that memset after LIBCFS_ALLOC
is not necessary as it is already done during LIBCFS_ALLOC_POST. This
commit removes these unnecessary memsets. Based on the results of running
a cocci patch along the lines of:
@@
expression E1, E2;
@@
LIBCFS_ALLOC (E1,E2
30 matches
Mail list logo
