On Tue, Jan 23 2018, Dan Carpenter wrote:
> On Tue, Jan 23, 2018 at 09:25:41AM +, Zhen, Liang wrote:
>> Hi, I just realized the “free_conn” parameter is unused in kernel source,
>> but it’s actually used in the original patch:
>> https://review.whamcloud.com/#/c/17892 , so I think it should
On Tue, Jan 23, 2018 at 09:25:41AM +, Zhen, Liang wrote:
> Hi, I just realized the “free_conn” parameter is unused in kernel source, but
> it’s actually used in the original patch:
> https://review.whamcloud.com/#/c/17892 , so I think it should be fixed in
> the kernel.
>
Dmitry already s
>
> Hello NeilBrown,
>
> The patch 3c88bdbbf919: "staging: lustre: replace simple cases of
> LIBCFS_ALLOC with kzalloc." from Jan 9, 2018, leads to the following
> static checker warning:
>
> drivers/st
hat should be free and what shouldn't isn't immediately clear.
Liang: do you remember what you intended for that arg to do?
Thanks,
NeilBrown
>
> Hello NeilBrown,
>
> The patch 3c88bdbbf919: "staging: lustre: replace simple cases of
>
d for that arg to do?
Thanks,
NeilBrown
>
> Hello NeilBrown,
>
> The patch 3c88bdbbf919: "staging: lustre: replace simple cases of
> LIBCFS_ALLOC with kzalloc." from Jan 9, 2018, leads to the following
> static checker warning:
>
> drivers/staging/lustre/lnet/kl
On Mon, Jan 15, 2018 at 06:27:26PM +, Eremin, Dmitry wrote:
> Hello Dan,
>
> The function kiblnd_destroy_conn() is conditionally free the conn pointer.
>
> void kiblnd_destroy_conn(kib_conn_t *conn, bool free_conn)
> {
> […]
> if (free_conn)
>LI
e.org
> Subject: RE: [lustre-devel] [bug report] staging: lustre: replace simple cases
> of LIBCFS_ALLOC with kzalloc.
>
> Hello Dan,
>
> The function kiblnd_destroy_conn() is conditionally free the conn pointer.
>
> void kiblnd_destroy_conn(kib_conn_t *conn, bool free_conn
ubject: [lustre-devel] [bug report] staging: lustre: replace simple cases of
> LIBCFS_ALLOC with kzalloc.
>
> [ This code was already buggy, it's just that Neil's change made it
>show up in static analysis. - dan ]
>
> Hello NeilBrown,
>
> The patch 3c88b
[ This code was already buggy, it's just that Neil's change made it
show up in static analysis. - dan ]
Hello NeilBrown,
The patch 3c88bdbbf919: "staging: lustre: replace simple cases of
LIBCFS_ALLOC with kzalloc." from Jan 9, 2018, leads to the following
st
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
___
devel mailing list
de
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
___
devel mailing list
de...@l
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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.or
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
23 matches
Mail list logo
