lkml.org 
[lkml]   [2008]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86_64 ia32 syscall restart fix

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > > The code to restart syscalls after signals depends on checking for a
> > > negative orig_ax, and for particular negative -ERESTART* values in ax.
> > > These fields are 64 bits and for a 32-bit task they get zero-extended.
> > > The syscall restart behavior is lost, a regression from a native
> > > 32-bit kernel and from 64-bit tasks' behavior. This patch fixes the
> > > problem by doing sign-extension where it matters. For orig_ax, the
> > > only time the value should be -1 but winds up as 0x0ffffffff is via a
> > > 32-bit ptrace call. So the patch changes ptrace to sign-extend the
> > > 32-bit orig_eax value when it's stored; it doesn't change the checks
> > > on orig_ax, though it uses the new current_syscall() inline to better
> > > document the subtle importance of the used of signedness there. The
> > > ax value is stored a lot of ways and it seems hard to get them all
> > > sign-extended at their origins. So for that, we use the
> > > current_syscall_ret() to sign-extend it only for 32-bit tasks at the
> > > time of the -ERESTART* comparisons.
> >
> > thanks, applied.
>
> Btw, can we please try to keep commit log messages readable?

yeah - the minute i added the patch i pinged Roland about that offline.

> Yeah, maybe it's just me, but I like my whitespace.
> Ihaveareallyhardtime
> readingtextthatdoesn'thavethepropermarkersforwhereconceptsstartandbegin,
> andthatreallydoesincludetheverticalwhitespacetoo.

heh :)

> Now, the only reason I mention this is that normally I would probably
> just have fixed this up myself without even a comment (because it's
> such a tiny detail that it's not not worth one), but when Ingo merges
> it I'll now get it through git and it will be fixed.

currently the reality is that i have to fix over 90% of the commit
messages that go towards you :-/

While i'd like that proportion to be a lot lower, it's really hard for
people to write good commit messages for fixes: people tend to send
their fixes the minute they find the problem (being happy about having
found and fixed a problem!), so the commit message gets little
attention.

another effect is that kernel generalist people like Roland have a very
large list of todo items so when they write up the commit message they
might be thinking about the next unsolved problem already - and the
commit message becomes a quick, unstructured and semi-automatic
brain-dump of all details in essence :-/

Also, who am i to complain about the commit message - i'm often the one
who has put the bug in to begin with! [ So i'm perfectly happy with you
volunteering to take over that role ;-) ]

But yes, it's easier for me too to sort and prioritize patches if their
description has good structure, so i regularly try to remind high-volume
patch submitters about that. ( With little success i have to say -
commit messages seem to be suffering from the same curse of inattention
as other types of documentation do :-/ )

Ingo


\
 
 \ /
  Last update: 2008-02-29 17:49    [W:0.484 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site