linux-kernel - Re: [PATCH RFC 2/8] blackfin: implement syscall restart generically

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: <1319609801.2699.118.camel@satguru>
Date:	Wed, 26 Oct 2011 08:16:41 +0200
From:	Jonas Bonn <jonas@...thpole.se>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [PATCH RFC 2/8] blackfin: implement syscall restart generically


On Tue, 2011-10-25 at 20:01 -0400, Mike Frysinger wrote:
> On Sun, Oct 23, 2011 at 06:19, Jonas Bonn <jonas@...thpole.se> wrote:
> > --- a/arch/blackfin/include/asm/syscall.h
> > +++ b/arch/blackfin/include/asm/syscall.h
> >
> >  static inline long
> >  syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
> >  {
> > -       return regs->p0;
> > +       return regs->orig_p0;
> >  }
> 
> i'm not sure this is correct.  we set the orig_p0 to -1 when forcing
> the syscall to go to restart.  shouldn't syscall_get_nr() still return
> the right value ?

No, syscall_get_nr is only valid while processing a syscall (should
return -1 otherwise) and the syscall processing is effectively finished
once you've handled the restart requirements so returning -1 at that
point makes sense... patch 1/8 relies on that fact.

> 
> >  syscall_set_return_value(struct task_struct *task, struct pt_regs *regs,
> >                          int error, long val)
> >  {
> > -       regs->r0 = error ? -error : val;
> > +       regs->r0 = error ? error : val;
> >  }
> 
> this fix is unrelated (and unmentioned in the changelog).  i also see
> a bunch of other arches doing this.  so we should pull this change out
> into a dedicated patchset, and fix all the arches at the same time.

Agreed, this should go into a separate patch.  It's true that some
arches do the negation as above, but those arch's return positive error
numbers and indicate syscall error by setting a separate flag.  I'll
prepare a separate patch for this.

/Jonas

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