[uml-devel] Re: [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> When a task is put to sleep, it is dequeued from the runqueue
> while it is still running. The problem is that the runqueue
> lock can be dropped and retaken in schedule() before the task
> actually schedules off, and wait_task_inactive did not account
> for this.
ugh. This has been the Nth time we got bitten by the fundamental
unrobustness of non-atomic scheduling on some architectures ...
(And i'll say the N+1th time that this is not good.)
> +static int task_onqueue(runqueue_t *rq, task_t *p)
> +{
> + return (p->array || task_running(rq, p));
> +}
the fix looks good, but i'd go for the simplified oneliner patch below.
I dont like the name 'task_onqueue()', a because a task is 'on the
queue' when it has p->array != NULL. The task is running when it's
task_running(). On architectures with nonatomic scheduling a task may
be running while not on the queue and external observers with the
runqueue lock might notice this - and wait_task_inactive() has to take
care of this case. I'm not sure how introducing a function named
"task_onqueue()" will make the situation any clearer.
ok?
Ingo
--
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that one some arches
that has non-atomic scheduling, the runqueue lock can be
dropped and retaken in schedule() before the task actually
schedules off, and wait_task_inactive did not account for this.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
linux/kernel/sched.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -867,7 +875,7 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, &flags);
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p->array)) {
+ if (unlikely(p->array || task_running(rq, p))) {
/* If it's preempted, we yield. It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, &flags);
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[uml-devel] Re: Bugs on your remap_file_pages protections implementations
* Blaisorblade <[EMAIL PROTECTED]> wrote: > Hi Ingo, I'm the young UML hacker you met at OLS and who got your UML > patches sent ;-) > > I've been studying your patch (and the whole Linux VM, indeed) in the > past days, and I have some remarks, about the version of the code in > 2.6.4-rc2-mm1 (which is the same you sent me) - I've now downloaded > the version dropped from 2.6.5-mm1, but it doesn't seem to address > those problems. > > Btw, I've now seen why that patch was dropped, but not why it wasn't > resubmit. was not resubmitted due to me only having 30 hours available to hack, per day ;) Feel free to pick the patch up. > *) with your patch, remapped pages without MAP_INHERIT are IMHO not > safe across swapout; re-swapping them in will pass through the > arch-specific fault handler, which will check VMA's protections, and > fail if the VMA originally had MAP_NONE. Or am I missing something? not sure, was a long time ago. I have checked swap-safeness, but only once. UML did work though, but i dont think i ever pushed it into swapping out its RAM-file. Ingo --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[uml-devel] Re: [RFC] [patch 0/39] remap_file_pages protection support, try 2
* Blaisorblade <[EMAIL PROTECTED]> wrote: > Ok, I've been working for the past two weeks learning well the Linux > VM, understanding the Ingo's remap_file_pages protection support and > its various weakness (due to lack of time on his part), and splitting > and finishing it. > > Here follow a series of 39 _little_ patches against the git-commit-id > 889371f61fd5bb914d0331268f12432590cf7e85, which means between > 2.6.13-rc4 and -rc5. > > Actually, the first 7 ones are unrelated trivial cleanups which > somehow get in the way on this work and that can probably be merged > even now (many are just comment fixes). > > Since I was a VM newbie until two weeks ago, I've separated my changes > into many little patches. hi. Great work! I'm wondering about this comment in rfp-fix-unmap-linear.patch: > Additionally, add a missing TLB flush in both locations. However, > there'is some excess of flushes in these functions. excess TLB flushes one of the reasons of bad UML performance, so you should really review them and not do spurious TLB flushes. Ingo --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Re: [RFC] [patch 0/39] remap_file_pages protection support, try 2
* David S. Miller <[EMAIL PROTECTED]> wrote: > From: Blaisorblade <[EMAIL PROTECTED]> > Date: Fri, 12 Aug 2005 20:56:11 +0200 > > > However, I sent the initial tarball containing all them, so I hope > > that will be useful. > > So not only did you spam the list with 40 patch postings, you sent a > second copy of everything as a tarball attachment as well. That's > even worse. > > Please do not abuse the list server in this way, it is a resource that > is not just your's, but rather one which has to be shared amongst all > folks doing kernel development. while i agree that 40 patches is not common, i'd like to point out that Paolo has sent 40 very nicely split up patches instead of one unreviewable monolithic patch, which are the encouraged format for kernel changes. I havent seen any hard limit mentioned for patch-bombs on lkml before - and i've seen much larger patchbombs going to lkml as well, without any followup chastising of the submitter. E.g.: Subject: [0/48] Suspend2 2.1.9.8 for 2.6.12 So if there needs to be some limit, it might be worth defining some actual hard limit for this. But the more important point is that given how complex the VM, and in particular sys_remap_file_pages_prot() is, i'm personally much more happy about the work having been submitted in a split-up way than i am unhappy about the bombing! Paolo has actually worked alot on this, which resulted in 40 real, new patches, so i couldnt think of any better way to present this work for review. Had he posted some link it would not be individually reviewable. (nor could the patch components be picked up by search utilities in that case - i frequently search lkml for patches, but naturally i dont traverse links referenced in them.) So i think we should rather be happy about the 40-patch progress that Paolo has made to Linux, than be unhappy about this intense work's effect on our infrastructure. In other words, we should not be worried about the number of real changes submitted to lkml, and we should only hope for that number to increase, and we should encourage people to do it! Paolo did this in 2 weeks, so it's not like he has sent changes accumulated over a long time in a patch-bomb. It was real, cutting-edge work very relevant to lkml, which work i believe Paolo didnt have much choice submitting in any other sensible and reviewable form. (i think i agree that maybe the tarball should not have been sent - but even that one was within the usual size limits and other people send tarballs frequently too.) Ingo --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
* Russell King - ARM Linux wrote: > So, if you want to use this, then you should update the CONFIG_BUG text > to include a warning to this effect: > > Warning: if CONFIG_BUG is turned off, and control flow reaches > a BUG(), the system behaviour will be undefined. > > so that people can make an informed choice about this, because at the > moment: > > Disabling this option eliminates support for BUG and WARN, reducing > the size of your kernel image and potentially quietly ignoring > numerous fatal conditions. You should only consider disabling this > option for embedded systems with no facilities for reporting errors. > Just say Y. > > will become completely misleading. Turning this option off will _not_ > result in "quietly ignoring numerous fatal conditions". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > And I come back to one of my previous arguments - is it not better to > panic() if we hit one of these conditions so that the system can try to > do a panic-reboot rather than continue blindly into the unknown? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH 1/2] mm: Introducing arch_remap hook
* Laurent Dufour wrote:
> Some architecture would like to be triggered when a memory area is moved
> through the mremap system call.
>
> This patch is introducing a new arch_remap mm hook which is placed in the
> path of mremap, and is called before the old area is unmapped (and the
> arch_unmap hook is called).
>
> To no break the build, this patch adds the empty hook definition to the
> architectures that were not using the generic hook's definition.
>
> Signed-off-by: Laurent Dufour
> ---
> arch/s390/include/asm/mmu_context.h | 6 ++
> arch/um/include/asm/mmu_context.h| 5 +
> arch/unicore32/include/asm/mmu_context.h | 6 ++
> arch/x86/include/asm/mmu_context.h | 6 ++
> include/asm-generic/mm_hooks.h | 6 ++
> mm/mremap.c | 9 +++--
> 6 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/include/asm/mmu_context.h
> b/arch/s390/include/asm/mmu_context.h
> index 8fb3802f8fad..ddd861a490ba 100644
> --- a/arch/s390/include/asm/mmu_context.h
> +++ b/arch/s390/include/asm/mmu_context.h
> @@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct
> *mm,
> {
> }
>
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
> #endif /* __S390_MMU_CONTEXT_H */
> diff --git a/arch/um/include/asm/mmu_context.h
> b/arch/um/include/asm/mmu_context.h
> index 941527e507f7..f499b017c1f9 100644
> --- a/arch/um/include/asm/mmu_context.h
> +++ b/arch/um/include/asm/mmu_context.h
> @@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
>struct vm_area_struct *vma)
> {
> }
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> +}
> /*
> * end asm-generic/mm_hooks.h functions
> */
> diff --git a/arch/unicore32/include/asm/mmu_context.h
> b/arch/unicore32/include/asm/mmu_context.h
> index 1cb5220afaf9..39a0a553172e 100644
> --- a/arch/unicore32/include/asm/mmu_context.h
> +++ b/arch/unicore32/include/asm/mmu_context.h
> @@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
> {
> }
>
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
> #endif
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index 883f6b933fa4..75cb71f4be1e 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm,
> struct vm_area_struct *vma,
> mpx_notify_unmap(mm, vma, start, end);
> }
>
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> +}
> +
> #endif /* _ASM_X86_MMU_CONTEXT_H */
So instead of spreading these empty prototypes around mmu_context.h
files, why not add something like this to the PPC definition:
#define __HAVE_ARCH_REMAP
and define the empty prototype for everyone else? It's a bit like how
the __HAVE_ARCH_PTEP_* namespace works.
That should shrink this patch considerably.
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap
* Laurent Dufour wrote:
> Some processes (CRIU) are moving the vDSO area using the mremap system
> call. As a consequence the kernel reference to the vDSO base address is
> no more valid and the signal return frame built once the vDSO has been
> moved is not pointing to the new sigreturn address.
>
> This patch handles vDSO remapping and unmapping.
>
> Signed-off-by: Laurent Dufour
> ---
> arch/powerpc/include/asm/mmu_context.h | 36
> +-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h
> b/arch/powerpc/include/asm/mmu_context.h
> index 73382eba02dc..be5dca3f7826 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> /*
> @@ -109,5 +108,40 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
> #endif
> }
>
> +static inline void arch_dup_mmap(struct mm_struct *oldmm,
> + struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_exit_mmap(struct mm_struct *mm)
> +{
> +}
> +
> +static inline void arch_unmap(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long start, unsigned long end)
> +{
> + if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> + mm->context.vdso_base = 0;
> +}
> +
> +static inline void arch_bprm_mm_init(struct mm_struct *mm,
> + struct vm_area_struct *vma)
> +{
> +}
> +
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> + /*
> + * mremap don't allow moving multiple vma so we can limit the check
> + * to old_start == vdso_base.
s/mremap don't allow moving multiple vma
mremap() doesn't allow moving multiple vmas
right?
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
* Laurent Dufour wrote:
> +static inline void arch_unmap(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long start, unsigned long end)
> +{
> + if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> + mm->context.vdso_base = 0;
> +}
So AFAICS PowerPC can have multi-page vDSOs, right?
So what happens if I munmap() the middle or end of the vDSO? The above
condition only seems to cover unmaps that affect the first page. I
think 'affects any page' ought to be the right condition? (But I know
nothing about PowerPC so I might be wrong.)
> +#define __HAVE_ARCH_REMAP
> +static inline void arch_remap(struct mm_struct *mm,
> + unsigned long old_start, unsigned long old_end,
> + unsigned long new_start, unsigned long new_end)
> +{
> + /*
> + * mremap() doesn't allow moving multiple vmas so we can limit the
> + * check to old_start == vdso_base.
> + */
> + if (old_start == mm->context.vdso_base)
> + mm->context.vdso_base = new_start;
> +}
mremap() doesn't allow moving multiple vmas, but it allows the
movement of multi-page vmas and it also allows partial mremap()s,
where it will split up a vma.
In particular, what happens if an mremap() is done with
old_start == vdso_base, but a shorter end than the end of the vDSO?
(i.e. a partial mremap() with fewer pages than the vDSO size)
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
* Ingo Molnar wrote:
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > + unsigned long old_start, unsigned long old_end,
> > + unsigned long new_start, unsigned long new_end)
> > +{
> > + /*
> > +* mremap() doesn't allow moving multiple vmas so we can limit the
> > +* check to old_start == vdso_base.
> > +*/
> > + if (old_start == mm->context.vdso_base)
> > + mm->context.vdso_base = new_start;
> > +}
>
> mremap() doesn't allow moving multiple vmas, but it allows the
> movement of multi-page vmas and it also allows partial mremap()s,
> where it will split up a vma.
I.e. mremap() supports the shrinking (and growing) of vmas. In that
case mremap() will unmap the end of the vma and will shrink the
remaining vDSO vma.
Doesn't that result in a non-working vDSO that should zero out
vdso_base?
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
* Benjamin Herrenschmidt wrote:
> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> >
> > > > +#define __HAVE_ARCH_REMAP
> > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > + unsigned long old_start, unsigned long
> > > > old_end,
> > > > + unsigned long new_start, unsigned long
> > > > new_end)
> > > > +{
> > > > + /*
> > > > +* mremap() doesn't allow moving multiple vmas so we can limit
> > > > the
> > > > +* check to old_start == vdso_base.
> > > > +*/
> > > > + if (old_start == mm->context.vdso_base)
> > > > + mm->context.vdso_base = new_start;
> > > > +}
> > >
> > > mremap() doesn't allow moving multiple vmas, but it allows the
> > > movement of multi-page vmas and it also allows partial mremap()s,
> > > where it will split up a vma.
> >
> > I.e. mremap() supports the shrinking (and growing) of vmas. In that
> > case mremap() will unmap the end of the vma and will shrink the
> > remaining vDSO vma.
> >
> > Doesn't that result in a non-working vDSO that should zero out
> > vdso_base?
>
> Right. Now we can't completely prevent the user from shooting itself
> in the foot I suppose, though there is a legit usage scenario which
> is to move the vDSO around which it would be nice to support. I
> think it's reasonable to put the onus on the user here to do the
> right thing.
I argue we should use the right condition to clear vdso_base: if the
vDSO gets at least partially unmapped. Otherwise there's little point
in the whole patch: either correctly track whether the vDSO is OK, or
don't ...
There's also the question of mprotect(): can users mprotect() the vDSO
on PowerPC?
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
* Benjamin Herrenschmidt wrote:
> > > +#define __HAVE_ARCH_REMAP
> > > +static inline void arch_remap(struct mm_struct *mm,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_start, unsigned long new_end)
> > > +{
> > > + /*
> > > + * mremap() doesn't allow moving multiple vmas so we can limit the
> > > + * check to old_start == vdso_base.
> > > + */
> > > + if (old_start == mm->context.vdso_base)
> > > + mm->context.vdso_base = new_start;
> > > +}
> >
> > mremap() doesn't allow moving multiple vmas, but it allows the
> > movement of multi-page vmas and it also allows partial mremap()s,
> > where it will split up a vma.
> >
> > In particular, what happens if an mremap() is done with
> > old_start == vdso_base, but a shorter end than the end of the vDSO?
> > (i.e. a partial mremap() with fewer pages than the vDSO size)
>
> Is there a way to forbid splitting ? Does x86 deal with that case at
> all or it doesn't have to for some other reason ?
So we use _install_special_mapping() - maybe PowerPC does that too?
That adds VM_DONTEXPAND which ought to prevent some - but not all - of
the VM API weirdnesses.
On x86 we'll just dump core if someone unmaps the vdso.
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
* Laurent Dufour wrote: > > I argue we should use the right condition to clear vdso_base: if > > the vDSO gets at least partially unmapped. Otherwise there's > > little point in the whole patch: either correctly track whether > > the vDSO is OK, or don't ... > > That's a good option, but it may be hard to achieve in the case the > vDSO area has been splitted in multiple pieces. > > Not sure there is a right way to handle that, here this is a best > effort, allowing a process to unmap its vDSO and having the > sigreturn call done through the stack area (it has to make it > executable). > > Anyway I'll dig into that, assuming that the vdso_base pointer > should be clear if a part of the vDSO is moved or unmapped. The > patch will be larger since I'll have to get the vDSO size which is > private to the vdso.c file. At least for munmap() I don't think that's a worry: once unmapped (even if just partially), vdso_base becomes zero and won't ever be set again. So no need to track the zillion pieces, should there be any: Humpty Dumpty won't be whole again, right? > > There's also the question of mprotect(): can users mprotect() the > > vDSO on PowerPC? > > Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and > certainly all the other architectures. Furthermore, if it is done on > a partial part of the vDSO it is splitting the vma... btw., CRIU's main purpose here is to reconstruct a vDSO that was originally randomized, but whose address must now be reproduced as-is, right? In that sense detecting the 'good' mremap() as your patch does should do the trick and is certainly not objectionable IMHO - I was just wondering whether we could make a perfect job very simply. Thanks, Ingo -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap
* Laurent Dufour wrote:
> +{
> + unsigned long vdso_end, vdso_start;
> +
> + if (!mm->context.vdso_base)
> + return;
> + vdso_start = mm->context.vdso_base;
> +
> +#ifdef CONFIG_PPC64
> + /* Calling is_32bit_task() implies that we are dealing with the
> + * current process memory. If there is a call path where mm is not
> + * owned by the current task, then we'll have need to store the
> + * vDSO size in the mm->context.
> + */
> + BUG_ON(current->mm != mm);
> + if (is_32bit_task())
> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> + else
> + vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> + vdso_end += (1< +
> + /* Check if the vDSO is in the range of the remapped area */
> + if ((vdso_start <= old_start && old_start < vdso_end) ||
> + (vdso_start < old_end && old_end <= vdso_end) ||
> + (old_start <= vdso_start && vdso_start < old_end)) {
> + /* Update vdso_base if the vDSO is entirely moved. */
> + if (old_start == vdso_start && old_end == vdso_end &&
> + (old_end - old_start) == (new_end - new_start))
> + mm->context.vdso_base = new_start;
> + else
> + mm->context.vdso_base = 0;
> + }
> +}
Oh my, that really looks awfully complex, as you predicted, and right
in every mremap() call.
I'm fine with your original, imperfect, KISS approach. Sorry about
this detour ...
Reviewed-by: Ingo Molnar
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH] Syslets - Fix cachemiss_thread return value
* Jeff Dike <[EMAIL PROTECTED]> wrote: > cachemiss_thread should explicitly return 0 or error instead of > task_ret_reg(current) (which is -ENOSYS anyway) because > async_thread_helper is careful to put the return value in eax anyway. oops, indeed! Thanks. Ingo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* WANG Cong <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 22, 2007 at 12:36:00PM +0100, Al Viro wrote:
> >On Mon, Oct 22, 2007 at 03:48:23PM +0800, WANG Cong wrote:
> >> I just followed what Sam told me, errors are much fewer this time,
> >> but still exist. Error messages are:
> >>
> >> CC arch/um/kernel/syscall.o
> >> CC arch/um/kernel/sysrq.o
> >> arch/um/kernel/sysrq.c: In function ???show_stack???:
> >> arch/um/kernel/sysrq.c:63: error: ???UESP??? undeclared (first use in this
> >> function)
> >> arch/um/kernel/sysrq.c:63: error: (Each undeclared identifier is reported
> >> only once
> >> arch/um/kernel/sysrq.c:63: error: for each function it appears in.)
> >> make[1]: *** [arch/um/kernel/sysrq.o] Error 1
> >> make: *** [arch/um/kernel] Error 2
> >>
> >> Or I missed something again?
> >>
> >> And I use `make defconfig ARCH=um' to generate .config, my tree
> >> is 2.6.23-git16 (Al, is this OK?).
> >
> >Now apply the patch upthread, it should've fixed that one (and yes, you
> >are down to the stuff this patch is supposed to fix - and does so here).
>
> Yes, this one is fixed. Thanks for your patch.
>
> But another one comes out. ;(
>
> CC kernel/sched.o
> kernel/sched.c:3902: error: conflicting types for
> ‘wait_for_completion_interruptible’
> include/linux/completion.h:46: error: previous declaration of
> ‘wait_for_completion_interruptible’ was here
> kernel/sched.c:3908: error: conflicting types for
> ‘wait_for_completion_interruptible’
> include/linux/completion.h:46: error: previous declaration of
> ‘wait_for_completion_interruptible’ was here
> make[1]: *** [kernel/sched.o] Error 1
> make: *** [kernel] Error 2
does the patch below ontop of latest -git help?
Ingo
>
Subject: sched: fix fastcall mismatch in completion APIs
From: Ingo Molnar <[EMAIL PROTECTED]>
Jeff Dike noticed that wait_for_completion_interruptible()'s prototype
had a mismatched fastcall.
Fix this by removing the fastcall attributes from all the completion APIs.
Found-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/linux/completion.h | 16
kernel/sched.c | 10 +-
2 files changed, 13 insertions(+), 13 deletions(-)
Index: linux/include/linux/completion.h
===
--- linux.orig/include/linux/completion.h
+++ linux/include/linux/completion.h
@@ -42,15 +42,15 @@ static inline void init_completion(struc
init_waitqueue_head(&x->wait);
}
-extern void FASTCALL(wait_for_completion(struct completion *));
-extern int FASTCALL(wait_for_completion_interruptible(struct completion *x));
-extern unsigned long FASTCALL(wait_for_completion_timeout(struct completion *x,
- unsigned long timeout));
-extern unsigned long FASTCALL(wait_for_completion_interruptible_timeout(
- struct completion *x, unsigned long timeout));
+extern void wait_for_completion(struct completion *);
+extern int wait_for_completion_interruptible(struct completion *x);
+extern unsigned long wait_for_completion_timeout(struct completion *x,
+ unsigned long timeout);
+extern unsigned long wait_for_completion_interruptible_timeout(
+ struct completion *x, unsigned long timeout);
-extern void FASTCALL(complete(struct completion *));
-extern void FASTCALL(complete_all(struct completion *));
+extern void complete(struct completion *);
+extern void complete_all(struct completion *);
#define INIT_COMPLETION(x) ((x).done = 0)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -3821,7 +3821,7 @@ __wake_up_sync(wait_queue_head_t *q, uns
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
-void fastcall complete(struct completion *x)
+void complete(struct completion *x)
{
unsigned long flags;
@@ -3833,7 +3833,7 @@ void fastcall complete(struct completion
}
EXPORT_SYMBOL(complete);
-void fastcall complete_all(struct completion *x)
+void complete_all(struct completion *x)
{
unsigned long flags;
@@ -3885,13 +3885,13 @@ wait_for_common(struct completion *x, lo
return timeout;
}
-void fastcall __sched wait_for_completion(struct completion *x)
+void __sched wait_for_completion(struct completion *x)
{
wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
EXPORT_SYMBOL(wait_for_completion);
-unsigned long fastcall __sched
+unsigned long __sched
wait_for_completion_timeout(s
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Al Viro <[EMAIL PROTECTED]> wrote: > in kernel/sched.c > > FWIW, I would simply kill the damn fastcall thing - right now the only > user is uml/i386; everything else either has it #defined to nothing or > (as i386 does) passes -mregparm=3 while having fastcall expand to > __attribute__((regparm(3))) - i.e. has all functions fastcall. > > Do we really need it on uml/i386 enough to keep bothering with that > mess? we should kill it there too. the only place where we should _please_ keep those annotations are for functions that get called from assembly code. This makes life immensely easier for -pg (CONFIG_FUNCTION_TRACING) kernels. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > we should kill it there too. > > > > the only place where we should _please_ keep those annotations are for > > functions that get called from assembly code. This makes life immensely > > easier for -pg (CONFIG_FUNCTION_TRACING) kernels. > > Should we re-add them for the function pointers in asm-x86/paravirt.h? yes, yes, yes. :-) It was a nightmare to sort it out in -rt (and still is). It's also good documentation - it pinpoints functions that are called from assembly. > Andi argued we should remove them since x86 is unconditionally regparm > now anyway - and they're pretty ugly syntactically. Sure, it doesnt make things prettier, but i didnt see any particular ugliness. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >> Should we re-add them for the function pointers in
> >> asm-x86/paravirt.h?
> >
> > yes, yes, yes. :-) It was a nightmare to sort it out in -rt (and
> > still is).
>
> Do you have a patch to do this already?
yes, attached. Ack?
Ingo
>
Subject: [patch] paravirt: mark assembly dependencies as fastcall
From: Ingo Molnar <[EMAIL PROTECTED]>
the 'fastcall removal' changes to paravirt.c were over-eager: they
removed fastcall annotations from functions that are (or might be)
implemented in assembly. So if someone changes the compiler model,
such as -pg which disables regparm, the kernel breaks in nasty ways.
so this patch adds back fastcall annotations. This serves as
documentation for assembly calling-convention dependencies as
well.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/i386/kernel/paravirt.c |6 -
arch/i386/kernel/smp.c|7 +
include/asm-i386/desc.h | 18 ++--
include/asm-i386/io.h |2
include/asm-i386/irqflags.h | 12 +-
include/asm-i386/msr.h| 13 +--
include/asm-i386/page.h | 21 ++---
include/asm-i386/paravirt.h | 156 +++---
include/asm-i386/pgtable-2level.h | 10 +-
include/asm-i386/pgtable-3level.h | 18 ++--
include/asm-i386/pgtable.h|2
include/asm-i386/processor.h |8 -
include/asm-i386/system.h | 22 ++---
include/asm-i386/time.h |4
include/asm-i386/tlbflush.h |4
15 files changed, 154 insertions(+), 149 deletions(-)
Index: linux-2.6.23-rt1/arch/i386/kernel/paravirt.c
===
--- linux-2.6.23-rt1.orig/arch/i386/kernel/paravirt.c 2007-10-11
15:58:08.0 -0400
+++ linux-2.6.23-rt1/arch/i386/kernel/paravirt.c2007-10-11
16:00:03.0 -0400
@@ -208,7 +208,7 @@ void init_IRQ(void)
paravirt_ops.init_IRQ();
}
-static void native_flush_tlb(void)
+static fastcall void native_flush_tlb(void)
{
__native_flush_tlb();
}
@@ -217,12 +217,12 @@ static void native_flush_tlb(void)
* Global pages have to be flushed a bit differently. Not a real
* performance problem because this does not happen often.
*/
-static void native_flush_tlb_global(void)
+static fastcall void native_flush_tlb_global(void)
{
__native_flush_tlb_global();
}
-static void native_flush_tlb_single(unsigned long addr)
+static fastcall void native_flush_tlb_single(unsigned long addr)
{
__native_flush_tlb_single(addr);
}
Index: linux-2.6.23-rt1/arch/i386/kernel/smp.c
===
--- linux-2.6.23-rt1.orig/arch/i386/kernel/smp.c2007-10-11
15:58:08.0 -0400
+++ linux-2.6.23-rt1/arch/i386/kernel/smp.c 2007-10-11 16:00:03.0
-0400
@@ -344,8 +344,9 @@ out:
put_cpu_no_resched();
}
-void native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,
-unsigned long va)
+void fastcall
+native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,
+ unsigned long va)
{
cpumask_t cpumask = *cpumaskp;
@@ -470,6 +471,7 @@ void flush_tlb_all(void)
*/
static void native_smp_send_reschedule(int cpu)
{
+ trace_special(cpu, 0, 0);
WARN_ON(cpu_is_offline(cpu));
send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR);
}
@@ -639,6 +641,7 @@ static void native_smp_send_stop(void)
*/
fastcall void smp_reschedule_interrupt(struct pt_regs *regs)
{
+ trace_special(regs->eip, 0, 0);
ack_APIC_irq();
}
Index: linux-2.6.23-rt1/include/asm-i386/desc.h
===
--- linux-2.6.23-rt1.orig/include/asm-i386/desc.h 2007-10-11
15:58:08.0 -0400
+++ linux-2.6.23-rt1/include/asm-i386/desc.h2007-10-11 16:00:03.0
-0400
@@ -78,14 +78,14 @@ static inline void pack_gate(__u32 *a, _
#define write_idt_entry(dt, entry, a, b) write_dt_entry(dt, entry, a, b)
#endif
-static inline void write_dt_entry(struct desc_struct *dt,
+static inline fastcall void write_dt_entry(struct desc_struct *dt,
int entry, u32 entry_low, u32 entry_high)
{
dt[entry].a = entry_low;
dt[entry].b = entry_high;
}
-static inline void native_set_ldt(const void *addr, unsigned int entries)
+static fastcall inline void native_set_ldt(const void *addr, unsigned int
entries)
{
if (likely(entries == 0))
__asm__ __volatile__("lldt %w0"::"q" (0));
@@ -102,39 +102,39 @@ static inline void native_set_ldt(const
}
-static inline void native_load_tr_desc(void)
+static fastcall inline void native_load_tr_desc(void)
{
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > so this patch adds back fastcall annotations. This serves as > > documentation for assembly calling-convention dependencies as well. > > You should rename it then to "asmcall" or something. if then that should be a separate renaming patch. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Andi Kleen <[EMAIL PROTECTED]> wrote: > >> You should rename it then to "asmcall" or something. > > > > if then that should be a separate renaming patch. > > Well you're asking for the ugly hacks for out of tree code. [...] nice word-bending there. I'm asking for pre-existing annotations to survive. It hurts you _nothing_ and it was a world of pain for us to recover those lost annotations. Anyway, if Jeremy does not object to the patch we'll push it in and then rename fastcall to asmcall. Much ado about nothing. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > >>>> You should rename it then to "asmcall" or something. > >>>> > >>> if then that should be a separate renaming patch. > >>> > >> Well you're asking for the ugly hacks for out of tree code. [...] > >> > > > > nice word-bending there. I'm asking for pre-existing annotations to > > survive. It hurts you _nothing_ and it was a world of pain for us to > > recover those lost annotations. Anyway, if Jeremy does not object to the > > patch > > I don't have any objections to the idea of the patch, but I'm still > concerned about the practical aspects of it. Maintaining these kinds > of annotations is hard/fragile/etc when the compiler doesn't warn when > you get it wrong, and only a very specific use-case will reveal the > problem (and do so in a fairly obscure way). it wont be any different from the situation before - we had no such warnings there either. Anyway, this shouldnt really bother you as at the moment it's only used for -rt. The issue is to keep something we had before (but which was stupidly/carelessly removed). If it breaks we'll fix it up. > > we'll push it in and then rename fastcall to asmcall. Much ado about > > nothing. > > Hm, "asmcall" is confusingly close to "asmlinkage" - and they have > exactly the same intent (can be called from asm), but with exactly the > opposite effect. How about something which actually says what we > mean. How about just "regparm"? yeah, regparm is fine. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Andi Kleen <[EMAIL PROTECTED]> wrote: > On Tue, Oct 23, 2007 at 04:20:06PM +0200, Ingo Molnar wrote: > > > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > >> You should rename it then to "asmcall" or something. > > > > > > > > if then that should be a separate renaming patch. > > > > > > Well you're asking for the ugly hacks for out of tree code. [...] > > > > nice word-bending there. I'm asking for pre-existing annotations to > > survive. > > What I'm objecting to is that you ask for this for your out of tree > code without any justification on why exactly -- -pg should in theory > work with -mregparms. last i checked it didnt work - i'll re-check that. but even taking the latency tracer completely out of the picture, maintaining this information is useful - at least for some time. > It's standard policy to require very good reasons for changes that are > only useful for out of tree code. [...] it's not just for out of tree code - it's to keep the information of the calling convention maintained - we could need it in the future. > Is it just because you didn't want to adapt the tracer for i386 > regparm? [...] uhm, thank you for such accusations and personal attacks :-( How did i deserve that? Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > [...] -pg should in theory work with -mregparms. > > last i checked it didnt work - i'll re-check that. earlier gcc versions had problems with -mregparm and with -pg. I just did a quick test with latest gcc and at a quick glance it seems to work better - i'll propagate that throught he whole latency tracer to see whether it's indeed working throughout. Anyway, this means that there's no urgent need for this patch and we've dropped it from the x86 queue for now. As long as it only affects older gcc's it's probably not worth force-keeping the annotations for that purpose alone. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > When writing a big file to a ubd disk, everything in uml slows down to > a crawl, even though CPU usage is minimal. > > So I wanted to try the latency tracer from -rt, but it doesn't compile > with UML: note that there are standalone patches as well: http://people.redhat.com/mingo/latency-tracing-patches/ so there's no forced need to use -rt. > Ingo, do you think this route is worthwhile pursuing, or is it too > difficult to make -rt work for UML? -rt should work for UML as well - but it needs porting (as every architecture). Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > so there's no forced need to use -rt. > > Ah, forgotten about that. > > Unfortunately the latency tracer patch doesn't compile either: > > CC kernel/latency_trace.o > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs. > kernel/latency_trace.c: In function ???trace???: > kernel/latency_trace.c:658: error: implicit declaration of function > ???irqs_disabled_flags??? > make[1]: *** [kernel/latency_trace.o] Error 1 hm, just fill those functions in - should be fairly trivial and we can carry those patches in -rt. (I'd suggest to create an empty asm-um/rtc.h stub as well, for consistency.) Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > CC kernel/latency_trace.o > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory > > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs. > > kernel/latency_trace.c: In function ???trace???: > > kernel/latency_trace.c:658: error: implicit declaration of function > > ???irqs_disabled_flags??? > > make[1]: *** [kernel/latency_trace.o] Error 1 > > hm, just fill those functions in - should be fairly trivial and we can > carry those patches in -rt. (I'd suggest to create an empty > asm-um/rtc.h stub as well, for consistency.) trivial == 'far easier than porting -rt to UML' :-) Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > it doesnt need it - turn IRQOFF_TRACING off.
>
> # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
>
> This seems to be off.
>
> But latency_trace.c uses irqs_disabled_flags(), which is defined in
> only if CONFIG_TRACE_IRQFLAGS_SUPPORT is set.
>
> So perhaps latency_trace.c should be using raw_irqs_disabled_flags()
> instead. But UML doesn't define that either and I have no idea how to
> do that, so this is still not solved yet.
irqs_disabled_flags() gives us a nonessential bit of the trace output:
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
privoxy-12926 1.Ns10us : ktime_get_ts (ktime_get)
privoxy-12926 1.Ns10us : getnstimeofday (ktime_get_ts)
privoxy-12926 1.Ns11us : set_normalized_timespec (ktime_get_ts)
privoxy-12926 1.Ns11us : rb_first (htb_dequeue)
it's the 'irqs-off' flag, which is 'd', 'D' or '.'.
so you can define irqs_off_flags to always-0 and you should be able to
get pretty good traces still. It should have no functional impact.
Ingo
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote: > > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory > > > > For things like this, look at the host's asm/foo.h and see if it's > > usable in UML (and contains things that you need). If it is, just > > make a asm-um/foo.h which just includes "asm/arch/foo.h". > > Yeah, I know that trick :) > > It doesn't help in this case. I've gotten as far as realizing that > the latency tracer needs the irqflags tracing > (Documentation/irqflags-tracing.tx) and that UML doesn't yet support > that. it doesnt need it - turn IRQOFF_TRACING off. You want FUNCTION_TRACING to work (and perhaps WAKEUP_TIMING) so that you can take a look at what's going on, right? Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > so you can define irqs_off_flags to always-0 and you should be able > > to get pretty good traces still. It should have no functional > > impact. > > OK, managed to make it compile, but then something goes wrong in > tracer_alloc_bootmem(). try with a lower MAX_TRACE first - 1 million entries (default) uses up like 32 MB of RAM per CPU, that might be quite a bit and your UML image might not be able to take that. also, you can do a s/trace_alloc_bootmem/alloc_bootmem - the alloc-bootmem wrapping was only done to get the tracer boot with really ridiculously high MAX_TRACE. Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > OK, managed to make it compile, but then something goes wrong in > > tracer_alloc_bootmem(). > > It needs 32M, and uml has that much by default. Doh. reduce MAX_TRACE to something like 1024 to make sure allocation is not an issue. Do you still see problems? Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] -rt doesn't compile for UML
* Jeff Dike <[EMAIL PROTECTED]> wrote: > On Wed, Nov 28, 2007 at 04:35:12PM +0100, Miklos Szeredi wrote: > > Something like: > > > > dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100 > > > > and run 'top' or 'watch something' in another terminal, which > > sometimes completely stops updating during the write. > > Are you talking about missing updates for a few seconds, or for > longer? With the common above, with top -delay 1, and with 600M of > data, I'm seeing occasional 2-3 pauses, with one missing 5 seconds. even sub-second delays are a huge issue if the system is otherwise idle - it signals some sort of missed event condition. scheduling must be instantenous. Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] scheduling anomaly on uml (was: -rt doesn't compile for UML)
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > I can't say I'm understading these traces very well, but here's a > snippet that looks a bit strange. I'm running 'while true; do date; > done' in parallel with the dd. > > For some time it is doing 100% CPU as expected, then it goes into a > second or so of mosty idle (afaics), and then returns to the normal > pattern again. try: echo 1 > /proc/sys/kernel/stackframe_tracing to get symbolic stack backdumps for the wakeup points, and add trace_special_sym() calls to generate extra stackdump entries at arbitrary places. schedule() does not have it right now - it might make sense to add it. also, enabling mcount: echo 1 > /proc/sys/kernel/mcount_enabled will give you a _lot_ more verbose trace. Likewise: echo 1 > /proc/sys/kernel/syscall_tracing (but for that you'd have to add the sys_call()/sys_ret() instrumentation that x86 has in entry_32.S) but even this highlevel trace shows something weird: > events/0-4 0 16044512us+: schedule <-0> (20 -5) > -0 0 16044564us!: schedule (-5 20) > -0 0.Nh. 16076072us+: __trace_start_sched_wakeup (120 > -1) > -0 0.Nh. 16076075us+: __trace_start_sched_wakeup (120 > -1) > -0 0.Nh. 16076078us+: __trace_start_sched_wakeup > (115 -1) > dd-6444 0 16076104us+: schedule <-0> (20 0) how come UML idled for 30 msecs here, while the workload was supposed to be CPU-bound? It's not IO bound anywhere, right? No SMP artifacts either, right? Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] scheduling anomaly on uml (was: -rt doesn't compile for UML)
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > how come UML idled for 30 msecs here, while the workload was > > supposed to be CPU-bound? It's not IO bound anywhere, right? No SMP > > artifacts either, right? > > Yes. The UML kernel is UP, and I don't think 'date' or 'bash' want to > do any disk I/O. > > Could disk I/O be blocking the tty? I think UML uses separate threads > for these, but I don't know the details. even if the workload is fully CPU bound externally - internally a request to the external (CPU-bound) thread will look like an asynchonous request - so small amounts of idle time can be within UML, legitimately. (for the amount of time it takes for the external thread to service the request) 30 msecs already sounds a bit excessive (this is on your T60 with Core2Duo, right?), and 1-2 seconds noticeable latency is definitely excessive. Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] scheduling anomaly on uml (was: -rt doesn't compile for UML)
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > to get symbolic stack backdumps for the wakeup points, and add > > trace_special_sym() calls to generate extra stackdump entries at > > arbitrary places. schedule() does not have it right now - it might > > make sense to add it. > > OK, this helped. > > It looks like the delays are caused by the page allocator, and not > UML. Which is good news, because I'm supposed to understand memory > management better than scheduling. heh :-) Scheduling isnt hard either - and looking at traces (especially with mcount_enabled=1) certainly helps. Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] scheduling anomaly on uml (was: -rt doesn't compile for UML)
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> > date-7119 0 15636591us!: schedule (0 0)
> > bash-502 0 15643908us!: schedule (0 0)
> > bash-502 0 15646250us!: schedule (0 0)
>
> How exactly did you end up getting this data?
>
> And is there something I can read to tell what it means?
the header of /proc/latency_trace explains the format:
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
privoxy-12926 1.Ns10us : ktime_get_ts (ktime_get)
'time' is timestamp in microseconds. Then come the caller (and parent,
or other, special parameters like the task-pid of the scheduled task).
It's supposed to be easy to read to kernel hackers - let me know if any
of the details is non-obvious.
for example:
> > date-7119 0 15636591us!: schedule (0 0)
the task 'date' (pid 7119) scheduled at timestamp 15636591us, and
switched to another task 'bash' (pid 502). Both had a default nice level
of 0 [the (0 0) arguments].
Ingo
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] scheduling anomaly on uml (was: -rt doesn't compile for UML)
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > heh :-) Scheduling isnt hard either - and looking at traces > > (especially with mcount_enabled=1) certainly helps. > > I still don't know what mcount_enabled=1 should do. I didn't see any > difference in the trace after enabling it. if you build with CONFIG_FUNCTION_TRACING then you should see a trace of *every* function call done within the kernel. Warning: reading it can be very addictive ;-) Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH] UML - change sigcontext fields to match x86
* Jeff Dike <[EMAIL PROTECTED]> wrote: > git-x86, in commit 70aa1bd3839e3ec74ce65316528a82570e8de666, changed a > lot of the sigcontext field names. This patch changes UML usage to > match. thanks, we indeed missed those. Should we carry this in x86.git, or would you like to carry this in your UML tree? Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH] UML - change sigcontext fields to match x86
* Jeff Dike <[EMAIL PROTECTED]> wrote: > On Wed, Dec 05, 2007 at 05:48:16PM +0100, Ingo Molnar wrote: > > thanks, we indeed missed those. Should we carry this in x86.git, or > > would you like to carry this in your UML tree? > > Probably better for it to go in x86.git - that way it travels with > your sigcontext patch. ok, added it. Ingo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] uml and -regparm=3
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> FASTCALL is defined empty in -mm, but UML is not compiled with
> -mregparm=3 and so this breaks things (I noticed problems with
> rwsem_down_write_failed).
>
> Tried recompiling UML with -mregparm=3, but that resulted in a strange
> failure immediately after startup:
>
> |%G�%@: Invalid argument
>
> What's up?
Miklos, could you try the fix below?
In general most FASTCALL/fastcall uses are bogus, except for code where
a function that takes parameters is implemented in assembly with a
regparm calling convention. The fix is to introduce the "asmregparm"
attribute to mark such function prototypes with regparm(3). This is the
opposite of asmlinkage. [asmlinkage forced regparm(0)]
Ingo
---->
Subject: x86: fix UML calling convention
From: Ingo Molnar <[EMAIL PROTECTED]>
introduce the "asmregparm" calling convention: for functions
implemented in assembly with a fixed regparm input parameters
calling convention.
mark the semaphore and rwsem slowpath functions with that.
Reported-by: Miklos Szeredi <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/asm-x86/linkage.h |5 +
include/asm-x86/rwsem.h| 12
include/asm-x86/semaphore_32.h |8
3 files changed, 17 insertions(+), 8 deletions(-)
Index: linux-x86.q/include/asm-x86/linkage.h
===
--- linux-x86.q.orig/include/asm-x86/linkage.h
+++ linux-x86.q/include/asm-x86/linkage.h
@@ -9,6 +9,11 @@
#ifdef CONFIG_X86_32
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
#define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret))
+/*
+ * For 32-bit UML - mark functions implemented in assembly that use
+ * regparm input parameters:
+ */
+#define asmregparm __attribute__((regparm(3)))
#endif
#ifdef CONFIG_X86_ALIGNMENT_16
Index: linux-x86.q/include/asm-x86/rwsem.h
===
--- linux-x86.q.orig/include/asm-x86/rwsem.h
+++ linux-x86.q/include/asm-x86/rwsem.h
@@ -44,10 +44,14 @@
struct rwsem_waiter;
-extern struct rw_semaphore *FASTCALL(rwsem_down_read_failed(struct
rw_semaphore *sem));
-extern struct rw_semaphore *FASTCALL(rwsem_down_write_failed(struct
rw_semaphore *sem));
-extern struct rw_semaphore *FASTCALL(rwsem_wake(struct rw_semaphore *));
-extern struct rw_semaphore *FASTCALL(rwsem_downgrade_wake(struct rw_semaphore
*sem));
+extern asmregparm struct rw_semaphore *
+ rwsem_down_read_failed(struct rw_semaphore *sem);
+extern asmregparm struct rw_semaphore *
+ rwsem_down_write_failed(struct rw_semaphore *sem);
+extern asmregparm struct rw_semaphore *
+ rwsem_wake(struct rw_semaphore *);
+extern asmregparm struct rw_semaphore *
+ rwsem_downgrade_wake(struct rw_semaphore *sem);
/*
* the semaphore definition
Index: linux-x86.q/include/asm-x86/semaphore_32.h
===
--- linux-x86.q.orig/include/asm-x86/semaphore_32.h
+++ linux-x86.q/include/asm-x86/semaphore_32.h
@@ -83,10 +83,10 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
-void __down_failed(void /* special register calling convention */);
-int __down_failed_interruptible(void /* params in registers */);
-int __down_failed_trylock(void /* params in registers */);
-void __up_wakeup(void /* special register calling convention */);
+extern asmregparm void __down_failed(atomic_t *count_ptr);
+extern asmregparm int __down_failed_interruptible(atomic_t *count_ptr);
+extern asmregparm int __down_failed_trylock(atomic_t *count_ptr);
+extern asmregparm void __up_wakeup(atomic_t *count_ptr);
/*
* This is ugly, but we want the default case to fall through.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] uml and -regparm=3
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > Thanks. Patch works, but needed to add asmregparm to the definitions > as well, plus added default define into (updated > patch below). thanks, applied. Ingo - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATH] Fix compilation when CONFIG_TRACE_IRQFLAGS_SUPPORT is not set
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> Rui Sousa wrote:
> > On Thursday 4 September 2008 19:14, Hiroshi Shimamoto wrote:
> >> Ingo Molnar wrote:
> >>> * Rui Sousa <[EMAIL PROTECTED]> wrote:
> >>>> Hi,
> >>>>
> >>>> This patch fixes compilation if CONFIG_TRACE_IRQFLAGS_SUPPORT is ever
> >>>> disabled (which is currently not allowed by Kconfig). Alternatively we
> >>>> could just remove the option altogether and the associated code paths.
> >>>> Since the compilation error has been in the tree for at least two
> >>>> years and no one noticed it, I guess we don't really have the need for
> >>>> CONFIG_TRACE_IRQFLAGS_SUPPORT=n. Boot tested on x86 UP.
> >>> applied to tip/core/locking - thanks Rui.
> >>>
> >>> since you fixed it i prefer the fix over the removal. We could still
> >>> remove the !TRACE_IRQFLAGS_SUPPORT now (in a separate commit) and
> >>> simpify this header a bit that way. Thus if someone needs the
> >>> !TRACE_IRQFLAGS_SUPPORT mode of build for future work, it can be
> >>> restored via a simple revert.
> >> Hi, it seems that this patch breaks uml build.
> >
> > Hi Hiroshi,
> >
> >> kernel/printk.c: In function 'vprintk':
> >> kernel/printk.c:674: error: implicit declaration of function
> >> 'raw_local_irq_save' kernel/printk.c:772: error: implicit declaration of
> >> function 'raw_local_irq_restore'
> >
> > With the patch bellow it compiles (make ARCH=um with a x86 host), but I'm
> > really out of my league on this one...
>
> Hi Rui,
>
> with this patch, build and boot (on my x86_64 box) looks ok.
>
> I CC-ed to uml people to check this.
i've applied the fix below to tip/core/locking - but would be nice if
the UML folks had a comment as well.
Ingo
>From 8c56250f48347750c82ab18d98d647dcf99ca674 Mon Sep 17 00:00:00 2001
From: Rui Sousa <[EMAIL PROTECTED]>
Date: Thu, 4 Sep 2008 19:47:53 +0200
Subject: [PATCH] lockdep, UML: fix compilation when
CONFIG_TRACE_IRQFLAGS_SUPPORT is not set
Hiroshi Shimamoto reported:
> > !TRACE_IRQFLAGS_SUPPORT mode of build for future work, it can be
> > restored via a simple revert.
>
> Hi, it seems that this patch breaks uml build.
>
> kernel/printk.c: In function 'vprintk':
> kernel/printk.c:674: error: implicit declaration of function
> 'raw_local_irq_save' kernel/printk.c:772: error: implicit declaration of
> function 'raw_local_irq_restore'
With the patch bellow it compiles (make ARCH=um with a x86 host), but I'm
really out of my league on this one...
Reported-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/asm-um/system-generic.h | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/asm-um/system-generic.h b/include/asm-um/system-generic.h
index 5bcfa35..f1ea4da 100644
--- a/include/asm-um/system-generic.h
+++ b/include/asm-um/system-generic.h
@@ -4,15 +4,15 @@
#include "asm/arch/system.h"
#undef switch_to
-#undef local_irq_save
-#undef local_irq_restore
-#undef local_irq_disable
-#undef local_irq_enable
-#undef local_save_flags
-#undef local_irq_restore
-#undef local_irq_enable
-#undef local_irq_disable
-#undef local_irq_save
+#undef raw_local_irq_save
+#undef raw_local_irq_restore
+#undef raw_local_irq_disable
+#undef raw_local_irq_enable
+#undef raw_local_save_flags
+#undef raw_local_irq_restore
+#undef raw_local_irq_enable
+#undef raw_local_irq_disable
+#undef raw_local_irq_save
#undef irqs_disabled
extern void *switch_to(void *prev, void *next, void *last);
@@ -23,21 +23,21 @@ extern int get_signals(void);
extern void block_signals(void);
extern void unblock_signals(void);
-#define local_save_flags(flags) do { typecheck(unsigned long, flags); \
+#define raw_local_save_flags(flags) do { typecheck(unsigned long, flags); \
(flags) = get_signals(); } while(0)
-#define local_irq_restore(flags) do { typecheck(unsigned long, flags); \
+#define raw_local_irq_restore(flags) do { typecheck(unsigned long, flags); \
set_signals(flags); } while(0)
-#define local_irq_save(flags) do { local_save_flags(flags); \
- local_irq_disable(); } while(0)
+#define raw_local_irq_save(flags) do { raw_local_save_flags(flags); \
+ raw_local_irq_disable(); } while(0)
-#define local_irq_enable() unblock_signals()
-#define local_irq_disable() block_signals()
+#define raw_local_irq_enable() unblock_s
Re: [uml-devel] [PATCH 2/2] ptrace_vm: ptrace for syscall emulation virtual machines
* Renzo Davoli wrote:
> +/* test thread code. This thread is started only to test
> + * which features are provided by the linux kernel */
> +static int sysptvm_child(void *arg)
> +{
> + int *featurep=arg;
> + int p[2]={-1,-1};
> + pid_t pid=os_getpid();
> + if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){
> + perror("ptrace test_ptracemulti");
> + kill(pid, SIGKILL);
> + }
> + kill(pid, SIGSTOP);
> + *featurep=0;
> + os_getpid();
> + /* if it reaches this point in 1 stop it means that
> + * PTRACE_SYSCALL_SKIPEXIT works */
> + *featurep=PTRACE_SYSCALL_SKIPEXIT;
> + pipe(p);
> + /* if after a PTRACE_SYSCALL_SKIPCALL p[0] is already <0
> + * pipe has been really skipped */
> + if (p[0] < 0)
> + *featurep=PTRACE_SYSCALL_SKIPCALL;
> + else { /* clean up everything */
> + close(p[0]);
> + close(p[1]);
> + }
> + return 0;
Please check Documentation/CodingStyle. Every second line above
violates it. scripts/checkpatch.pl can help out with the more
obvious ones.
Ingo
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] fix uml slowness caused by ptrace preemption bug on host
* Miklos Szeredi wrote: > On Fri, 20 Mar 2009, Peter Zijlstra wrote: > > On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote: > > > > > > This patch solves this by not scheduling on preempt_enable() after > > > ptrace_stop() has woken up the tracer. > > > > Nice,.. however did you find this? > > Ftrace helped a lot, it's a really cool tool :). I had to patch it > with this, otherwise the timestamps would be totally off: > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c > index bd38c5c..557c2dd 100644 > --- a/kernel/trace/ring_buffer.c > +++ b/kernel/trace/ring_buffer.c > @@ -108,7 +108,7 @@ u64 ring_buffer_time_stamp(int cpu) > > preempt_disable_notrace(); > /* shift to debug/test normalization and TIME_EXTENTS */ > - time = sched_clock() << DEBUG_SHIFT; > + time = cpu_clock(cpu) << DEBUG_SHIFT; > preempt_enable_no_resched_notrace(); Btw., based on your earlier report, the same is now possible in the latest tracing tree via: echo 1 > /debug/tracing/options/global_clock Ingo -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] don't preempt not TASK_RUNNING tasks
* Miklos Szeredi wrote: > On Fri, 20 Mar 2009, Peter Zijlstra wrote: > > On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote: > > > Ingo, > > > > > > I tested this one, and I think it makes sense in any case as an > > > optimization. It should also be good for -stable kernels. > > > > > > Does it look OK? > > > > The idea is good, but there is a risk of preemption latencies here. Some > > code paths aren't real quick between setting ->state != TASK_RUNNING and > > calling schedule. > > > > [ Both quick: as in O(1) and few instructions ] > > > > So if we're going to do this, we'd need to audit all such code paths -- > > and there be lots. > > Oh, yes. > > In a random sample the most common pattern is something like this: > > spin_lock(&some_lock); > /* do something */ > set_task_state(TASK_SOMESLEEP); > /* do something more */ > spin_unlock(&some_lock); > schedule(); > ... > > Which should only positively be impacted by the change. But I can > imagine rare cases where it's more complex. I'd suggest spin_unlock_no_resched() and task_unlock_no_resched() instead of open-coding preempt-disable sequences. > > The first line of attack for this problem is making > > wait_task_inactive() sucks less, which shouldn't be too hard, > > that unconditional 1 jiffy sleep is simply retarded. > > I completely agree. However, I'd like to have a non-invasive > solution that can go into current and stable kernels so UML users > don't need to suffer any more. Agreed. task_unlock_no_resched() should do that i think. Ingo -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] don't preempt not TASK_RUNNING tasks
* Miklos Szeredi wrote: > On Fri, 20 Mar 2009, Ingo Molnar wrote: > > > > The first line of attack for this problem is making > > > > wait_task_inactive() sucks less, which shouldn't be too hard, > > > > that unconditional 1 jiffy sleep is simply retarded. > > > > > > I completely agree. However, I'd like to have a non-invasive > > > solution that can go into current and stable kernels so UML users > > > don't need to suffer any more. > > > > Agreed. task_unlock_no_resched() should do that i think. > > I don't see how that would help. it more clearly expresses the need there, and we already have _no_resched API variants (we add them on an as-needed basis). Doing: preempt_disable(); read_lock(); ... read_unlock(); preempt_enable_no_resched(); Really just open-codes read_unlock_no_resched() and uglifies the code. > ptrace_stop() specifically would need read_unlock_no_resched(). > But I'm reluctant to add more spinlock functions with all their > variants... if you worry about backportability, we can certainly add the easy fix too, if it's followed by the more involved fix(es). Ingo -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] fix ptrace slowness
* Miklos Szeredi wrote:
> This one incorporates comments from Oleg and Ingo. Please apply
> to 2.6.29 and 2.6.2[78]-stable trees.
The fix first needs to go upstream. There's an alternative patch
below. Would you mind to give it a test? Chances are that it will
make UML even faster than your fix.
Ingo
diff --git a/kernel/sched.c b/kernel/sched.c
index 3e827b8..2d60f23 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2119,7 +2119,8 @@ unsigned long wait_task_inactive(struct task_struct *p,
long match_state)
* yield - it could be a while.
*/
if (unlikely(on_rq)) {
- schedule_timeout_uninterruptible(1);
+ cpu_relax();
+ cond_resched();
continue;
}
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] fix ptrace slowness
* Miklos Szeredi wrote: > On Mon, 23 Mar 2009, Ingo Molnar wrote: > > * Miklos Szeredi wrote: > > > > > This one incorporates comments from Oleg and Ingo. Please apply > > > to 2.6.29 and 2.6.2[78]-stable trees. > > > > The fix first needs to go upstream. There's an alternative patch > > below. Would you mind to give it a test? Chances are that it > > will make UML even faster than your fix. > > Just the opposite. With my patch a UML image boots in 17 > seconnds, with your patch it boots in 33 seconds. Without either > patch it boots in about 5 minutes. okay - i've queued up your fix. Ingo -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [patch] fix ptrace slowness
* Oleg Nesterov wrote:
> On 03/23, Ingo Molnar wrote:
> >
> > There's an alternative patch
> > below. Would you mind to give it a test? Chances are that it will
> > make UML even faster than your fix.
> >
> > Ingo
> >
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 3e827b8..2d60f23 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -2119,7 +2119,8 @@ unsigned long wait_task_inactive(struct task_struct
> > *p, long match_state)
> > * yield - it could be a while.
> > */
> > if (unlikely(on_rq)) {
> > - schedule_timeout_uninterruptible(1);
> > + cpu_relax();
> > + cond_resched();
>
> What if the caller is a realtime task? We can spin "forever", no?
hm, yes. I sure should have noticed _that_ ;-)
Ingo
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)
* H. Peter Anvin wrote: > Borislav, > > We're tracking down an issue with the way system call arguments are > handled on 32 bits. We have a solution for SYSENTER but not > SYSCALL; fixing SYSCALL "properly" appears to be very difficult at > best. > > So the question is: how much overhead would it be to simply fall > back to int $0x80 or some other legacy-style domain crossing > instruction for 32-bit system calls on AMD64 processors? We don't > ever use SYSCALL in legacy mode, so native i386 kernels are > unaffected. Last i measured INT80 and SYSCALL costs they were pretty close to each other on AMD CPUs - closer than on Intel. Also, most installations are either pure 32-bit or dominantly 64-bit, the significantly mixed-mode case is dwindling. Unifying some more in this area would definitely simplify things ... Thanks, Ingo -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
