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 <ne...@suse.com>
---
.../lustre/include/linux/libcfs/libcfs_private.h | 51
1 file changed, 51 deletions(-)
diff
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_nodemask)
goto failed;
- LIBCFS_ALLOC(cptab->ctb_cpu2cpt,
-num_possible_cpus() * sizeof(cptab->ctb_cpu2cpt[0]));
+ cptab->ctb_cpu2cpt = kvmalloc_array(num_possible_cpus(),
+ sizeof(cpta
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->ctb_nodemask
struct libcfs_ioctl_hdr **hdr_pp,
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 **
,
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 vmalloc
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 vmalloc
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
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))
>>
>> are ch
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))
>>
>> are ch
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);
>
> Similarly, al
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);
>
> Similarly, al
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]
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]
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:
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:
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:
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:
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
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:
- LIBCFS_FR
@@ do {
\
} \
} while (0)
-/**
- * default allocator
- */
-#define LIBCFS_ALLOC(ptr, size)
\
-do { \
- L
{
\
} \
} 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->
struct libcfs_ioctl_hdr **hdr_pp,
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 **
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_nodemask
,
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 vmalloc
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 vmalloc
From: Frank Zago <fz...@cray.com>
LIBCFS_ALLOC already zero out the memory allocated, so there is no
need to zero out the memory again.
Signed-off-by: Frank Zago <fz...@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5304
Reviewed-on: http://review.whamcloud.com/11
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
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
From: Frank Zago <fz...@cray.com>
LIBCFS_ALLOC already zero out the memory allocated, so there is no
need to zero out the memory again.
Signed-off-by: Frank Zago <fz...@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5304
Reviewed-on: http://review.whamcloud.com/11
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 acceptable for kzalloc too, but I wouldn't
&
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 LIBCFS_ALLOC is used just by the
libcfs/LNet
layer.
That is because there was (is?) interest from Cray and others to use LNet
y 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 LIBCFS_ALLOC is used just by the libcfs/LN
just LIBCFS_ALLOC. For some reason before my time OBD_ALLOC got spawned
off of that. Currently LIBCFS_ALLOC is used just by the libcfs/LNet layer. Now
OBD_ALLOC in our development branch has moved to a try kmalloc first and
if it fails try vmalloc for any size memory allocation. LIBCFS_ALLOC
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(c
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
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
>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
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 vmalloc
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 exhaustion
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
On 2015/06/28, 12:52 AM, Julia Lawall julia.law...@lip6.fr 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, sizeof(*cr));
The definition
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
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
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
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
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 (and
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/
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 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 (and
all frees
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
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
a cocci patch
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
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
60 matches
Mail list logo
