>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 re
--- 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
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 vari
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 (l
--- [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
>
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
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.
> >
> > Becaus
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
> confusing.
> --- 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 thoug
--- 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)
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
--- 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
> pro
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
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:
--- Pekk
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 N
--- 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 ef
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 o
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 i
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 dete
> 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 i
--- 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 thi
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 fun
--- 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
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 t
--- 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
> > va
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
--- 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.
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
>>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 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 po
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 f
+#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 *__kzall
39 matches
Mail list logo
