[PATCH] [1/20] x86: Make ptrace.h safe to include from assembler code - Kernel

This is a discussion on [PATCH] [1/20] x86: Make ptrace.h safe to include from assembler code - Kernel ; > > And printing the offset into a mapping also always allows to find the > > correct fault point in a library even with randomized mappings. Previously > > there was no way to actually find the correct code ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: [PATCH] [1/20] x86: Make ptrace.h safe to include from assembler code

  1. Re: [PATCH] [20/20] x86: Print which shared library/executable faulted in segfault etc. messages


    > > And printing the offset into a mapping also always allows to find the
    > > correct fault point in a library even with randomized mappings. Previously
    > > there was no way to actually find the correct code address inside
    > > the randomized mapping.
    > >
    > > Relies on earlier patch to shorten the printk formats.
    > >
    > > They are often now longer than 80 characters, but I think that's worth
    > > it.

    >
    > why not make it multi-line? that way the %lx hack wouldnt be needed
    > either.


    I prefer it single-line. I also disagree on %lx being a hack.

    >
    > > +void print_vma_addr(char *prefix, unsigned long ip)
    > > +{
    > > + struct mm_struct *mm = current->mm;
    > > + struct vm_area_struct *vma;
    > > + down_read(&mm->mmap_sem);
    > > + vma = find_vma(mm, ip);

    >
    > grumble. Proper CodingStyle please.



    Looks fine to me. If you mean the new line after variables -- that was always optional.

    Anyways I'll repost with the error check.

    Also it seems like you did apply only parts of the patchkit. If you do that can
    you send a list of what patches you didn't add, otherwise it'll be messy to figure
    this out from here.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] [12/20] x86: Use a per cpu timer for correctable machine check checking

    On Thursday 03 January 2008 11:49:56 Ingo Molnar wrote:
    >
    > * Andi Kleen wrote:
    >
    > > Previously the code used a single timer that then used
    > > smp_call_function to interrupt all CPUs while the original CPU was
    > > waiting for them.
    > >
    > > But it is better / more real time and more power friendly to simply
    > > run individual timers on each CPU so they all do this independently.
    > >
    > > This way no single CPU has to wait for all others.

    >
    > i think we should unify this code first and provide it on 32-bit as
    > well.


    That's done in another patch that hasn't been posted yet.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] [19/20] x86: Use shorter addresses in i386 segfault printks

    On Thursday 03 January 2008 11:56:14 Ingo Molnar wrote:
    >
    > * Andi Kleen wrote:
    >
    > > x86: Use shorter addresses in i386 segfault printks

    >
    > hm, why? It's pretty well-established that we print addresses 8 char
    > wide on 32-bit.


    It's useless. What purpose does it have?

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] [16/20] x86: Allow TSC clock source on AMD Fam10h and some cleanup


    * Andi Kleen wrote:

    > After a lot of discussions with AMD it turns out that TSC on Fam10h
    > CPUs is synchronized when the CONSTANT_TSC cpuid bit is set. Or rather
    > that if there are ever systems where that is not true it would be
    > their BIOS' task to disable the bit.
    >
    > So finally use TSC gettimeofday on Fam10h by default.


    thanks, applied.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] [17/20] x86: Remove explicit C3 TSC check on 64bit


    * Andi Kleen wrote:

    > Trust the ACPI code to disable TSC instead when C3 is used.


    thanks, applied.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] [18/20] x86: Don't disable TSC in any C states on AMD Fam10h


    * Andi Kleen wrote:

    > The ACPI code currently disables TSC use in any C2 and C3 states. But
    > the AMD Fam10h BKDG documents that the TSC will never stop in any C
    > states when the CONSTANT_TSC bit is set. Make this disabling
    > conditional on CONSTANT_TSC not set on AMD.
    >
    > I actually think this is true on Intel too for C2 states on CPUs with
    > p-state invariant TSC, but this needs further discussions with Len to
    > really confirm :-)
    >
    > So far it is only enabled on AMD.


    thanks Andi - i've picked this up for x86.git, to get it tested. Len,
    what do you think? If/when you pick it up into the ACPI tree i'll drop
    it from x86.git.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] [5/20] x86: Introduce nsec_barrier() II

    Andi Kleen writes:

    > On Thursday 03 January 2008 11:47:54 Ingo Molnar wrote:
    >>
    >> * Andi Kleen wrote:
    >>
    >> > nsec_barrier() is a new barrier primitive that stops RDTSC speculation
    >> > to avoid races with timer interrupts on other CPUs.
    >> >
    >> > Add it to all architectures. Except for x86 it is a nop right now. I
    >> > only tested x86, but it's a very simple change.
    >> >
    >> > On x86 it expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD
    >> > CPUs) which stops RDTSC on all currently known microarchitectures that
    >> > implement SSE. On CPUs without SSE there is generally no RDTSC
    >> > speculation.

    >>
    >> i've picked up your rdtsc patches into x86.git but have simplified it:
    >> there's no nsec_barrier() anymore - rdtsc() is always synchronous.
    >> MFENCE/LFENCE is fast enough. Open-coding such barriers almost always
    >> leads to needless trouble. Please check the next x86.git tree.

    >
    > That's most likely wrong unless you added two barriers -- the barriers
    > are strictly need to be before and after RDTSC.


    I checked your patch now -- 743abf4d987911af1ffce4c96f06cba6ffaa7e88
    and 428f309ba5244fa25b44fcdf1d79aa94c8745cfd in gitx86 and you did it
    indeed wrong.

    The problem is that you inserted the barrier only after the RDTSC, but
    the instruction can be speculated both forward and backward and both
    can cause inconsistencies if it leaves the critical section.

    The minimal fix would be to change native_read_tsc to

    rdtsc_barrier();
    asm volatile("rdtsc" : EAX_EDX_RET(val, low, high));
    rdtsc_barrier();

    (e.g. add the missing barrier)

    Better would be still to keep the explicit nsec barriers as in
    the original patch for several reasons:
    - There are situations where RDTSC without barrier is ok and it might
    be useful there.
    - It is better to give the CPU some room to run uops in parallel;
    especially in very performance critical like gtod(). A wider
    barriered area is faster.
    - I actually expect that other architectures with aggressive OOO
    implementations (like POWER4/5) should make use of
    nsec_barrier() too. I don't think it's really an x86 specific concept.
    - Explicit barriers can be useful when measuring performance, although
    admittedly there a x86 specific barrier is usually ok. However forcing
    the barrier inside RDTSC is not.

    If you insist to keep the incorrect patch please drop my name from it.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2