25 May, 2012

1 commit

  • All invocations of chip->irq_set_affinity() are doing the same return
    value checks. Let them all use a common function.

    [ tglx: removed the silly likely while at it ]

    Signed-off-by: Jiang Liu
    Cc: Jiang Liu
    Cc: Keping Chen
    Link: http://lkml.kernel.org/r/1333120296-13563-3-git-send-email-jiang.liu@huawei.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

31 Mar, 2012

1 commit

  • irq_move_masked_irq() checks the return code of
    chip->irq_set_affinity() only for 0, but IRQ_SET_MASK_OK_NOCOPY is
    also a valid return code, which is there to avoid a redundant copy of
    the cpumask. But in case of IRQ_SET_MASK_OK_NOCOPY we not only avoid
    the redundant copy, we also fail to adjust the thread affinity of an
    eventually threaded interrupt handler.

    Handle IRQ_SET_MASK_OK (==0) and IRQ_SET_MASK_OK_NOCOPY(==1) return
    values correctly by checking the valid return values seperately.

    Signed-off-by: Jiang Liu
    Cc: Jiang Liu
    Cc: Keping Chen
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1333120296-13563-2-git-send-email-jiang.liu@huawei.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

31 Mar, 2011

1 commit


29 Mar, 2011

2 commits


28 Mar, 2011

1 commit


19 Feb, 2011

6 commits


03 Feb, 2011

1 commit

  • move_native_irq() masks and unmasks the interrupt line
    unconditionally, but the interrupt line might be masked due to a
    threaded oneshot handler in progress. Unmasking the line in that case
    can lead to interrupt storms. Observed on PREEMPT_RT.

    Originally-from: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Cc: stable@kernel.org

    Thomas Gleixner
     

04 Oct, 2010

4 commits


15 Dec, 2009

1 commit


21 Jul, 2009

1 commit

  • irq_set_thread_affinity() calls set_cpus_allowed_ptr() which might
    sleep, but irq_set_thread_affinity() is called with desc->lock held
    and can be called from hard interrupt context as well. The code has
    another bug as it does not hold a ref on the task struct as required
    by set_cpus_allowed_ptr().

    Just set the IRQTF_AFFINITY bit in action->thread_flags. The next time
    the thread runs it migrates itself. Solves all of the above problems
    nicely.

    Add kerneldoc to irq_set_thread_affinity() while at it.

    Signed-off-by: Thomas Gleixner
    LKML-Reference:

    Thomas Gleixner
     

28 Apr, 2009

1 commit

  • irq_set_affinity() and move_masked_irq() try to assign affinity
    before calling chip set_affinity(). Some archs are assigning it
    in ->set_affinity() again.

    We do something like:

    cpumask_cpy(desc->affinity, mask);
    desc->chip->set_affinity(mask);

    But in the failure path, affinity should not be touched - otherwise
    we'll end up with a different affinity mask despite the failure to
    migrate the IRQ.

    So try to update the afffinity only if set_affinity returns with 0.
    Also call irq_set_thread_affinity accordingly.

    v2: update after "irq, x86: Remove IRQ_DISABLED check in process context IRQ move"
    v3: according to Ingo, change set_affinity() in irq_chip should return int.
    v4: update comments by removing moving irq_desc code.

    [ Impact: fix /proc/irq/*/smp_affinity setting corner case bug ]

    Signed-off-by: Yinghai Lu
    Cc: Andrew Morton
    Cc: Suresh Siddha
    Cc: "Eric W. Biederman"
    Cc: Rusty Russell
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

12 Jan, 2009

1 commit

  • Impact: reduce memory usage, use new cpumask API.

    Replace the affinity and pending_masks with cpumask_var_t's. This adds
    to the significant size reduction done with the SPARSE_IRQS changes.

    The added functions (init_alloc_desc_masks & init_copy_desc_masks) are
    in the include file so they can be inlined (and optimized out for the
    !CONFIG_CPUMASKS_OFFSTACK case.) [Naming chosen to be consistent with
    the other init*irq functions, as well as the backwards arg declaration
    of "from, to" instead of the more common "to, from" standard.]

    Includes a slight change to the declaration of struct irq_desc to embed
    the pending_mask within ifdef(CONFIG_SMP) to be consistent with other
    references, and some small changes to Xen.

    Tested: sparse/non-sparse/cpumask_offstack/non-cpumask_offstack/nonuma/nosmp on x86_64

    Signed-off-by: Mike Travis
    Cc: Chris Wright
    Cc: Jeremy Fitzhardinge
    Cc: KOSAKI Motohiro
    Cc: Venkatesh Pallipadi
    Cc: virtualization@lists.osdl.org
    Cc: xen-devel@lists.xensource.com
    Cc: Yinghai Lu

    Mike Travis
     

13 Dec, 2008

1 commit

  • Impact: change existing irq_chip API

    Not much point with gentle transition here: the struct irq_chip's
    setaffinity method signature needs to change.

    Fortunately, not widely used code, but hits a few architectures.

    Note: In irq_select_affinity() I save a temporary in by mangling
    irq_desc[irq].affinity directly. Ingo, does this break anything?

    (Folded in fix from KOSAKI Motohiro)

    Signed-off-by: Rusty Russell
    Signed-off-by: Mike Travis
    Reviewed-by: Grant Grundler
    Acked-by: Ingo Molnar
    Cc: ralf@linux-mips.org
    Cc: grundler@parisc-linux.org
    Cc: jeremy@xensource.com
    Cc: KOSAKI Motohiro

    Rusty Russell
     

10 Nov, 2008

1 commit

  • Impact: preserve user-modified affinities on interrupts

    Kumar Galak noticed that commit
    18404756765c713a0be4eb1082920c04822ce588 (genirq: Expose default irq
    affinity mask (take 3))

    overrides an already set affinity setting across a free /
    request_irq(). Happens e.g. with ifdown/ifup of a network device.

    Change the logic to mark the affinities as set and keep them
    intact. This also fixes the unlocked access to irq_desc in
    irq_select_affinity() when called from irq_affinity_proc_write()

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

16 Oct, 2008

1 commit

  • add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
    Get rid of irq_desc[] array assumptions.

    Preallocate 32 irq_desc, and irq_desc() will try to get more.

    ( No change in functionality is expected anywhere, except the odd build
    failure where we missed a code site or where a crossing commit itroduces
    new irq_desc[] usage. )

    v2: according to Eric, change get_irq_desc() to irq_desc()

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

27 Feb, 2007

1 commit

  • move_native_irqs tries to do the right thing when migrating irqs
    by disabling them. However disabling them is a software logical
    thing, not a hardware thing. This has always been a little flaky
    and after Ingo's latest round of changes it is guaranteed to not
    mask the apic.

    So this patch fixes move_native_irq to directly call the mask and
    unmask chip methods to guarantee that we mask the irq when we
    are migrating it. We must do this as it is required by
    all code that call into the path.

    Since we don't know the masked status when IRQ_DISABLED is
    set so we will not be able to restore it. The patch makes the code
    just give up and trying again the next time this routing is called.

    Signed-off-by: Eric W. Biederman
    Acked-by: Suresh Siddha
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

04 Oct, 2006

2 commits

  • Currently move_native_irq disables and renables the irq we are migrating to
    ensure we don't take that irq when we are actually doing the migration
    operation. Disabling the irq needs to happen but sometimes doing the work is
    move_native_irq is too late.

    On x86 with ioapics the irq move sequences needs to be:
    edge_triggered:
    mask irq.
    move irq.
    unmask irq.
    ack irq.
    level_triggered:
    mask irq.
    ack irq.
    move irq.
    unmask irq.

    We can easily perform the edge triggered sequence, with the current defintion
    of move_native_irq. However the level triggered case does not map well. For
    that I have added move_masked_irq, to allow me to disable the irqs around both
    the ack and the move.

    Q: Why have we not seen this problem earlier?

    A: The only symptom I have been able to reproduce is that if we change
    the vector before acknowleding an irq the wrong irq is acknowledged.
    Since we currently are not reprogramming the irq vector during
    migration no problems show up.

    We have to mask the irq before we acknowledge the irq or else we could
    hit a window where an irq is asserted just before we acknowledge it.

    Edge triggered irqs do not have this problem because acknowledgements
    do not propogate in the same way.

    Signed-off-by: Eric W. Biederman
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Benjamin Herrenschmidt
    Cc: Rajesh Shah
    Cc: Andi Kleen
    Cc: "Protasevich, Natalie"
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • The primary aim of this patchset is to remove maintenances problems caused by
    the irq infrastructure. The two big issues I address are an artificially
    small cap on the number of irqs, and that MSI assumes vector == irq. My
    primary focus is on x86_64 but I have touched other architectures where
    necessary to keep them from breaking.

    - To increase the number of irqs I modify the code to look at the (cpu,
    vector) pair instead of just looking at the vector.

    With a large number of irqs available systems with a large irq count no
    longer need to compress their irq numbers to fit. Removing a lot of brittle
    special cases.

    For acpi guys the result is that irq == gsi.

    - Addressing the fact that MSI assumes irq == vector takes a few more
    patches. But suffice it to say when I am done none of the generic irq code
    even knows what a vector is.

    In quick testing on a large Unisys x86_64 machine we stumbled over at least
    one driver that assumed that NR_IRQS could always fit into an 8 bit number.
    This driver is clearly buggy today. But this has become a class of bugs that
    it is now much easier to hit.

    This patch:

    This is a minor space optimization. In practice I don't think this has any
    affect because of our alignment constraints and the other fields but there is
    not point in chewing up an uncessary word and since we already read the flag
    field this should improve the cache hit ratio of the irq handler.

    Signed-off-by: Eric W. Biederman
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Benjamin Herrenschmidt
    Cc: Rajesh Shah
    Cc: Andi Kleen
    Cc: "Protasevich, Natalie"
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

30 Jun, 2006

4 commits

  • Consolidation: remove the pending_irq_cpumask[NR_IRQS] array and move it into
    the irq_desc[NR_IRQS].pending_mask field.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • Cleanup: remove irq_desc_t use from the generic IRQ code, and mark it
    obsolete.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • Cleanup: remove irq_descp() - explicit use of irq_desc[] is shorter and more
    readable.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • This patch-queue improves the generic IRQ layer to be truly generic, by adding
    various abstractions and features to it, without impacting existing
    functionality.

    While the queue can be best described as "fix and improve everything in the
    generic IRQ layer that we could think of", and thus it consists of many
    smaller features and lots of cleanups, the one feature that stands out most is
    the new 'irq chip' abstraction.

    The irq-chip abstraction is about describing and coding and IRQ controller
    driver by mapping its raw hardware capabilities [and quirks, if needed] in a
    straightforward way, without having to think about "IRQ flow"
    (level/edge/etc.) type of details.

    This stands in contrast with the current 'irq-type' model of genirq
    architectures, which 'mixes' raw hardware capabilities with 'flow' details.
    The patchset supports both types of irq controller designs at once, and
    converts i386 and x86_64 to the new irq-chip design.

    As a bonus side-effect of the irq-chip approach, chained interrupt controllers
    (master/slave PIC constructs, etc.) are now supported by design as well.

    The end result of this patchset intends to be simpler architecture-level code
    and more consolidation between architectures.

    We reused many bits of code and many concepts from Russell King's ARM IRQ
    layer, the merging of which was one of the motivations for this patchset.

    This patch:

    rename desc->handler to desc->chip.

    Originally i did not want to do this, because it's a big patch. But having
    both "desc->handler", "desc->handle_irq" and "action->handler" caused a
    large degree of confusion and made the code appear alot less clean than it
    truly is.

    I have also attempted a dual approach as well by introducing a
    desc->chip alias - but that just wasnt robust enough and broke
    frequently.

    So lets get over with this quickly. The conversion was done automatically
    via scripts and converts all the code in the kernel.

    This renaming patch is the first one amongst the patches, so that the
    remaining patches can stay flexible and can be merged and split up
    without having some big monolithic patch act as a merge barrier.

    [akpm@osdl.org: build fix]
    [akpm@osdl.org: another build fix]
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

23 Jun, 2006

1 commit

  • If you get to that point in the code it means that desc->move_irq is set,
    pending_irq_cpumask[irq] and cpu_online_map should have a value. Still
    pretty good chance anding those two you'll still have a value. So these
    two branch predictors should be inverted.

    Signed-off-by: Daniel Walker
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Walker
     

11 Apr, 2006

1 commit


26 Mar, 2006

2 commits

  • This fix prevents re-disabling and enabling of a previously disabled
    interrupt. On an SMP system with irq balancing enabled; If an interrupt is
    disabled from within its own interrupt context with disable_irq_nosync and is
    also earmarked for processor migration, the interrupt is blindly moved to the
    other processor and enabled without regard for its current "enabled" state.
    If there is an interrupt pending, it will unexpectedly invoke the irq handler
    on the new irq owning processor (even though the irq was previously disabled)

    The more intuitive fix would be to invoke disable_irq_nosync and
    enable_irq, but since we already have the desc->lock from __do_IRQ, we
    cannot call them directly. Instead we can use the same logic to disable
    and enable found in disable_irq_nosync and enable_irq, with regards to the
    desc->depth.

    This now prevents a disabled interrupt from being re-disabled, and more
    importantly prevents a disabled interrupt from being incorrectly enabled on
    a different processor.

    Signed-off-by: Bryan Holty
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bryan Holty
     
  • Uninline some massive IRQ migration functions. Put them in the new
    kernel/irq/migration.c.

    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton