Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Thu, Oct 25, 2012 at 09:31:31AM -0400, Chris Metcalf wrote: > On 10/23/2012 4:36 PM, Al Viro wrote: > > Could you test the following on top of your patch? It gets rid of > > regs use in sys_clone() *and* of the regs argument in copy_thread(). > > If that work (including SMP - note that it changes the path taken > > by copy_thread() when called by fork_idle()), that should be all > > we'll need in arch/tile for killing idle_regs() and killing the pt_regs > > passing to do_fork()/copy_process()/copy_thread(). > > It seems to work fine. Thanks! Thanks. Put into no-rebase mode. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/23/2012 4:36 PM, Al Viro wrote: > Could you test the following on top of your patch? It gets rid of > regs use in sys_clone() *and* of the regs argument in copy_thread(). > If that work (including SMP - note that it changes the path taken > by copy_thread() when called by fork_idle()), that should be all > we'll need in arch/tile for killing idle_regs() and killing the pt_regs > passing to do_fork()/copy_process()/copy_thread(). It seems to work fine. Thanks! Acked-by: Chris Metcalf -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/23/2012 4:36 PM, Al Viro wrote: Could you test the following on top of your patch? It gets rid of regs use in sys_clone() *and* of the regs argument in copy_thread(). If that work (including SMP - note that it changes the path taken by copy_thread() when called by fork_idle()), that should be all we'll need in arch/tile for killing idle_regs() and killing the pt_regs passing to do_fork()/copy_process()/copy_thread(). It seems to work fine. Thanks! Acked-by: Chris Metcalf cmetc...@tilera.com -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Thu, Oct 25, 2012 at 09:31:31AM -0400, Chris Metcalf wrote: On 10/23/2012 4:36 PM, Al Viro wrote: Could you test the following on top of your patch? It gets rid of regs use in sys_clone() *and* of the regs argument in copy_thread(). If that work (including SMP - note that it changes the path taken by copy_thread() when called by fork_idle()), that should be all we'll need in arch/tile for killing idle_regs() and killing the pt_regs passing to do_fork()/copy_process()/copy_thread(). It seems to work fine. Thanks! Thanks. Put into no-rebase mode. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote: > On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: > > > It is spelled: > > > > > > git notes add -m SHA1 > > > > > > The resulting notes are stored in a separate revision-controlled branch > > > and can be pushed and pulled like regular refs. Note, though, that the > > > default refspecs do not yet include refs/notes, so you'd have to add > > > them manually. The workflows around notes are not very mature yet, so if > > > you start using them, feedback would be appreciated. > > > > What would be nice is that notes are pushed/pulled automatically with > > standard git push/fetch/pull commands. Usually git walks the DAG > > starting with the pulled commit or tag and following the parents. With > > notes, the reference is reversed, the note pointing to the commit and > > not the other way around. So handling this automatically in Git would > > be really useful. > > Right, that's what I meant about the refspecs. You can configure git to > push or pull them automatically, but it is not the default. Something > like: > > git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' Yes, but that's a bit more complicated than a simple pull. Anyway, Linus seems to not be in favour of annotating commits later for adding acks, so no need for such feature. > > The other feature I'd like is that notes are automatically folded in > > the log during git rebase (maybe similar to the squash option). If you > > rebase, you lose all the notes (though this depends on the workflow, > > it may not be needed with published branches). > > Git-rebase can automatically copy notes from one commit to another > during a rebase, but you need to set notes.rewriteRef to do so (see "git > help config" for details). The reason for this conservative default is > that some notes may not be appropriate for automatic copying (e.g., a > notes tree containing QA approval should probably be invalidated during > a rebase, whereas one with commentary probably should). Thanks, I wasn't aware of this. > Squashing the notes into the commit message during rebase would be a > useful feature (at least for some type of notes), but that feature does > not currently exist (and as far as I recall, this is the first it has > been proposed). For some workflow - I post patches to the list, people reply with their acks, I could just add those to notes and later fold them into the existing commits before pushing the branch upstream. I guess it may be just a matter of changing git format-patch to include the notes. I can later reword he commits and drop the "Notes:" line. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Am 10/24/2012 0:23, schrieb Jeff King: > For the fold-on-rebase idea, I'd think you would want something similar, > like setting rebase.foldNotes to "foo" to say "refs/notes/foo contains > pseudo-headers that should be folded in like a signed-off-by". If you are rebasing anyway, you can already use interactive rebase's --autosquash option: # a late ACK came in: git commit --allow-empty -m'squash! tile: support GENERIC_ Acked-by: A U Thor ' git rebase -i --keep-empty --autosquash $forkpoint Requires git 1.7.11 for --keep-empty and requires to edit out the 'squash!...' headers when the editor appears during the rebase. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
* Linus Torvalds wrote: > On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: > >> > >> It is spelled: > >> > >> git notes add -m SHA1 > > > > Cool! > > Don't use them for anything global. > > Use them for local codeflow, but don't expect them to be > distributed. It's a separate "flow", and while it *can* be > distributed, it's not going to be for the kernel, for example. > So no, don't start using this to ack things, because the acks > *will* get lost. I'd also add a small meta argument: that it would be actively wrong to *allow* 'belated' acks to be added. In practice acks are most useful *before* a commit gets created and they often have a mostly buerocratic role afterwards. So we should encourage timely acks (which actually help development), and accept ack-less patches as long as they are correct and create no problems. More utility, less buerocracy. Incorrect, ack-less patches causing problems will get all the flames they deserve. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
* Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. I'd also add a small meta argument: that it would be actively wrong to *allow* 'belated' acks to be added. In practice acks are most useful *before* a commit gets created and they often have a mostly buerocratic role afterwards. So we should encourage timely acks (which actually help development), and accept ack-less patches as long as they are correct and create no problems. More utility, less buerocracy. Incorrect, ack-less patches causing problems will get all the flames they deserve. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Am 10/24/2012 0:23, schrieb Jeff King: For the fold-on-rebase idea, I'd think you would want something similar, like setting rebase.foldNotes to foo to say refs/notes/foo contains pseudo-headers that should be folded in like a signed-off-by. If you are rebasing anyway, you can already use interactive rebase's --autosquash option: # a late ACK came in: git commit --allow-empty -m'squash! tile: support GENERIC_ Acked-by: A U Thor aut...@example.com' git rebase -i --keep-empty --autosquash $forkpoint Requires git 1.7.11 for --keep-empty and requires to edit out the 'squash!...' headers when the editor appears during the rebase. -- Hannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote: On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. Right, that's what I meant about the refspecs. You can configure git to push or pull them automatically, but it is not the default. Something like: git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' Yes, but that's a bit more complicated than a simple pull. Anyway, Linus seems to not be in favour of annotating commits later for adding acks, so no need for such feature. The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). Git-rebase can automatically copy notes from one commit to another during a rebase, but you need to set notes.rewriteRef to do so (see git help config for details). The reason for this conservative default is that some notes may not be appropriate for automatic copying (e.g., a notes tree containing QA approval should probably be invalidated during a rebase, whereas one with commentary probably should). Thanks, I wasn't aware of this. Squashing the notes into the commit message during rebase would be a useful feature (at least for some type of notes), but that feature does not currently exist (and as far as I recall, this is the first it has been proposed). For some workflow - I post patches to the list, people reply with their acks, I could just add those to notes and later fold them into the existing commits before pushing the branch upstream. I guess it may be just a matter of changing git format-patch to include the notes. I can later reword he commits and drop the Notes: line. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro wrote: > > How about git commit --allow-empty, with > "belated ACK for Don't bother. It's not that important, and it's just distracting. It's not like this is vital information. If you pushed it out without the ack, it's out without the ack. Big deal. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Jeff King wrote: > On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > > The resulting notes are stored in a separate > > > revision-controlled branch > > > > Which branch(es) is/are that ? What are the semantics of that? [...] Nice feature. Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? -Marc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote: > On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: > >> > >> It is spelled: > >> > >> git notes add -m SHA1 > > > > Cool! > > Don't use them for anything global. > > Use them for local codeflow, but don't expect them to be distributed. > It's a separate "flow", and while it *can* be distributed, it's not > going to be for the kernel, for example. So no, don't start using this > to ack things, because the acks *will* get lost. How about git commit --allow-empty, with "belated ACK for Acked-by: <...> " as commit message? I mean, that ought to work and propagate sanely, but I'm really not sure if that's something in a good taste and should be allowed as a common practice... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: >> >> It is spelled: >> >> git notes add -m SHA1 > > Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate "flow", and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote: > Can a later commit be eventually be made to reference some set > of notes added so far, so they become part of the whole history > signed by the HEAD SHA1? hence pulled/pushed automatically as > well. Otherwise do you not end up with a forever growing separate > tree of notes that loses some of the properties of being behind > the head SHA1 (and perhaps less scalable in manageability)? > Also that way notes are separate only temporarily. Interesting idea. It would be tough to do with existing objects. There are really only two ways for a commit to reference objects: 1. Via a parent header. But we would not want to include the notes tree as a separate parent. The semantics are all wrong, and would make your commit look like a nonsense merge. 2. As an entry in a tree. But we do not enforce connectivity of commits referenced in trees, because that is the way that submodules are implemented. So I think we would have to add a new header that says "also, here are some notes for my history". That has two problems: 1. It's not backwards compatible. People with the new version of git will expect to have objects referenced by the new header, but older servers may not provide those objects (and vice versa). We can add a protocol extension to communicate this, but fundamentally you are going to lose the object connection any time it passes through a repo running an older git. 2. It's impure from the perspective of git's data model. Adding in the notes reference is not really a property of the commit. It's more like saying "Oh, these other things happened to _past_ commits, and I'm just now mentioning them". So you pick an arbitrary commit to attach it to. What are the semantics with relation to that commit's position in the history graph? If I have a commit that is identical but without the notes reference, it will have a different sha1. But is it the same commit? So it's a bit ugly. I think I'd rather build out the transfer infrastructure to pass the notes references around more gracefully without trying to shoehorn them into the commit graph. > As for automating the inclusion of notes in the flow, can that > be conditional on some pattern in the note, so that e.g. the > Acked-by's get included and folded in automatically, whereas > others do not, according to settings? Yeah. You can store arbitrary data in notes (e.g., one of the existing uses of notes is to record metadata on the patch emails that led to a commit). Right now you typically separate it out by data type into separate refs, and then you ask git log to show you particular ones (so we see refs/notes/commits with "--notes", but you can do "--notes=foo" to see refs/notes/foo, or even show multiple refs). For the fold-on-rebase idea, I'd think you would want something similar, like setting rebase.foldNotes to "foo" to say "refs/notes/foo contains pseudo-headers that should be folded in like a signed-off-by". -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > The resulting notes are stored in a separate revision-controlled branch > > Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs if you want to store logically distinct sets of notes. A notes ref's tree is just a tree whose entries are sha1s, and the file contents contain the notes themselves (the sha1s are broken down into subdirectories for performance, but "git notes" handles this behind the scenes). Technically you could check it out as a branch, edit, and commit, but "git checkout" is not happy to have a HEAD outside of refs/heads/, so you are stuck with plumbing like: $ git checkout `git rev-parse refs/notes/commits` $ edit edit edit $ git commit ... $ git update-ref refs/notes/commits HEAD It's probably not good for much beyond exploring how notes are implemented. See "git help notes" for more discussion. > Assume I commit something to branch "foo" > > Now I get that late Ack/Reviewed-by and want to associate that to that > commit in branch "foo". Does that go into "notes/foo" ? No. It would go into refs/notes/commits, or you could ask it to go to refs/notes/acks if you wanted to keep them separate from your default notes. It is indexed by commit object, not by branch (so if that branch later goes away, the notes are always still attached to the commit objects, assuming they got merged in). > Later when I send a pull request to my upstream maintainer for branch > "foo" does he get "notes/foo" automagically or do I have to request to > pull him that separately? No, he would have to pull your notes separately. Most of the discussion around sharing has been configuring the default refspec configuration to fetch notes. But in the kernel you guys use a lot of one-off pulls without configured remotes. I'm not sure what the right workflow would be. It might simply be to ask git to always pull particular notes commits at the same time (so you might push your notes to refs/notes/for-linus, and then git would automatically grab the notes when somebody pulls refs/heads/for-linus). > Either way is fine for me, though something which lets me "automate" > that would be appreciated. I can work around that easily as my pull > requests are generated via scripts, so I can add the secondary one for > the dependent "notes" branch if necessary. Though it would be nice to > avoid that. Avoiding that, i.e having a straight connection (maybe > configurable) between "foo" and "notes/foo" and the commits which have > not yet hit my upstream maintainer would make my life easier. I.e. I > just have to check "foo" for stuff which is not upstream yet instead > of checking both, but that might just be my laziness. > > Thoughts? That all makes sense. Putting extra work on the puller is not a good long-term solution. So while sending them an extra "also pull these notes" line, even if it ends up being a cut-and-pastable single-liner, is not great (even if it is the most flexible thing). Using a convention based on name-equivalence seems like a sensible compromise. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Jeff King wrote: > On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: > > > I agree that this is a common issue. Acked-by/Reviewed-by mails come > > in after the fact that the patch has been committed to an immutable > > (i.e no-rebase mode) branch or if the change in question already hit > > Linus tree. > > > > Still it would be nice to have a recording of that in the git tree > > itself. > > > > Something like: "git --attach SHA1 " would be appreciated! > > It is spelled: > > git notes add -m SHA1 Cool! > The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? Assume I commit something to branch "foo" Now I get that late Ack/Reviewed-by and want to associate that to that commit in branch "foo". Does that go into "notes/foo" ? If yes, good. (Any other sensible prefix is good as well). If no, where does it go to? Later when I send a pull request to my upstream maintainer for branch "foo" does he get "notes/foo" automagically or do I have to request to pull him that separately? Either way is fine for me, though something which lets me "automate" that would be appreciated. I can work around that easily as my pull requests are generated via scripts, so I can add the secondary one for the dependent "notes" branch if necessary. Though it would be nice to avoid that. Avoiding that, i.e having a straight connection (maybe configurable) between "foo" and "notes/foo" and the commits which have not yet hit my upstream maintainer would make my life easier. I.e. I just have to check "foo" for stuff which is not upstream yet instead of checking both, but that might just be my laziness. Thoughts? tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: > > It is spelled: > > > > git notes add -m SHA1 > > > > The resulting notes are stored in a separate revision-controlled branch > > and can be pushed and pulled like regular refs. Note, though, that the > > default refspecs do not yet include refs/notes, so you'd have to add > > them manually. The workflows around notes are not very mature yet, so if > > you start using them, feedback would be appreciated. > > What would be nice is that notes are pushed/pulled automatically with > standard git push/fetch/pull commands. Usually git walks the DAG > starting with the pulled commit or tag and following the parents. With > notes, the reference is reversed, the note pointing to the commit and > not the other way around. So handling this automatically in Git would > be really useful. Right, that's what I meant about the refspecs. You can configure git to push or pull them automatically, but it is not the default. Something like: git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' would be a start, but you'd also want to "git notes merge" upstream's changes into your local notes (you _could_ just fetch straight into refs/notes/, but if you are making your own notes locally, you have to resolve it somehow). Exactly how to make this smooth is one of the workflow considerations; there's been discussion, but most people aren't using the feature, so we don't have a lot of data. If you are asking whether we could "auto-follow" notes for commits that have been fetched like we do for tags, the answer is "not really". The notes tree is version-controlled as a whole, so you generally fetch the whole thing or not. And the remote does not advertise note information the same way we advertise peeled tag references, so a client does not know which notes are available for fetch. The intended strategy is to pull in the notes or not (though you can have multiple notes refs with different names, and fetch just a subset of them). > The other feature I'd like is that notes are automatically folded in > the log during git rebase (maybe similar to the squash option). If you > rebase, you lose all the notes (though this depends on the workflow, > it may not be needed with published branches). Git-rebase can automatically copy notes from one commit to another during a rebase, but you need to set notes.rewriteRef to do so (see "git help config" for details). The reason for this conservative default is that some notes may not be appropriate for automatic copying (e.g., a notes tree containing QA approval should probably be invalidated during a rebase, whereas one with commentary probably should). Squashing the notes into the commit message during rebase would be a useful feature (at least for some type of notes), but that feature does not currently exist (and as far as I recall, this is the first it has been proposed). Again, I think a lot of this comes down to the fact that not many people are really using notes for their daily workflow, so these itches are not coming up and getting scratched. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 23 October 2012 21:51, Jeff King wrote: > On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: > >> I agree that this is a common issue. Acked-by/Reviewed-by mails come >> in after the fact that the patch has been committed to an immutable >> (i.e no-rebase mode) branch or if the change in question already hit >> Linus tree. >> >> Still it would be nice to have a recording of that in the git tree >> itself. >> >> Something like: "git --attach SHA1 " would be appreciated! > > It is spelled: > > git notes add -m SHA1 > > The resulting notes are stored in a separate revision-controlled branch > and can be pushed and pulled like regular refs. Note, though, that the > default refspecs do not yet include refs/notes, so you'd have to add > them manually. The workflows around notes are not very mature yet, so if > you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: > I agree that this is a common issue. Acked-by/Reviewed-by mails come > in after the fact that the patch has been committed to an immutable > (i.e no-rebase mode) branch or if the change in question already hit > Linus tree. > > Still it would be nice to have a recording of that in the git tree > itself. > > Something like: "git --attach SHA1 " would be appreciated! It is spelled: git notes add -m SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Al Viro wrote: > On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote: > > > I fetched the series from your arch-tile branch and built it, and it works > > fine. It looks good from my inspection: > > > > Acked-by: Chris Metcalf > > Thanks; Acked-by applied, branch pushed and put into no-rebase mode. > > BTW, something like detached Acked-by objects might be a good idea - i.e. > commit-like git object with amendment to commit message of a given ancestor. > The situation when ACKs come only after the commit has been pushed is quite > common. Linus, what do you think about usefulness of such thing? Ability > to append ACKed-by/Tested-by of an earlier commit to a branch instead of > git commit --amend + possibly some cherry-picks + force-push, that is. I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: "git --attach SHA1 " would be appreciated! Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 03:22:36PM -0400, Chris Metcalf wrote:
> On 10/23/2012 2:41 PM, Al Viro wrote:
> > On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
> >> As you had suggested in an earlier email, I went ahead and eliminated the
> >> special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a
> >> tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it
> >> separately and you can include it in your tree if you like.
> > OK by me... Or just pull this arch-tile into a separate branch in your
> > tree, add commit on top of it and I'll pull that.
>
> Done in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
> viro-signal-tile
Argh... That's exactly the reason why I would like to get amending commits -
you've done that commit on top of the identical tree, but without your
Acked-by on the last commit. Result: merge conflict ;-/
Could you test the following on top of your patch? It gets rid of
regs use in sys_clone() *and* of the regs argument in copy_thread().
If that work (including SMP - note that it changes the path taken
by copy_thread() when called by fork_idle()), that should be all
we'll need in arch/tile for killing idle_regs() and killing the pt_regs
passing to do_fork()/copy_process()/copy_thread().
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 6e7fb4e..1c20029 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -158,7 +158,7 @@ static void save_arch_state(struct thread_struct *t);
int copy_thread(unsigned long clone_flags, unsigned long sp,
unsigned long arg,
- struct task_struct *p, struct pt_regs *regs)
+ struct task_struct *p, struct pt_regs *unused)
{
struct pt_regs *childregs = task_pt_regs(p);
unsigned long ksp;
@@ -184,7 +184,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
/* Record the pid of the task that created this one. */
p->thread.creator_pid = current->pid;
- if (unlikely(!regs)) {
+ if (unlikely(p->flags & PF_KTHREAD)) {
/* kernel thread */
memset(childregs, 0, sizeof(struct pt_regs));
memset(_regs[2], 0,
@@ -208,25 +208,26 @@ int copy_thread(unsigned long clone_flags, unsigned long
sp,
*/
task_thread_info(p)->step_state = NULL;
- /* Save user stack top pointer so we can ID the stack vm area later. */
- p->thread.usp0 = sp;
-
/*
* Copy the registers onto the kernel stack so the
* return-from-interrupt code will reload it into registers.
*/
- *childregs = *regs;
+ *childregs = *current_pt_regs();
childregs->regs[0] = 0; /* return value is zero */
- childregs->sp = sp; /* override with new user stack pointer */
- memcpy(callee_regs, >regs[CALLEE_SAVED_FIRST_REG],
+ if (sp)
+ childregs->sp = sp; /* override with new user stack pointer */
+ memcpy(callee_regs, >regs[CALLEE_SAVED_FIRST_REG],
CALLEE_SAVED_REGS_COUNT * sizeof(unsigned long));
+ /* Save user stack top pointer so we can ID the stack vm area later. */
+ p->thread.usp0 = childregs->sp;
+
/*
* If CLONE_SETTLS is set, set "tp" in the new task to "r4",
* which is passed in as arg #5 to sys_clone().
*/
if (clone_flags & CLONE_SETTLS)
- childregs->tp = regs->regs[4];
+ childregs->tp = childregs->regs[4];
#if CHIP_HAS_TILE_DMA()
@@ -587,10 +588,7 @@ int do_work_pending(struct pt_regs *regs, u32
thread_info_flags)
SYSCALL_DEFINE4(clone, unsigned long, clone_flags, unsigned long, newsp,
void __user *, parent_tidptr, void __user *, child_tidptr)
{
- struct pt_regs *regs = current_pt_regs();
- if (!newsp)
- newsp = regs->sp;
- return do_fork(clone_flags, newsp, regs, 0,
+ return do_fork(clone_flags, newsp, current_pt_regs(), 0,
parent_tidptr, child_tidptr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/23/2012 2:41 PM, Al Viro wrote: > On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote: >> As you had suggested in an earlier email, I went ahead and eliminated the >> special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a >> tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it >> separately and you can include it in your tree if you like. > OK by me... Or just pull this arch-tile into a separate branch in your > tree, add commit on top of it and I'll pull that. Done in git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git viro-signal-tile Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
> I fetched the series from your arch-tile branch and built it, and it works
> fine. It looks good from my inspection:
>
> Acked-by: Chris Metcalf
Thanks; Acked-by applied, branch pushed and put into no-rebase mode.
BTW, something like detached Acked-by objects might be a good idea - i.e.
commit-like git object with amendment to commit message of a given ancestor.
The situation when ACKs come only after the commit has been pushed is quite
common. Linus, what do you think about usefulness of such thing? Ability
to append ACKed-by/Tested-by of an earlier commit to a branch instead of
git commit --amend + possibly some cherry-picks + force-push, that is.
> As you had suggested in an earlier email, I went ahead and eliminated the
> special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a
> tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it
> separately and you can include it in your tree if you like.
OK by me... Or just pull this arch-tile into a separate branch in your
tree, add commit on top of it and I'll pull that.
AFAICS, the current state is:
avr32 untested
blackfinuntested
crisuntested
frv untested, maintainer going to test
h8300 untested
hexagon maintainer hunting the breakage down
m32runtested
microblaze maintainer hunting the breakage down
mn10300 untested
powerpc should work, needs testing and ACK
s390should work, needs testing and ACK
score untested
sh untested, maintainers planned reviewing and testing
xtensa maintainers writing that one
everything else done
so we are more than halfway through on that one... FWIW, here's what I want
to do next in that area:
* consider taking the "if (!usp) usp = " logics from
clone(2) to copy_thread(). Note that it allows to have fork and vfork
(where implemented) simply pass 0. Per-architecture change, independent for
different architectures.
* do generic sys_fork() and sys_vfork() variants, have the
architectures that want to use them do so.
* consider making regs argument of copy_thread() unused. The thing
is, we can tell whether we have userland process or kernel thread being
spawned just by looking at p->flags & PF_KTHREAD. And on the "userland
process" side of things, it's often just as cheap (or cheaper) to use
current_pt_regs() instead of using the argument, especially on architectures
where 6-argument functions get the last args passed on stack. Again,
independent for different architectures.
* kill pt_regs argument of do_execve/compat_do_execve/do_execve_common/
search_binary_handler/->load_binary. Depends on having everything switched
to generic kernel_execve/sys_execve; local to fs/* and on the last step
a couple of binfmt instances in arch (alpha ecoff, ia32 aout)
* kill ifdefs by CONFIG_GENERIC_KERNEL_{THREAD,EXECVE} once everything
has those always true.
* kill pt_regs argument of copy_thread() if all architectures can live
with that. Same for copy_process() and do_fork(). A flagday change, obviously.
* kill idle_regs() - it'll be unused by that point.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/20/2012 1:16 PM, Al Viro wrote: > On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: >> On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: >>> First, the compat_sys_execve() declaration provided in >>> arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only >>> deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). >>> >>> However, then arch/tile/kernel/compat.c failed to build, because >>> is included before , and >>> provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at >>> all for compat_sys_execve. For most platforms this is no big deal, but on >>> tile we use the __SYSCALL #define to provide the actual syscall table, and >>> for that to work we need a declaration in scope for each syscall at the >>> time we create the table. >>> >>> The best solution seems likely to be to copy the other place in >>> where we need to do something configurable (that is, >>> CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE >>> to be a Kconfig option. >> Frankly, I hope to get rid of the damn thing completely. By now we have >> at least some variant of execve conversions for just about everything; >> I certainly hope that by the beginning of the next cycle we'll have it >> defined on everything. And put unconditional declarations in syscalls.h >> and compat.h >> >> Actually, we can make the declaration in linux/compat.h unconditional >> right now. The only obstacle is the situation on arm64; there the mainline >> has C variant of that sucker (with struct pt_regs * in arguments) in >> arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull >> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve >> and then do the following in one patch: >> introduce current_pt_regs() on tile (from your commit) >> get rid of pt_regs * argument in tile compat_sys_execve(), making it >> use current_pt_regs(); kill its wrapper >> kill the declarations of compat_sys_execve()/_compat_sys_execve() >> in tile asm/compat.h >> make declaration in linux/compat.h unconditional >> Note that this does *not* depend on kernel_thread/kernel_execve patch - >> kernel_execve() is never going to hit compat_sys_execve(), since it's >> only called from kernel threads and those are not going to be 32bit. >> After that we can do kernel_thread/kernel_execve commit and >> sys_execve() conversion with nothing outside of arch/tile touched. > Another possible variant is for you to merge that branch from arm64 tree > (only 3 commits it it) and then do as described above. I.e. on top of > that apply the thing below, followed by your kernel_thread()/kernel_execve() > patch (sans current_pt_regs() part), followed by obviously massaged parts > of generic sys_execve for tile patch I've sent. FWIW, I've put the > whole series (based at the end of arm64 branch) in signal.git#arch-tile. > Comments? I fetched the series from your arch-tile branch and built it, and it works fine. It looks good from my inspection: Acked-by: Chris Metcalf As you had suggested in an earlier email, I went ahead and eliminated the special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it separately and you can include it in your tree if you like. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/20/2012 1:16 PM, Al Viro wrote: On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because linux/compat.h is included before asm/unistd.h, and asm/unistd.h provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in linux/compat.h where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Frankly, I hope to get rid of the damn thing completely. By now we have at least some variant of execve conversions for just about everything; I certainly hope that by the beginning of the next cycle we'll have it defined on everything. And put unconditional declarations in syscalls.h and compat.h Actually, we can make the declaration in linux/compat.h unconditional right now. The only obstacle is the situation on arm64; there the mainline has C variant of that sucker (with struct pt_regs * in arguments) in arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve and then do the following in one patch: introduce current_pt_regs() on tile (from your commit) get rid of pt_regs * argument in tile compat_sys_execve(), making it use current_pt_regs(); kill its wrapper kill the declarations of compat_sys_execve()/_compat_sys_execve() in tile asm/compat.h make declaration in linux/compat.h unconditional Note that this does *not* depend on kernel_thread/kernel_execve patch - kernel_execve() is never going to hit compat_sys_execve(), since it's only called from kernel threads and those are not going to be 32bit. After that we can do kernel_thread/kernel_execve commit and sys_execve() conversion with nothing outside of arch/tile touched. Another possible variant is for you to merge that branch from arm64 tree (only 3 commits it it) and then do as described above. I.e. on top of that apply the thing below, followed by your kernel_thread()/kernel_execve() patch (sans current_pt_regs() part), followed by obviously massaged parts of generic sys_execve for tile patch I've sent. FWIW, I've put the whole series (based at the end of arm64 branch) in signal.git#arch-tile. Comments? I fetched the series from your arch-tile branch and built it, and it works fine. It looks good from my inspection: Acked-by: Chris Metcalf cmetc...@tilera.com As you had suggested in an earlier email, I went ahead and eliminated the special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it separately and you can include it in your tree if you like. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
I fetched the series from your arch-tile branch and built it, and it works
fine. It looks good from my inspection:
Acked-by: Chris Metcalf cmetc...@tilera.com
Thanks; Acked-by applied, branch pushed and put into no-rebase mode.
BTW, something like detached Acked-by objects might be a good idea - i.e.
commit-like git object with amendment to commit message of a given ancestor.
The situation when ACKs come only after the commit has been pushed is quite
common. Linus, what do you think about usefulness of such thing? Ability
to append ACKed-by/Tested-by of an earlier commit to a branch instead of
git commit --amend + possibly some cherry-picks + force-push, that is.
As you had suggested in an earlier email, I went ahead and eliminated the
special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a
tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it
separately and you can include it in your tree if you like.
OK by me... Or just pull this arch-tile into a separate branch in your
tree, add commit on top of it and I'll pull that.
AFAICS, the current state is:
avr32 untested
blackfinuntested
crisuntested
frv untested, maintainer going to test
h8300 untested
hexagon maintainer hunting the breakage down
m32runtested
microblaze maintainer hunting the breakage down
mn10300 untested
powerpc should work, needs testing and ACK
s390should work, needs testing and ACK
score untested
sh untested, maintainers planned reviewing and testing
xtensa maintainers writing that one
everything else done
so we are more than halfway through on that one... FWIW, here's what I want
to do next in that area:
* consider taking the if (!usp) usp = parent's usp logics from
clone(2) to copy_thread(). Note that it allows to have fork and vfork
(where implemented) simply pass 0. Per-architecture change, independent for
different architectures.
* do generic sys_fork() and sys_vfork() variants, have the
architectures that want to use them do so.
* consider making regs argument of copy_thread() unused. The thing
is, we can tell whether we have userland process or kernel thread being
spawned just by looking at p-flags PF_KTHREAD. And on the userland
process side of things, it's often just as cheap (or cheaper) to use
current_pt_regs() instead of using the argument, especially on architectures
where 6-argument functions get the last args passed on stack. Again,
independent for different architectures.
* kill pt_regs argument of do_execve/compat_do_execve/do_execve_common/
search_binary_handler/-load_binary. Depends on having everything switched
to generic kernel_execve/sys_execve; local to fs/* and on the last step
a couple of binfmt instances in arch (alpha ecoff, ia32 aout)
* kill ifdefs by CONFIG_GENERIC_KERNEL_{THREAD,EXECVE} once everything
has those always true.
* kill pt_regs argument of copy_thread() if all architectures can live
with that. Same for copy_process() and do_fork(). A flagday change, obviously.
* kill idle_regs() - it'll be unused by that point.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/23/2012 2:41 PM, Al Viro wrote: On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote: As you had suggested in an earlier email, I went ahead and eliminated the special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it separately and you can include it in your tree if you like. OK by me... Or just pull this arch-tile into a separate branch in your tree, add commit on top of it and I'll pull that. Done in git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git viro-signal-tile Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 03:22:36PM -0400, Chris Metcalf wrote:
On 10/23/2012 2:41 PM, Al Viro wrote:
On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
As you had suggested in an earlier email, I went ahead and eliminated the
special pt_regs handling for sigaltstack, rt_sigreturn, and clone. (Also a
tilepro-specific syscall that was also using PTREG_SYSCALL.) I'll send it
separately and you can include it in your tree if you like.
OK by me... Or just pull this arch-tile into a separate branch in your
tree, add commit on top of it and I'll pull that.
Done in
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
viro-signal-tile
Argh... That's exactly the reason why I would like to get amending commits -
you've done that commit on top of the identical tree, but without your
Acked-by on the last commit. Result: merge conflict ;-/
Could you test the following on top of your patch? It gets rid of
regs use in sys_clone() *and* of the regs argument in copy_thread().
If that work (including SMP - note that it changes the path taken
by copy_thread() when called by fork_idle()), that should be all
we'll need in arch/tile for killing idle_regs() and killing the pt_regs
passing to do_fork()/copy_process()/copy_thread().
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 6e7fb4e..1c20029 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -158,7 +158,7 @@ static void save_arch_state(struct thread_struct *t);
int copy_thread(unsigned long clone_flags, unsigned long sp,
unsigned long arg,
- struct task_struct *p, struct pt_regs *regs)
+ struct task_struct *p, struct pt_regs *unused)
{
struct pt_regs *childregs = task_pt_regs(p);
unsigned long ksp;
@@ -184,7 +184,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
/* Record the pid of the task that created this one. */
p-thread.creator_pid = current-pid;
- if (unlikely(!regs)) {
+ if (unlikely(p-flags PF_KTHREAD)) {
/* kernel thread */
memset(childregs, 0, sizeof(struct pt_regs));
memset(callee_regs[2], 0,
@@ -208,25 +208,26 @@ int copy_thread(unsigned long clone_flags, unsigned long
sp,
*/
task_thread_info(p)-step_state = NULL;
- /* Save user stack top pointer so we can ID the stack vm area later. */
- p-thread.usp0 = sp;
-
/*
* Copy the registers onto the kernel stack so the
* return-from-interrupt code will reload it into registers.
*/
- *childregs = *regs;
+ *childregs = *current_pt_regs();
childregs-regs[0] = 0; /* return value is zero */
- childregs-sp = sp; /* override with new user stack pointer */
- memcpy(callee_regs, regs-regs[CALLEE_SAVED_FIRST_REG],
+ if (sp)
+ childregs-sp = sp; /* override with new user stack pointer */
+ memcpy(callee_regs, childregs-regs[CALLEE_SAVED_FIRST_REG],
CALLEE_SAVED_REGS_COUNT * sizeof(unsigned long));
+ /* Save user stack top pointer so we can ID the stack vm area later. */
+ p-thread.usp0 = childregs-sp;
+
/*
* If CLONE_SETTLS is set, set tp in the new task to r4,
* which is passed in as arg #5 to sys_clone().
*/
if (clone_flags CLONE_SETTLS)
- childregs-tp = regs-regs[4];
+ childregs-tp = childregs-regs[4];
#if CHIP_HAS_TILE_DMA()
@@ -587,10 +588,7 @@ int do_work_pending(struct pt_regs *regs, u32
thread_info_flags)
SYSCALL_DEFINE4(clone, unsigned long, clone_flags, unsigned long, newsp,
void __user *, parent_tidptr, void __user *, child_tidptr)
{
- struct pt_regs *regs = current_pt_regs();
- if (!newsp)
- newsp = regs-sp;
- return do_fork(clone_flags, newsp, regs, 0,
+ return do_fork(clone_flags, newsp, current_pt_regs(), 0,
parent_tidptr, child_tidptr);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Al Viro wrote: On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote: I fetched the series from your arch-tile branch and built it, and it works fine. It looks good from my inspection: Acked-by: Chris Metcalf cmetc...@tilera.com Thanks; Acked-by applied, branch pushed and put into no-rebase mode. BTW, something like detached Acked-by objects might be a good idea - i.e. commit-like git object with amendment to commit message of a given ancestor. The situation when ACKs come only after the commit has been pushed is quite common. Linus, what do you think about usefulness of such thing? Ability to append ACKed-by/Tested-by of an earlier commit to a branch instead of git commit --amend + possibly some cherry-picks + force-push, that is. I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. -Peff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 23 October 2012 21:51, Jeff King p...@peff.net wrote: On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet include refs/notes, so you'd have to add them manually. The workflows around notes are not very mature yet, so if you start using them, feedback would be appreciated. What would be nice is that notes are pushed/pulled automatically with standard git push/fetch/pull commands. Usually git walks the DAG starting with the pulled commit or tag and following the parents. With notes, the reference is reversed, the note pointing to the commit and not the other way around. So handling this automatically in Git would be really useful. Right, that's what I meant about the refspecs. You can configure git to push or pull them automatically, but it is not the default. Something like: git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' would be a start, but you'd also want to git notes merge upstream's changes into your local notes (you _could_ just fetch straight into refs/notes/, but if you are making your own notes locally, you have to resolve it somehow). Exactly how to make this smooth is one of the workflow considerations; there's been discussion, but most people aren't using the feature, so we don't have a lot of data. If you are asking whether we could auto-follow notes for commits that have been fetched like we do for tags, the answer is not really. The notes tree is version-controlled as a whole, so you generally fetch the whole thing or not. And the remote does not advertise note information the same way we advertise peeled tag references, so a client does not know which notes are available for fetch. The intended strategy is to pull in the notes or not (though you can have multiple notes refs with different names, and fetch just a subset of them). The other feature I'd like is that notes are automatically folded in the log during git rebase (maybe similar to the squash option). If you rebase, you lose all the notes (though this depends on the workflow, it may not be needed with published branches). Git-rebase can automatically copy notes from one commit to another during a rebase, but you need to set notes.rewriteRef to do so (see git help config for details). The reason for this conservative default is that some notes may not be appropriate for automatic copying (e.g., a notes tree containing QA approval should probably be invalidated during a rebase, whereas one with commentary probably should). Squashing the notes into the commit message during rebase would be a useful feature (at least for some type of notes), but that feature does not currently exist (and as far as I recall, this is the first it has been proposed). Again, I think a lot of this comes down to the fact that not many people are really using notes for their daily workflow, so these itches are not coming up and getting scratched. -Peff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, 23 Oct 2012, Jeff King wrote: On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still it would be nice to have a recording of that in the git tree itself. Something like: git --attach SHA1 comment would be appreciated! It is spelled: git notes add -m comment SHA1 Cool! The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? Assume I commit something to branch foo Now I get that late Ack/Reviewed-by and want to associate that to that commit in branch foo. Does that go into notes/foo ? If yes, good. (Any other sensible prefix is good as well). If no, where does it go to? Later when I send a pull request to my upstream maintainer for branch foo does he get notes/foo automagically or do I have to request to pull him that separately? Either way is fine for me, though something which lets me automate that would be appreciated. I can work around that easily as my pull requests are generated via scripts, so I can add the secondary one for the dependent notes branch if necessary. Though it would be nice to avoid that. Avoiding that, i.e having a straight connection (maybe configurable) between foo and notes/foo and the commits which have not yet hit my upstream maintainer would make my life easier. I.e. I just have to check foo for stuff which is not upstream yet instead of checking both, but that might just be my laziness. Thoughts? tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs if you want to store logically distinct sets of notes. A notes ref's tree is just a tree whose entries are sha1s, and the file contents contain the notes themselves (the sha1s are broken down into subdirectories for performance, but git notes handles this behind the scenes). Technically you could check it out as a branch, edit, and commit, but git checkout is not happy to have a HEAD outside of refs/heads/, so you are stuck with plumbing like: $ git checkout `git rev-parse refs/notes/commits` $ edit edit edit $ git commit ... $ git update-ref refs/notes/commits HEAD It's probably not good for much beyond exploring how notes are implemented. See git help notes for more discussion. Assume I commit something to branch foo Now I get that late Ack/Reviewed-by and want to associate that to that commit in branch foo. Does that go into notes/foo ? No. It would go into refs/notes/commits, or you could ask it to go to refs/notes/acks if you wanted to keep them separate from your default notes. It is indexed by commit object, not by branch (so if that branch later goes away, the notes are always still attached to the commit objects, assuming they got merged in). Later when I send a pull request to my upstream maintainer for branch foo does he get notes/foo automagically or do I have to request to pull him that separately? No, he would have to pull your notes separately. Most of the discussion around sharing has been configuring the default refspec configuration to fetch notes. But in the kernel you guys use a lot of one-off pulls without configured remotes. I'm not sure what the right workflow would be. It might simply be to ask git to always pull particular notes commits at the same time (so you might push your notes to refs/notes/for-linus, and then git would automatically grab the notes when somebody pulls refs/heads/for-linus). Either way is fine for me, though something which lets me automate that would be appreciated. I can work around that easily as my pull requests are generated via scripts, so I can add the secondary one for the dependent notes branch if necessary. Though it would be nice to avoid that. Avoiding that, i.e having a straight connection (maybe configurable) between foo and notes/foo and the commits which have not yet hit my upstream maintainer would make my life easier. I.e. I just have to check foo for stuff which is not upstream yet instead of checking both, but that might just be my laziness. Thoughts? That all makes sense. Putting extra work on the puller is not a good long-term solution. So while sending them an extra also pull these notes line, even if it ends up being a cut-and-pastable single-liner, is not great (even if it is the most flexible thing). Using a convention based on name-equivalence seems like a sensible compromise. -Peff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote: Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. Interesting idea. It would be tough to do with existing objects. There are really only two ways for a commit to reference objects: 1. Via a parent header. But we would not want to include the notes tree as a separate parent. The semantics are all wrong, and would make your commit look like a nonsense merge. 2. As an entry in a tree. But we do not enforce connectivity of commits referenced in trees, because that is the way that submodules are implemented. So I think we would have to add a new header that says also, here are some notes for my history. That has two problems: 1. It's not backwards compatible. People with the new version of git will expect to have objects referenced by the new header, but older servers may not provide those objects (and vice versa). We can add a protocol extension to communicate this, but fundamentally you are going to lose the object connection any time it passes through a repo running an older git. 2. It's impure from the perspective of git's data model. Adding in the notes reference is not really a property of the commit. It's more like saying Oh, these other things happened to _past_ commits, and I'm just now mentioning them. So you pick an arbitrary commit to attach it to. What are the semantics with relation to that commit's position in the history graph? If I have a commit that is identical but without the notes reference, it will have a different sha1. But is it the same commit? So it's a bit ugly. I think I'd rather build out the transfer infrastructure to pass the notes references around more gracefully without trying to shoehorn them into the commit graph. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? Yeah. You can store arbitrary data in notes (e.g., one of the existing uses of notes is to record metadata on the patch emails that led to a commit). Right now you typically separate it out by data type into separate refs, and then you ask git log to show you particular ones (so we see refs/notes/commits with --notes, but you can do --notes=foo to see refs/notes/foo, or even show multiple refs). For the fold-on-rebase idea, I'd think you would want something similar, like setting rebase.foldNotes to foo to say refs/notes/foo contains pseudo-headers that should be folded in like a signed-off-by. -Peff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote: On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. How about git commit --allow-empty, with belated ACK for commit Acked-by: ... as commit message? I mean, that ought to work and propagate sanely, but I'm really not sure if that's something in a good taste and should be allowed as a common practice... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Jeff King wrote: On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? [...] Nice feature. Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? -Marc -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro v...@zeniv.linux.org.uk wrote: How about git commit --allow-empty, with belated ACK for commit Don't bother. It's not that important, and it's just distracting. It's not like this is vital information. If you pushed it out without the ack, it's out without the ack. Big deal. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Hi Al, Sorry, couldn't reply earlier. On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: > On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: > > First, the compat_sys_execve() declaration provided in > > arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only > > deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). > > > > However, then arch/tile/kernel/compat.c failed to build, because > > is included before , and > > provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at > > all for compat_sys_execve. For most platforms this is no big deal, but on > > tile we use the __SYSCALL #define to provide the actual syscall table, and > > for that to work we need a declaration in scope for each syscall at the > > time we create the table. > > > > The best solution seems likely to be to copy the other place in > > where we need to do something configurable (that is, > > CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE > > to be a Kconfig option. > > Frankly, I hope to get rid of the damn thing completely. By now we have > at least some variant of execve conversions for just about everything; > I certainly hope that by the beginning of the next cycle we'll have it > defined on everything. And put unconditional declarations in syscalls.h > and compat.h > > Actually, we can make the declaration in linux/compat.h unconditional > right now. The only obstacle is the situation on arm64; there the mainline > has C variant of that sucker (with struct pt_regs * in arguments) in > arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve > and then do the following in one patch: > introduce current_pt_regs() on tile (from your commit) > get rid of pt_regs * argument in tile compat_sys_execve(), making it > use current_pt_regs(); kill its wrapper > kill the declarations of compat_sys_execve()/_compat_sys_execve() > in tile asm/compat.h > make declaration in linux/compat.h unconditional > Note that this does *not* depend on kernel_thread/kernel_execve patch - > kernel_execve() is never going to hit compat_sys_execve(), since it's > only called from kernel threads and those are not going to be 32bit. > After that we can do kernel_thread/kernel_execve commit and > sys_execve() conversion with nothing outside of arch/tile touched. > > Comments? If Catalin feels that arm64 series needs more testing, we could > reorder it a bit - all we really need there is getting rid of pt_regs argument > in compat_sys_execve() and just as on tile, that isn't tied into kernel_execve > and kernel_thread issues. I don't mind merging it earlier (if Linus is ok to take it after the merging window). It works fine in my tests. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Hi Al, Sorry, couldn't reply earlier. On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because linux/compat.h is included before asm/unistd.h, and asm/unistd.h provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in linux/compat.h where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Frankly, I hope to get rid of the damn thing completely. By now we have at least some variant of execve conversions for just about everything; I certainly hope that by the beginning of the next cycle we'll have it defined on everything. And put unconditional declarations in syscalls.h and compat.h Actually, we can make the declaration in linux/compat.h unconditional right now. The only obstacle is the situation on arm64; there the mainline has C variant of that sucker (with struct pt_regs * in arguments) in arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve and then do the following in one patch: introduce current_pt_regs() on tile (from your commit) get rid of pt_regs * argument in tile compat_sys_execve(), making it use current_pt_regs(); kill its wrapper kill the declarations of compat_sys_execve()/_compat_sys_execve() in tile asm/compat.h make declaration in linux/compat.h unconditional Note that this does *not* depend on kernel_thread/kernel_execve patch - kernel_execve() is never going to hit compat_sys_execve(), since it's only called from kernel threads and those are not going to be 32bit. After that we can do kernel_thread/kernel_execve commit and sys_execve() conversion with nothing outside of arch/tile touched. Comments? If Catalin feels that arm64 series needs more testing, we could reorder it a bit - all we really need there is getting rid of pt_regs argument in compat_sys_execve() and just as on tile, that isn't tied into kernel_execve and kernel_thread issues. I don't mind merging it earlier (if Linus is ok to take it after the merging window). It works fine in my tests. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: > On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: > > First, the compat_sys_execve() declaration provided in > > arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only > > deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). > > > > However, then arch/tile/kernel/compat.c failed to build, because > > is included before , and > > provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at > > all for compat_sys_execve. For most platforms this is no big deal, but on > > tile we use the __SYSCALL #define to provide the actual syscall table, and > > for that to work we need a declaration in scope for each syscall at the > > time we create the table. > > > > The best solution seems likely to be to copy the other place in > > where we need to do something configurable (that is, > > CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE > > to be a Kconfig option. > > Frankly, I hope to get rid of the damn thing completely. By now we have > at least some variant of execve conversions for just about everything; > I certainly hope that by the beginning of the next cycle we'll have it > defined on everything. And put unconditional declarations in syscalls.h > and compat.h > > Actually, we can make the declaration in linux/compat.h unconditional > right now. The only obstacle is the situation on arm64; there the mainline > has C variant of that sucker (with struct pt_regs * in arguments) in > arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve > and then do the following in one patch: > introduce current_pt_regs() on tile (from your commit) > get rid of pt_regs * argument in tile compat_sys_execve(), making it > use current_pt_regs(); kill its wrapper > kill the declarations of compat_sys_execve()/_compat_sys_execve() > in tile asm/compat.h > make declaration in linux/compat.h unconditional > Note that this does *not* depend on kernel_thread/kernel_execve patch - > kernel_execve() is never going to hit compat_sys_execve(), since it's > only called from kernel threads and those are not going to be 32bit. > After that we can do kernel_thread/kernel_execve commit and > sys_execve() conversion with nothing outside of arch/tile touched. Another possible variant is for you to merge that branch from arm64 tree (only 3 commits it it) and then do as described above. I.e. on top of that apply the thing below, followed by your kernel_thread()/kernel_execve() patch (sans current_pt_regs() part), followed by obviously massaged parts of generic sys_execve for tile patch I've sent. FWIW, I've put the whole series (based at the end of arm64 branch) in signal.git#arch-tile. Comments? Drop struct pt_regs * argument in compat_sys_execve() Signed-off-by: Al Viro --- diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h index 3063e6f..3bcf1b9 100644 --- a/arch/tile/include/asm/compat.h +++ b/arch/tile/include/asm/compat.h @@ -275,9 +275,6 @@ extern int compat_setup_rt_frame(int sig, struct k_sigaction *ka, struct compat_sigaction; struct compat_siginfo; struct compat_sigaltstack; -long compat_sys_execve(const char __user *path, - compat_uptr_t __user *argv, - compat_uptr_t __user *envp, struct pt_regs *); long compat_sys_rt_sigaction(int sig, struct compat_sigaction __user *act, struct compat_sigaction __user *oact, size_t sigsetsize); @@ -304,9 +301,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid, struct compat_timespec __user *interval); /* These are the intvec_64.S trampolines. */ -long _compat_sys_execve(const char __user *path, - const compat_uptr_t __user *argv, - const compat_uptr_t __user *envp); long _compat_sys_sigaltstack(const struct compat_sigaltstack __user *uss_ptr, struct compat_sigaltstack __user *uoss_ptr); long _compat_sys_rt_sigreturn(void); diff --git a/arch/tile/include/asm/processor.h b/arch/tile/include/asm/processor.h index 8c4dd9f..9a83e53 100644 --- a/arch/tile/include/asm/processor.h +++ b/arch/tile/include/asm/processor.h @@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p); #define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA) #define task_pt_regs(task) \ ((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1) +#define current_pt_regs() \ + ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \ + (KSTK_PTREGS_GAP - 1)) - 1) #define task_sp(task) (task_pt_regs(task)->sp) #define task_pc(task) (task_pt_regs(task)->pc) /* Aliases for pc and sp (used in fs/proc/array.c) */ diff --git
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: > First, the compat_sys_execve() declaration provided in > arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only > deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). > > However, then arch/tile/kernel/compat.c failed to build, because > is included before , and > provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at > all for compat_sys_execve. For most platforms this is no big deal, but on > tile we use the __SYSCALL #define to provide the actual syscall table, and > for that to work we need a declaration in scope for each syscall at the > time we create the table. > > The best solution seems likely to be to copy the other place in > where we need to do something configurable (that is, > CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE > to be a Kconfig option. Frankly, I hope to get rid of the damn thing completely. By now we have at least some variant of execve conversions for just about everything; I certainly hope that by the beginning of the next cycle we'll have it defined on everything. And put unconditional declarations in syscalls.h and compat.h Actually, we can make the declaration in linux/compat.h unconditional right now. The only obstacle is the situation on arm64; there the mainline has C variant of that sucker (with struct pt_regs * in arguments) in arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve and then do the following in one patch: introduce current_pt_regs() on tile (from your commit) get rid of pt_regs * argument in tile compat_sys_execve(), making it use current_pt_regs(); kill its wrapper kill the declarations of compat_sys_execve()/_compat_sys_execve() in tile asm/compat.h make declaration in linux/compat.h unconditional Note that this does *not* depend on kernel_thread/kernel_execve patch - kernel_execve() is never going to hit compat_sys_execve(), since it's only called from kernel threads and those are not going to be 32bit. After that we can do kernel_thread/kernel_execve commit and sys_execve() conversion with nothing outside of arch/tile touched. Comments? If Catalin feels that arm64 series needs more testing, we could reorder it a bit - all we really need there is getting rid of pt_regs argument in compat_sys_execve() and just as on tile, that isn't tied into kernel_execve and kernel_thread issues. FWIW, it's my fault - I assumed that it would be easier to sort the compat side of things out on per-arch basis. Should've consolidated *that* first (unlike sys_execve(), that doesn't have any prereqs), followed by the infrastructure for kernel_thread/kernel_execve/sys_execve series, followed by the per-architecture conversions. Too late for that now, of course, and fortunately the mess is fairly small. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/19/2012 5:35 PM, Al Viro wrote: > On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote: >> Also provide an optimized current_pt_regs() while we're at it. > Applied. BTW, are you sure you want to record parent's pid and not tid? By recording ->pid rather than ->pgid, we ARE recording the tid :-) > Anyway, here's a followup on top of this one (again, completely untested) - > switching to generic sys_execve(). Does that look right for you? It does look right, but it doesn't quite work as-is. But after some tweaks it did yield a kernel that booted up userspace correctly, so I think it's basically good. First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because is included before , and provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Another possibility is to pre-include in the tile compat.c before including . This requires adding some #undefs for _SC_3264, etc., in , since we'll need to include the header twice, once to satisfy , and then again to actually provide the body of the syscall array. If we go down this path, I suspect we should just make include , so it gets the __ARCH_WANT_SYS_EXECVE define provided. Otherwise we have the ugly requirement of requiring the C file to include specific headers in specific order for it to work right. > While > we are at it, I wonder if any of PTREGS_SYSCALL wrappers are needed - > current_pt_regs() would do just as well, won't it? It's a couple of > arithmetical operations vs. arith operation + branch; even if the latter > is somehow cheaper, can't be cheaper by much. And I'd expect it to be > costlier, actually, what with the icache effects. Yes, that's a good idea. I'll look at it when I'm back in the office next week. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On 10/19/2012 5:35 PM, Al Viro wrote: On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote: Also provide an optimized current_pt_regs() while we're at it. Applied. BTW, are you sure you want to record parent's pid and not tid? By recording -pid rather than -pgid, we ARE recording the tid :-) Anyway, here's a followup on top of this one (again, completely untested) - switching to generic sys_execve(). Does that look right for you? It does look right, but it doesn't quite work as-is. But after some tweaks it did yield a kernel that booted up userspace correctly, so I think it's basically good. First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because linux/compat.h is included before asm/unistd.h, and asm/unistd.h provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in linux/compat.h where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Another possibility is to pre-include asm/unistd.h in the tile compat.c before including linux/compat.h. This requires adding some #undefs for _SC_3264, etc., in asm-generic/unistd.h, since we'll need to include the header twice, once to satisfy linux/compat.h, and then again to actually provide the body of the syscall array. If we go down this path, I suspect we should just make linux/compat.h include asm/unistd.h, so it gets the __ARCH_WANT_SYS_EXECVE define provided. Otherwise we have the ugly requirement of requiring the C file to include specific headers in specific order for it to work right. While we are at it, I wonder if any of PTREGS_SYSCALL wrappers are needed - current_pt_regs() would do just as well, won't it? It's a couple of arithmetical operations vs. arith operation + branch; even if the latter is somehow cheaper, can't be cheaper by much. And I'd expect it to be costlier, actually, what with the icache effects. Yes, that's a good idea. I'll look at it when I'm back in the office next week. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because linux/compat.h is included before asm/unistd.h, and asm/unistd.h provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in linux/compat.h where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Frankly, I hope to get rid of the damn thing completely. By now we have at least some variant of execve conversions for just about everything; I certainly hope that by the beginning of the next cycle we'll have it defined on everything. And put unconditional declarations in syscalls.h and compat.h Actually, we can make the declaration in linux/compat.h unconditional right now. The only obstacle is the situation on arm64; there the mainline has C variant of that sucker (with struct pt_regs * in arguments) in arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve and then do the following in one patch: introduce current_pt_regs() on tile (from your commit) get rid of pt_regs * argument in tile compat_sys_execve(), making it use current_pt_regs(); kill its wrapper kill the declarations of compat_sys_execve()/_compat_sys_execve() in tile asm/compat.h make declaration in linux/compat.h unconditional Note that this does *not* depend on kernel_thread/kernel_execve patch - kernel_execve() is never going to hit compat_sys_execve(), since it's only called from kernel threads and those are not going to be 32bit. After that we can do kernel_thread/kernel_execve commit and sys_execve() conversion with nothing outside of arch/tile touched. Comments? If Catalin feels that arm64 series needs more testing, we could reorder it a bit - all we really need there is getting rid of pt_regs argument in compat_sys_execve() and just as on tile, that isn't tied into kernel_execve and kernel_thread issues. FWIW, it's my fault - I assumed that it would be easier to sort the compat side of things out on per-arch basis. Should've consolidated *that* first (unlike sys_execve(), that doesn't have any prereqs), followed by the infrastructure for kernel_thread/kernel_execve/sys_execve series, followed by the per-architecture conversions. Too late for that now, of course, and fortunately the mess is fairly small. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote: On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote: First, the compat_sys_execve() declaration provided in arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve). However, then arch/tile/kernel/compat.c failed to build, because linux/compat.h is included before asm/unistd.h, and asm/unistd.h provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at all for compat_sys_execve. For most platforms this is no big deal, but on tile we use the __SYSCALL #define to provide the actual syscall table, and for that to work we need a declaration in scope for each syscall at the time we create the table. The best solution seems likely to be to copy the other place in linux/compat.h where we need to do something configurable (that is, CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE to be a Kconfig option. Frankly, I hope to get rid of the damn thing completely. By now we have at least some variant of execve conversions for just about everything; I certainly hope that by the beginning of the next cycle we'll have it defined on everything. And put unconditional declarations in syscalls.h and compat.h Actually, we can make the declaration in linux/compat.h unconditional right now. The only obstacle is the situation on arm64; there the mainline has C variant of that sucker (with struct pt_regs * in arguments) in arch/arm64/kernel/sys_compat.c. So we could ask Linus to pull git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve and then do the following in one patch: introduce current_pt_regs() on tile (from your commit) get rid of pt_regs * argument in tile compat_sys_execve(), making it use current_pt_regs(); kill its wrapper kill the declarations of compat_sys_execve()/_compat_sys_execve() in tile asm/compat.h make declaration in linux/compat.h unconditional Note that this does *not* depend on kernel_thread/kernel_execve patch - kernel_execve() is never going to hit compat_sys_execve(), since it's only called from kernel threads and those are not going to be 32bit. After that we can do kernel_thread/kernel_execve commit and sys_execve() conversion with nothing outside of arch/tile touched. Another possible variant is for you to merge that branch from arm64 tree (only 3 commits it it) and then do as described above. I.e. on top of that apply the thing below, followed by your kernel_thread()/kernel_execve() patch (sans current_pt_regs() part), followed by obviously massaged parts of generic sys_execve for tile patch I've sent. FWIW, I've put the whole series (based at the end of arm64 branch) in signal.git#arch-tile. Comments? Drop struct pt_regs * argument in compat_sys_execve() Signed-off-by: Al Viro v...@zeniv.linux.org.uk --- diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h index 3063e6f..3bcf1b9 100644 --- a/arch/tile/include/asm/compat.h +++ b/arch/tile/include/asm/compat.h @@ -275,9 +275,6 @@ extern int compat_setup_rt_frame(int sig, struct k_sigaction *ka, struct compat_sigaction; struct compat_siginfo; struct compat_sigaltstack; -long compat_sys_execve(const char __user *path, - compat_uptr_t __user *argv, - compat_uptr_t __user *envp, struct pt_regs *); long compat_sys_rt_sigaction(int sig, struct compat_sigaction __user *act, struct compat_sigaction __user *oact, size_t sigsetsize); @@ -304,9 +301,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid, struct compat_timespec __user *interval); /* These are the intvec_64.S trampolines. */ -long _compat_sys_execve(const char __user *path, - const compat_uptr_t __user *argv, - const compat_uptr_t __user *envp); long _compat_sys_sigaltstack(const struct compat_sigaltstack __user *uss_ptr, struct compat_sigaltstack __user *uoss_ptr); long _compat_sys_rt_sigreturn(void); diff --git a/arch/tile/include/asm/processor.h b/arch/tile/include/asm/processor.h index 8c4dd9f..9a83e53 100644 --- a/arch/tile/include/asm/processor.h +++ b/arch/tile/include/asm/processor.h @@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p); #define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA) #define task_pt_regs(task) \ ((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1) +#define current_pt_regs() \ + ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \ + (KSTK_PTREGS_GAP - 1)) - 1) #define task_sp(task) (task_pt_regs(task)-sp) #define task_pc(task) (task_pt_regs(task)-pc) /* Aliases for pc and sp (used in fs/proc/array.c) */ diff --git
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote:
> Also provide an optimized current_pt_regs() while we're at it.
Applied. BTW, are you sure you want to record parent's pid and not tid?
Anyway, here's a followup on top of this one (again, completely untested) -
switching to generic sys_execve(). Does that look right for you? While
we are at it, I wonder if any of PTREGS_SYSCALL wrappers are needed -
current_pt_regs() would do just as well, won't it? It's a couple of
arithmetical operations vs. arith operation + branch; even if the latter
is somehow cheaper, can't be cheaper by much. And I'd expect it to be
costlier, actually, what with the icache effects.
Until now current_pt_regs() was not an option for execve(), due to
kernel_thread() implementation being what it was, but now it should
work for all of them...
diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h
index 3063e6f..404a3dd 100644
--- a/arch/tile/include/asm/compat.h
+++ b/arch/tile/include/asm/compat.h
@@ -304,9 +304,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid,
struct compat_timespec __user *interval);
/* These are the intvec_64.S trampolines. */
-long _compat_sys_execve(const char __user *path,
- const compat_uptr_t __user *argv,
- const compat_uptr_t __user *envp);
long _compat_sys_sigaltstack(const struct compat_sigaltstack __user *uss_ptr,
struct compat_sigaltstack __user *uoss_ptr);
long _compat_sys_rt_sigreturn(void);
diff --git a/arch/tile/include/asm/elf.h b/arch/tile/include/asm/elf.h
index f8ccf08..b73e103 100644
--- a/arch/tile/include/asm/elf.h
+++ b/arch/tile/include/asm/elf.h
@@ -148,6 +148,7 @@ extern int arch_setup_additional_pages(struct linux_binprm
*bprm,
#define compat_start_thread(regs, ip, usp) do { \
regs->pc = ptr_to_compat_reg((void *)(ip)); \
regs->sp = ptr_to_compat_reg((void *)(usp)); \
+ single_step_execve(); \
} while (0)
/*
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 9a83e53..879073e 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -211,6 +211,7 @@ static inline void start_thread(struct pt_regs *regs,
{
regs->pc = pc;
regs->sp = usp;
+ single_step_execve();
}
/* Free all resources held by a thread. */
diff --git a/arch/tile/include/asm/syscalls.h b/arch/tile/include/asm/syscalls.h
index 06f0464..0d52992 100644
--- a/arch/tile/include/asm/syscalls.h
+++ b/arch/tile/include/asm/syscalls.h
@@ -68,9 +68,10 @@ long _sys_sigaltstack(const stack_t __user *, stack_t __user
*);
long _sys_rt_sigreturn(void);
long _sys_clone(unsigned long clone_flags, unsigned long newsp,
void __user *parent_tid, void __user *child_tid);
-long _sys_execve(const char __user *filename,
+long sys_execve(const char __user *filename,
const char __user *const __user *argv,
const char __user *const __user *envp);
+#define sys_execve sys_execve
#include
diff --git a/arch/tile/include/asm/unistd.h b/arch/tile/include/asm/unistd.h
index 6e032a0..dab827d 100644
--- a/arch/tile/include/asm/unistd.h
+++ b/arch/tile/include/asm/unistd.h
@@ -16,4 +16,5 @@
#define __ARCH_WANT_SYS_LLSEEK
#endif
#define __ARCH_WANT_SYS_NEWFSTATAT
+#define __ARCH_WANT_SYS_EXECVE
#include
diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
index d67459b..a8e5a84 100644
--- a/arch/tile/kernel/compat.c
+++ b/arch/tile/kernel/compat.c
@@ -103,7 +103,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid,
#define compat_sys_readahead sys32_readahead
/* Call the trampolines to manage pt_regs where necessary. */
-#define compat_sys_execve _compat_sys_execve
#define compat_sys_sigaltstack _compat_sys_sigaltstack
#define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
#define sys_clone _sys_clone
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 58aad51..174b837 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1476,7 +1476,6 @@ STD_ENTRY_LOCAL(bad_intr)
}; \
STD_ENDPROC(_##x)
-PTREGS_SYSCALL(sys_execve, r3)
PTREGS_SYSCALL(sys_sigaltstack, r2)
PTREGS_SYSCALL_SIGRETURN(sys_rt_sigreturn, r0)
PTREGS_SYSCALL(sys_cmpxchg_badaddr, r1)
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index a84911c4..283efed 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1205,11 +1205,9 @@ STD_ENTRY_LOCAL(bad_intr)
}; \
STD_ENDPROC(_##x)
-PTREGS_SYSCALL(sys_execve, r3)
PTREGS_SYSCALL(sys_sigaltstack, r2)
PTREGS_SYSCALL_SIGRETURN(sys_rt_sigreturn, r0)
#ifdef CONFIG_COMPAT
-PTREGS_SYSCALL(compat_sys_execve, r3)
[PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf
---
[Re-sending to correct linus-arch / linux-arch typo.]
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
arch/tile/kernel/entry.S | 11
arch/tile/kernel/intvec_32.S | 15 ++
arch/tile/kernel/intvec_64.S | 15 ++
arch/tile/kernel/process.c| 103 ++---
7 files changed, 78 insertions(+), 76 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..ea7f61e 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -21,6 +21,8 @@ config TILE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
+ select GENERIC_KERNEL_THREAD
+ select GENERIC_KERNEL_EXECVE
# FIXME: investigate whether we need/want these options.
# select HAVE_IOREMAP_PROT
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 8c4dd9f..9a83e53 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p);
#define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA)
#define task_pt_regs(task) \
((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1)
+#define current_pt_regs() \
+ ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \
+ (KSTK_PTREGS_GAP - 1)) - 1)
#define task_sp(task) (task_pt_regs(task)->sp)
#define task_pc(task) (task_pt_regs(task)->pc)
/* Aliases for pc and sp (used in fs/proc/array.c) */
diff --git a/arch/tile/include/asm/switch_to.h
b/arch/tile/include/asm/switch_to.h
index 1d48c5f..b8f888c 100644
--- a/arch/tile/include/asm/switch_to.h
+++ b/arch/tile/include/asm/switch_to.h
@@ -68,7 +68,10 @@ extern unsigned long get_switch_to_pc(void);
/* Support function for forking a new task. */
void ret_from_fork(void);
-/* Called from ret_from_fork() when a new process starts up. */
+/* Support function for forking a new kernel thread. */
+void ret_from_kernel_thread(void *fn, void *arg);
+
+/* Called from ret_from_xxx() when a new process starts up. */
struct task_struct *sim_notify_fork(struct task_struct *prev);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/tile/kernel/entry.S b/arch/tile/kernel/entry.S
index c31637b..f116cb0 100644
--- a/arch/tile/kernel/entry.S
+++ b/arch/tile/kernel/entry.S
@@ -28,17 +28,6 @@ STD_ENTRY(current_text_addr)
STD_ENDPROC(current_text_addr)
/*
- * Implement execve(). The i386 code has a note that forking from kernel
- * space results in no copy on write until the execve, so we should be
- * careful not to write to the stack here.
- */
-STD_ENTRY(kernel_execve)
- moveli TREG_SYSCALL_NR_NAME, __NR_execve
- swint1
- jrp lr
- STD_ENDPROC(kernel_execve)
-
-/*
* We don't run this function directly, but instead copy it to a page
* we map into every user process. See vdso_setup().
*
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 6943515..58aad51 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1291,6 +1291,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/*
* Code for ill interrupt.
*/
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index 7c06d59..a84911c 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1150,6 +1150,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/* Various stub interrupt handlers and syscall handlers */
STD_ENTRY_LOCAL(_kernel_double_fault)
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 307d010..ca6de8d 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -157,24 +157,44 @@ void arch_release_thread_info(struct thread_info *info)
static void
[PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf
---
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
arch/tile/kernel/entry.S | 11
arch/tile/kernel/intvec_32.S | 15 ++
arch/tile/kernel/intvec_64.S | 15 ++
arch/tile/kernel/process.c| 103 ++---
7 files changed, 78 insertions(+), 76 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..ea7f61e 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -21,6 +21,8 @@ config TILE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
+ select GENERIC_KERNEL_THREAD
+ select GENERIC_KERNEL_EXECVE
# FIXME: investigate whether we need/want these options.
# select HAVE_IOREMAP_PROT
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 8c4dd9f..9a83e53 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p);
#define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA)
#define task_pt_regs(task) \
((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1)
+#define current_pt_regs() \
+ ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \
+ (KSTK_PTREGS_GAP - 1)) - 1)
#define task_sp(task) (task_pt_regs(task)->sp)
#define task_pc(task) (task_pt_regs(task)->pc)
/* Aliases for pc and sp (used in fs/proc/array.c) */
diff --git a/arch/tile/include/asm/switch_to.h
b/arch/tile/include/asm/switch_to.h
index 1d48c5f..b8f888c 100644
--- a/arch/tile/include/asm/switch_to.h
+++ b/arch/tile/include/asm/switch_to.h
@@ -68,7 +68,10 @@ extern unsigned long get_switch_to_pc(void);
/* Support function for forking a new task. */
void ret_from_fork(void);
-/* Called from ret_from_fork() when a new process starts up. */
+/* Support function for forking a new kernel thread. */
+void ret_from_kernel_thread(void *fn, void *arg);
+
+/* Called from ret_from_xxx() when a new process starts up. */
struct task_struct *sim_notify_fork(struct task_struct *prev);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/tile/kernel/entry.S b/arch/tile/kernel/entry.S
index c31637b..f116cb0 100644
--- a/arch/tile/kernel/entry.S
+++ b/arch/tile/kernel/entry.S
@@ -28,17 +28,6 @@ STD_ENTRY(current_text_addr)
STD_ENDPROC(current_text_addr)
/*
- * Implement execve(). The i386 code has a note that forking from kernel
- * space results in no copy on write until the execve, so we should be
- * careful not to write to the stack here.
- */
-STD_ENTRY(kernel_execve)
- moveli TREG_SYSCALL_NR_NAME, __NR_execve
- swint1
- jrp lr
- STD_ENDPROC(kernel_execve)
-
-/*
* We don't run this function directly, but instead copy it to a page
* we map into every user process. See vdso_setup().
*
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 6943515..58aad51 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1291,6 +1291,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/*
* Code for ill interrupt.
*/
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index 7c06d59..a84911c 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1150,6 +1150,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/* Various stub interrupt handlers and syscall handlers */
STD_ENTRY_LOCAL(_kernel_double_fault)
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 307d010..ca6de8d 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -157,24 +157,44 @@ void arch_release_thread_info(struct thread_info *info)
static void save_arch_state(struct thread_struct *t);
int
[PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
arch/tile/kernel/entry.S | 11
arch/tile/kernel/intvec_32.S | 15 ++
arch/tile/kernel/intvec_64.S | 15 ++
arch/tile/kernel/process.c| 103 ++---
7 files changed, 78 insertions(+), 76 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..ea7f61e 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -21,6 +21,8 @@ config TILE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
+ select GENERIC_KERNEL_THREAD
+ select GENERIC_KERNEL_EXECVE
# FIXME: investigate whether we need/want these options.
# select HAVE_IOREMAP_PROT
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 8c4dd9f..9a83e53 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p);
#define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA)
#define task_pt_regs(task) \
((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1)
+#define current_pt_regs() \
+ ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \
+ (KSTK_PTREGS_GAP - 1)) - 1)
#define task_sp(task) (task_pt_regs(task)-sp)
#define task_pc(task) (task_pt_regs(task)-pc)
/* Aliases for pc and sp (used in fs/proc/array.c) */
diff --git a/arch/tile/include/asm/switch_to.h
b/arch/tile/include/asm/switch_to.h
index 1d48c5f..b8f888c 100644
--- a/arch/tile/include/asm/switch_to.h
+++ b/arch/tile/include/asm/switch_to.h
@@ -68,7 +68,10 @@ extern unsigned long get_switch_to_pc(void);
/* Support function for forking a new task. */
void ret_from_fork(void);
-/* Called from ret_from_fork() when a new process starts up. */
+/* Support function for forking a new kernel thread. */
+void ret_from_kernel_thread(void *fn, void *arg);
+
+/* Called from ret_from_xxx() when a new process starts up. */
struct task_struct *sim_notify_fork(struct task_struct *prev);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/tile/kernel/entry.S b/arch/tile/kernel/entry.S
index c31637b..f116cb0 100644
--- a/arch/tile/kernel/entry.S
+++ b/arch/tile/kernel/entry.S
@@ -28,17 +28,6 @@ STD_ENTRY(current_text_addr)
STD_ENDPROC(current_text_addr)
/*
- * Implement execve(). The i386 code has a note that forking from kernel
- * space results in no copy on write until the execve, so we should be
- * careful not to write to the stack here.
- */
-STD_ENTRY(kernel_execve)
- moveli TREG_SYSCALL_NR_NAME, __NR_execve
- swint1
- jrp lr
- STD_ENDPROC(kernel_execve)
-
-/*
* We don't run this function directly, but instead copy it to a page
* we map into every user process. See vdso_setup().
*
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 6943515..58aad51 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1291,6 +1291,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/*
* Code for ill interrupt.
*/
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index 7c06d59..a84911c 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1150,6 +1150,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/* Various stub interrupt handlers and syscall handlers */
STD_ENTRY_LOCAL(_kernel_double_fault)
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 307d010..ca6de8d 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -157,24 +157,44 @@ void arch_release_thread_info(struct thread_info *info)
static void save_arch_state(struct thread_struct *t);
[PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
[Re-sending to correct linus-arch / linux-arch typo.]
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
arch/tile/kernel/entry.S | 11
arch/tile/kernel/intvec_32.S | 15 ++
arch/tile/kernel/intvec_64.S | 15 ++
arch/tile/kernel/process.c| 103 ++---
7 files changed, 78 insertions(+), 76 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..ea7f61e 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -21,6 +21,8 @@ config TILE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
+ select GENERIC_KERNEL_THREAD
+ select GENERIC_KERNEL_EXECVE
# FIXME: investigate whether we need/want these options.
# select HAVE_IOREMAP_PROT
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 8c4dd9f..9a83e53 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p);
#define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA)
#define task_pt_regs(task) \
((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1)
+#define current_pt_regs() \
+ ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \
+ (KSTK_PTREGS_GAP - 1)) - 1)
#define task_sp(task) (task_pt_regs(task)-sp)
#define task_pc(task) (task_pt_regs(task)-pc)
/* Aliases for pc and sp (used in fs/proc/array.c) */
diff --git a/arch/tile/include/asm/switch_to.h
b/arch/tile/include/asm/switch_to.h
index 1d48c5f..b8f888c 100644
--- a/arch/tile/include/asm/switch_to.h
+++ b/arch/tile/include/asm/switch_to.h
@@ -68,7 +68,10 @@ extern unsigned long get_switch_to_pc(void);
/* Support function for forking a new task. */
void ret_from_fork(void);
-/* Called from ret_from_fork() when a new process starts up. */
+/* Support function for forking a new kernel thread. */
+void ret_from_kernel_thread(void *fn, void *arg);
+
+/* Called from ret_from_xxx() when a new process starts up. */
struct task_struct *sim_notify_fork(struct task_struct *prev);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/tile/kernel/entry.S b/arch/tile/kernel/entry.S
index c31637b..f116cb0 100644
--- a/arch/tile/kernel/entry.S
+++ b/arch/tile/kernel/entry.S
@@ -28,17 +28,6 @@ STD_ENTRY(current_text_addr)
STD_ENDPROC(current_text_addr)
/*
- * Implement execve(). The i386 code has a note that forking from kernel
- * space results in no copy on write until the execve, so we should be
- * careful not to write to the stack here.
- */
-STD_ENTRY(kernel_execve)
- moveli TREG_SYSCALL_NR_NAME, __NR_execve
- swint1
- jrp lr
- STD_ENDPROC(kernel_execve)
-
-/*
* We don't run this function directly, but instead copy it to a page
* we map into every user process. See vdso_setup().
*
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 6943515..58aad51 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1291,6 +1291,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/*
* Code for ill interrupt.
*/
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index 7c06d59..a84911c 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1150,6 +1150,21 @@ STD_ENTRY(ret_from_fork)
}
STD_ENDPROC(ret_from_fork)
+STD_ENTRY(ret_from_kernel_thread)
+ jal sim_notify_fork
+ jal schedule_tail
+ FEEDBACK_REENTER(ret_from_fork)
+ {
+move r0, r31
+jalr r30
+ }
+ FEEDBACK_REENTER(ret_from_kernel_thread)
+ {
+movei r30, 0 /* not an NMI */
+j .Lresume_userspace /* jump into middle of interrupt_return */
+ }
+ STD_ENDPROC(ret_from_kernel_thread)
+
/* Various stub interrupt handlers and syscall handlers */
STD_ENTRY_LOCAL(_kernel_double_fault)
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index 307d010..ca6de8d 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -157,24 +157,44 @@ void arch_release_thread_info(struct thread_info *info)
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote:
Also provide an optimized current_pt_regs() while we're at it.
Applied. BTW, are you sure you want to record parent's pid and not tid?
Anyway, here's a followup on top of this one (again, completely untested) -
switching to generic sys_execve(). Does that look right for you? While
we are at it, I wonder if any of PTREGS_SYSCALL wrappers are needed -
current_pt_regs() would do just as well, won't it? It's a couple of
arithmetical operations vs. arith operation + branch; even if the latter
is somehow cheaper, can't be cheaper by much. And I'd expect it to be
costlier, actually, what with the icache effects.
Until now current_pt_regs() was not an option for execve(), due to
kernel_thread() implementation being what it was, but now it should
work for all of them...
diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h
index 3063e6f..404a3dd 100644
--- a/arch/tile/include/asm/compat.h
+++ b/arch/tile/include/asm/compat.h
@@ -304,9 +304,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid,
struct compat_timespec __user *interval);
/* These are the intvec_64.S trampolines. */
-long _compat_sys_execve(const char __user *path,
- const compat_uptr_t __user *argv,
- const compat_uptr_t __user *envp);
long _compat_sys_sigaltstack(const struct compat_sigaltstack __user *uss_ptr,
struct compat_sigaltstack __user *uoss_ptr);
long _compat_sys_rt_sigreturn(void);
diff --git a/arch/tile/include/asm/elf.h b/arch/tile/include/asm/elf.h
index f8ccf08..b73e103 100644
--- a/arch/tile/include/asm/elf.h
+++ b/arch/tile/include/asm/elf.h
@@ -148,6 +148,7 @@ extern int arch_setup_additional_pages(struct linux_binprm
*bprm,
#define compat_start_thread(regs, ip, usp) do { \
regs-pc = ptr_to_compat_reg((void *)(ip)); \
regs-sp = ptr_to_compat_reg((void *)(usp)); \
+ single_step_execve(); \
} while (0)
/*
diff --git a/arch/tile/include/asm/processor.h
b/arch/tile/include/asm/processor.h
index 9a83e53..879073e 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -211,6 +211,7 @@ static inline void start_thread(struct pt_regs *regs,
{
regs-pc = pc;
regs-sp = usp;
+ single_step_execve();
}
/* Free all resources held by a thread. */
diff --git a/arch/tile/include/asm/syscalls.h b/arch/tile/include/asm/syscalls.h
index 06f0464..0d52992 100644
--- a/arch/tile/include/asm/syscalls.h
+++ b/arch/tile/include/asm/syscalls.h
@@ -68,9 +68,10 @@ long _sys_sigaltstack(const stack_t __user *, stack_t __user
*);
long _sys_rt_sigreturn(void);
long _sys_clone(unsigned long clone_flags, unsigned long newsp,
void __user *parent_tid, void __user *child_tid);
-long _sys_execve(const char __user *filename,
+long sys_execve(const char __user *filename,
const char __user *const __user *argv,
const char __user *const __user *envp);
+#define sys_execve sys_execve
#include asm-generic/syscalls.h
diff --git a/arch/tile/include/asm/unistd.h b/arch/tile/include/asm/unistd.h
index 6e032a0..dab827d 100644
--- a/arch/tile/include/asm/unistd.h
+++ b/arch/tile/include/asm/unistd.h
@@ -16,4 +16,5 @@
#define __ARCH_WANT_SYS_LLSEEK
#endif
#define __ARCH_WANT_SYS_NEWFSTATAT
+#define __ARCH_WANT_SYS_EXECVE
#include uapi/asm/unistd.h
diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
index d67459b..a8e5a84 100644
--- a/arch/tile/kernel/compat.c
+++ b/arch/tile/kernel/compat.c
@@ -103,7 +103,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid,
#define compat_sys_readahead sys32_readahead
/* Call the trampolines to manage pt_regs where necessary. */
-#define compat_sys_execve _compat_sys_execve
#define compat_sys_sigaltstack _compat_sys_sigaltstack
#define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
#define sys_clone _sys_clone
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index 58aad51..174b837 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -1476,7 +1476,6 @@ STD_ENTRY_LOCAL(bad_intr)
}; \
STD_ENDPROC(_##x)
-PTREGS_SYSCALL(sys_execve, r3)
PTREGS_SYSCALL(sys_sigaltstack, r2)
PTREGS_SYSCALL_SIGRETURN(sys_rt_sigreturn, r0)
PTREGS_SYSCALL(sys_cmpxchg_badaddr, r1)
diff --git a/arch/tile/kernel/intvec_64.S b/arch/tile/kernel/intvec_64.S
index a84911c4..283efed 100644
--- a/arch/tile/kernel/intvec_64.S
+++ b/arch/tile/kernel/intvec_64.S
@@ -1205,11 +1205,9 @@ STD_ENTRY_LOCAL(bad_intr)
}; \
STD_ENDPROC(_##x)
-PTREGS_SYSCALL(sys_execve, r3)
PTREGS_SYSCALL(sys_sigaltstack, r2)
PTREGS_SYSCALL_SIGRETURN(sys_rt_sigreturn, r0)
#ifdef CONFIG_COMPAT
