| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20151214120021.GJ1072@fixme-laptop.cn.ibm.com>
Date: Mon, 14 Dec 2015 20:00:35 +0800
From: Boqun Feng <boqun.feng@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-sparse@...r.kernel.org, linux-kernel@...r.kernel.org,
Christopher Li <sparse@...isli.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Andy Whitcroft <apw@...onical.com>,
Joe Perches <joe@...ches.com>,
Jiang Liu <jiang.liu@...ux.intel.com>,
Marc Zyngier <marc.zyngier@....com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Russell King <rmk+kernel@....linux.org.uk>,
Brian Norris <computersforpeace@...il.com>
Subject: Re: [RFC 3/3] irq: Privatize irq_common_data::state_use_accessors
On Mon, Dec 14, 2015 at 11:03:03AM +0100, Thomas Gleixner wrote:
> On Mon, 14 Dec 2015, Peter Zijlstra wrote:
> > On Sat, Dec 12, 2015 at 10:56:02AM +0800, Boqun Feng wrote:
> > > According to Peter Zijlstra, irq_common_data::state_use_accessors is not
> > > designed for public use. Therefore make it private so that people who
> > > write code accessing it directly will get blamed by sparse.
> > >
> > > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> > > ---
> > > include/linux/irq.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/linux/irq.h b/include/linux/irq.h
> > > index 3c1c967..0b8f273 100644
> > > --- a/include/linux/irq.h
> > > +++ b/include/linux/irq.h
> > > @@ -137,7 +137,7 @@ struct irq_domain;
> > > * @msi_desc: MSI descriptor
> > > */
> > > struct irq_common_data {
> > > - unsigned int state_use_accessors;
> > > + unsigned int __private state_use_accessors;
> > > #ifdef CONFIG_NUMA
> > > unsigned int node;
> > > #endif
> > > @@ -208,7 +208,7 @@ enum {
> > > IRQD_FORWARDED_TO_VCPU = (1 << 20),
> > > };
> > >
> > > -#define __irqd_to_state(d) ((d)->common->state_use_accessors)
> > > +#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
> > >
> > > static inline bool irqd_is_setaffinity_pending(struct irq_data *d)
> > > {
> >
> > We should probably #undef that one once we're done with it.. Thomas?
>
> Probably.
>
Probably something like this(untested, only run "make kernel/irq/")?
Subject: [RFC v2 3/3] irq: Privatize irq_common_data::state_use_accessors
According to Peter Zijlstra, irq_common_data::state_use_accessors is not
designed for public use. Therefore make it private so that people who
write code accessing it directly will get blamed by sparse.
Also macro __irqd_to_state() is for _designed_ accesses to irq_data's
state only, it's better to limit its scope, therefore put all its
callers together and #undef it after use.
Signed-off-by: Boqun Feng <boqun.feng@...il.com>
---
v1-->v2:
* move all callers of __irqd_to_state() together so that we can
#undef it after use.
include/linux/irq.h | 35 +++++++++++++++++++++++++++++++++--
kernel/irq/internals.h | 28 ----------------------------
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 3c1c967..9b20df6 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -137,7 +137,7 @@ struct irq_domain;
* @msi_desc: MSI descriptor
*/
struct irq_common_data {
- unsigned int state_use_accessors;
+ unsigned int __private state_use_accessors;
#ifdef CONFIG_NUMA
unsigned int node;
#endif
@@ -208,7 +208,11 @@ enum {
IRQD_FORWARDED_TO_VCPU = (1 << 20),
};
-#define __irqd_to_state(d) ((d)->common->state_use_accessors)
+#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
+
+/*
+ * Manipulation functions for irq_data's state
+ */
static inline bool irqd_is_setaffinity_pending(struct irq_data *d)
{
@@ -299,6 +303,33 @@ static inline void irqd_clr_forwarded_to_vcpu(struct irq_data *d)
__irqd_to_state(d) &= ~IRQD_FORWARDED_TO_VCPU;
}
+static inline void irqd_set_move_pending(struct irq_data *d)
+{
+ __irqd_to_state(d) |= IRQD_SETAFFINITY_PENDING;
+}
+
+static inline void irqd_clr_move_pending(struct irq_data *d)
+{
+ __irqd_to_state(d) &= ~IRQD_SETAFFINITY_PENDING;
+}
+
+static inline void irqd_clear(struct irq_data *d, unsigned int mask)
+{
+ __irqd_to_state(d) &= ~mask;
+}
+
+static inline void irqd_set(struct irq_data *d, unsigned int mask)
+{
+ __irqd_to_state(d) |= mask;
+}
+
+static inline bool irqd_has_set(struct irq_data *d, unsigned int mask)
+{
+ return __irqd_to_state(d) & mask;
+}
+
+#undef __irqd_to_state
+
static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
{
return d->hwirq;
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index fcab63c..307fff8 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -160,34 +160,6 @@ irq_put_desc_unlock(struct irq_desc *desc, unsigned long flags)
__irq_put_desc_unlock(desc, flags, false);
}
-/*
- * Manipulation functions for irq_data.state
- */
-static inline void irqd_set_move_pending(struct irq_data *d)
-{
- __irqd_to_state(d) |= IRQD_SETAFFINITY_PENDING;
-}
-
-static inline void irqd_clr_move_pending(struct irq_data *d)
-{
- __irqd_to_state(d) &= ~IRQD_SETAFFINITY_PENDING;
-}
-
-static inline void irqd_clear(struct irq_data *d, unsigned int mask)
-{
- __irqd_to_state(d) &= ~mask;
-}
-
-static inline void irqd_set(struct irq_data *d, unsigned int mask)
-{
- __irqd_to_state(d) |= mask;
-}
-
-static inline bool irqd_has_set(struct irq_data *d, unsigned int mask)
-{
- return __irqd_to_state(d) & mask;
-}
-
static inline void kstat_incr_irqs_this_cpu(struct irq_desc *desc)
{
__this_cpu_inc(*desc->kstat_irqs);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists