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.