linux-kernel - Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile

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:	Wed, 20 Aug 2008 14:39:45 +0200
From:	Robert Richter <robert.richter@....com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	linuxppc-dev@...abs.org, cbe-oss-dev@...abs.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	oprofile-list@...ts.sourceforge.net,
	Paul Mackerras <paulus@...ba.org>, cel <cel@...ux.vnet.ibm.com>
Subject: Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile

On 11.08.08 09:25:07, Arnd Bergmann wrote:
> From: Carl Love <cel@...ibm.com>
> 
> The issue is the SPU code is not holding the kernel mutex lock while
> adding samples to the kernel buffer.
> 
> This patch creates per SPU buffers to hold the data.  Data
> is added to the buffers from in interrupt context.  The data
> is periodically pushed to the kernel buffer via a new Oprofile
> function oprofile_put_buff(). The oprofile_put_buff() function
> is called via a work queue enabling the funtion to acquire the
> mutex lock.
> 
> The existing user controls for adjusting the per CPU buffer
> size is used to control the size of the per SPU buffers.
> Similarly, overflows of the SPU buffers are reported by
> incrementing the per CPU buffer stats.  This eliminates the
> need to have architecture specific controls for the per SPU
> buffers which is not acceptable to the OProfile user tool
> maintainer.
> 
> The export of the oprofile add_event_entry() is removed as it
> is no longer needed given this patch.
> 
> Note, this patch has not addressed the issue of indexing arrays
> by the spu number.  This still needs to be fixed as the spu
> numbering is not guarenteed to be 0 to max_num_spus-1.
> 
> Signed-off-by: Carl Love <carll@...ibm.com>
> Signed-off-by: Maynard Johnson <maynardj@...ibm.com>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Acked-by: Robert Richter <robert.richter@....com>

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@....com

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