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: <alpine.DEB.2.02.1203140957020.2146@localhost6.localdomain6>
Date:	Wed, 14 Mar 2012 10:23:47 +0100 (CET)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Guan Xuetao <gxt@...c.pku.edu.cn>
cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/7] arch/unicore32/kernel/dma.c: ensure arguments to
 request_irq and free_irq are compatible



On Wed, 14 Mar 2012, Guan Xuetao wrote:

> On Wed, 2012-03-14 at 11:19 +0300, Dan Carpenter wrote:
>> On Wed, Mar 14, 2012 at 04:07:24PM +0800, Guan Xuetao wrote:
>>> puv3_init_dma() is called ONCE when initializing.
>>> In logical, if request_irq(IRQ_DMAERR, *) failed, free_irq(IRQ_DMA, *)
>>> is unnecessary, and dma device/driver can keep on working.
>>> The patch could be:
>>>   	ret = request_irq(IRQ_DMAERR, dma_err_handler, 0, "DMAERR", NULL);
>>>   	if (ret) {
>>>   		printk(KERN_CRIT "Can't register IRQ for DMAERR\n");
>>>  -		free_irq(IRQ_DMA, "DMA");
>>>   		return ret;
>>>   	}
>>
>> It seems like you should remove the error return as well?
>>
>> regards,
>> dan carpenter
>>
> The error return value will only generate an extra warning message, and
> have no side-effect.

The whole thing seems a little strange.  I guess your point is that the 
call site never looks at the return value?  Wouldn't it be better to make 
there be no return value in that case?  If there is a return value, some 
calling context in the future might take that into account and then the 
lack of a free_irq would be a memory leak.  Also if the first request_irq 
can never fail, perhaps that should be made explicit by not testing the 
return value?

julia
--
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