All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: [linux-review:UPDATE-20200203-052746/Evan-Green/PCI-MSI-Avoid-torn-updates-to-MSI-pairs/20200118-154252 1/1] arch/x86//kernel/apic/msi.c:164:3: error: expected ')' before 'irq_data_get_irq_chip'
Date: Mon, 03 Feb 2020 08:42:41 +0800	[thread overview]
Message-ID: <202002030838.o7oDBYqR%lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 6111 bytes --]

tree:   https://github.com/0day-ci/linux/commits/UPDATE-20200203-052746/Evan-Green/PCI-MSI-Avoid-torn-updates-to-MSI-pairs/20200118-154252
head:   c1210f04f40e67c847d7fae7678203d3c03826cc
commit: c1210f04f40e67c847d7fae7678203d3c03826cc [1/1] x86/apic/msi: Plug non-maskable MSI affinity race
config: x86_64-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
        git checkout c1210f04f40e67c847d7fae7678203d3c03826cc
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   arch/x86//kernel/apic/msi.c: In function 'msi_set_affinity':
>> arch/x86//kernel/apic/msi.c:164:3: error: expected ')' before 'irq_data_get_irq_chip'
      irq_data_get_irq_chip(irqd)->irq_retrigger(irqd);
      ^~~~~~~~~~~~~~~~~~~~~
>> arch/x86//kernel/apic/msi.c:167:1: error: expected expression before '}' token
    }
    ^
>> arch/x86//kernel/apic/msi.c:167:1: warning: control reaches end of non-void function [-Wreturn-type]
    }
    ^

vim +164 arch/x86//kernel/apic/msi.c

    60	
    61	static int
    62	msi_set_affinity(struct irq_data *irqd, const struct cpumask *mask, bool force)
    63	{
    64		struct irq_cfg old_cfg, *cfg = irqd_cfg(irqd);
    65		struct irq_data *parent = irqd->parent_data;
    66		unsigned int cpu;
    67		int ret;
    68	
    69		/* Save the current configuration */
    70		cpu = cpumask_first(irq_data_get_effective_affinity_mask(irqd));
    71		old_cfg = *cfg;
    72	
    73		/* Allocate a new target vector */
    74		ret = parent->chip->irq_set_affinity(parent, mask, force);
    75		if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
    76			return ret;
    77	
    78		/*
    79		 * For non-maskable and non-remapped MSI interrupts the migration
    80		 * to a different destination CPU and a different vector has to be
    81		 * done careful to handle the possible stray interrupt which can be
    82		 * caused by the non-atomic update of the address/data pair.
    83		 *
    84		 * Direct update is possible when:
    85		 * - The MSI is maskable (remapped MSI does not use this code path)).
    86		 *   The quirk bit is not set in this case.
    87		 * - The new vector is the same as the old vector
    88		 * - The old vector is MANAGED_IRQ_SHUTDOWN_VECTOR (interrupt starts up)
    89		 * - The new destination CPU is the same as the old destination CPU
    90		 */
    91		if (!irqd_msi_nomask_quirk(irqd) ||
    92		    cfg->vector == old_cfg.vector ||
    93		    old_cfg.vector == MANAGED_IRQ_SHUTDOWN_VECTOR ||
    94		    cfg->dest_apicid == old_cfg.dest_apicid) {
    95			irq_msi_update_msg(irqd, cfg);
    96			return ret;
    97		}
    98	
    99		/*
   100		 * Paranoia: Validate that the interrupt target is the local
   101		 * CPU.
   102		 */
   103		if (WARN_ON_ONCE(cpu != smp_processor_id())) {
   104			irq_msi_update_msg(irqd, cfg);
   105			return ret;
   106		}
   107	
   108		/*
   109		 * Redirect the interrupt to the new vector on the current CPU
   110		 * first. This might cause a spurious interrupt on this vector if
   111		 * the device raises an interrupt right between this update and the
   112		 * update to the final destination CPU.
   113		 *
   114		 * If the vector is in use then the installed device handler will
   115		 * denote it as spurious which is no harm as this is a rare event
   116		 * and interrupt handlers have to cope with spurious interrupts
   117		 * anyway. If the vector is unused, then it is marked so it won't
   118		 * trigger the 'No irq handler for vector' warning in do_IRQ().
   119		 *
   120		 * This requires to hold vector lock to prevent concurrent updates to
   121		 * the affected vector.
   122		 */
   123		lock_vector_lock();
   124	
   125		/*
   126		 * Mark the new target vector on the local CPU if it is currently
   127		 * unused. Reuse the VECTOR_RETRIGGERED state which is also used in
   128		 * the CPU hotplug path for a similar purpose. This cannot be
   129		 * undone here as the current CPU has interrupts disabled and
   130		 * cannot handle the interrupt before the whole set_affinity()
   131		 * section is done. In the CPU unplug case, the current CPU is
   132		 * about to vanish and will not handle any interrupts anymore. The
   133		 * vector is cleaned up when the CPU comes online again.
   134		 */
   135		if (IS_ERR_OR_NULL(this_cpu_read(vector_irq[cfg->vector])))
   136			this_cpu_write(vector_irq[cfg->vector], VECTOR_RETRIGGERED);
   137	
   138		/* Redirect it to the new vector on the local CPU temporarily */
   139		old_cfg.vector = cfg->vector;
   140		irq_msi_update_msg(irqd, &old_cfg);
   141	
   142		/* Now transition it to the target CPU */
   143		irq_msi_update_msg(irqd, cfg);
   144	
   145		/*
   146		 * All interrupts after this point are now targeted at the new
   147		 * vector/CPU.
   148		 *
   149		 * Drop vector lock before testing whether the temporary assignment
   150		 * to the local CPU was hit by an interrupt raised in the device,
   151		 * because the retrigger function acquires vector lock again.
   152		 */
   153		unlock_vector_lock();
   154	
   155		/*
   156		 * Check whether the transition raced with a device interrupt and
   157		 * is pending in the local APICs IRR. It is safe to do this outside
   158		 * of vector lock as the irq_desc::lock of this interrupt is still
   159		 * held and interrupts are disabled: The check is not accessing the
   160		 * underlying vector store. It's just checking the local APIC's
   161		 * IRR.
   162		 */
   163		if (lapic_vector_set_in_irr(cfg->vector)
 > 164			irq_data_get_irq_chip(irqd)->irq_retrigger(irqd);
   165	
   166		return ret;
 > 167	}
   168	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 28860 bytes --]

                 reply	other threads:[~2020-02-03  0:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202002030838.o7oDBYqR%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.