lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200607211312.26459.eike-kernel@sf-tec.de>
Date:	Fri, 21 Jul 2006 13:12:25 +0200
From:	Rolf Eike Beer <eike-kernel@...tec.de>
To:	Panagiotis Issaris <takis@....org>
Cc:	Panagiotis Issaris <takis@...umba.uhasselt.be>,
	linux-kernel@...r.kernel.org, len.brown@...el.com,
	chas@....nrl.navy.mil, miquel@...uba.ar, kkeil@...e.de,
	benh@...nel.crashing.org, video4linux-list@...hat.com,
	rmk+mmc@....linux.org.uk, Neela.Kolli@...enio.com,
	jgarzik@...ox.com, vandrove@...cvut.cz, adaplas@....net,
	thomas@...ischhofer.net, weissg@...nna.at, philb@....org,
	linux-pcmcia@...ts.infradead.org, jkmaline@...hut.fi,
	paulus@...ba.org
Subject: Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.

Panagiotis Issaris wrote:

> > > @@ -443,12 +442,11 @@ int con_clear_unimap(struct vc_data *vc,
> > >  	p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
> > >  	if (p && p->readonly) return -EIO;
> > >  	if (!p || --p->refcount) {
> > > -		q = (struct uni_pagedir *)kmalloc(sizeof(*p), GFP_KERNEL);
> > > +		q = kzalloc(sizeof(*p), GFP_KERNEL);
> > >  		if (!q) {
> > >  			if (p) p->refcount++;
> > >  			return -ENOMEM;
> > >  		}
> > > -		memset(q, 0, sizeof(*q));
> > >  		q->refcount=1;
> > >  		*vc->vc_uni_pagedir_loc = (unsigned long)q;
> > >  	} else {
> >
> > This one still changes the way the code works. Before your patch *p will
> > be always zeroed out. Now if p is there before it will keep it's
> > contents.
>
> Hmm. I do not really see the functional change here: If the memory
> allocation failed, then in both cases, q will be zero and the function
> will return. If the memory allocation succeeds, then in both cases a
> memset will occur. Is it more subtle than that?

You're right, I got somehow confused by this p and q stuff.

Eike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ