>Amit Choudhary <[EMAIL PROTECTED]> wrote:
>> --- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>>> On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
>> Any strong reason why not? x has some value that does not make sense and can
>> create only problems. And as I explained, it can
Amit Choudhary [EMAIL PROTECTED] wrote:
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Any strong reason why not? x has some value that does not make sense and can
create only problems. And as I explained, it can result in
--- Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 9 Jan 2007 11:02:35 -0800 (PST) Amit Choudhary wrote:
>
> No thanks. If a driver author wants to maintain driver state
> that way, it's OK, but that doesn't make it a global requirement.
>
Ok. So, a driver can have its own local
On Tue, 09 Jan 2007 16:00:51 PST, Amit Choudhary said:
> What did you understand when I wrote that "if you access the same memory
> again using the variable
> 'x"?
>
> Using variable 'x' means using variable 'x' and not variable 'y'.
Right - but in real-world code, 'y' is the actual problem.
--- [EMAIL PROTECTED] wrote:
> On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said:
> > Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can
> > still be debugged by
> > using the slab debugging options. One other benefit of doing this is that
> > if someone tries to
> >
On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said:
> Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can
> still be debugged by
> using the slab debugging options. One other benefit of doing this is that if
> someone tries to
> access the same memory again using the
On Tue, 9 Jan 2007 11:02:35 -0800 (PST) Amit Choudhary wrote:
>
> --- [EMAIL PROTECTED] wrote:
>
> > On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
> > > I do not see how a double free can result in _logical_wrong_behaviour_ of
> > > the program and the
> > > program keeps on running
--- [EMAIL PROTECTED] wrote:
> On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
> > I do not see how a double free can result in _logical_wrong_behaviour_ of
> > the program and the
> > program keeps on running (like an incoming packet being dropped because of
> > double free).
> Double
--- [EMAIL PROTECTED] wrote:
On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
I do not see how a double free can result in _logical_wrong_behaviour_ of
the program and the
program keeps on running (like an incoming packet being dropped because of
double free).
Double
free
On Tue, 9 Jan 2007 11:02:35 -0800 (PST) Amit Choudhary wrote:
--- [EMAIL PROTECTED] wrote:
On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
I do not see how a double free can result in _logical_wrong_behaviour_ of
the program and the
program keeps on running (like an
On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said:
Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can
still be debugged by
using the slab debugging options. One other benefit of doing this is that if
someone tries to
access the same memory again using the variable
--- [EMAIL PROTECTED] wrote:
On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said:
Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can
still be debugged by
using the slab debugging options. One other benefit of doing this is that
if someone tries to
access the
On Tue, 09 Jan 2007 16:00:51 PST, Amit Choudhary said:
What did you understand when I wrote that if you access the same memory
again using the variable
'x?
Using variable 'x' means using variable 'x' and not variable 'y'.
Right - but in real-world code, 'y' is the actual problem.
Did I
--- Randy Dunlap [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007 11:02:35 -0800 (PST) Amit Choudhary wrote:
No thanks. If a driver author wants to maintain driver state
that way, it's OK, but that doesn't make it a global requirement.
Ok. So, a driver can have its own local definition of
On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
> I do not see how a double free can result in _logical_wrong_behaviour_ of the
> program and the
> program keeps on running (like an incoming packet being dropped because of
> double free). Double
> free will _only_and_only_ result in
Amit Choudhary <[EMAIL PROTECTED]> wrote:
> --- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>> On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
>> > Well, I am not proposing this as a debugging aid. The idea is about correct
>> > programming,
>> atleast
>> > from my view. Ideally,
On 08/01/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
--- Pekka Enberg <[EMAIL PROTECTED]> wrote:
> On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> > > And as I explained, it can result in longer code too. So, why
> > > keep this value around. Why not re-initialize it to NULL.
> >
> >
On 1/8/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
It is a programming error because the underlying code cannot handle it.
Yes. Do you also grasp the fact that there is no way for the allocator
to handle it either? So, double-free, from allocator standpoint can
_never_ be no-op.
What you're
On Mon, Jan 08, 2007 at 12:47:07AM -0800, Amit Choudhary wrote:
> Let's try to apply the same logic to my explanation:
>
> KFREE() macro has __actually__ been used at atleast 1000 places in the kernel
> by atleast 50
> different people. Doesn't that lend enough credibility to what I am saying.
--- Pekka Enberg <[EMAIL PROTECTED]> wrote:
> Hi Amit,
>
> On 1/8/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
> > Man, doesn't make sense to me.
>
> Well, man, double-free is a programming error and papering over it
> with NULL initializations bloats the kernel and makes the code
>
> --- Hua Zhong <[EMAIL PROTECTED]> wrote:
>
> > > Any strong reason why not? x has some value that does not
> > > make sense and can create only problems.
> >
> > By the same logic, you should memset the buffer to zero
> before freeing it too.
> >
>
> How does this help?
It doesn't. I
--- Sumit Narayan <[EMAIL PROTECTED]> wrote:
> Asking for KFREE is as silly as asking for a macro to check if kmalloc
> succeeded for a pointer, else return ENOMEM.
>
> #define CKMALLOC(p,x) \
>do { \
>p = kmalloc(x, GFP_KERNEL); \
>if(!p) return -ENOMEM; \
> }
On Mon, 8 Jan 2007, Sumit Narayan wrote:
> Asking for KFREE is as silly as asking for a macro to check if
> kmalloc succeeded for a pointer, else return ENOMEM.
>
> #define CKMALLOC(p,x) \
> do { \
> p = kmalloc(x, GFP_KERNEL); \
> if(!p) return -ENOMEM; \
>} while(0)
--- Vadim Lobanov <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-01-07 at 23:29 -0800, Amit Choudhary wrote:
> > I do not want to write this but I think that you are arguing just for the
> > heck of it. Please
> be
> > sane.
>
> No, I'm merely trying to demonstrate, on a logical basis, why the
>
Hi Amit,
On 1/8/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
Man, doesn't make sense to me.
Well, man, double-free is a programming error and papering over it
with NULL initializations bloats the kernel and makes the code
confusing.
Clear enough for you?
-
To unsubscribe from this list:
Asking for KFREE is as silly as asking for a macro to check if kmalloc
succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
On 1/8/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
---
On Mon, Jan 08, 2007 at 12:31:44AM -0800, Amit Choudhary wrote:
>
> --- Pekka Enberg <[EMAIL PROTECTED]> wrote:
>
> > On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> > > > And as I explained, it can result in longer code too. So, why
> > > > keep this value around. Why not re-initialize it to
--- Pekka Enberg <[EMAIL PROTECTED]> wrote:
> On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> > > And as I explained, it can result in longer code too. So, why
> > > keep this value around. Why not re-initialize it to NULL.
> >
> > Because initialization increases code size.
>
> And it also
On Mon, Jan 08, 2007 at 12:05:59AM -0800, Amit Choudhary wrote:
> Attached is some code from the kernel. Expanded KFREE() has been used atleast
> 1000 times in the
> kernel. By your logic, everyone is stupid in doing so. Something has been
> done atleast 1000 times
> in the kernel, that looks
On Sun, 2007-01-07 at 23:29 -0800, Amit Choudhary wrote:
> I do not want to write this but I think that you are arguing just for the
> heck of it. Please be
> sane.
No, I'm merely trying to demonstrate, on a logical basis, why the
proposed patch does not (in my opinion) belong within the kernel.
--- Hua Zhong <[EMAIL PROTECTED]> wrote:
> > Any strong reason why not? x has some value that does not
> > make sense and can create only problems.
>
> By the same logic, you should memset the buffer to zero before freeing it too.
>
How does this help?
> > And as I explained, it can result
On 1/8/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> And as I explained, it can result in longer code too. So, why
> keep this value around. Why not re-initialize it to NULL.
Because initialization increases code size.
And it also effectively blocks the slab debugging code from doing its
job
On 1/8/07, Hua Zhong [EMAIL PROTECTED] wrote:
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it to NULL.
Because initialization increases code size.
And it also effectively blocks the slab debugging code from doing its
job
--- Hua Zhong [EMAIL PROTECTED] wrote:
Any strong reason why not? x has some value that does not
make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
How does this help?
And as I explained, it can result in longer
On Mon, Jan 08, 2007 at 12:05:59AM -0800, Amit Choudhary wrote:
Attached is some code from the kernel. Expanded KFREE() has been used atleast
1000 times in the
kernel. By your logic, everyone is stupid in doing so. Something has been
done atleast 1000 times
in the kernel, that looks okay.
On Sun, 2007-01-07 at 23:29 -0800, Amit Choudhary wrote:
I do not want to write this but I think that you are arguing just for the
heck of it. Please be
sane.
No, I'm merely trying to demonstrate, on a logical basis, why the
proposed patch does not (in my opinion) belong within the kernel.
--- Pekka Enberg [EMAIL PROTECTED] wrote:
On 1/8/07, Hua Zhong [EMAIL PROTECTED] wrote:
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it to NULL.
Because initialization increases code size.
And it also effectively blocks
On Mon, Jan 08, 2007 at 12:31:44AM -0800, Amit Choudhary wrote:
--- Pekka Enberg [EMAIL PROTECTED] wrote:
On 1/8/07, Hua Zhong [EMAIL PROTECTED] wrote:
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it to NULL.
Asking for KFREE is as silly as asking for a macro to check if kmalloc
succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
On 1/8/07, Amit Choudhary [EMAIL PROTECTED] wrote:
--- Pekka
Hi Amit,
On 1/8/07, Amit Choudhary [EMAIL PROTECTED] wrote:
Man, doesn't make sense to me.
Well, man, double-free is a programming error and papering over it
with NULL initializations bloats the kernel and makes the code
confusing.
Clear enough for you?
-
To unsubscribe from this list: send
--- Vadim Lobanov [EMAIL PROTECTED] wrote:
On Sun, 2007-01-07 at 23:29 -0800, Amit Choudhary wrote:
I do not want to write this but I think that you are arguing just for the
heck of it. Please
be
sane.
No, I'm merely trying to demonstrate, on a logical basis, why the
proposed patch
On Mon, 8 Jan 2007, Sumit Narayan wrote:
Asking for KFREE is as silly as asking for a macro to check if
kmalloc succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
oooh ...
--- Sumit Narayan [EMAIL PROTECTED] wrote:
Asking for KFREE is as silly as asking for a macro to check if kmalloc
succeeded for a pointer, else return ENOMEM.
#define CKMALLOC(p,x) \
do { \
p = kmalloc(x, GFP_KERNEL); \
if(!p) return -ENOMEM; \
} while(0)
There
--- Hua Zhong [EMAIL PROTECTED] wrote:
Any strong reason why not? x has some value that does not
make sense and can create only problems.
By the same logic, you should memset the buffer to zero
before freeing it too.
How does this help?
It doesn't. I thought that was my
--- Pekka Enberg [EMAIL PROTECTED] wrote:
Hi Amit,
On 1/8/07, Amit Choudhary [EMAIL PROTECTED] wrote:
Man, doesn't make sense to me.
Well, man, double-free is a programming error and papering over it
with NULL initializations bloats the kernel and makes the code
confusing.
Clear
On Mon, Jan 08, 2007 at 12:47:07AM -0800, Amit Choudhary wrote:
Let's try to apply the same logic to my explanation:
KFREE() macro has __actually__ been used at atleast 1000 places in the kernel
by atleast 50
different people. Doesn't that lend enough credibility to what I am saying.
No.
On 1/8/07, Amit Choudhary [EMAIL PROTECTED] wrote:
It is a programming error because the underlying code cannot handle it.
Yes. Do you also grasp the fact that there is no way for the allocator
to handle it either? So, double-free, from allocator standpoint can
_never_ be no-op.
What you're
On 08/01/07, Amit Choudhary [EMAIL PROTECTED] wrote:
--- Pekka Enberg [EMAIL PROTECTED] wrote:
On 1/8/07, Hua Zhong [EMAIL PROTECTED] wrote:
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it to NULL.
Because initialization
Amit Choudhary [EMAIL PROTECTED] wrote:
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Well, I am not proposing this as a debugging aid. The idea is about correct
programming,
atleast
from my view. Ideally, if you kfree(x),
On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
I do not see how a double free can result in _logical_wrong_behaviour_ of the
program and the
program keeps on running (like an incoming packet being dropped because of
double free). Double
free will _only_and_only_ result in system
> Any strong reason why not? x has some value that does not
> make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
> And as I explained, it can result in longer code too. So, why
> keep this value around. Why not re-initialize
--- Vadim Lobanov <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-01-07 at 20:09 -0800, Amit Choudhary wrote:
> > I have already explained it earlier. I will try again. You will not need
> > free_2: and free_1:
> with
> > KFREE(). You will only need one free: with KFREE.
>
I do not want to write
On Sun, 2007-01-07 at 20:09 -0800, Amit Choudhary wrote:
> I have already explained it earlier. I will try again. You will not need
> free_2: and free_1: with
> KFREE(). You will only need one free: with KFREE.
So, to rephrase, your stated goal is to get rid of any non-singular goto
labels in
--- Vadim Lobanov <[EMAIL PROTECTED]> wrote:
>
> struct type1 {
> /* something */
> };
>
> struct type2 {
> /* something */
> };
>
> #define COUNT 10
>
> void function1(struct type1 **a1, struct type2 **a2, unsigned int sz);
>
> void function2(void)
> {
> struct type1
On Sun, 2007-01-07 at 16:02 -0800, Amit Choudhary wrote:
> That's where KFREE(ptr) comes in so that the code doesn't look ugly and still
> the purpose is
> achieved.
Shoving it into a macro makes it no better.
> > Reading code like that makes me say "wtf?", simply because 'ptr' is not
> > used
--- Vadim Lobanov <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-01-07 at 14:43 -0800, Amit Choudhary wrote:
> > Any strong reason why not? x has some value that does not make sense and
> > can create only
> problems.
> > And as I explained, it can result in longer code too. So, why keep this
> >
On Sun, 2007-01-07 at 14:43 -0800, Amit Choudhary wrote:
> Any strong reason why not? x has some value that does not make sense and can
> create only problems.
> And as I explained, it can result in longer code too. So, why keep this value
> around. Why not
> re-initialize it to NULL.
Because
--- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
> > Well, I am not proposing this as a debugging aid. The idea is about correct
> > programming,
> atleast
> > from my view. Ideally, if you kfree(x), then you should set x to
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
> Well, I am not proposing this as a debugging aid. The idea is about correct
> programming, atleast
> from my view. Ideally, if you kfree(x), then you should set x to NULL. So,
> either programmers do
> it themselves or a ready
>>On 1/1/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
>>+#define KFREE(x) \
>>+ do { \
>>+ kfree(x); \
>>+ x = NULL; \
>>+ } while(0)
>>NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
>>catches use after free and double-free so I don't see the point of
On 1/1/07, Amit Choudhary [EMAIL PROTECTED] wrote:
+#define KFREE(x) \
+ do { \
+ kfree(x); \
+ x = NULL; \
+ } while(0)
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after free and double-free so I don't see the point of
this.
Well, I am
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Well, I am not proposing this as a debugging aid. The idea is about correct
programming, atleast
from my view. Ideally, if you kfree(x), then you should set x to NULL. So,
either programmers do
it themselves or a ready made
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Well, I am not proposing this as a debugging aid. The idea is about correct
programming,
atleast
from my view. Ideally, if you kfree(x), then you should set x to NULL. So,
On Sun, 2007-01-07 at 14:43 -0800, Amit Choudhary wrote:
Any strong reason why not? x has some value that does not make sense and can
create only problems.
And as I explained, it can result in longer code too. So, why keep this value
around. Why not
re-initialize it to NULL.
Because it
--- Vadim Lobanov [EMAIL PROTECTED] wrote:
On Sun, 2007-01-07 at 14:43 -0800, Amit Choudhary wrote:
Any strong reason why not? x has some value that does not make sense and
can create only
problems.
And as I explained, it can result in longer code too. So, why keep this
value around.
On Sun, 2007-01-07 at 16:02 -0800, Amit Choudhary wrote:
That's where KFREE(ptr) comes in so that the code doesn't look ugly and still
the purpose is
achieved.
Shoving it into a macro makes it no better.
Reading code like that makes me say wtf?, simply because 'ptr' is not
used
--- Vadim Lobanov [EMAIL PROTECTED] wrote:
struct type1 {
/* something */
};
struct type2 {
/* something */
};
#define COUNT 10
void function1(struct type1 **a1, struct type2 **a2, unsigned int sz);
void function2(void)
{
struct type1 *arr1[COUNT];
On Sun, 2007-01-07 at 20:09 -0800, Amit Choudhary wrote:
I have already explained it earlier. I will try again. You will not need
free_2: and free_1: with
KFREE(). You will only need one free: with KFREE.
So, to rephrase, your stated goal is to get rid of any non-singular goto
labels in
--- Vadim Lobanov [EMAIL PROTECTED] wrote:
On Sun, 2007-01-07 at 20:09 -0800, Amit Choudhary wrote:
I have already explained it earlier. I will try again. You will not need
free_2: and free_1:
with
KFREE(). You will only need one free: with KFREE.
I do not want to write this but I
Any strong reason why not? x has some value that does not
make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
And as I explained, it can result in longer code too. So, why
keep this value around. Why not re-initialize it
On Mon, Jan 01, 2007 at 11:23:20PM +0200, Pekka Enberg wrote:
> NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
> catches use after free and double-free so I don't see the point of
> this.
And CONFIG_SLAB_DEBUG actually finds them for real using poisoning,
unlike setting the
On Mon, Jan 01, 2007 at 11:23:20PM +0200, Pekka Enberg wrote:
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after free and double-free so I don't see the point of
this.
And CONFIG_SLAB_DEBUG actually finds them for real using poisoning,
unlike setting the
On 1/1/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after
On 1/1/07, Amit Choudhary [EMAIL PROTECTED] wrote:
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
This doesn't work correctly if "x" has side effects --
double evaluation. Use a temporary variable instead,
or better, an inline function.
Description: new KFREE() macro to set the variable NULL after freeing it.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 1ef822e..28da74c 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -75,6 +75,12 @@ void
Description: new KFREE() macro to set the variable NULL after freeing it.
Signed-off-by: Amit Choudhary [EMAIL PROTECTED]
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 1ef822e..28da74c 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -75,6 +75,12 @@ void
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
This doesn't work correctly if x has side effects --
double evaluation. Use a temporary variable instead,
or better, an inline function. A
78 matches
Mail list logo
