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]
Date:	Mon, 14 Apr 2008 09:49:36 -0500
From:	Timur Tabi <timur@...escale.com>
To:	Jiri Slaby <jirislaby@...il.com>
CC:	linuxppc-dev@...abs.org, Andrew Morton <akpm@...ux-foundation.org>,
	York Sun <yorksun@...escale.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU

Jiri Slaby wrote:
> On 04/14/2008 04:12 PM, Timur Tabi wrote:
>> Unfortunately, the author of the patch, York, is out this week, so I'll have to
>> take care of this.  It'd be easier to modify rh_alloc() so that it doesn't
>> sleep, so that's what I'm going to do.
> 
> Anyway, why do you need the spin lock there (and not mutex)? 

I don't know.  A spinlock just seemed obvious.  Why would I prefer a mutex?

We need a mutual exclusion device in order to prevent multiple threads from
opening the DIU driver simultaneously.  When the driver is opened the first
time, it needs to initialize the hardware.  The hardware can't be initialized
unless we allocate a buffer first.

Now, we could pre-allocate the buffer, but then this would be a permanent 5MB
(8MB if we eliminate rh_alloc) allocation of physically contiguous memory.  I'm
assuming that this would be a bad thing.  It wouldn't eliminate the spinlock,
but at least we wouldn't be calling kmalloc().

I open to suggestion for improvements.  I'm still going to post the rh_alloc
atomic patch, because I think it makes sense anyway.  This should fix the
sleep-within-spinlock problem, but it does not fix the kmalloc-5MB-in-spinlock
problem.

-- 
Timur Tabi
Linux kernel developer at Freescale
--
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