[PATCH] ARM: Add SWP/SWPB emulation for ARMv7 processors (v2)

[Russell King - ARM Linux]

On Fri, Dec 18, 2009 at 07:48:14PM +0000, Jamie Lokier wrote:
> Russell King - ARM Linux wrote:
> > On Fri, Dec 18, 2009 at 06:04:06PM +0000, Leif Lindholm wrote:
> > > +static int swp_handler(struct pt_regs *regs, unsigned int instr)
> > > +{
> > > +	unsigned int address, destreg, data;
> > > +	unsigned int res = 0;
> > > +	long current_pid = sys_getpid();
> > 
> > Kernel functions calling system calls like this is frowned upon.  We
> > know what the current PID is - it's available from current->pid.  No
> > function call required.
> 
> Quick nitpick in case Leif follows that advice :-)
> 
> sys_getpid returns task_tgid_vnr(current).
> 
> It is neither ->pid (gettid returns that), nor directly dereferenced
> because of the vnr part.  You'll have to decide whether current->tgid
> or task_tgid_vnr(current), or current->pid after all are the
> appropriate value in this situation.

task_tgid_vnr() returns the "thread group" (aka process) ID, and is
what 'ps' spits out for PID.  current->pid is effectively the thread
ID and is unique to every thread.

If you base this decision on the thread group (sys_getpid()), it can
miss threads within a process which may make use of swp - and the
use of swp may not be in the binary but a called library.

If the purpose of this is to find where the swp's are, then you want
to use current->pid, not sys_getpid().

That aside, the printk is a DoS attack waiting to happen.  It needs
rate limiting.