tree 7419b6244e8278f687b4156a05a7e6855d3bcfce
parent fca1037864a9fb75c9c48cb65649b24de8101ec4
parent 2546287c5fb363a0165933ae2181c92f03e701d0
author Linus Torvalds <torvalds@linux-foundation.org> 1582421146 -0800
committer Linus Torvalds <torvalds@linux-foundation.org> 1582421146 -0800
mergetag object 2546287c5fb363a0165933ae2181c92f03e701d0
 type commit
 tag irq-urgent-2020-02-22
 tagger Thomas Gleixner <tglx@linutronix.de> 1582401515 +0100
 
 Two fixes for the irq core code which are follow ups to the recent MSI
 fixes:
 
  - The WARN_ON which was put into the MSI setaffinity callback for paranoia
    reasons actually triggered via a callchain which escaped when all the
    possible ways to reach that code were analyzed.
 
    The proc/irq/$N/*affinity interfaces have a quirk which came in when
    ALPHA moved to the generic interface: In case that the written affinity
    mask does not contain any online CPU it calls into ALPHAs magic auto
    affinity setting code.
 
    A few years later this mechanism was also made available to x86 for no
    good reasons and in a way which circumvents all sanity checks for
    interrupts which cannot have their affinity set from process context on
    X86 due to the way the X86 interrupt delivery works.
 
    It would be possible to make this work properly, but there is no point
    in doing so. If the interrupt is not yet started then the affinity
    setting has no effect and if it is started already then it is already
    assigned to an online CPU so there is no point to randomly move it to
    some other CPU. Just return EINVAL as the code has done before that
    change forever.
 
  - The new MSI quirk bit in the irq domain flags turned out to be already
    occupied, which escaped the author and the reviewers because the already
    in use bits were 0,6,2,3,4,5 listed in that order. That bit 6 was simply
    overlooked because the ordering was straight forward linear
    otherwise. So the new bit ended up being a duplicate. Fix it up by
    switching the oddball 6 to the obvious 1.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAl5Rh+sTHHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYoQ8gD/0aO/tFJrRLmcSlS5r8r70dtHMHIhcq
 L6bUkg0GKsud6oLVFEhU43K7aWXZkTEqm1bIjX9x0FnMHIYsASmkHyloP/8OBxoA
 VOG6Q1THxklge/YLBLz7I2NbZNKs/w+WkRKl63FNV9LmdtxtQblYc67CkaQVXiwC
 tHuijaKOwT/t4V0+HNRVX15FApiDWOSguwcDNigUwk03Uo+hmJsPXuGtJfvyVAf6
 Oa00sbvy/XV3qNr2Zm01Pb4osL4FOwCcGuyoeXMZqSvlRbxgT2qz0TzYObqKzZb5
 pvZj7coaxKSimNZsVFQ6mluCp9IvFpZOnp1FXcFrzbbFPxEr0G/IMWgVmgf2s3w/
 8XjFCuF33J4mVz36/HYzR2ieH5FsVcGJQR96ZOHArONmszmbun7D7fC3j8RJlkKC
 9QpYDcHK17xbLdhR8YanEIDl5QQT/C/qEOdLWrgON7uWEZLs5Y+u39x479MfknyV
 fYQqi7CC6qUTxQhrt29puaWy8WQvrG4GzWV+vS9d+8v0FIK2KcbA66p/c7UioV3r
 F9PhxfneSYjswvLhAPmJCM4PSYWvrYZcoGkT+/OzmPXcm+r+Tg4Stgac0EVmhvq5
 rBpenELnSuK1MGiFXzL0DKlyNJhpj+UdeAuCoUzConfBMpMwQdvPXpmnT73CQtRb
 pOgBI4qB3YgP4Q==
 =jvVI
 -----END PGP SIGNATURE-----

Merge tag 'irq-urgent-2020-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "Two fixes for the irq core code which are follow ups to the recent MSI
  fixes:

   - The WARN_ON which was put into the MSI setaffinity callback for
     paranoia reasons actually triggered via a callchain which escaped
     when all the possible ways to reach that code were analyzed.

     The proc/irq/$N/*affinity interfaces have a quirk which came in
     when ALPHA moved to the generic interface: In case that the written
     affinity mask does not contain any online CPU it calls into ALPHAs
     magic auto affinity setting code.

     A few years later this mechanism was also made available to x86 for
     no good reasons and in a way which circumvents all sanity checks
     for interrupts which cannot have their affinity set from process
     context on X86 due to the way the X86 interrupt delivery works.

     It would be possible to make this work properly, but there is no
     point in doing so. If the interrupt is not yet started then the
     affinity setting has no effect and if it is started already then it
     is already assigned to an online CPU so there is no point to
     randomly move it to some other CPU. Just return EINVAL as the code
     has done before that change forever.

   - The new MSI quirk bit in the irq domain flags turned out to be
     already occupied, which escaped the author and the reviewers
     because the already in use bits were 0,6,2,3,4,5 listed in that
     order.

     That bit 6 was simply overlooked because the ordering was straight
     forward linear otherwise. So the new bit ended up being a
     duplicate.

     Fix it up by switching the oddball 6 to the obvious 1"

* tag 'irq-urgent-2020-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq/irqdomain: Make sure all irq domain flags are distinct
  genirq/proc: Reject invalid affinity masks (again)