Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
Tejun Heo wrote:
> Hello,
>
> On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote:
> > > Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag?
> > > The user is running cgrulesengd process in order to utilize cpuset cgroup.
> > > Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process
> > > writes someone's pid to /cgroup/cpuset/$group/tasks interface.
> > >
> > > cpuset_update_task_spread_flag() is updating other thread's
> > > "struct task_struct"->flags without exclusion control or atomic
> > > operations!
> > >
> > > -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c --
> > > 300:/*
> > > 301: * update task's spread flag if cpuset's page/slab spread flag is set
> > > 302: *
> > > 303: * Called with callback_mutex/cgroup_mutex held
> > > 304: */
> > > 305:static void cpuset_update_task_spread_flag(struct cpuset *cs,
> > > 306:struct task_struct *tsk)
> > > 307:{
> > > 308:if (is_spread_page(cs))
> > > 309:tsk->flags |= PF_SPREAD_PAGE;
> > > 310:else
> > > 311:tsk->flags &= ~PF_SPREAD_PAGE;
> > > 312:if (is_spread_slab(cs))
> > > 313:tsk->flags |= PF_SPREAD_SLAB;
> > > 314:else
> > > 315:tsk->flags &= ~PF_SPREAD_SLAB;
> > > 316:}
> >
> > We should make the updating of this flag atomic.
>
> Ugh, why do we even implement that in cpuset. This should be handled
> by MPOL_INTERLEAVE. It feels like people have been using cpuset as
> the dumpsite that people used w/o thinking much. Going forward, let's
> please confine cpuset to collective cpu and memory affinity
> configuration. It really shouldn't be implementing novel features for
> scheduler or mm.
>
> Anyways, yeah, the patch looks correct to me. Can you please send a
> version w/ proper description and sob?
>
This race condition exists since commit 950592f7b991 ("cpusets: update
tasks' page/slab spread flags in time") (i.e. Linux 2.6.31 and later)
but "struct task_struct"->atomic_flags was added in Linux 3.17.
If use of ->atomic_flags for cpuset is acceptable, how should we fix
older kernels? Backport ->atomic_flags?
> Thanks.
>
> --
> tejun
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] sched: Delete rq::skip_clock_update == -1
On Sat, 2014-09-20 at 21:01 +0200, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 08:51:46PM +0400, Kirill Tkhai wrote: > > From: Kirill Tkhai > > > > Idle class task is always queued, so we can safely remove "-1" case here. > > Tag you're it :-) > > https://lkml.org/lkml/2014/4/8/295 Maybe it should be given the too annoying to live treatment. Saving fastpath cycles is great, corner cases less so. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] f2fs: fix roll-forward missing scenarios
On Sun, Sep 21, 2014 at 07:22:32AM +0800, Huang Ying wrote:
> On Sat, 2014-09-20 at 09:23 -0700, Jaegeuk Kim wrote:
> > On Thu, Sep 18, 2014 at 09:04:11PM +0800, huang ying wrote:
> > > On Thu, Sep 18, 2014 at 1:51 PM, Jaegeuk Kim wrote:
> > >
> > > > We can summarize the roll forward recovery scenarios as follows.
> > > >
> > > > [Term] F: fsync_mark, D: dentry_mark
> > > >
> > > > 1. inode(x) | CP | inode(x) | dnode(F)
> > > > -> Update the latest inode(x).
> > > >
> > > > 2. inode(x) | CP | inode(F) | dnode(F)
> > > > -> No problem.
> > > >
> > > > 3. inode(x) | CP | dnode(F) | inode(x)
> > > > -> Recover to the latest dnode(F), and drop the last inode(x)
> > > >
> > > > 4. inode(x) | CP | dnode(F) | inode(F)
> > > > -> No problem.
> > > >
> > > > 5. CP | inode(x) | dnode(F)
> > > > -> The inode(DF) was missing. Should drop this dnode(F).
> > > >
> > > > 6. CP | inode(DF) | dnode(F)
> > > > -> No problem.
> > > >
> > > > 7. CP | dnode(F) | inode(DF)
> > > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > > >
> > > > 8. CP | dnode(F) | inode(x)
> > > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > > >But it will fail due to no inode(DF).
> > > >
> > > > So, this patch adds some missing points such as #1, #5, #7, and #8.
> > > >
> > > > Signed-off-by: Huang Ying
> > > > Signed-off-by: Jaegeuk Kim
> > > > ---
> > > > fs/f2fs/recovery.c | 71
> > > > +-
> > > > 1 file changed, 60 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > > > index 36d4f73..a4eb978 100644
> > > > --- a/fs/f2fs/recovery.c
> > > > +++ b/fs/f2fs/recovery.c
> > > > @@ -14,6 +14,37 @@
> > > > #include "node.h"
> > > > #include "segment.h"
> > > >
> > > > +/*
> > > > + * Roll forward recovery scenarios.
> > > > + *
> > > > + * [Term] F: fsync_mark, D: dentry_mark
> > > > + *
> > > > + * 1. inode(x) | CP | inode(x) | dnode(F)
> > > > + * -> Update the latest inode(x).
> > > > + *
> > > > + * 2. inode(x) | CP | inode(F) | dnode(F)
> > > > + * -> No problem.
> > > > + *
> > > > + * 3. inode(x) | CP | dnode(F) | inode(x)
> > > > + * -> Recover to the latest dnode(F), and drop the last inode(x)
> > > > + *
> > > > + * 4. inode(x) | CP | dnode(F) | inode(F)
> > > > + * -> No problem.
> > > > + *
> > > > + * 5. CP | inode(x) | dnode(F)
> > > > + * -> The inode(DF) was missing. Should drop this dnode(F).
> > > > + *
> > > > + * 6. CP | inode(DF) | dnode(F)
> > > > + * -> No problem.
> > > > + *
> > > > + * 7. CP | dnode(F) | inode(DF)
> > > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > + *
> > > > + * 8. CP | dnode(F) | inode(x)
> > > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > + *But it will fail due to no inode(DF).
> > > > + */
> > > > +
> > > > static struct kmem_cache *fsync_entry_slab;
> > > >
> > > > bool space_for_roll_forward(struct f2fs_sb_info *sbi)
> > > > @@ -110,27 +141,32 @@ out:
> > > > return err;
> > > > }
> > > >
> > > > -static int recover_inode(struct inode *inode, struct page *node_page)
> > > > +static void __recover_inode(struct inode *inode, struct page *page)
> > > > {
> > > > - struct f2fs_inode *raw_inode = F2FS_INODE(node_page);
> > > > + struct f2fs_inode *raw = F2FS_INODE(page);
> > > > +
> > > > + inode->i_mode = le16_to_cpu(raw->i_mode);
> > > > + i_size_write(inode, le64_to_cpu(raw->i_size));
> > > > + inode->i_atime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > > + inode->i_ctime.tv_sec = le64_to_cpu(raw->i_ctime);
> > > > + inode->i_mtime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > > + inode->i_atime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > > + inode->i_ctime.tv_nsec = le32_to_cpu(raw->i_ctime_nsec);
> > > > + inode->i_mtime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > > +}
> > > >
> > > > +static int recover_inode(struct inode *inode, struct page *node_page)
> > > > +{
> > > > if (!IS_INODE(node_page))
> > > > return 0;
> > > >
> > > > - inode->i_mode = le16_to_cpu(raw_inode->i_mode);
> > > > - i_size_write(inode, le64_to_cpu(raw_inode->i_size));
> > > > - inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > > - inode->i_ctime.tv_sec = le64_to_cpu(raw_inode->i_ctime);
> > > > - inode->i_mtime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > > - inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > > - inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
> > > > - inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > > + __recover_inode(inode, node_page);
> > > >
> > > > if (is_dent_dnode(node_page))
> > > > return recover_dentry(node_page, inode);
> > > >
> > > > f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x,
> > > > name
> > > > = %s",
> > > > -
[PATCH 2/3] cap1106: support for active-high interrupt option
Some applications need to use the active-high push-pull interrupt
option. This allows it be enabled in the device tree child node.
Signed-off-by: Matt Ranostay
---
drivers/input/keyboard/cap1106.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
index b9c43b5..33e2590 100644
--- a/drivers/input/keyboard/cap1106.c
+++ b/drivers/input/keyboard/cap1106.c
@@ -234,6 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
+ if (of_property_read_bool(node, "microchip,active-high")) {
+ error = regmap_write(priv->regmap, CAP1106_REG_CONFIG2, 0);
+ if (error)
+ return error;
+ }
+
/* Provide some useful defaults */
for (i = 0; i < priv->num_channels; i++)
priv->keycodes[i] = KEY_A + i;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cap1106: Add support for various cap11xx devices
Several other variants of the cap11xx device exists with a varying
number of capacitance detection channels. Add support for creating
the channels dynamically.
Signed-off-by: Matt Ranostay
---
drivers/input/keyboard/cap1106.c | 54 +++-
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
index d70b65a..b9c43b5 100644
--- a/drivers/input/keyboard/cap1106.c
+++ b/drivers/input/keyboard/cap1106.c
@@ -55,8 +55,6 @@
#define CAP1106_REG_MANUFACTURER_ID0xfe
#define CAP1106_REG_REVISION 0xff
-#define CAP1106_NUM_CHN 6
-#define CAP1106_PRODUCT_ID 0x55
#define CAP1106_MANUFACTURER_ID0x5d
struct cap1106_priv {
@@ -64,7 +62,8 @@ struct cap1106_priv {
struct input_dev *idev;
/* config */
- unsigned short keycodes[CAP1106_NUM_CHN];
+ u32 *keycodes;
+ unsigned int num_channels;
};
static const struct reg_default cap1106_reg_defaults[] = {
@@ -151,7 +150,7 @@ static irqreturn_t cap1106_thread_func(int irq_num, void
*data)
if (ret < 0)
goto out;
- for (i = 0; i < CAP1106_NUM_CHN; i++)
+ for (i = 0; i < priv->num_channels; i++)
input_report_key(priv->idev, priv->keycodes[i],
status & (1 << i));
@@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client
*i2c_client,
struct cap1106_priv *priv;
struct device_node *node;
int i, error, irq, gain = 0;
- unsigned int val, rev;
- u32 gain32, keycodes[CAP1106_NUM_CHN];
+ unsigned int val, prod, rev;
+ u32 gain32;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ priv->num_channels = (unsigned long) id->driver_data;
+ priv->keycodes = devm_kzalloc(dev,
+ sizeof(u32) * priv->num_channels, GFP_KERNEL);
+ if (!priv->keycodes)
+ return -ENOMEM;
+
priv->regmap = devm_regmap_init_i2c(i2c_client, _regmap_config);
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
- error = regmap_read(priv->regmap, CAP1106_REG_PRODUCT_ID, );
- if (error)
- return error;
-
- if (val != CAP1106_PRODUCT_ID) {
- dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
- val, CAP1106_PRODUCT_ID);
- return -ENODEV;
- }
-
error = regmap_read(priv->regmap, CAP1106_REG_MANUFACTURER_ID, );
if (error)
return error;
@@ -220,6 +215,10 @@ static int cap1106_i2c_probe(struct i2c_client *i2c_client,
return -ENODEV;
}
+ error = regmap_read(priv->regmap, CAP1106_REG_PRODUCT_ID, );
+ if (error < 0)
+ return error;
+
error = regmap_read(priv->regmap, CAP1106_REG_REVISION, );
if (error < 0)
return error;
@@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client
*i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
- BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
-
/* Provide some useful defaults */
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- keycodes[i] = KEY_A + i;
+ for (i = 0; i < priv->num_channels; i++)
+ priv->keycodes[i] = KEY_A + i;
of_property_read_u32_array(node, "linux,keycodes",
- keycodes, ARRAY_SIZE(keycodes));
-
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- priv->keycodes[i] = keycodes[i];
+ priv->keycodes, priv->num_channels);
error = regmap_update_bits(priv->regmap, CAP1106_REG_MAIN_CONTROL,
CAP1106_REG_MAIN_CONTROL_GAIN_MASK,
@@ -269,17 +263,17 @@ static int cap1106_i2c_probe(struct i2c_client
*i2c_client,
if (of_property_read_bool(node, "autorepeat"))
__set_bit(EV_REP, priv->idev->evbit);
- for (i = 0; i < CAP1106_NUM_CHN; i++)
+ for (i = 0; i < priv->num_channels; i++)
__set_bit(priv->keycodes[i], priv->idev->keybit);
__clear_bit(KEY_RESERVED, priv->idev->keybit);
priv->idev->keycode = priv->keycodes;
priv->idev->keycodesize = sizeof(priv->keycodes[0]);
- priv->idev->keycodemax = ARRAY_SIZE(priv->keycodes);
+ priv->idev->keycodemax = priv->num_channels;
priv->idev->id.vendor = CAP1106_MANUFACTURER_ID;
- priv->idev->id.product = CAP1106_PRODUCT_ID;
+ priv->idev->id.product = prod;
priv->idev->id.version = rev;
priv->idev->open = cap1106_input_open;
@@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client
*i2c_client,
static const struct of_device_id cap1106_dt_ids[] = {
{ .compatible =
[PATCH 3/3] dt: cap1106 active-high property addition
Documenting the microchip,active-high property for interrupt pin behavior. Signed-off-by: Matt Ranostay --- Documentation/devicetree/bindings/input/cap1106.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/input/cap1106.txt b/Documentation/devicetree/bindings/input/cap1106.txt index 4b46390..7e64fd6 100644 --- a/Documentation/devicetree/bindings/input/cap1106.txt +++ b/Documentation/devicetree/bindings/input/cap1106.txt @@ -26,6 +26,10 @@ Optional properties: Valid values are 1, 2, 4, and 8. By default, a gain of 1 is set. + microchip,active-high: By default the interrupt pin is active low open + drain. This property allows using the active high + push-pull output. + linux,keycodes: Specifies an array of numeric keycode values to be used for the channels. If this property is omitted, KEY_A, KEY_B, etc are used as -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] cap1106: add support for cap11xx variants
These patches enable using cap11xx devices that have different number of capacitance channels, and using active-high on the interrupt output. Matt Ranostay (3): cap1106: Add support for various cap11xx devices cap1106: support for active-high interrupt option dt: cap1106 active-high property addition .../devicetree/bindings/input/cap1106.txt | 4 ++ drivers/input/keyboard/cap1106.c | 58 -- 2 files changed, 35 insertions(+), 27 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [sched] Clean up some typos and grammatical errors in code/comments
Well, the subject line says it all.
Signed-off-by: Zhihui Zhang
---
kernel/sched/core.c | 4 ++--
kernel/sched/fair.c | 6 +++---
kernel/sched/sched.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ec1a286..eb5505f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8005,7 +8005,7 @@ static int tg_cfs_schedulable_down(struct task_group *tg,
void *data)
struct cfs_bandwidth *parent_b = >parent->cfs_bandwidth;
quota = normalize_cfs_quota(tg, d);
- parent_quota = parent_b->hierarchal_quota;
+ parent_quota = parent_b->hierarchical_quota;
/*
* ensure max(child_quota) <= parent_quota, inherit when no
@@ -8016,7 +8016,7 @@ static int tg_cfs_schedulable_down(struct task_group *tg,
void *data)
else if (parent_quota != RUNTIME_INF && quota > parent_quota)
return -EINVAL;
}
- cfs_b->hierarchal_quota = quota;
+ cfs_b->hierarchical_quota = quota;
return 0;
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..6d83845 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2211,8 +2211,8 @@ static __always_inline u64 decay_load(u64 val, u64 n)
/*
* As y^PERIOD = 1/2, we can combine
-*y^n = 1/2^(n/PERIOD) * k^(n%PERIOD)
-* With a look-up table which covers k^n (navg_load >= busiest->avg_load)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 579712f..80b124d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -184,7 +184,7 @@ struct cfs_bandwidth {
raw_spinlock_t lock;
ktime_t period;
u64 quota, runtime;
- s64 hierarchal_quota;
+ s64 hierarchical_quota;
u64 runtime_expires;
int idle, timer_active;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/18] usbip: Add support for client authentication
Hi,
On Tue, Sep 16, 2014 at 11:38:39PM +, Maximilian Eschenbacher wrote:
> From: Dominik Paulus
>
> This patch adds support for authenticating both client and server using
> a pre-shared passphrase using SRP (Secure Remote Password) over TLS (see
> RFC 5054) using GnuTLS. Both usbip and usbipd now accept a shared secret
> as a command line argument.
The command line is not a good fit for passing secrets.
There is no way for the caller to provide the passphrase securely
because anything in the command line can be seen by other local users.
I suggest to read the passphrase from a file instead.
> Currently, the established TLS connection is
> only used to perform a secure handshake and dropped before the socket is
> passed to the kernel. The code may be extended to exchange a session key
> over TLS and pass it to the kernel to perform IPsec.
>
> Signed-off-by: Maximilian Eschenbacher
> Signed-off-by: Fjodor Schelichow
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Dominik Paulus
> Signed-off-by: Tobias Polzer
> ---
> tools/usb/usbip/configure.ac| 14 +++
> tools/usb/usbip/doc/usbip.8 | 4 +
> tools/usb/usbip/doc/usbipd.8| 5 +
> tools/usb/usbip/src/usbip.c | 30 +-
> tools/usb/usbip/src/usbip_attach.c | 2 +-
> tools/usb/usbip/src/usbip_list.c| 2 +-
> tools/usb/usbip/src/usbip_network.c | 185
>
> tools/usb/usbip/src/usbip_network.h | 11 ++-
> tools/usb/usbip/src/usbipd.c| 115 --
> 9 files changed, 335 insertions(+), 33 deletions(-)
>
> diff --git a/tools/usb/usbip/configure.ac b/tools/usb/usbip/configure.ac
> index 607d05c..6a8156f 100644
> --- a/tools/usb/usbip/configure.ac
> +++ b/tools/usb/usbip/configure.ac
> @@ -83,6 +83,20 @@ AC_ARG_WITH([tcp-wrappers],
> AC_DEFINE([HAVE_LIBWRAP], [1], [use tcp wrapper])],
> [AC_MSG_RESULT([no]); LIBS="$saved_LIBS"])])
>
> +# Checks for the GnuTLS library
> +AC_ARG_WITH([gnutls],
> + [AS_HELP_STRING([--with-gnutls],
> + [use the GnuTLS library
> for authentication])],
> + dnl [ACTION-IF-GIVEN]
> + [if test "$withval" = "yes"; then
> + PKG_CHECK_MODULES([GNUTLS], [gnutls])
GnuTLS version 2.12 passes this configure test but then fails during the
build. Please check for the minimum version here:
+ PKG_CHECK_MODULES([GNUTLS], [gnutls >= 3.0])
> + AC_DEFINE([HAVE_GNUTLS], [1], [use gnutls])
> + CFLAGS="$CFLAGS $GNUTLS_CFLAGS"
> + LDFLAGS="$LDFLAGS $GNUTLS_LIBS"
> + fi
> + ],
> + )
> +
> # Sets directory containing usb.ids.
> AC_ARG_WITH([usbids-dir],
> [AS_HELP_STRING([--with-usbids-dir=DIR],
> diff --git a/tools/usb/usbip/doc/usbip.8 b/tools/usb/usbip/doc/usbip.8
> index a6097be..847aa40 100644
> --- a/tools/usb/usbip/doc/usbip.8
> +++ b/tools/usb/usbip/doc/usbip.8
> @@ -27,6 +27,10 @@ Log to syslog.
> \fB\-\-tcp-port PORT\fR
> .IP
> Connect to PORT on remote host (used for attach and list --remote).
> +
> +\fB\-\-auth\fR
> +.IP
> +Set the password to be used for client authentication. See usbipd(8) for
> more information.
> .PP
>
> .SH COMMANDS
> diff --git a/tools/usb/usbip/doc/usbipd.8 b/tools/usb/usbip/doc/usbipd.8
> index ac4635d..8beb95a 100644
> --- a/tools/usb/usbip/doc/usbipd.8
> +++ b/tools/usb/usbip/doc/usbipd.8
> @@ -52,6 +52,11 @@ If no FILE specified, use /var/run/usbipd.pid
> \fB\-tPORT\fR, \fB\-\-tcp\-port PORT\fR
> .IP
> Listen on TCP/IP port PORT.
> +
> +.HP
> +\fB\-s\fR, \fB\-\-auth\fR
> +.IP
> +Sets the password to be used for client authentication. If -a is used, the
> server will only accept connections from authenticated clients. Note: USB
> traffic will still be unencrypted, this currently only serves for
> authentication.
> .PP
>
> \fB\-h\fR, \fB\-\-help\fR
> diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
> index d7599d9..cd7e420 100644
> --- a/tools/usb/usbip/src/usbip.c
> +++ b/tools/usb/usbip/src/usbip.c
> @@ -25,6 +25,12 @@
> #include
> #include
>
> +#include "../config.h"
> +
> +#ifdef HAVE_GNUTLS
> +#include
> +#endif
> +
> #include "usbip_common.h"
> #include "usbip_network.h"
> #include "usbip.h"
> @@ -35,8 +41,12 @@ static int usbip_version(int argc, char *argv[]);
> static const char usbip_version_string[] = PACKAGE_STRING;
>
> static const char usbip_usage_string[] =
> - "usbip [--debug] [--log] [--tcp-port PORT] [version]\n"
> - " [help] \n";
> + "usbip "
> +#ifdef HAVE_GNUTLS
> + "[--auth PASSWORD] "
> +#endif
> + "[--debug] [--log] [--tcp-port PORT]\n"
> + " [version] [help] \n";
>
> static void usbip_usage(void)
> {
> @@ -148,6 +158,7 @@ int main(int argc, char
Re: [PATCH 03/18] usbip: Add kernel support for client ACLs
Hi,
On Tue, Sep 16, 2014 at 11:38:40PM +, Maximilian Eschenbacher wrote:
> From: Dominik Paulus
>
> This patch adds the possibility to stored ACLs for allowed clients for
> each stub device in sysfs. It adds a new sysfs entry called "usbip_acl"
> for each stub device, containing a list of CIDR masks of allowed
> clients. This file will be used by usbip and usbipd to store the ACL.
Is there a need to involve the kernel here, couldn't usbip and usbipd
apply the ACLs during connection setup in userspace?
> Signed-off-by: Maximilian Eschenbacher
> Signed-off-by: Fjodor Schelichow
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Kurt Kanzenbach
> Signed-off-by: Dominik Paulus
> Signed-off-by: Tobias Polzer
> ---
> drivers/usb/usbip/stub.h | 5
> drivers/usb/usbip/stub_dev.c | 60
> +++-
> 2 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/usbip/stub.h b/drivers/usb/usbip/stub.h
> index 266e2b0..b2d3d55 100644
> --- a/drivers/usb/usbip/stub.h
> +++ b/drivers/usb/usbip/stub.h
> @@ -60,6 +60,11 @@ struct stub_device {
> struct list_head unlink_free;
>
> wait_queue_head_t tx_waitq;
> +
> + /* list of allowed IP addrs */
> + char *acls;
> + /* for locking list operations */
> + spinlock_t ip_lock;
Perhaps name this 'acl_lock' to make more obvious what it covers?
> };
>
> /* private data into urb->priv */
> diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
> index fac20e0..e6624f1 100644
> --- a/drivers/usb/usbip/stub_dev.c
> +++ b/drivers/usb/usbip/stub_dev.c
> @@ -119,6 +119,55 @@ err:
> }
> static DEVICE_ATTR(usbip_sockfd, S_IWUSR, NULL, store_sockfd);
>
> +/*
> + * This function replaces the current ACL list
> + */
> +static ssize_t store_acl(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct stub_device *sdev = dev_get_drvdata(dev);
> + int retval;
> +
> + if (count >= PAGE_SIZE)
> + return -EINVAL;
> +
> + spin_lock_irq(>ip_lock);
> + kfree(sdev->acls);
> + sdev->acls = kstrdup(buf, GFP_KERNEL);
> + if (!sdev->acls)
> + retval = -ENOMEM;
> + else
> + retval = strlen(sdev->acls);
> + spin_unlock_irq(>ip_lock);
> +
> + return retval;
> +}
> +
> +/*
> + * This functions prints all allowed IP addrs for this dev
> + */
> +static ssize_t show_acl(struct device *dev, struct device_attribute *attr,
> +char *buf)
> +{
> + struct stub_device *sdev = dev_get_drvdata(dev);
> + int retval = 0;
> +
> + if (!sdev)
> + return -ENODEV;
> +
> + spin_lock_irq(>ip_lock);
> + if (sdev->acls == NULL) {
> + retval = 0;
> + } else {
> + strcpy(buf, sdev->acls);
> + retval = strlen(buf);
> + }
> + spin_unlock_irq(>ip_lock);
> +
> + return retval;
> +}
> +static DEVICE_ATTR(usbip_acl, S_IWUSR | S_IRUGO, show_acl, store_acl);
> +
> static int stub_add_files(struct device *dev)
> {
> int err = 0;
> @@ -134,9 +183,13 @@ static int stub_add_files(struct device *dev)
> err = device_create_file(dev, _attr_usbip_debug);
> if (err)
> goto err_debug;
> + err = device_create_file(dev, _attr_usbip_acl);
> + if (err)
> + goto err_ip;
>
> return 0;
> -
> +err_ip:
> + device_remove_file(dev, _attr_usbip_debug);
> err_debug:
> device_remove_file(dev, _attr_usbip_sockfd);
> err_sockfd:
> @@ -150,6 +203,7 @@ static void stub_remove_files(struct device *dev)
> device_remove_file(dev, _attr_usbip_status);
> device_remove_file(dev, _attr_usbip_sockfd);
> device_remove_file(dev, _attr_usbip_debug);
> + device_remove_file(dev, _attr_usbip_acl);
> }
>
> static void stub_shutdown_connection(struct usbip_device *ud)
> @@ -287,6 +341,7 @@ static struct stub_device *stub_device_alloc(struct
> usb_device *udev)
> INIT_LIST_HEAD(>priv_free);
> INIT_LIST_HEAD(>unlink_free);
> INIT_LIST_HEAD(>unlink_tx);
> + spin_lock_init(>ip_lock);
> spin_lock_init(>priv_lock);
>
> init_waitqueue_head(>tx_waitq);
> @@ -453,6 +508,9 @@ static void stub_disconnect(struct usb_device *udev)
>
> usb_put_dev(sdev->udev);
>
> + /* free ACL list */
> + kfree(sdev->acls);
> +
> /* free sdev */
> busid_priv->sdev = NULL;
> stub_device_free(sdev);
Otherwise looks good to me.
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 02/11] next: mips: Fix ip27_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/ip27_defconfig | 112 +--
1 file changed, 37 insertions(+), 75 deletions(-)
diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index cc07560..cb8cf5ba 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -2,32 +2,28 @@ CONFIG_SGI_IP27=y
CONFIG_NUMA=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_SMP=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_1000=y
-CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CGROUPS=y
CONFIG_CPUSETS=y
CONFIG_RELAY=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
-# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_SRCVERSION_ALL=y
-# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
CONFIG_PCI=y
-CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_MIPS32_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
-CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -42,7 +38,6 @@ CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
-CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
@@ -96,7 +91,6 @@ CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_CFG80211=m
CONFIG_MAC80211=m
-CONFIG_MAC80211_RC_PID=y
CONFIG_RFKILL=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_BLK_DEV_LOOP=y
@@ -104,7 +98,6 @@ CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_OSD=m
CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
-# CONFIG_MISC_DEVICES is not set
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -117,7 +110,6 @@ CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
-# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_BE2ISCSI=m
@@ -162,6 +154,37 @@ CONFIG_DM_UEVENT=y
CONFIG_IFB=m
CONFIG_MACVLAN=m
CONFIG_VETH=m
+CONFIG_ATL2=m
+CONFIG_ATL1E=m
+CONFIG_ATL1C=m
+CONFIG_B44=m
+CONFIG_BNX2X=m
+CONFIG_ENIC=m
+CONFIG_DNET=m
+CONFIG_BE2NET=m
+CONFIG_VXGE=m
+CONFIG_E1000E=m
+CONFIG_IGB=m
+CONFIG_IGBVF=m
+CONFIG_IXGBE=m
+CONFIG_IP1000=m
+CONFIG_JME=m
+CONFIG_MLX4_EN=m
+# CONFIG_MLX4_DEBUG is not set
+CONFIG_KS8851_MLL=m
+CONFIG_AX88796=m
+CONFIG_AX88796_93CX6=y
+CONFIG_ETHOC=m
+CONFIG_QLA3XXX=m
+CONFIG_QLGE=m
+CONFIG_NETXEN_NIC=m
+CONFIG_SFC=m
+CONFIG_SGI_IOC3_ETH=y
+CONFIG_SMC91X=m
+CONFIG_SMSC911X=m
+CONFIG_NIU=m
+CONFIG_TEHUTI=m
+CONFIG_VIA_VELOCITY=m
CONFIG_PHYLIB=y
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
@@ -175,39 +198,6 @@ CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
CONFIG_STE10XP=m
CONFIG_LSI_ET1011C_PHY=m
-CONFIG_MDIO_BITBANG=m
-CONFIG_NET_ETHERNET=y
-CONFIG_AX88796=m
-CONFIG_AX88796_93CX6=y
-CONFIG_SGI_IOC3_ETH=y
-CONFIG_SMC91X=m
-CONFIG_ETHOC=m
-CONFIG_SMSC911X=m
-CONFIG_DNET=m
-CONFIG_B44=m
-CONFIG_KS8851_MLL=m
-CONFIG_ATL2=m
-CONFIG_E1000E=m
-CONFIG_IP1000=m
-CONFIG_IGB=m
-CONFIG_IGBVF=m
-CONFIG_VIA_VELOCITY=m
-CONFIG_QLA3XXX=m
-CONFIG_ATL1E=m
-CONFIG_ATL1C=m
-CONFIG_JME=m
-CONFIG_ENIC=m
-CONFIG_IXGBE=m
-CONFIG_VXGE=m
-CONFIG_NETXEN_NIC=m
-CONFIG_NIU=m
-CONFIG_MLX4_EN=m
-# CONFIG_MLX4_DEBUG is not set
-CONFIG_TEHUTI=m
-CONFIG_BNX2X=m
-CONFIG_QLGE=m
-CONFIG_SFC=m
-CONFIG_BE2NET=m
CONFIG_LIBERTAS_THINFIRM=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m
@@ -215,9 +205,6 @@ CONFIG_PRISM54=m
CONFIG_RTL8180=m
CONFIG_ADM8211=m
CONFIG_MWL8K=m
-CONFIG_ATH_COMMON=m
-CONFIG_ATH5K=m
-CONFIG_ATH9K=m
CONFIG_B43=m
CONFIG_B43LEGACY=m
# CONFIG_B43LEGACY_DEBUG is not set
@@ -229,22 +216,10 @@ CONFIG_HOSTAP_PCI=m
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
CONFIG_IPW2100_DEBUG=y
-CONFIG_IPW2200=m
-CONFIG_IPW2200_MONITOR=y
-CONFIG_IPW2200_PROMISCUOUS=y
-CONFIG_IPW2200_QOS=y
-CONFIG_IPW2200_DEBUG=y
CONFIG_IWLWIFI=m
-CONFIG_IWLAGN=m
-CONFIG_IWL4965=y
-CONFIG_IWL5000=y
+CONFIG_IWL4965=m
CONFIG_IWL3945=m
CONFIG_LIBERTAS=m
-CONFIG_HERMES=m
-# CONFIG_HERMES_CACHE_FW_ON_INIT is not set
-CONFIG_PLX_HERMES=m
-CONFIG_TMD_HERMES=m
-CONFIG_NORTEL_HERMES=m
CONFIG_P54_COMMON=m
CONFIG_P54_PCI=m
CONFIG_RT2X00=m
@@ -252,21 +227,19 @@
[RFC PATCH 04/11] next: mips: Fix loongson3_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/loongson3_defconfig | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/mips/configs/loongson3_defconfig
b/arch/mips/configs/loongson3_defconfig
index 4cb787f..5a73d17 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -1,12 +1,7 @@
CONFIG_MACH_LOONGSON=y
-CONFIG_SWIOTLB=y
CONFIG_LOONGSON_MACH3X=y
-CONFIG_CPU_LOONGSON3=y
-CONFIG_64BIT=y
-CONFIG_PAGE_SIZE_16KB=y
CONFIG_KSM=y
CONFIG_SMP=y
-CONFIG_NR_CPUS=4
CONFIG_HZ_256=y
CONFIG_PREEMPT=y
CONFIG_KEXEC=y
@@ -42,12 +37,9 @@ CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
-CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_IOSCHED_DEADLINE=m
CONFIG_CFQ_GROUP_IOSCHED=y
-CONFIG_PCI=y
-CONFIG_HT_PCI=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
# CONFIG_PCIEAER is not set
@@ -59,6 +51,7 @@ CONFIG_MIPS32_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
@@ -95,7 +88,6 @@ CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
@@ -124,7 +116,6 @@ CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SPI_ATTRS=m
@@ -165,7 +156,6 @@ CONFIG_TUN=m
# CONFIG_NET_VENDOR_AMD is not set
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_VENDOR_ATHEROS is not set
-# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_VENDOR_CHELSIO is not set
@@ -242,6 +232,7 @@ CONFIG_HW_RANDOM=y
CONFIG_RAW_DRIVER=m
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PIIX4=y
+CONFIG_SPI=y
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_W83627HF=m
@@ -251,7 +242,6 @@ CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
-CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB_RADEON=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=m
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 05/11] next: mips: Fix malta_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/malta_defconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/mips/configs/malta_defconfig
b/arch/mips/configs/malta_defconfig
index e18741e..7c3973f 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -19,6 +19,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -131,7 +132,6 @@ CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -174,7 +174,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_SCTP=m
CONFIG_BRIDGE=m
@@ -219,8 +218,6 @@ CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_CLS_IND=y
CONFIG_CFG80211=m
CONFIG_MAC80211=m
-CONFIG_MAC80211_RC_PID=y
-CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_MESH=y
CONFIG_RFKILL=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
@@ -259,7 +256,6 @@ CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 07/11] next: mips: Fix malta_kvm_guest_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/malta_kvm_guest_defconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/mips/configs/malta_kvm_guest_defconfig
b/arch/mips/configs/malta_kvm_guest_defconfig
index edd9ec9..2decf36 100644
--- a/arch/mips/configs/malta_kvm_guest_defconfig
+++ b/arch/mips/configs/malta_kvm_guest_defconfig
@@ -19,6 +19,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -131,7 +132,6 @@ CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -174,7 +174,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_SCTP=m
CONFIG_BRIDGE=m
@@ -219,8 +218,6 @@ CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_CLS_IND=y
CONFIG_CFG80211=m
CONFIG_MAC80211=m
-CONFIG_MAC80211_RC_PID=y
-CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_MESH=y
CONFIG_RFKILL=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
@@ -260,7 +257,6 @@ CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 08/11] next: mips: Fix mtx1_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/mtx1_defconfig | 254 ---
1 file changed, 101 insertions(+), 153 deletions(-)
diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
index d269a53..41f69c4 100644
--- a/arch/mips/configs/mtx1_defconfig
+++ b/arch/mips/configs/mtx1_defconfig
@@ -1,16 +1,14 @@
CONFIG_MIPS_ALCHEMY=y
CONFIG_MIPS_MTX1=y
CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
-CONFIG_AUDIT=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
@@ -19,14 +17,30 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
-# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ACORN_PARTITION=y
+CONFIG_ACORN_PARTITION_ICS=y
+CONFIG_ACORN_PARTITION_RISCIX=y
+CONFIG_OSF_PARTITION=y
+CONFIG_AMIGA_PARTITION=y
+CONFIG_ATARI_PARTITION=y
+CONFIG_MAC_PARTITION=y
+CONFIG_BSD_DISKLABEL=y
+CONFIG_MINIX_SUBPARTITION=y
+CONFIG_SOLARIS_X86_PARTITION=y
+CONFIG_UNIXWARE_DISKLABEL=y
+CONFIG_LDM_PARTITION=y
+CONFIG_SGI_PARTITION=y
+CONFIG_ULTRIX_PARTITION=y
+CONFIG_SUN_PARTITION=y
+CONFIG_KARMA_PARTITION=y
CONFIG_PCI=y
CONFIG_PCCARD=m
CONFIG_YENTA=m
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_BINFMT_MISC=m
-CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -38,8 +52,6 @@ CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
@@ -50,7 +62,6 @@ CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
-CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
@@ -58,7 +69,6 @@ CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
@@ -81,16 +91,12 @@ CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_LOG=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
@@ -98,7 +104,6 @@ CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
-CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
@@ -108,7 +113,6 @@ CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
-CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
@@ -133,7 +137,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_IP_DCCP=m
CONFIG_IP_SCTP=m
CONFIG_TIPC=m
@@ -151,13 +154,8 @@ CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
-CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
@@ -225,8 +223,6 @@ CONFIG_TOSHIBA_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_MCS_FIR=m
CONFIG_BT=m
-CONFIG_BT_L2CAP=y
-CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
@@ -246,7 +242,6 @@ CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_CONNECTOR=m
CONFIG_MTD=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
@@ -257,22 +252,21 @@ CONFIG_MTD_PHYSMAP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
-# CONFIG_MISC_DEVICES is not set
CONFIG_SCSI=m
[RFC PATCH 10/11] next: mips: Fix nlm_xlr_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/nlm_xlr_defconfig | 90 -
1 file changed, 28 insertions(+), 62 deletions(-)
diff --git a/arch/mips/configs/nlm_xlr_defconfig
b/arch/mips/configs/nlm_xlr_defconfig
index c6f8465..0a64df1 100644
--- a/arch/mips/configs/nlm_xlr_defconfig
+++ b/arch/mips/configs/nlm_xlr_defconfig
@@ -3,29 +3,25 @@ CONFIG_HIGHMEM=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_SMP=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_KEXEC=y
-CONFIG_EXPERIMENTAL=y
-CONFIG_CROSS_COMPILE=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
-CONFIG_AUDIT=y
CONFIG_NAMESPACES=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
-CONFIG_INITRAMFS_COMPRESSION_GZIP=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_ELF_CORE is not set
@@ -37,12 +33,31 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_BLK_DEV_INTEGRITY=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ACORN_PARTITION=y
+CONFIG_ACORN_PARTITION_ICS=y
+CONFIG_ACORN_PARTITION_RISCIX=y
+CONFIG_OSF_PARTITION=y
+CONFIG_AMIGA_PARTITION=y
+CONFIG_ATARI_PARTITION=y
+CONFIG_MAC_PARTITION=y
+CONFIG_BSD_DISKLABEL=y
+CONFIG_MINIX_SUBPARTITION=y
+CONFIG_SOLARIS_X86_PARTITION=y
+CONFIG_UNIXWARE_DISKLABEL=y
+CONFIG_LDM_PARTITION=y
+CONFIG_SGI_PARTITION=y
+CONFIG_ULTRIX_PARTITION=y
+CONFIG_SUN_PARTITION=y
+CONFIG_KARMA_PARTITION=y
+CONFIG_SYSV68_PARTITION=y
CONFIG_PCI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_DEBUG=y
CONFIG_BINFMT_MISC=m
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -74,7 +89,6 @@ CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
-CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
@@ -85,7 +99,6 @@ CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_NETLABEL=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
@@ -101,7 +114,6 @@ CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
-CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
@@ -161,21 +173,13 @@ CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
-CONFIG_IP_VS_FTP=m
CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_LOG=m
-CONFIG_IP_NF_TARGET_ULOG=m
-CONFIG_NF_NAT=m
-CONFIG_IP_NF_TARGET_MASQUERADE=m
-CONFIG_IP_NF_TARGET_NETMAP=m
-CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -186,8 +190,6 @@ CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_NF_CONNTRACK_IPV6=m
-CONFIG_IP6_NF_QUEUE=m
-CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
@@ -197,7 +199,6 @@ CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
-CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
@@ -224,7 +225,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_RDS=m
@@ -245,13 +245,8 @@ CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
-CONFIG_WAN_ROUTER=m
CONFIG_PHONET=m
CONFIG_IEEE802154=m
CONFIG_NET_SCHED=y
@@ -308,7 +303,6 @@ CONFIG_BLK_DEV_OSD=m
CONFIG_BLK_DEV_RAM=y
[RFC PATCH 09/11] next: mips: Fix nlm_xlp_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/nlm_xlp_defconfig | 36
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/arch/mips/configs/nlm_xlp_defconfig
b/arch/mips/configs/nlm_xlp_defconfig
index 2f660e9..a269b0c 100644
--- a/arch/mips/configs/nlm_xlp_defconfig
+++ b/arch/mips/configs/nlm_xlp_defconfig
@@ -6,19 +6,18 @@ CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_SMP=y
# CONFIG_SECCOMP is not set
-CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
-CONFIG_AUDIT=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
CONFIG_CGROUPS=y
CONFIG_NAMESPACES=y
CONFIG_BLK_DEV_INITRD=y
@@ -50,7 +49,6 @@ CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
-CONFIG_EFI_PARTITION=y
CONFIG_SYSV68_PARTITION=y
CONFIG_PCI=y
CONFIG_PCI_DEBUG=y
@@ -63,6 +61,7 @@ CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -94,7 +93,6 @@ CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
-CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
@@ -105,7 +103,6 @@ CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_NETLABEL=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
@@ -121,7 +118,6 @@ CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
-CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
@@ -181,20 +177,13 @@ CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
-CONFIG_IP_VS_FTP=m
CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_ULOG=m
-CONFIG_NF_NAT=m
-CONFIG_IP_NF_TARGET_MASQUERADE=m
-CONFIG_IP_NF_TARGET_NETMAP=m
-CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -205,7 +194,6 @@ CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_NF_CONNTRACK_IPV6=m
-CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
@@ -241,7 +229,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_RDS=m
@@ -262,10 +249,8 @@ CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_WAN_ROUTER=m
CONFIG_PHONET=m
CONFIG_IEEE802154=m
CONFIG_NET_SCHED=y
@@ -317,7 +302,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_CONNECTOR=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
@@ -340,11 +324,11 @@ CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_SPI_ATTRS=m
+CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_ISCSI_TCP=m
@@ -414,7 +398,6 @@ CONFIG_LEGACY_PTY_COUNT=0
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_N_HDLC=m
# CONFIG_DEVKMEM is not set
-CONFIG_STALDRV=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=48
@@ -436,7 +419,6 @@ CONFIG_THERMAL=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_DS1374=y
CONFIG_UIO=y
-CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
@@ -493,7 +475,7 @@ CONFIG_UFS_FS=m
CONFIG_EXOFS_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3_ACL=y
-CONFIG_NFS_V4=y
+CONFIG_NFS_V4=m
CONFIG_NFS_FSCACHE=y
[RFC PATCH 11/11] next: mips: Fix rm200_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/rm200_defconfig | 55 +++
1 file changed, 10 insertions(+), 45 deletions(-)
diff --git a/arch/mips/configs/rm200_defconfig
b/arch/mips/configs/rm200_defconfig
index 29d79ae..12d94db 100644
--- a/arch/mips/configs/rm200_defconfig
+++ b/arch/mips/configs/rm200_defconfig
@@ -3,7 +3,6 @@ CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_ARC_CONSOLE=y
CONFIG_HZ_1000=y
CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
@@ -11,15 +10,15 @@ CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_RELAY=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
+CONFIG_PARTITION_ADVANCED=y
CONFIG_PCI=y
CONFIG_BINFMT_MISC=m
-CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
@@ -27,8 +26,6 @@ CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
@@ -36,7 +33,6 @@ CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_TCP_MD5SIG=y
-CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
@@ -49,7 +45,6 @@ CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
@@ -94,21 +89,12 @@ CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_LOG=m
-CONFIG_IP_NF_TARGET_ULOG=m
-CONFIG_NF_NAT=m
-CONFIG_IP_NF_TARGET_MASQUERADE=m
-CONFIG_IP_NF_TARGET_NETMAP=m
-CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -118,7 +104,6 @@ CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_NF_CONNTRACK_IPV6=m
-CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
@@ -129,7 +114,6 @@ CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
-CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
@@ -154,7 +138,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE=m
CONFIG_DECNET=m
CONFIG_NET_SCHED=y
@@ -214,7 +197,6 @@ CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
-CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=m
CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
@@ -228,7 +210,6 @@ CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_FC_ATTRS=y
-# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_ISCSI_TCP=m
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
@@ -253,11 +234,16 @@ CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_NETDEVICES=y
-CONFIG_DUMMY=m
CONFIG_BONDING=m
+CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
-CONFIG_PHYLIB=m
+CONFIG_PCNET32=y
+CONFIG_CHELSIO_T3=m
+CONFIG_NE2000=m
+CONFIG_QLA3XXX=m
+CONFIG_NETXEN_NIC=m
+CONFIG_VIA_VELOCITY=m
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
@@ -265,22 +251,13 @@ CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_NET_ISA=y
-CONFIG_NE2000=m
-CONFIG_NET_PCI=y
-CONFIG_PCNET32=y
-CONFIG_VIA_VELOCITY=m
-CONFIG_QLA3XXX=m
-CONFIG_CHELSIO_T3=m
-CONFIG_NETXEN_NIC=m
+CONFIG_PLIP=m
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
# CONFIG_USB_NET_CDC_SUBSET is not set
-CONFIG_PLIP=m
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_SERIO_PARKBD=m
[RFC PATCH 06/11] next: mips: Fix malta_kvm_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/malta_kvm_defconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/mips/configs/malta_kvm_defconfig
b/arch/mips/configs/malta_kvm_defconfig
index cf0e01f..3c7150c 100644
--- a/arch/mips/configs/malta_kvm_defconfig
+++ b/arch/mips/configs/malta_kvm_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
@@ -132,7 +133,6 @@ CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -175,7 +175,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_SCTP=m
CONFIG_BRIDGE=m
@@ -220,8 +219,6 @@ CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_CLS_IND=y
CONFIG_CFG80211=m
CONFIG_MAC80211=m
-CONFIG_MAC80211_RC_PID=y
-CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_MESH=y
CONFIG_RFKILL=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
@@ -260,7 +257,6 @@ CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 03/11] next: mips: Fix jazz_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/jazz_defconfig | 43 +---
1 file changed, 5 insertions(+), 38 deletions(-)
diff --git a/arch/mips/configs/jazz_defconfig b/arch/mips/configs/jazz_defconfig
index 2575302..c24896f 100644
--- a/arch/mips/configs/jazz_defconfig
+++ b/arch/mips/configs/jazz_defconfig
@@ -1,7 +1,6 @@
CONFIG_MACH_JAZZ=y
CONFIG_OLIVETTI_M700=y
CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
@@ -9,15 +8,14 @@ CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_RELAY=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
+CONFIG_PARTITION_ADVANCED=y
CONFIG_BINFMT_MISC=m
-CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
@@ -25,15 +23,12 @@ CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_TCP_MD5SIG=y
-CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
@@ -42,7 +37,6 @@ CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
@@ -85,21 +79,12 @@ CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_LOG=m
-CONFIG_IP_NF_TARGET_ULOG=m
-CONFIG_NF_NAT=m
-CONFIG_IP_NF_TARGET_MASQUERADE=m
-CONFIG_IP_NF_TARGET_NETMAP=m
-CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -109,7 +94,6 @@ CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_NF_CONNTRACK_IPV6=m
-CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
@@ -120,7 +104,6 @@ CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
-CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
@@ -145,7 +128,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE=m
CONFIG_DECNET=m
CONFIG_NET_SCHED=y
@@ -235,10 +217,12 @@ CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_NETDEVICES=y
-CONFIG_DUMMY=m
CONFIG_BONDING=m
+CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
+CONFIG_MIPS_JAZZ_SONIC=y
+CONFIG_NE2000=m
CONFIG_PHYLIB=m
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
@@ -247,12 +231,6 @@ CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_MII=y
-CONFIG_MIPS_JAZZ_SONIC=y
-CONFIG_NET_ISA=y
-CONFIG_NE2000=m
-CONFIG_NET_PCI=y
CONFIG_PLIP=m
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_SERIO_PARKBD=m
@@ -276,7 +254,6 @@ CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
-CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=m
@@ -303,12 +280,8 @@ CONFIG_ROMFS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_NFS_FS=m
-CONFIG_NFS_V3=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
-CONFIG_RPCSEC_GSS_KRB5=m
-CONFIG_RPCSEC_GSS_SPKM3=m
-CONFIG_SMB_FS=m
CONFIG_CIFS=m
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
@@ -321,7 +294,6 @@ CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
CONFIG_AFS_FS=m
-CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
@@ -360,22 +332,17 @@ CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
-CONFIG_DLM=m
CONFIG_KEYS_DEBUG_PROC_KEYS=y
[RFC PATCH 00/11] next: mips: Fix default configurations
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') in linux-next changes 'select NET' to 'depends NET'. As a
result, many configurations which do not explicitly select CONFIG_NET are no
longer valid and need to be updated.
An alternative to this patch series would be to revert the original commit which
caused the problem. However, a simple revert is no longer possible due to
secondary commits changing more dependencies; an attempt to build
nlm_xlp_defconfig after reverting the commit still failed with a build error.
It would therefore be necessary to track down and revert all related commits.
This patch series attempts to fix the problem for the affected mips
configurations. I did not look into other architectures or configurations.
The command sequence to create the new configuration files is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
This sequence results in building images for all modified configurations,
but due to secondary dependency changes can not guarantee correctness
or completeness. Only time will show if there are more problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 01/11] next: mips: Fix gpr_defconfig
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') changes 'select NET' to 'depends NET'. As a result, many
configurations which do not explicitly select CONFIG_NET are no longer valid
and need to be updated.
The command sequence to create the new configuration is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
Fixes: 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET')
Signed-off-by: Guenter Roeck
---
arch/mips/configs/gpr_defconfig | 104 +---
1 file changed, 34 insertions(+), 70 deletions(-)
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 8f219da..8cc7cab 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@ -1,24 +1,23 @@
CONFIG_MIPS_ALCHEMY=y
CONFIG_MIPS_GPR=y
-CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EXPERT=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
CONFIG_PCI=y
CONFIG_BINFMT_MISC=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
@@ -36,7 +35,6 @@ CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
@@ -58,16 +56,12 @@ CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
-CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
-CONFIG_IP_NF_TARGET_LOG=m
-CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
@@ -95,7 +89,6 @@ CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
-CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_IP_DCCP=m
CONFIG_IP_SCTP=m
CONFIG_TIPC=m
@@ -113,13 +106,8 @@ CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
-CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
@@ -165,7 +153,6 @@ CONFIG_YAM=m
CONFIG_CFG80211=y
CONFIG_MAC80211=y
CONFIG_MTD=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
@@ -180,15 +167,29 @@ CONFIG_TIFM_CORE=m
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_SG=m
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
-# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_NETDEVICES=y
+CONFIG_NET_FC=y
+CONFIG_NETCONSOLE=m
+CONFIG_ATM_TCP=m
+CONFIG_ATM_LANAI=m
+CONFIG_ATM_ENI=m
+CONFIG_ATM_FIRESTREAM=m
+CONFIG_ATM_ZATM=m
+CONFIG_ATM_NICSTAR=m
+CONFIG_ATM_IDT77252=m
+CONFIG_ATM_AMBASSADOR=m
+CONFIG_ATM_HORIZON=m
+CONFIG_ATM_IA=m
+CONFIG_ATM_FORE200E=m
+CONFIG_ATM_HE=m
+CONFIG_ATM_HE_USE_SUNI=y
+CONFIG_MIPS_AU1X00_ENET=y
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
@@ -196,15 +197,20 @@ CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_MII=y
-CONFIG_MIPS_AU1X00_ENET=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_1 is not set
-CONFIG_ATH_COMMON=y
-CONFIG_ATH_DEBUG=y
-CONFIG_ATH5K=y
-CONFIG_ATH5K_DEBUG=y
+CONFIG_PPP=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPP_FILTER=y
+CONFIG_PPP_MPPE=m
+CONFIG_PPP_MULTILINK=y
+CONFIG_PPPOATM=m
+CONFIG_PPPOE=m
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
+CONFIG_SLIP=m
+CONFIG_SLIP_COMPRESSED=y
+CONFIG_SLIP_SMART=y
+CONFIG_SLIP_MODE_SLIP6=y
CONFIG_WAN=y
CONFIG_LANMEDIA=m
CONFIG_HDLC=m
@@ -221,40 +227,8 @@ CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
CONFIG_DSCC4_PCI_RST=y
CONFIG_DLCI=m
-CONFIG_WAN_ROUTER_DRIVERS=m
-CONFIG_CYCLADES_SYNC=m
-CONFIG_CYCLOMX_X25=y
CONFIG_LAPBETHER=m
CONFIG_X25_ASY=m
-CONFIG_ATM_TCP=m
-CONFIG_ATM_LANAI=m
-CONFIG_ATM_ENI=m
-CONFIG_ATM_FIRESTREAM=m
-CONFIG_ATM_ZATM=m
-CONFIG_ATM_NICSTAR=m
-CONFIG_ATM_IDT77252=m
-CONFIG_ATM_AMBASSADOR=m
-CONFIG_ATM_HORIZON=m
-CONFIG_ATM_IA=m
-CONFIG_ATM_FORE200E=m
-CONFIG_ATM_HE=m
[RFC PATCH 00/11] next: mips: Fix default configurations
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') in linux-next changes 'select NET' to 'depends NET'. As a
result, many configurations which do not explicitly select CONFIG_NET are no
longer valid and need to be updated.
An alternative to this patch series would be to revert the original commit which
caused the problem. However, a simple revert is no longer possible due to
secondary commits changing more dependencies; an attempt to build
nlm_xlp_defconfig after reverting the commit still failed with a build error.
It would therefore be necessary to track down and revert all related commits.
This patch series attempts to fix the problem for the affected mips
configurations. I did not look into other architectures or configurations.
The command sequence to create the new configuration files is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
This sequence results in building images for all modified configurations,
but due to secondary dependency changes can not guarantee correctness
or completeness. Only time will show if there are more problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] rtc: rtc-twl: Fixed nested IRQ handling in resume from suspend
On Wednesday, September 17, 2014 02:57:11 PM Thomas Gleixner wrote:
> On Sat, 13 Sep 2014, Laurent Pinchart wrote:
>
> > The TWL RTC interrupt is a double-nested threaded interrupt, handled
> > through the TWL SIH (Secondary Interrupt Handler) and PIH (Primary
> > Interrupt Handler).
> >
> > When the system is woken up from suspend by a TWL RTC alarm interrupt,
> > the TWL PIH and SIH are enabled first (due to the normal IRQ enabling
> > sequence for the PIH and to the IRQF_EARLY_RESUME flag for the SIH)
> > before the TWL RTC interrupt gets enabled. This results on the interrupt
> > being processed by the TWL primary interrupt handler, forwarded to the
> > nested SIH, and then marked as pending for the RTC by handle_nested_irq
> > called from the SIH.
> >
> > The RTC interrupt then eventually gets reenabled the kernel, which will
> > try to call its top half interrupt handler. As the interrupt is a nested
> > threaded IRQ, its primary handler has been set to the
> > irq_nested_primary_handler function, which is never supposed to be
> > called and generates a WARN_ON, without waking the IRQ thread up.
>
> Right. It CANNOT wake up the thread, because there is no thread
> associated to that particular interrupt. It's handler is called in the
> context of the parent (demultiplexing) interrupt thread. Of course
> twl4030 does not call irq_set_parent() for the nested
> interrupts. That's there so the resend of a nested thread irq will be
> targeted to its parent.
>
> Using IRQF_EARLY_RESUME is really, really wrong for device drivers
> simply because at the point where early resume is called the devices
> have not yet been resumed, so a interrupt delivered at this point
> might run into a stale device and cause a machine stall or any other
> undesired side effect. It was added for a special case with Xen where
> Xen needs the IPIs working early in resume. And it's definitely not
> meant to solve ordering issues of interrupts on resume.
>
> That said, looking at that twl4030 driver, there seems to be a double
> nesting issue. So also the simple one level parent redirection of the
> irq resend wont work. I really wonder why this only triggers in the
> context of resume.
>
> Now the resend issue is simple to fix. The resume time ordering
> constraints is a bit more involved, but it should be possible w/o
> inflicting anything more complex on drivers than requiring them to use
> irq_set_parent(), which should be name irq_set_nested_parent().
>
> Completely untested patch below. It applies on top of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/pm
>
> So what twl4030 needs on top of that are calls to
> irq_set_nested_parent() for the nested interrupts.
>
> That will automatically establish the nesting depth, redirect the
> retrigger to the top most interrupt and solve the resume ordering.
>
> The resume ordering is the reverse of the nesting:
>
> top-irq1 - nested irq10 - nested irq20 (parent = 10)
>| (parent = 1) - nested irq21 (parent = 10)
>|
>- nested irq11 - nested irq22 (parent = 11)
>| (parent = 1) - nested irq23 (parent = 11)
>|
>- nested irq12 - nested irq24 (parent = 12)
> (parent = 1) - nested irq25 (parent = 12)
>
> So the resume ordering is
>
>20-21-22-23-24-25 - 10-11-12 - 1
I was thinking about this earlier today.
Can't we do something like this (pseudo code) during resume:
resume_irq(irq) {
if (has parent_irq)
resume_irq(parent_irq);
do stuff;
}
which will get us the right ordering without using bitmaps and visiting
the same one twice (once from the child and once from the main resume loop)
doesn't matter?
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 00/11] next: mips: Fix default configurations
Commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent on NET instead
of selecting NET') in linux-next changes 'select NET' to 'depends NET'. As a
result, many configurations which do not explicitly select CONFIG_NET are no
longer valid and need to be updated.
An alternative to this patch series would be to revert the original commit which
caused the problem. However, a simple revert is no longer possible due to
secondary commits changing more dependencies; an attempt to build
nlm_xlp_defconfig after reverting the commit still failed with a build error.
It would therefore be necessary to track down and revert all related commits.
This patch series attempts to fix the problem for the affected mips
configurations. I did not look into other architectures or configurations.
The command sequence to create the new configuration files is as follows.
- Run "make ARCH=mips " on upstream kernel
- Copy resulting .config to next-20140919
- Run "make ARCH=mips olddefconfig" in next-20140919
- Run "make ARCH=mips savedefconfig"
- Copy resulting defconfig file to arch/mips/configs/
- Build the image with the resulting configuration
This sequence results in building images for all modified configurations,
but due to secondary dependency changes can not guarantee correctness
or completeness. Only time will show if there are more problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: irq mask swapping during suspend/resume
On Thursday, September 18, 2014 01:32:06 PM Thomas Gleixner wrote: > On Wed, 17 Sep 2014, Dmitry Torokhov wrote: > > Hi Thomas, > > > > On Wednesday, September 17, 2014 12:05:42 PM Thomas Gleixner wrote: > > > On Tue, 16 Sep 2014, Eric Caruso wrote: > > > > We would like to be able to set different irq masks for triggers during > > > > normal operation and for waking up the system. For example, while a > > > > laptop > > > > is awake, closing the lid and opening the lid should both fire an > > > > interrupt, but when the system is asleep, we would like to stay asleep > > > > when > > > > closing the lid. > > > > > > > > We are thinking about stashing the irq mask used specifically for waking > > > > the system up in the irq_desc struct, and then swapping it during > > > > enable_irq_wake and disable_irq_wake calls. Devices that do not specify > > > > a > > > > different wake mask will use their normal trigger mask for both > > > > situations. > > > > > > > > Is this acceptable? > > > > > > Not really. Why should irq_desc provide storage for random > > > configurations and bind them to some random system state? > > > > > > What's wrong with calling > > > > > >irq_set_type(irq, B); > > >enable_irq_wake(irq); > > > > > >disable_irq_wake(irq); > > >irq_set_type(irq, A); > > > > The desire is to avoid doing it in [every] driver but rather have it done > > centrally by device/PM core. It does not have to be irq_desc though, > > maybe you can suggest a better place for it (aside of the individual driver > > code that is)? > > Well, if it should be done by the device/pm core then you want to > store that information in the device related data structure. > > struct dev_pm_info might be the right place for it, but that's up to > Rafael. > > So driver would set > >dev->power.update_wakeirq_type = true; >dev->power.irq_type_normal = IRQ_TYPE_EDGE_BOTH; >dev->power.irq_type_sleep = IRQ_TYPE_EDGE_LOW; > > And the dev/PM core can issue the calls on suspend/resume. So I'd rather put that into the struct wakeup_source pointed to by the wakeup pointer in struct dev_pm_info. That would give us a mapping between wakeup source objects and wakeup interrupts and which would make a fair amount of sense in my view. Then, we could simply walk the list of wakeup source objects before suspend_device_irqs() and call enable_irq_wake() etc. for all of the interrupts in question without drivers having to worry about that. We also could save the current IRQ type for them at that point and restore it during resume. Of course, that would require some changes to wakeup_source_create() and friends, but is probably worth doing. Still, before we start making those changes, here's a bunch of questions to answer: (1) Say a wakeup interrupt is shared between two drivers and one of them asks for a different "IRQ type for sleep" than the other one. How are we going to resolve such conflicts? (2) Can platforms place restrictions on the IRQ type to be used with a given line? If so, how do we handle situations in which the requested "IRQ type for sleep" is different from what the given line can use? Do we need to resolve that at the struct wakeup_source creation time or can we do that later (during suspend?) and how? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 00/16] Add ACPI _DSD and unified device properties support
On Tuesday, September 16, 2014 02:52:31 PM Mika Westerberg wrote: > This is a second revision of the patches first submitted here [1]. > > The recent publication of the ACPI 5.1 specification [2] adds a reserved name > for Device Specific Data (_DSD, Section 6.2.5). This mechanism allows for > passing arbitrary hardware description data to the OS. The exact format of the > _DSD data is specific to the UUID paired with it [3]. > > An ACPI Device Properties UUID has been defined [4] to provide a format > compatible with existing device tree schemas. The purpose for this was to > allow for the reuse of the existing schemas and encourage the development > of firmware agnostic device drivers. > > This series accomplishes the following (as well as some other dependencies): > > * Add _DSD support to the ACPI core >This simply reads the UUID and the accompanying Package > > * Add ACPI Device Properties _DSD format support >This understands the hierarchical key:value pair structure >defined by the Device Properties UUID > > * Add a unified device properties API with ACPI and OF backends >This provides for the firmware agnostic device properties >Interface to be used by drivers > > * Provides 3 example drivers that were previously Device Tree aware that >can now be used with either Device Tree or ACPI Device Properties. The >drivers use "PRP0001" as their _HID which means that the match should be >done using driver's .of_match_table instead. > > The patch series has been tested on Minnoboard and Minnowboard MAX and the > relevant part of DSDTs are at the end of this cover letter. > > This series does not provide for a means to append to a system DSDT. That > will ultimately be required to make the most effective use of the _DSD > mechanism. Work is underway on that as a separate effort. > > Most important changes to the previous RFC version: > > * Added wrapper functions for most used property types > * Return -EOVERFLOW in case integer would not fit to a type > * Dropped dev_prop_ops > * We now have dev_node_xxx() functions to access firmware node > properties without dev pointer > * The accessor function names try to be close to their corresponding of_* > counterpart > * Tried to have a bit better examples in the documentation patch > * gpiolib got support for _DSD and also it now understand firmware node > properties with dev_node_get_named_gpiod() that requests the GPIO > properly. > * Support for "PRP0001" _HID/_CID. This means that the match should be > done using driver .of_match_table instead. > * Add unified property support for at25 SPI eeprom driver as well. > > [1] https://lkml.org/lkml/2014/8/17/10 > [2] http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf > [3] > http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm > [4] > http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > > Aaron Lu (2): > input: gpio_keys_polled - Add support for GPIO descriptors > input: gpio_keys_polled - Make use of device property API > > Max Eliaser (2): > leds: leds-gpio: Make use of device property API > leds: leds-gpio: Add ACPI probing support > > Mika Westerberg (11): > ACPI: Add support for device specific properties > ACPI: Allow drivers to match using Device Tree compatible property > ACPI: Document ACPI device specific properties > mfd: Add ACPI support > gpio / ACPI: Add support for _DSD device properties > gpio: Add support for unified device properties interface > gpio: sch: Consolidate core and resume banks > leds: leds-gpio: Add support for GPIO descriptors > input: gpio_keys_polled - Add ACPI probing support > misc: at25: Make use of device property API > misc: at25: Add ACPI probing support Given the ACKs that we've got already (the Greg's one in particular) and the apparent lack of objections (or indeed any comments at all), I'm about to queue this up for 3.18 next week. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] PM: Print pending wakeup IRQ preventing suspend
On Friday, September 19, 2014 04:52:35 AM Amit Pundir wrote:
> From: Todd Poynor
>
> Currently when a pending wakeup irq stops suspend, it can be difficult
> to determine why suspend was prevented and which IRQ was actually
> responsible. In order to help debug such situation, this patch prints the
> IRQ number and action name of that pending wakeup irq.
>
> Cc: Pavel Machek
> Cc: Thomas Gleixner
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: linux...@vger.kernel.org
> Cc: Android Kernel Team
> Acked-by: Pavel Machek
> Signed-off-by: Todd Poynor
> [Amit Pundir: Reworded the commit message]
> Signed-off-by: Amit Pundir
> ---
> Resending this patch assuming that it might have got lost in between merge
> window rush last time and now people might have some time to look at it.
>
> kernel/irq/pm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> index abcd6ca..c2bc8d9 100644
> --- a/kernel/irq/pm.c
> +++ b/kernel/irq/pm.c
> @@ -109,8 +109,13 @@ int check_wakeup_irqs(void)
check_wakeup_irqs() is going away in 3.18, please see linux-next (or the
pm-genirq branch of linux-pm.git) for details.
>* can abort suspend.
>*/
> if (irqd_is_wakeup_set(>irq_data)) {
> - if (desc->depth == 1 && desc->istate & IRQS_PENDING)
> + if (desc->depth == 1 && desc->istate & IRQS_PENDING) {
> + pr_info("Wakeup IRQ %d %s pending, suspend
> aborted\n",
> + irq,
> + desc->action && desc->action->name ?
> + desc->action->name : "");
> return -EBUSY;
> + }
> continue;
> }
> /*
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] ARM: mvebu: armada-xp: Correct misnumbered PCIe port nodes
On 09/20/2014 08:06 PM, Sebastian Hesselbarth wrote:
> Currently, Armada XP PCIe nodes are numbered pcie@,0 with N just
> incrementing. To reflect port/lane relationship, rename the nodes
> to pcie@,. While at it, add node aliases to each of pcie
> controller and port nodes and get rid of now redundant port/lane
> comments.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
After thinking a while about the current numbering scheme, I have to
admit that it is correct. The @numbers represent assigned-address of
the pcie port and this what it is right now.
If there are no more comments, I'll resend the series without messing
with the numbering scheme.
Sebastian
> ---
> arch/arm/boot/dts/armada-xp-axpwifiap.dts| 11 ---
> arch/arm/boot/dts/armada-xp-db.dts | 20 +++-
> arch/arm/boot/dts/armada-xp-gp.dts | 11 ---
> arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 8 +++-
> arch/arm/boot/dts/armada-xp-matrix.dts | 5 ++---
> arch/arm/boot/dts/armada-xp-mv78230.dtsi | 12 ++--
> arch/arm/boot/dts/armada-xp-mv78260.dtsi | 20 ++--
> arch/arm/boot/dts/armada-xp-mv78460.dtsi | 22 +++---
> arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 11 ---
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 ++---
> 10 files changed, 53 insertions(+), 72 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> index 0e53fad111de..1b2dd3a4000b 100644
> --- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> +++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> @@ -37,24 +37,21 @@
> ranges = MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10>;
>
> - pcie-controller {
> + pcie: pcie-controller {
> status = "okay";
>
> /* First mini-PCIe port */
> - pcie@1,0 {
> - /* Port 0, Lane 0 */
> + pcie00: pcie@0,0 {
> status = "okay";
> };
>
> /* Second mini-PCIe port */
> - pcie@2,0 {
> - /* Port 0, Lane 1 */
> + pcie01: pcie@0,1 {
> status = "okay";
> };
>
> /* Renesas uPD720202 USB 3.0 controller */
> - pcie@3,0 {
> - /* Port 0, Lane 3 */
> + pcie03: pcie@0,3 {
> status = "okay";
> };
> };
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] PM: Print wall time at suspend entry and exit
On Friday, September 19, 2014 04:57:12 AM Amit Pundir wrote:
> From: Todd Poynor
>
> Existing timestamps in a dmesg only log suspend activities
> (e.g. filesystem syncs, freezing/unfreezing tasks etc) while the
> system has already started to enter/exit the suspend state.
>
> Sometimes it is handy to have suspend entry/exit overhead
> information while debugging suspend issues. This patch print
> markers with wall timestamps at suspend Entry and Exit in
> the kernel log. These timestamps can be used to compute how
> long the system spent in low-power suspend state plus the
> entry/exit overhead.
Don't we already have tracepoints for that?
> Cc: Pavel Machek
> Cc: Thomas Gleixner
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: linux...@vger.kernel.org
> Cc: Android Kernel Team
> Signed-off-by: Todd Poynor
> [Amit Pundir: Reworded the commit message]
> Signed-off-by: Amit Pundir
> ---
> Resending this patch assuming that it might have got lost in between merge
> window rush last time and now people might have some time to look at it.
>
> kernel/power/suspend.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 18c6219..5390c6c 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -443,6 +444,18 @@ static int enter_state(suspend_state_t state)
> return error;
> }
>
> +static void pm_suspend_marker(char *annotation)
> +{
> + struct timespec ts;
> + struct rtc_time tm;
> +
> + getnstimeofday();
> + rtc_time_to_tm(ts.tv_sec, );
> + pr_info("PM: suspend %s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
> + annotation, tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
> +}
> +
> /**
> * pm_suspend - Externally visible function for suspending the system.
> * @state: System sleep state to enter.
> @@ -457,6 +470,7 @@ int pm_suspend(suspend_state_t state)
> if (state <= PM_SUSPEND_ON || state >= PM_SUSPEND_MAX)
> return -EINVAL;
>
> + pm_suspend_marker("entry");
> error = enter_state(state);
> if (error) {
> suspend_stats.fail++;
> @@ -464,6 +478,7 @@ int pm_suspend(suspend_state_t state)
> } else {
> suspend_stats.success++;
> }
> + pm_suspend_marker("exit");
> return error;
> }
> EXPORT_SYMBOL(pm_suspend);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Skein: skein_block: fixed 3 tab coding style isses
Fixed a coding style issue
Signed-off-by: Mike Roocroft
---
drivers/staging/skein/skein_block.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/skein/skein_block.c
b/drivers/staging/skein/skein_block.c
index 04ce1d0..b969fe1 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -34,7 +34,7 @@
#ifdef SKEIN_DEBUG
#define debug_save_tweak(ctx) { \
-ctx->h.tweak[0] = ts[0]; ctx->h.tweak[1] = ts[1]; }
+ ctx->h.tweak[0] = ts[0]; ctx->h.tweak[1] = ts[1]; }
#else
#define debug_save_tweak(ctx)
#endif
@@ -378,7 +378,7 @@ do { \
skein_show_r_ptr(BLK_BITS, >h, SKEIN_RND_KEY_INJECT, X_ptr); \
} while (0)
- for (r = 1; r < 2 * RCNT; r += 2 * SKEIN_UNROLL_512)
+ for (r = 1; r < 2 * RCNT; r += 2 * SKEIN_UNROLL_512)
#endif /* end of looped code definitions */
{
#define R512_8_ROUNDS(R) /* do 8 full rounds */ \
@@ -657,7 +657,7 @@ do { \
skein_show_r_ptr(BLK_BITSi, >h, SKEIN_RND_KEY_INJECT, X_ptr); \
} while (0)
- for (r = 1; r <= 2 * RCNT; r += 2 * SKEIN_UNROLL_1024)
+ for (r = 1; r <= 2 * RCNT; r += 2 * SKEIN_UNROLL_1024)
#endif
{
#define R1024_8_ROUNDS(R) \
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] f2fs: fix roll-forward missing scenarios
On Sat, 2014-09-20 at 09:23 -0700, Jaegeuk Kim wrote:
> On Thu, Sep 18, 2014 at 09:04:11PM +0800, huang ying wrote:
> > On Thu, Sep 18, 2014 at 1:51 PM, Jaegeuk Kim wrote:
> >
> > > We can summarize the roll forward recovery scenarios as follows.
> > >
> > > [Term] F: fsync_mark, D: dentry_mark
> > >
> > > 1. inode(x) | CP | inode(x) | dnode(F)
> > > -> Update the latest inode(x).
> > >
> > > 2. inode(x) | CP | inode(F) | dnode(F)
> > > -> No problem.
> > >
> > > 3. inode(x) | CP | dnode(F) | inode(x)
> > > -> Recover to the latest dnode(F), and drop the last inode(x)
> > >
> > > 4. inode(x) | CP | dnode(F) | inode(F)
> > > -> No problem.
> > >
> > > 5. CP | inode(x) | dnode(F)
> > > -> The inode(DF) was missing. Should drop this dnode(F).
> > >
> > > 6. CP | inode(DF) | dnode(F)
> > > -> No problem.
> > >
> > > 7. CP | dnode(F) | inode(DF)
> > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > >
> > > 8. CP | dnode(F) | inode(x)
> > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > >But it will fail due to no inode(DF).
> > >
> > > So, this patch adds some missing points such as #1, #5, #7, and #8.
> > >
> > > Signed-off-by: Huang Ying
> > > Signed-off-by: Jaegeuk Kim
> > > ---
> > > fs/f2fs/recovery.c | 71
> > > +-
> > > 1 file changed, 60 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > > index 36d4f73..a4eb978 100644
> > > --- a/fs/f2fs/recovery.c
> > > +++ b/fs/f2fs/recovery.c
> > > @@ -14,6 +14,37 @@
> > > #include "node.h"
> > > #include "segment.h"
> > >
> > > +/*
> > > + * Roll forward recovery scenarios.
> > > + *
> > > + * [Term] F: fsync_mark, D: dentry_mark
> > > + *
> > > + * 1. inode(x) | CP | inode(x) | dnode(F)
> > > + * -> Update the latest inode(x).
> > > + *
> > > + * 2. inode(x) | CP | inode(F) | dnode(F)
> > > + * -> No problem.
> > > + *
> > > + * 3. inode(x) | CP | dnode(F) | inode(x)
> > > + * -> Recover to the latest dnode(F), and drop the last inode(x)
> > > + *
> > > + * 4. inode(x) | CP | dnode(F) | inode(F)
> > > + * -> No problem.
> > > + *
> > > + * 5. CP | inode(x) | dnode(F)
> > > + * -> The inode(DF) was missing. Should drop this dnode(F).
> > > + *
> > > + * 6. CP | inode(DF) | dnode(F)
> > > + * -> No problem.
> > > + *
> > > + * 7. CP | dnode(F) | inode(DF)
> > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > + *
> > > + * 8. CP | dnode(F) | inode(x)
> > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > + *But it will fail due to no inode(DF).
> > > + */
> > > +
> > > static struct kmem_cache *fsync_entry_slab;
> > >
> > > bool space_for_roll_forward(struct f2fs_sb_info *sbi)
> > > @@ -110,27 +141,32 @@ out:
> > > return err;
> > > }
> > >
> > > -static int recover_inode(struct inode *inode, struct page *node_page)
> > > +static void __recover_inode(struct inode *inode, struct page *page)
> > > {
> > > - struct f2fs_inode *raw_inode = F2FS_INODE(node_page);
> > > + struct f2fs_inode *raw = F2FS_INODE(page);
> > > +
> > > + inode->i_mode = le16_to_cpu(raw->i_mode);
> > > + i_size_write(inode, le64_to_cpu(raw->i_size));
> > > + inode->i_atime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > + inode->i_ctime.tv_sec = le64_to_cpu(raw->i_ctime);
> > > + inode->i_mtime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > + inode->i_atime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > + inode->i_ctime.tv_nsec = le32_to_cpu(raw->i_ctime_nsec);
> > > + inode->i_mtime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > +}
> > >
> > > +static int recover_inode(struct inode *inode, struct page *node_page)
> > > +{
> > > if (!IS_INODE(node_page))
> > > return 0;
> > >
> > > - inode->i_mode = le16_to_cpu(raw_inode->i_mode);
> > > - i_size_write(inode, le64_to_cpu(raw_inode->i_size));
> > > - inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > - inode->i_ctime.tv_sec = le64_to_cpu(raw_inode->i_ctime);
> > > - inode->i_mtime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > - inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > - inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
> > > - inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > + __recover_inode(inode, node_page);
> > >
> > > if (is_dent_dnode(node_page))
> > > return recover_dentry(node_page, inode);
> > >
> > > f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x, name
> > > = %s",
> > > - ino_of_node(node_page), raw_inode->i_name);
> > > + ino_of_node(node_page),
> > > F2FS_INODE(node_page)->i_name);
> > > return 0;
> > > }
> > >
> > > @@ -183,10 +219,16 @@ static int find_fsync_dnodes(struct f2fs_sb_info
> > > *sbi, struct list_head *head)
> > >
(no subject)
-- Cleveland Finance Loan give out Guarantee Business Loans, Automobile Purchase Loans, House Purchase Loans and other Personal Loans E.T.C We give out long term loan from One to Fifty years maximum with 1% interest rate. Mrs. Jean L. McFarland. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
In the brcmf_count_20mhz_channels function we are looping through a list
of channels received from firmware. Since the index of the first channel
is 0 the condition leads to an off by one bug. This is causing us to hit
the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is
how I discovered the bug.
Introduced by:
commit b48d891676f756d48b4d0ee131e4a7a5d43ca417
("brcmfmac: rework wiphy structure setup")
Signed-off-by: Emil Goode
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 02fe706..93b5dd9 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -4918,7 +4918,7 @@ static void brcmf_count_20mhz_channels(struct
brcmf_cfg80211_info *cfg,
struct brcmu_chan ch;
int i;
- for (i = 0; i <= total; i++) {
+ for (i = 0; i < total; i++) {
ch.chspec = (u16)le32_to_cpu(chlist->element[i]);
cfg->d11inf.decchspec();
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: add GPIO hogging mechanism
Ben Gamari writes: > Hi Boris, > > I'm just returning to this now. > > > Greg Kroah-Hartman writes: > >> I don't understand what makes GPIO's "special" enough to get included in >> the driver core like this, and called for each and every device that is >> added to the system. >> > I'm also a bit confused why GPIOs ended up in the driver core but > perhaps I'm missing something. What was your motivation here? > Somehow I overlooked the message in which you responded to this. Ignore the above. Cheers, - Ben pgpWogBkMpRCA.pgp Description: PGP signature
[PATCH] eeepc-laptop: clean up control flow in *_rfkill_notifier
Handle errors immediately in eeepc_register_rfkill_notifier and
eeepc_unregister_rfkill_notifier. This clears up the control flow for the
reader. It also removes unnecessary indentation.
Signed-off-by: Frans Klaver
---
This depends on the earlier eeepc cleanup series [1] to apply cleanly.
[1] https://lkml.org/lkml/2014/9/17/654
drivers/platform/x86/eeepc-laptop.c | 57 ++---
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index 3f6c762..db79902 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -668,23 +668,21 @@ static int eeepc_register_rfkill_notifier(struct
eeepc_laptop *eeepc,
status = acpi_get_handle(NULL, node, );
- if (ACPI_SUCCESS(status)) {
- status = acpi_install_notify_handler(handle,
-ACPI_SYSTEM_NOTIFY,
-eeepc_rfkill_notify,
-eeepc);
- if (ACPI_FAILURE(status))
- pr_warn("Failed to register notify on %s\n", node);
-
- /*
-* Refresh pci hotplug in case the rfkill state was
-* changed during setup.
-*/
- eeepc_rfkill_hotplug(eeepc, handle);
- } else {
+ if (ACPI_FAILURE(status))
return -ENODEV;
- }
+ status = acpi_install_notify_handler(handle,
+ACPI_SYSTEM_NOTIFY,
+eeepc_rfkill_notify,
+eeepc);
+ if (ACPI_FAILURE(status))
+ pr_warn("Failed to register notify on %s\n", node);
+
+ /*
+* Refresh pci hotplug in case the rfkill state was
+* changed during setup.
+*/
+ eeepc_rfkill_hotplug(eeepc, handle);
return 0;
}
@@ -696,20 +694,21 @@ static void eeepc_unregister_rfkill_notifier(struct
eeepc_laptop *eeepc,
status = acpi_get_handle(NULL, node, );
- if (ACPI_SUCCESS(status)) {
- status = acpi_remove_notify_handler(handle,
-ACPI_SYSTEM_NOTIFY,
-eeepc_rfkill_notify);
- if (ACPI_FAILURE(status))
- pr_err("Error removing rfkill notify handler %s\n",
- node);
- /*
-* Refresh pci hotplug in case the rfkill
-* state was changed after
-* eeepc_unregister_rfkill_notifier()
-*/
- eeepc_rfkill_hotplug(eeepc, handle);
- }
+ if (ACPI_FAILURE(status))
+ return;
+
+ status = acpi_remove_notify_handler(handle,
+ACPI_SYSTEM_NOTIFY,
+eeepc_rfkill_notify);
+ if (ACPI_FAILURE(status))
+ pr_err("Error removing rfkill notify handler %s\n",
+ node);
+ /*
+* Refresh pci hotplug in case the rfkill
+* state was changed after
+* eeepc_unregister_rfkill_notifier()
+*/
+ eeepc_rfkill_hotplug(eeepc, handle);
}
static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: add GPIO hogging mechanism
Hi Boris, I'm just returning to this now. Greg Kroah-Hartman writes: > I don't understand what makes GPIO's "special" enough to get included in > the driver core like this, and called for each and every device that is > added to the system. > I'm also a bit confused why GPIOs ended up in the driver core but perhaps I'm missing something. What was your motivation here? Cheers, - Ben pgp6jwYaJIT8D.pgp Description: PGP signature
[PATCH 3/3] x86, ptdump: Take parent page flags into account
We currently ignore the flags of parent entries when evaluating the
flags of a given page table entry in printk_prot(). This might lead to
wrong results when a particular flag in a parent entry differs from the
one of the current page table entry. So, we might show memory regions as
writable even if not all parent entries have the _PAGE_RW bit set. The
same is true for the _PAGE_USER and _PAGE_NX flags. There values in
upper levels of the hierarchy influence the effective access rights but
are ignored in printk_prot().
To handle those cases, track the effective flags for _PAGE_USER,
_PAGE_RW and _PAGE_NX throughout the page table walk and take them into
account when printing a page table entry's flags.
Signed-off-by: Mathias Krause
Cc: Arjan van de Ven
Cc: H. Peter Anvin
---
The kernel currently does not do such a thing as having a parent page
table entry having stricter flags set than the final page table entry
itself. But we might start doing so in the future. Even if not, better
be correct and safe here, then sorry for printing wrong results. This is
a debugging tool that should aid the developer, not lie to him.
This patch, in fact, helped me to debug some EFI runtime service mapping
related problems where the _PAGE_NX bit was set in the PGD entry but
ignored when shown via /sys/kernel/debug/kernel_page_tables.
---
arch/x86/mm/dump_pagetables.c | 72 ++---
1 file changed, 48 insertions(+), 24 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index f7af11c7e83f..e9aa46f7ddef 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -118,11 +118,26 @@ static struct addr_marker address_markers[] = {
seq_printf(m, fmt, ##args); \
} while (0)
+static pgprot_t effective_prot(pgprot_t parent_prot, pgprot_t new_prot)
+{
+ pgprotval_t pv_parent = pgprot_val(parent_prot) & PTE_FLAGS_MASK;
+ pgprotval_t pv_new = pgprot_val(new_prot) & PTE_FLAGS_MASK;
+ pgprotval_t pv_effective = 0;
+
+ pv_effective |= (pv_parent & pv_new) & _PAGE_USER;
+ pv_effective |= (pv_parent & pv_new) & _PAGE_RW;
+ pv_effective |= (pv_parent | pv_new) & _PAGE_NX;
+
+ return __pgprot(pv_effective);
+}
+
/*
* Print a readable form of a pgprot_t to the seq_file
*/
-static void printk_prot(struct seq_file *m, pgprot_t prot, int level, bool
dmsg)
+static void printk_prot(struct seq_file *m, pgprot_t eff_prot, pgprot_t prot,
+ int level, bool dmsg)
{
+ pgprotval_t pr_eff = pgprot_val(effective_prot(eff_prot, prot));
pgprotval_t pr = pgprot_val(prot);
static const char * const level_name[] =
{ "cr3", "pgd", "pud", "pmd", "pte" };
@@ -131,8 +146,8 @@ static void printk_prot(struct seq_file *m, pgprot_t prot,
int level, bool dmsg)
/* Not present */
ptd_cont(m, dmsg, "%-26s", "");
} else {
- ptd_cont(m, dmsg, "%-4s", pr & _PAGE_USER ? "USR" : "");
- ptd_cont(m, dmsg, "%-3s", pr & _PAGE_RW ? "RW" : "ro");
+ ptd_cont(m, dmsg, "%-4s", pr_eff & _PAGE_USER ? "USR" : "");
+ ptd_cont(m, dmsg, "%-3s", pr_eff & _PAGE_RW ? "RW" : "ro");
ptd_cont(m, dmsg, "%-4s", pr & _PAGE_PWT ? "PWT" : "");
ptd_cont(m, dmsg, "%-4s", pr & _PAGE_PCD ? "PCD" : "");
@@ -143,7 +158,7 @@ static void printk_prot(struct seq_file *m, pgprot_t prot,
int level, bool dmsg)
ptd_cont(m, dmsg, "%-4s", pr & _PAGE_PAT ? "pat" : "");
ptd_cont(m, dmsg, "%-4s", pr & _PAGE_GLOBAL ? "GLB" : "");
- ptd_cont(m, dmsg, "%-3s", pr & _PAGE_NX ? "NX" : "x");
+ ptd_cont(m, dmsg, "%-3s", pr_eff & _PAGE_NX ? "NX" : "x");
}
ptd_cont(m, dmsg, "%s\n", level_name[level]);
}
@@ -166,7 +181,7 @@ static unsigned long normalize_addr(unsigned long u)
* print what we collected so far.
*/
static void note_page(struct seq_file *m, struct pg_state *st,
- pgprot_t new_prot, int level)
+ pgprot_t eff_prot, pgprot_t new_prot, int level)
{
pgprotval_t prot, cur;
static const char units[] = "BKMGTPE";
@@ -207,7 +222,7 @@ static void note_page(struct seq_file *m, struct pg_state
*st,
unit++;
}
ptd_cont(m, st->to_dmesg, "%9lu%c ", delta, *unit);
- printk_prot(m, st->current_prot, st->level,
+ printk_prot(m, eff_prot, st->current_prot, st->level,
st->to_dmesg);
}
st->lines++;
@@ -239,7 +254,7 @@ static void note_page(struct seq_file *m, struct pg_state
*st,
}
static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr,
- unsigned long
[PATCH 0/3] x86, ptdump: a EFI related fix + enhancements
This series slightly simplifies (patch 2) and then enhances (patch 3) the page table dump code to respect the page table attributes of the whole page table walk when determining the effective access rights. It also fixes the regression that the EFI runtime service mappings are no longer visible when CONFIG_X86_ESPFIX64 is set (patch 1). Please apply! Mathias Krause (3): x86, ptdump: Add section for EFI runtime services x86, ptdump: Simplify page flag evaluation code x86, ptdump: Take parent page flags into account arch/x86/include/asm/pgtable_64_types.h |2 + arch/x86/mm/dump_pagetables.c | 175 +++ arch/x86/platform/efi/efi_64.c |3 +- 3 files changed, 90 insertions(+), 90 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] x86, ptdump: Simplify page flag evaluation code
The code evaluating the page flags is rather scattered. Simplify it by
folding the 'if .. else ..' part into the actual print call. Make use
of appropriate format strings to get the desired string width.
Also change the pt_dump_seq_printf() and pt_dump_cont_printf() macros to
use the common 'do ... while(0)' pattern instead of a compound statement
expression. We don't need no expression, just the statement.
Last, but not least, fix the checkpatch warnings for the lines touched.
Signed-off-by: Mathias Krause
Cc: Arjan van de Ven
Cc: H. Peter Anvin
---
arch/x86/mm/dump_pagetables.c | 106 -
1 file changed, 39 insertions(+), 67 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 1a8053d1012e..f7af11c7e83f 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -100,23 +100,23 @@ static struct addr_marker address_markers[] = {
#define PUD_LEVEL_MULT (PTRS_PER_PMD * PMD_LEVEL_MULT)
#define PGD_LEVEL_MULT (PTRS_PER_PUD * PUD_LEVEL_MULT)
-#define pt_dump_seq_printf(m, to_dmesg, fmt, args...) \
-({ \
- if (to_dmesg) \
- printk(KERN_INFO fmt, ##args); \
- else\
- if (m) \
- seq_printf(m, fmt, ##args); \
-})
-
-#define pt_dump_cont_printf(m, to_dmesg, fmt, args...) \
-({ \
- if (to_dmesg) \
- printk(KERN_CONT fmt, ##args); \
- else\
- if (m) \
- seq_printf(m, fmt, ##args); \
-})
+#define ptd_print(m, to_dmesg, fmt, args...) \
+ do {\
+ if (to_dmesg) \
+ pr_info(fmt, ##args); \
+ else\
+ if (m) \
+ seq_printf(m, fmt, ##args); \
+ } while (0)
+
+#define ptd_cont(m, to_dmesg, fmt, args...)\
+ do {\
+ if (to_dmesg) \
+ pr_cont(fmt, ##args); \
+ else\
+ if (m) \
+ seq_printf(m, fmt, ##args); \
+ } while (0)
/*
* Print a readable form of a pgprot_t to the seq_file
@@ -129,47 +129,23 @@ static void printk_prot(struct seq_file *m, pgprot_t
prot, int level, bool dmsg)
if (!pgprot_val(prot)) {
/* Not present */
- pt_dump_cont_printf(m, dmsg, " ");
+ ptd_cont(m, dmsg, "%-26s", "");
} else {
- if (pr & _PAGE_USER)
- pt_dump_cont_printf(m, dmsg, "USR ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- if (pr & _PAGE_RW)
- pt_dump_cont_printf(m, dmsg, "RW ");
- else
- pt_dump_cont_printf(m, dmsg, "ro ");
- if (pr & _PAGE_PWT)
- pt_dump_cont_printf(m, dmsg, "PWT ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- if (pr & _PAGE_PCD)
- pt_dump_cont_printf(m, dmsg, "PCD ");
- else
- pt_dump_cont_printf(m, dmsg, "");
+ ptd_cont(m, dmsg, "%-4s", pr & _PAGE_USER ? "USR" : "");
+ ptd_cont(m, dmsg, "%-3s", pr & _PAGE_RW ? "RW" : "ro");
+ ptd_cont(m, dmsg, "%-4s", pr & _PAGE_PWT ? "PWT" : "");
+ ptd_cont(m, dmsg, "%-4s", pr & _PAGE_PCD ? "PCD" : "");
/* Bit 9 has a different meaning on level 3 vs 4 */
- if (level <= 3) {
- if (pr & _PAGE_PSE)
- pt_dump_cont_printf(m, dmsg, "PSE ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- } else {
- if (pr & _PAGE_PAT)
- pt_dump_cont_printf(m, dmsg, "pat ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- }
- if (pr & _PAGE_GLOBAL)
- pt_dump_cont_printf(m, dmsg, "GLB
[PATCH 1/3] x86, ptdump: Add section for EFI runtime services
In commit 3891a04aafd6 ("x86-64, espfix: Don't leak bits 31:16 of %esp
returning..") the "ESPFix Area" was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are, unfortunately, located in-between the
espfix area and the high kernel memory mapping. Due to the enforced
limitation for the espfix area, the EFI mappings won't be printed in the
page table dump.
To make the ESP runtime service mappings visible again, provide them a
dedicated entry.
Signed-off-by: Mathias Krause
Cc: Matt Fleming
Cc: H. Peter Anvin
---
arch/x86/include/asm/pgtable_64_types.h |2 ++
arch/x86/mm/dump_pagetables.c |3 +++
arch/x86/platform/efi/efi_64.c |3 +--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 7166e25ecb57..602b6028c5b6 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -63,6 +63,8 @@ typedef struct { pteval_t pte; } pte_t;
#define MODULES_LEN (MODULES_END - MODULES_VADDR)
#define ESPFIX_PGD_ENTRY _AC(-2, UL)
#define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
+#define EFI_VA_START( -4 * (_AC(1, UL) << 30))
+#define EFI_VA_END (-68 * (_AC(1, UL) << 30))
#define EARLY_DYNAMIC_PAGE_TABLES 64
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 95a427e57887..1a8053d1012e 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -76,6 +76,9 @@ static struct addr_marker address_markers[] = {
# ifdef CONFIG_X86_ESPFIX64
{ ESPFIX_BASE_ADDR, "ESPfix Area", 16 },
# endif
+# ifdef CONFIG_EFI
+ { EFI_VA_END, "EFI Runtime Services" },
+# endif
{ __START_KERNEL_map, "High Kernel Mapping" },
{ MODULES_VADDR,"Modules" },
{ MODULES_END, "End Modules" },
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 290d397e1dd9..899c7f17ad85 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -48,8 +48,7 @@ static unsigned long efi_flags __initdata;
* We allocate runtime services regions bottom-up, starting from -4G, i.e.
* 0x___ and limit EFI VA mapping space to 64G.
*/
-static u64 efi_va = -4 * (1UL << 30);
-#define EFI_VA_END (-68 * (1UL << 30))
+static u64 efi_va = EFI_VA_START;
/*
* Scratch space used for switching the pagetable in the EFI stub
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] watchdog: dw_wdt: add restart handler support
On 09/18/2014 11:29 PM, Jisheng Zhang wrote:
The kernel core now provides an API to trigger a system restart.
Register with it to support restarting the system via. watchdog.
Signed-off-by: Jisheng Zhang
---
drivers/watchdog/dw_wdt.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index ad0619d..4ca41e9 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -62,6 +64,7 @@ static struct {
unsigned long next_heartbeat;
struct timer_list timer;
int expect_close;
+ struct notifier_block restart_handler;
} dw_wdt;
static inline int dw_wdt_is_enabled(void)
@@ -119,6 +122,22 @@ static void dw_wdt_keepalive(void)
WDOG_COUNTER_RESTART_REG_OFFSET);
}
+static int dw_wdt_restart_handle(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ u32 val;
+
+ writel(0, dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+ val = readl(dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
+ if (val & WDOG_CONTROL_REG_WDT_EN_MASK)
+ writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
+ WDOG_COUNTER_RESTART_REG_OFFSET);
+ else
+ writel(WDOG_CONTROL_REG_WDT_EN_MASK,
+ dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
Another comment: You should probably wait here for a bit to let the reset catch.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/20/2014 12:36 PM, Helge Deller wrote:
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so I used the version from
next-20140917.
The v4l-dvb tree lost its build failure.
The security tree gained a conflict against the file-locks tree.
Non-merge commits (relative to Linus' tree): 6014
5488 files changed, 217522 insertions(+), 129375 deletions(-)
parisc:defconfig, parisc:generic-32bit_defconfig:
--
Error log:
arch/parisc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
arch/parisc/kernel/ptrace.c:274:2: error: implicit declaration of function
'secure_computing' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/parisc/kernel/ptrace.o] Error 1
Bisect points to commit 273299fb6380 ('Merge branch 'x86/seccomp') which
obviously doesn't help much. Suspected culprit is c90f06943e05 ('parisc: Wire up
seccomp, getrandom and memfd_create syscalls') which seems to be missing an
include file.
I could not reproduce this error with current git head.
With next-20140919 ?
Nevertheless, it probably makes sense to #include in ptrace.c
to
avoid a dependency on other header files to include it instead.
I've added this patch to my for-next tree:
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=0f18557b017b3469e1f8edf5cf34c1cba856fdbe
Could you try again?
That doesn't solve the problem for me, most likely because
HAVE_ARCH_SECCOMP_FILTER is not set for parisc in next-20140919.
This is what seccomp.h does with it:
#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
static inline int secure_computing(void) { return 0; }
#else
static inline void secure_computing_strict(int this_syscall) { return; }
#endif
You don't have this flag in your tree. It was introduced in -next with
commit 'seccomp,x86,arm,mips,s390: Remove nr parameter from secure_computing'.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 0/6] usb: hub: convert khubd into workqueue
> From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern > Sent: Friday, September 19, 2014 12:39 PM > > On Fri, 19 Sep 2014, Petr Mladek wrote: > > > The 3rd version of the patchset is slightly reordered and refactored > > as suggested earlier. See below for more details. > > > > IMHO, the result is more clean. But feel free to ask me to revert it. > > I do not want to make the review more complicated. Well, I double checked > > the diff of patches files between v2 and v3. It is pretty small and only > > the expected changes are there. > > > > Changes in: > > + v3: > > + split the optimization of hub->hdev reference counting > > into separate patch; usable standalone (1st patch) > > > > + switch order of the two patches that convert the kthread > > and that remove the while cycle in hub_event(); it is > > cleaner (2nd and 3rd patch) > > > > + use ordered workqueue by default; it makes it compatible > > with the original kthread solution (3rd patch) > > > > + added optional patch that allows to process events > > in parallel (6th patch) > > > > + fixed the suggested stylistic problems (2nd and 3rd patch) > > > > > > + v2: > > + solved potential races: > > + get hub->kref in kick_hub_wq() > > + call usb_get_dev(hdev) in hub_probe() > >and usb_put_dev(hdev) in hub_release() > > + INIT_WORK only once in hub_probe() > > > > + do not call cancel_work_sync() in hub_disconnect() > >to keep it fast > > > > + rename kick_khubd() to kick_hub_wq() already > >in the first patch; IMHO, it is cleaner while > >adding only very few changes > > > > > > The workqueue API is well defined and tested. It has many options > > that could be used to tune the scheduling. The code is usually > > easier and thus more safe. It allows to avoid the extra thread > > in most cases. It has has clearly defined behavior vrt. system suspend. > > > > This patchset converts khubd into the workqueue. It saves one thread, > > lock, and list. > > > > It looks huge but the main change is in the first patch. The rest is > > simple renaming of functions, comments and documentation. > > > > > > Thanks a lot Alan Stern and Tejun Heo for hints and guidance. > > > > The patches can be applied either against Linus' tree or linux-next. > > Very nice work. I haven't tried it out, but it all looks good. No > doubt we will be able to sort out unforeseen troubles if any arise, > without much difficulty. Hmm. What are the odds that some old kernel monitoring program, in an ancient Fedora distribution let's say, will be checking for 'khubd' in the kernel process list? Pretty high I would think. I guess we'll find out once this hits mainline ;) -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] nohz: Consolidate nohz full init code
The supports for CONFIG_NO_HZ_FULL_ALL=y and the nohz_full= kernel
parameter both have their own way to do the same thing: allocate
full dynticks cpumasks, fill them and initialize some state variables.
Lets consolidate that all in the same place.
While at it, convert some regular printk message to warnings when
fundamental allocations fail.
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index f654a8a..eb4af01 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -295,22 +295,12 @@ out:
/* Parse the boot-time nohz CPU list from the kernel parameters. */
static int __init tick_nohz_full_setup(char *str)
{
- int cpu;
-
alloc_bootmem_cpumask_var(_nohz_full_mask);
- alloc_bootmem_cpumask_var(_mask);
if (cpulist_parse(str, tick_nohz_full_mask) < 0) {
pr_warning("NOHZ: Incorrect nohz_full cpumask\n");
+ free_bootmem_cpumask_var(tick_nohz_full_mask);
return 1;
}
-
- cpu = smp_processor_id();
- if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
- pr_warning("NO_HZ: Clearing %d from nohz_full range for
timekeeping\n", cpu);
- cpumask_clear_cpu(cpu, tick_nohz_full_mask);
- }
- cpumask_andnot(housekeeping_mask,
- cpu_possible_mask, tick_nohz_full_mask);
tick_nohz_full_running = true;
return 1;
@@ -349,18 +339,11 @@ static int tick_nohz_init_all(void)
#ifdef CONFIG_NO_HZ_FULL_ALL
if (!alloc_cpumask_var(_nohz_full_mask, GFP_KERNEL)) {
- pr_err("NO_HZ: Can't allocate full dynticks cpumask\n");
- return err;
- }
- if (!alloc_cpumask_var(_mask, GFP_KERNEL)) {
- pr_err("NO_HZ: Can't allocate not-full dynticks cpumask\n");
+ WARN(1, "NO_HZ: Can't allocate full dynticks cpumask\n");
return err;
}
err = 0;
cpumask_setall(tick_nohz_full_mask);
- cpumask_clear_cpu(smp_processor_id(), tick_nohz_full_mask);
- cpumask_clear(housekeeping_mask);
- cpumask_set_cpu(smp_processor_id(), housekeeping_mask);
tick_nohz_full_running = true;
#endif
return err;
@@ -375,6 +358,23 @@ void __init tick_nohz_init(void)
return;
}
+ if (!alloc_cpumask_var(_mask, GFP_KERNEL)) {
+ WARN(1, "NO_HZ: Can't allocate not-full dynticks cpumask\n");
+ cpumask_clear(tick_nohz_full_mask);
+ tick_nohz_full_running = false;
+ return;
+ }
+
+ cpu = smp_processor_id();
+
+ if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
+ pr_warning("NO_HZ: Clearing %d from nohz_full range for
timekeeping\n", cpu);
+ cpumask_clear_cpu(cpu, tick_nohz_full_mask);
+ }
+
+ cpumask_andnot(housekeeping_mask,
+ cpu_possible_mask, tick_nohz_full_mask);
+
for_each_cpu(cpu, tick_nohz_full_mask)
context_tracking_cpu_set(cpu);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] x86: Tell irq work about self IPI support
x86 supports irq work self-IPIs when local apic is available. This is
partly known on runtime so lets implement arch_irq_work_has_interrupt()
accordingly.
This should be safely called after setup_arch().
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
arch/x86/include/asm/Kbuild | 1 -
arch/x86/include/asm/irq_work.h | 11 +++
arch/x86/kernel/irq_work.c | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/include/asm/irq_work.h
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index 8fa909c..3bf000f 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -7,6 +7,5 @@ genhdr-y += unistd_x32.h
generic-y += clkdev.h
generic-y += cputime.h
generic-y += early_ioremap.h
-generic-y += irq_work.h
generic-y += mcs_spinlock.h
generic-y += scatterlist.h
diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
new file mode 100644
index 000..78162f8
--- /dev/null
+++ b/arch/x86/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+ return cpu_has_apic;
+}
+
+#endif /* _ASM_IRQ_WORK_H */
diff --git a/arch/x86/kernel/irq_work.c b/arch/x86/kernel/irq_work.c
index 1de84e3..15d741d 100644
--- a/arch/x86/kernel/irq_work.c
+++ b/arch/x86/kernel/irq_work.c
@@ -41,7 +41,7 @@ __visible void smp_trace_irq_work_interrupt(struct pt_regs
*regs)
void arch_irq_work_raise(void)
{
#ifdef CONFIG_X86_LOCAL_APIC
- if (!cpu_has_apic)
+ if (!arch_irq_work_has_interrupt())
return;
apic->send_IPI_self(IRQ_WORK_VECTOR);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] arm: Tell irq work about self IPI support
ARM irq work IPI support depends on SMP support. That information is
partly known at early boottime. Lets implement
arch_irq_work_has_interrupt() accordingly.
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Russell King
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
arch/arm/include/asm/Kbuild | 1 -
arch/arm/include/asm/irq_work.h | 11 +++
arch/arm/kernel/smp.c | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/asm/irq_work.h
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 202905e..70cd84e 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -11,7 +11,6 @@ generic-y += hash.h
generic-y += ioctl.h
generic-y += ipcbuf.h
generic-y += irq_regs.h
-generic-y += irq_work.h
generic-y += kdebug.h
generic-y += local.h
generic-y += local64.h
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
new file mode 100644
index 000..712d03e
--- /dev/null
+++ b/arch/arm/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_ARM_IRQ_WORK_H
+#define __ASM_ARM_IRQ_WORK_H
+
+#include
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+ return is_smp();
+}
+
+#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9388a3d..bbe22fc 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -503,7 +503,7 @@ void arch_send_call_function_single_ipi(int cpu)
#ifdef CONFIG_IRQ_WORK
void arch_irq_work_raise(void)
{
- if (is_smp())
+ if (arch_irq_work_has_interrupt())
smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
}
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] nohz: Move nohz full init call to tick init
This way we unbloat a bit main.c and more importantly we initialize
nohz full after init_IRQ(). This dependency will be needed in further
patches because nohz full needs irq work to raise its own IRQ.
Information about the support for this ability on ARM64 is obtained on
init_IRQ() which initialize the pointer to __smp_call_function.
Since tick_init() is called right after init_IRQ(), this is a good place
to call tick_nohz_init() and prepare for that dependency.
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h| 2 --
init/main.c | 1 -
kernel/time/tick-common.c | 1 +
kernel/time/tick-internal.h | 7 +++
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 9a82c7d..595ee86 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -181,14 +181,12 @@ static inline bool tick_nohz_full_cpu(int cpu)
return cpumask_test_cpu(cpu, tick_nohz_full_mask);
}
-extern void tick_nohz_init(void);
extern void __tick_nohz_full_check(void);
extern void tick_nohz_full_kick(void);
extern void tick_nohz_full_kick_cpu(int cpu);
extern void tick_nohz_full_kick_all(void);
extern void __tick_nohz_task_switch(struct task_struct *tsk);
#else
-static inline void tick_nohz_init(void) { }
static inline bool tick_nohz_full_enabled(void) { return false; }
static inline bool tick_nohz_full_cpu(int cpu) { return false; }
static inline void __tick_nohz_full_check(void) { }
diff --git a/init/main.c b/init/main.c
index bb1aed9..8af2f1a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -577,7 +577,6 @@ asmlinkage __visible void __init start_kernel(void)
local_irq_disable();
idr_init_cache();
rcu_init();
- tick_nohz_init();
context_tracking_init();
radix_tree_init();
/* init some links before init_ISA_irqs() */
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 0a0608e..052b4b5 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -400,4 +400,5 @@ void tick_resume(void)
void __init tick_init(void)
{
tick_broadcast_init();
+ tick_nohz_init();
}
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index c19c1d8..366aeb4 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -99,6 +99,13 @@ static inline int tick_broadcast_oneshot_active(void) {
return 0; }
static inline bool tick_broadcast_oneshot_available(void) { return false; }
#endif /* !TICK_ONESHOT */
+/* NO_HZ_FULL internal */
+#ifdef CONFIG_NO_HZ_FULL
+extern void tick_nohz_init(void);
+# else
+static inline void tick_nohz_init(void) { }
+#endif
+
/*
* Broadcasting support
*/
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] arm64: Tell irq work about self IPI support
ARM64 irq work self-IPI support depends on __smp_cross_call to point to
some relevant IRQ controller operations. This information should be
available after the call to init_IRQ().
Lets implement arch_irq_work_has_interrupt() accordingly.
Acked-by: Peter Zijlstra (Intel)
Acked-by: Catalin Marinas
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Signed-off-by: Frederic Weisbecker
---
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/irq_work.h | 11 +++
arch/arm64/include/asm/smp.h | 2 ++
arch/arm64/kernel/smp.c | 2 +-
4 files changed, 14 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/irq_work.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index d617789..c196847 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -19,7 +19,6 @@ generic-y += ioctl.h
generic-y += ioctls.h
generic-y += ipcbuf.h
generic-y += irq_regs.h
-generic-y += irq_work.h
generic-y += kdebug.h
generic-y += kmap_types.h
generic-y += kvm_para.h
diff --git a/arch/arm64/include/asm/irq_work.h
b/arch/arm64/include/asm/irq_work.h
new file mode 100644
index 000..8e24ef3
--- /dev/null
+++ b/arch/arm64/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_IRQ_WORK_H
+#define __ASM_IRQ_WORK_H
+
+#include
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+ return !!__smp_cross_call;
+}
+
+#endif /* __ASM_IRQ_WORK_H */
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index a498f2c..780f82c 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -48,6 +48,8 @@ extern void smp_init_cpus(void);
*/
extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
+extern void (*__smp_cross_call)(const struct cpumask *, unsigned int);
+
/*
* Called from the secondary holding pen, this is the secondary CPU entry
point.
*/
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 4743397..b06d1d9 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -470,7 +470,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
-static void (*__smp_cross_call)(const struct cpumask *, unsigned int);
+void (*__smp_cross_call)(const struct cpumask *, unsigned int);
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned
int))
{
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] irq_work: Force raised irq work to run on irq work interrupt
The nohz full kick, which restarts the tick when any resource depend
on it, can't be executed anywhere given the operation it does on timers.
If it is called from the scheduler or timers code, chances are that
we run into a deadlock.
This is why we run the nohz full kick from an irq work. That way we make
sure that the kick runs on a virgin context.
However if that's the case when irq work runs in its own dedicated
self-ipi, things are different for the big bunch of archs that don't
support the self triggered way. In order to support them, irq works are
also handled by the timer interrupt as fallback.
Now when irq works run on the timer interrupt, the context isn't blank.
More precisely, they can run in the context of the hrtimer that runs the
tick. But the nohz kick cancels and restarts this hrtimer and cancelling
an hrtimer from itself isn't allowed. This is why we run in an endless
loop:
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2
CPU: 2 PID: 7538 Comm: kworker/u8:8 Not tainted 3.16.0+ #34
Workqueue: btrfs-endio-write normal_work_helper [btrfs]
880244c06c88 1b486fe1 880244c06bf0 8a7f1e37
8ac52a18 880244c06c78 8a7ef928 0010
880244c06c88 880244c06c20 1b486fe1
Call Trace:
] dump_stack+0x4e/0x7a
[] panic+0xd4/0x207
[] watchdog_overflow_callback+0x118/0x120
[] __perf_event_overflow+0xae/0x350
[] ? perf_event_task_disable+0xa0/0xa0
[] ? x86_perf_event_set_period+0xbf/0x150
[] perf_event_overflow+0x14/0x20
[] intel_pmu_handle_irq+0x206/0x410
[] perf_event_nmi_handler+0x2b/0x50
[] nmi_handle+0xd2/0x390
[] ? nmi_handle+0x5/0x390
[] ? match_held_lock+0x8/0x1b0
[] default_do_nmi+0x72/0x1c0
[] do_nmi+0xb8/0x100
[] end_repeat_nmi+0x1e/0x2e
[] ? match_held_lock+0x8/0x1b0
[] ? match_held_lock+0x8/0x1b0
[] ? match_held_lock+0x8/0x1b0
<] lock_acquired+0xaf/0x450
[] ? lock_hrtimer_base.isra.20+0x25/0x50
[] _raw_spin_lock_irqsave+0x78/0x90
[] ? lock_hrtimer_base.isra.20+0x25/0x50
[] lock_hrtimer_base.isra.20+0x25/0x50
[] hrtimer_try_to_cancel+0x33/0x1e0
[] hrtimer_cancel+0x1a/0x30
[] tick_nohz_restart+0x17/0x90
[] __tick_nohz_full_check+0xc3/0x100
[] nohz_full_kick_work_func+0xe/0x10
[] irq_work_run_list+0x44/0x70
[] irq_work_run+0x2a/0x50
[] update_process_times+0x5b/0x70
[] tick_sched_handle.isra.21+0x25/0x60
[] tick_sched_timer+0x41/0x60
[] __run_hrtimer+0x72/0x470
[] ? tick_sched_do_timer+0xb0/0xb0
[] hrtimer_interrupt+0x117/0x270
[] local_apic_timer_interrupt+0x37/0x60
[] smp_apic_timer_interrupt+0x3f/0x50
[] apic_timer_interrupt+0x6f/0x80
To fix this we force non-lazy irq works to run on irq work self-IPIs
when available. That ability of the arch to trigger irq work self IPIs
is available with arch_irq_work_has_interrupt().
Reported-by: Catalin Iacob
Reported-by: Dave Jones
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
include/linux/irq_work.h | 1 +
kernel/irq_work.c| 15 +--
kernel/time/timer.c | 2 +-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 6b47b2e..bf3fe71 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -39,6 +39,7 @@ bool irq_work_queue_on(struct irq_work *work, int cpu);
#endif
void irq_work_run(void);
+void irq_work_tick(void);
void irq_work_sync(struct irq_work *work);
#ifdef CONFIG_IRQ_WORK
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index e6bcbe7..385b85ad 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -115,8 +115,10 @@ bool irq_work_needs_cpu(void)
raised = &__get_cpu_var(raised_list);
lazy = &__get_cpu_var(lazy_list);
- if (llist_empty(raised) && llist_empty(lazy))
- return false;
+
+ if (llist_empty(raised) || arch_irq_work_has_interrupt())
+ if (llist_empty(lazy))
+ return false;
/* All work should have been flushed before going offline */
WARN_ON_ONCE(cpu_is_offline(smp_processor_id()));
@@ -171,6 +173,15 @@ void irq_work_run(void)
}
EXPORT_SYMBOL_GPL(irq_work_run);
+void irq_work_tick(void)
+{
+ struct llist_head *raised = &__get_cpu_var(raised_list);
+
+ if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
+ irq_work_run_list(raised);
+ irq_work_run_list(&__get_cpu_var(lazy_list));
+}
+
/*
* Synchronize against the irq_work @entry, ensures the entry is not
* currently in
[PATCH 2/8] irq_work: Introduce arch_irq_work_has_interrupt()
From: Peter Zijlstra The nohz full code needs irq work to trigger its own interrupt so that the subsystem can work even when the tick is stopped. Lets introduce arch_irq_work_has_interrupt() that archs can override to tell about their support for this ability. Signed-off-by: Peter Zijlstra Cc: Ingo Molnar Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Frederic Weisbecker --- arch/alpha/include/asm/Kbuild | 1 + arch/arc/include/asm/Kbuild| 1 + arch/arm/include/asm/Kbuild| 1 + arch/arm64/include/asm/Kbuild | 3 ++- arch/avr32/include/asm/Kbuild | 1 + arch/blackfin/include/asm/Kbuild | 1 + arch/c6x/include/asm/Kbuild| 1 + arch/cris/include/asm/Kbuild | 1 + arch/frv/include/asm/Kbuild| 1 + arch/hexagon/include/asm/Kbuild| 1 + arch/ia64/include/asm/Kbuild | 1 + arch/m32r/include/asm/Kbuild | 1 + arch/m68k/include/asm/Kbuild | 1 + arch/metag/include/asm/Kbuild | 1 + arch/microblaze/include/asm/Kbuild | 1 + arch/mips/include/asm/Kbuild | 1 + arch/mn10300/include/asm/Kbuild| 1 + arch/openrisc/include/asm/Kbuild | 1 + arch/parisc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/Kbuild| 1 + arch/s390/include/asm/Kbuild | 1 + arch/score/include/asm/Kbuild | 1 + arch/sh/include/asm/Kbuild | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/tile/include/asm/Kbuild | 1 + arch/um/include/asm/Kbuild | 1 + arch/unicore32/include/asm/Kbuild | 1 + arch/x86/include/asm/Kbuild| 1 + arch/xtensa/include/asm/Kbuild | 1 + include/asm-generic/irq_work.h | 10 ++ include/linux/irq_work.h | 2 ++ 31 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 include/asm-generic/irq_work.h diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index e858aa0..a52cbf1 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -4,6 +4,7 @@ generic-y += clkdev.h generic-y += cputime.h generic-y += exec.h generic-y += hash.h +generic-y += irq_work.h generic-y += mcs_spinlock.h generic-y += preempt.h generic-y += scatterlist.h diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index e76fd79..b8fffc1 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -18,6 +18,7 @@ generic-y += ioctl.h generic-y += ioctls.h generic-y += ipcbuf.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += kmap_types.h generic-y += kvm_para.h generic-y += local.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 70cd84e..202905e 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -11,6 +11,7 @@ generic-y += hash.h generic-y += ioctl.h generic-y += ipcbuf.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += kdebug.h generic-y += local.h generic-y += local64.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 0b3fcf8..d617789 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -9,8 +9,8 @@ generic-y += current.h generic-y += delay.h generic-y += div64.h generic-y += dma.h -generic-y += emergency-restart.h generic-y += early_ioremap.h +generic-y += emergency-restart.h generic-y += errno.h generic-y += ftrace.h generic-y += hash.h @@ -19,6 +19,7 @@ generic-y += ioctl.h generic-y += ioctls.h generic-y += ipcbuf.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += kdebug.h generic-y += kmap_types.h generic-y += kvm_para.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 00a0f3c..2a71b1c 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -9,6 +9,7 @@ generic-y += exec.h generic-y += futex.h generic-y += hash.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index 0d93b9a..46ed6bb 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -15,6 +15,7 @@ generic-y += hw_irq.h generic-y += ioctl.h generic-y += ipcbuf.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += kdebug.h generic-y += kmap_types.h generic-y += kvm_para.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index 8dbdce8..e77e0c1 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -22,6 +22,7 @@ generic-y += ioctl.h generic-y += ioctls.h generic-y += ipcbuf.h generic-y += irq_regs.h +generic-y += irq_work.h generic-y += kdebug.h generic-y += kmap_types.h generic-y += local.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 31742df..802b94c4 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -8,6 +8,7
[PATCH 0/8] nohz: Fix nohz kick irq work on tick v3
The v2 patches were pretty much agreed and these are mostly the same except for a few changes: 1) "x86: Tell irq work about self IPI support" now uses cpu_has instead of static_cpu_has. Unfortunately static_cpu_has() can't be called before the alternatives code is initialized which is way after IRQs are enabled for the first time on boot. Irq Work have many opportunies to be called in that window and calling static_cpu_has() there is illegal. 2) "irq_work: Force raised irq work to run on irq work interrupt" has a small optimization that first check from the irq_work_tick() whether the raised list is empty before checking if the arch can raise irq work(). Since that list should be empty most of the time, this reduce the fast-path to a single check. I'll do pull request in a few days if no comment arise. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git nohz/fixes-v3 HEAD: 9b01f5bf3999a3db5b1bbd9fdfd80d8d304e94ee Thanks, Frederic --- Frederic Weisbecker (7): nohz: Move nohz full init call to tick init irq_work: Force raised irq work to run on irq work interrupt x86: Tell irq work about self IPI support arm: Tell irq work about self IPI support arm64: Tell irq work about self IPI support nohz: Consolidate nohz full init code nohz: nohz full depends on irq work self IPI support Peter Zijlstra (1): irq_work: Introduce arch_irq_work_has_interrupt() arch/alpha/include/asm/Kbuild | 1 + arch/arc/include/asm/Kbuild| 1 + arch/arm/include/asm/irq_work.h| 11 arch/arm/kernel/smp.c | 2 +- arch/arm64/include/asm/Kbuild | 2 +- arch/arm64/include/asm/irq_work.h | 11 arch/arm64/include/asm/smp.h | 2 ++ arch/arm64/kernel/smp.c| 2 +- arch/avr32/include/asm/Kbuild | 1 + arch/blackfin/include/asm/Kbuild | 1 + arch/c6x/include/asm/Kbuild| 1 + arch/cris/include/asm/Kbuild | 1 + arch/frv/include/asm/Kbuild| 1 + arch/hexagon/include/asm/Kbuild| 1 + arch/ia64/include/asm/Kbuild | 1 + arch/m32r/include/asm/Kbuild | 1 + arch/m68k/include/asm/Kbuild | 1 + arch/metag/include/asm/Kbuild | 1 + arch/microblaze/include/asm/Kbuild | 1 + arch/mips/include/asm/Kbuild | 1 + arch/mn10300/include/asm/Kbuild| 1 + arch/openrisc/include/asm/Kbuild | 1 + arch/parisc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/Kbuild| 1 + arch/s390/include/asm/Kbuild | 1 + arch/score/include/asm/Kbuild | 1 + arch/sh/include/asm/Kbuild | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/tile/include/asm/Kbuild | 1 + arch/um/include/asm/Kbuild | 1 + arch/unicore32/include/asm/Kbuild | 1 + arch/x86/include/asm/irq_work.h| 11 arch/x86/kernel/irq_work.c | 2 +- arch/xtensa/include/asm/Kbuild | 1 + include/asm-generic/irq_work.h | 10 include/linux/irq_work.h | 3 +++ include/linux/tick.h | 2 -- init/main.c| 1 - kernel/irq_work.c | 15 +-- kernel/time/tick-common.c | 1 + kernel/time/tick-internal.h| 7 + kernel/time/tick-sched.c | 52 -- kernel/time/timer.c| 2 +- 43 files changed, 133 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] nohz: nohz full depends on irq work self IPI support
The nohz full functionality depends on IRQ work to trigger its own
interrupts. As it's used to restart the tick, we can't rely on the tick
fallback for irq work callbacks, ie: we can't use the tick to restart
the tick itself.
Lets reject the full dynticks initialization if that arch support isn't
available.
As a side effect, this makes sure that nohz kick is never called from
the tick. That otherwise would result in illegal hrtimer self-cancellation
and lockup.
Acked-by: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index eb4af01..5a9ff24 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -365,6 +365,20 @@ void __init tick_nohz_init(void)
return;
}
+ /*
+* Full dynticks uses irq work to drive the tick rescheduling on safe
+* locking contexts. But then we need irq work to raise its own
+* interrupts to avoid circular dependency on the tick
+*/
+ if (!arch_irq_work_has_interrupt()) {
+ pr_warning("NO_HZ: Can't run full dynticks because arch doesn't
"
+ "support irq work self-IPIs\n");
+ cpumask_clear(tick_nohz_full_mask);
+ cpumask_copy(housekeeping_mask, cpu_possible_mask);
+ tick_nohz_full_running = false;
+ return;
+ }
+
cpu = smp_processor_id();
if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re
Hello, I have a business proposal I'd like to share with you, on your response I'll email you with more details. I await your prompt reply on this. Kind regards Richard Wong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED_CTXSW)
В Вс, 21/09/2014 в 00:09 +0400, Kirill Tkhai пишет:
> В Сб, 20/09/2014 в 20:54 +0200, Peter Zijlstra пишет:
> > On Sat, Sep 20, 2014 at 08:33:26PM +0200, Peter Zijlstra wrote:
> > > On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote:
> > > > From: Kirill Tkhai
> > > >
> > > > We may pick a task which is in context_switch() on other cpu at the
> > > > moment.
> > > > Parallel using of a single stack by two processes is not a good idea.
> > >
> > > Please elaborate on who exactly that might happen. Its best to have
> > > comprehensive changelogs for issues that fix races.
> >
> > FWIW IIRC we can remove UNLOCKED_CTXSW from IA64 and I forgot if I
> > audited MIPS, but I suspect we can (and should) remove it there too.
> >
> > That would make this exception go away and clean up some of this ugly.
>
> Yeah, you've said me about IA64:
>
> http://www.spinics.net/lists/linux-ia64/msg10229.html
>
> It's about 10 years since the logic, which was documented in ia64
> header, has been removed. It looks like, ia64 maintainers are not
> interested much...
>
> ***
>
> To do not to start a new message. I've found the above when I was
> analysing if the optimisation below is OK (assume, we have accessor
> cpu_relax__while_on_cpu()):
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7d0d023..8d765ba 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1699,8 +1699,6 @@ try_to_wake_up(struct task_struct *p, unsigned int
> state, int wake_flags)
> goto stat;
>
> #ifdef CONFIG_SMP
> - cpu_relax__while_on_cpu(p);
> -
> p->sched_contributes_to_load = !!task_contributes_to_load(p);
> p->state = TASK_WAKING;
>
> @@ -1708,6 +1706,9 @@ try_to_wake_up(struct task_struct *p, unsigned int
> state, int wake_flags)
> p->sched_class->task_waking(p);
>
> cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
> +
> + cpu_relax__while_on_cpu(p);
> +
> if (task_cpu(p) != cpu) {
> wake_flags |= WF_MIGRATED;
> set_task_cpu(p, cpu);
>
> Looks like, now problem here. Task p is dequeued, we can set
> sched_contributes_to_load and state
s/now/no/
> here, also task_waking does not produce problems, only arithmetics is there.
> select_task_rq()
> is R/O function.
>
> Now I'm testing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re:
Hello, I have a business proposal I'd like to share with you, on your response I'll email you with more details. I await your prompt reply on this. Kind regards Richard Wong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED_CTXSW)
В Сб, 20/09/2014 в 20:54 +0200, Peter Zijlstra пишет:
> On Sat, Sep 20, 2014 at 08:33:26PM +0200, Peter Zijlstra wrote:
> > On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote:
> > > From: Kirill Tkhai
> > >
> > > We may pick a task which is in context_switch() on other cpu at the
> > > moment.
> > > Parallel using of a single stack by two processes is not a good idea.
> >
> > Please elaborate on who exactly that might happen. Its best to have
> > comprehensive changelogs for issues that fix races.
>
> FWIW IIRC we can remove UNLOCKED_CTXSW from IA64 and I forgot if I
> audited MIPS, but I suspect we can (and should) remove it there too.
>
> That would make this exception go away and clean up some of this ugly.
Yeah, you've said me about IA64:
http://www.spinics.net/lists/linux-ia64/msg10229.html
It's about 10 years since the logic, which was documented in ia64
header, has been removed. It looks like, ia64 maintainers are not
interested much...
***
To do not to start a new message. I've found the above when I was
analysing if the optimisation below is OK (assume, we have accessor
cpu_relax__while_on_cpu()):
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7d0d023..8d765ba 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1699,8 +1699,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state,
int wake_flags)
goto stat;
#ifdef CONFIG_SMP
- cpu_relax__while_on_cpu(p);
-
p->sched_contributes_to_load = !!task_contributes_to_load(p);
p->state = TASK_WAKING;
@@ -1708,6 +1706,9 @@ try_to_wake_up(struct task_struct *p, unsigned int state,
int wake_flags)
p->sched_class->task_waking(p);
cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
+
+ cpu_relax__while_on_cpu(p);
+
if (task_cpu(p) != cpu) {
wake_flags |= WF_MIGRATED;
set_task_cpu(p, cpu);
Looks like, now problem here. Task p is dequeued, we can set
sched_contributes_to_load and state
here, also task_waking does not produce problems, only arithmetics is there.
select_task_rq()
is R/O function.
Now I'm testing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3] mm: memcontrol: continue cache reclaim from offlined groups
On cgroup deletion, outstanding page cache charges are moved to the
parent group so that they're not lost and can be reclaimed during
pressure on/inside said parent. But this reparenting is fairly tricky
and its synchroneous nature has led to several lock-ups in the past.
Since css iterators now also include offlined css, memcg iterators can
be changed to include offlined children during reclaim of a group, and
leftover cache can just stay put.
There is a slight change of behavior in that charges of deleted groups
no longer show up as local charges in the parent. But they are still
included in the parent's hierarchical statistics.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 260 ++--
1 file changed, 5 insertions(+), 255 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 019a44ac25d6..48531433a2fc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -736,8 +736,6 @@ static void disarm_static_keys(struct mem_cgroup *memcg)
disarm_kmem_keys(memcg);
}
-static void drain_all_stock_async(struct mem_cgroup *memcg);
-
static struct mem_cgroup_per_zone *
mem_cgroup_zone_zoneinfo(struct mem_cgroup *memcg, struct zone *zone)
{
@@ -1208,7 +1206,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
*root,
goto out_unlock;
continue;
}
- if (css == >css || css_tryget_online(css)) {
+ if (css == >css || css_tryget(css)) {
memcg = mem_cgroup_from_css(css);
break;
}
@@ -2349,10 +2347,12 @@ static void refill_stock(struct mem_cgroup *memcg,
unsigned int nr_pages)
* of the hierarchy under it. sync flag says whether we should block
* until the work is done.
*/
-static void drain_all_stock(struct mem_cgroup *root_memcg, bool sync)
+static void drain_all_stock(struct mem_cgroup *root_memcg)
{
int cpu, curcpu;
+ if (!mutex_trylock(_charge_mutex))
+ return;
/* Notify other cpus that system-wide "drain" is running */
get_online_cpus();
curcpu = get_cpu();
@@ -2373,41 +2373,7 @@ static void drain_all_stock(struct mem_cgroup
*root_memcg, bool sync)
}
}
put_cpu();
-
- if (!sync)
- goto out;
-
- for_each_online_cpu(cpu) {
- struct memcg_stock_pcp *stock = _cpu(memcg_stock, cpu);
- if (test_bit(FLUSHING_CACHED_CHARGE, >flags))
- flush_work(>work);
- }
-out:
put_online_cpus();
-}
-
-/*
- * Tries to drain stocked charges in other cpus. This function is asynchronous
- * and just put a work per cpu for draining localy on each cpu. Caller can
- * expects some charges will be back later but cannot wait for it.
- */
-static void drain_all_stock_async(struct mem_cgroup *root_memcg)
-{
- /*
-* If someone calls draining, avoid adding more kworker runs.
-*/
- if (!mutex_trylock(_charge_mutex))
- return;
- drain_all_stock(root_memcg, false);
- mutex_unlock(_charge_mutex);
-}
-
-/* This is a synchronous drain interface. */
-static void drain_all_stock_sync(struct mem_cgroup *root_memcg)
-{
- /* called when force_empty is called */
- mutex_lock(_charge_mutex);
- drain_all_stock(root_memcg, true);
mutex_unlock(_charge_mutex);
}
@@ -2515,7 +2481,7 @@ retry:
goto retry;
if (!drained) {
- drain_all_stock_async(mem_over_limit);
+ drain_all_stock(mem_over_limit);
drained = true;
goto retry;
}
@@ -3366,79 +3332,6 @@ out:
return ret;
}
-/**
- * mem_cgroup_move_parent - moves page to the parent group
- * @page: the page to move
- * @pc: page_cgroup of the page
- * @child: page's cgroup
- *
- * move charges to its parent or the root cgroup if the group has no
- * parent (aka use_hierarchy==0).
- * Although this might fail (get_page_unless_zero, isolate_lru_page or
- * mem_cgroup_move_account fails) the failure is always temporary and
- * it signals a race with a page removal/uncharge or migration. In the
- * first case the page is on the way out and it will vanish from the LRU
- * on the next attempt and the call should be retried later.
- * Isolation from the LRU fails only if page has been isolated from
- * the LRU since we looked at it and that usually means either global
- * reclaim or migration going on. The page will either get back to the
- * LRU or vanish.
- * Finaly mem_cgroup_move_account fails only if the page got uncharged
- * (!PageCgroupUsed) or moved to a different group. The page will
- * disappear in the next attempt.
- */
-static int mem_cgroup_move_parent(struct page *page,
- struct page_cgroup *pc,
- struct mem_cgroup *child)
-{
- struct
[patch 1/3] mm: memcontrol: take a css reference for each charged page
Charges currently pin the css indirectly by playing tricks during
css_offline(): user pages stall the offlining process until all of
them have been reparented, whereas kmemcg acquires a keep-alive
reference if outstanding kernel pages are detected at that point.
In preparation for removing all this complexity, make the pinning
explicit and acquire a css references for every charged page.
Signed-off-by: Johannes Weiner
---
include/linux/cgroup.h | 26 +
include/linux/percpu-refcount.h | 43 -
mm/memcontrol.c | 17 +++-
3 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b5223c570eba..a9fe70d9c7c5 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -113,6 +113,19 @@ static inline void css_get(struct cgroup_subsys_state *css)
}
/**
+ * css_get_many - obtain references on the specified css
+ * @css: target css
+ * @n: number of references to get
+ *
+ * The caller must already have a reference.
+ */
+static inline void css_get_many(struct cgroup_subsys_state *css, unsigned int
n)
+{
+ if (!(css->flags & CSS_NO_REF))
+ percpu_ref_get_many(>refcnt, n);
+}
+
+/**
* css_tryget - try to obtain a reference on the specified css
* @css: target css
*
@@ -159,6 +172,19 @@ static inline void css_put(struct cgroup_subsys_state *css)
percpu_ref_put(>refcnt);
}
+/**
+ * css_put_many - put css references
+ * @css: target css
+ * @n: number of references to put
+ *
+ * Put references obtained via css_get() and css_tryget_online().
+ */
+static inline void css_put_many(struct cgroup_subsys_state *css, unsigned int
n)
+{
+ if (!(css->flags & CSS_NO_REF))
+ percpu_ref_put_many(>refcnt, n);
+}
+
/* bits in struct cgroup flags field */
enum {
/*
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index b1973ba1d5f3..a4551456e06f 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -112,26 +112,38 @@ static inline bool __pcpu_ref_alive(struct percpu_ref
*ref,
}
/**
- * percpu_ref_get - increment a percpu refcount
+ * percpu_ref_get_many - increment a percpu refcount
* @ref: percpu_ref to get
+ * @nr: number of references to get
*
- * Analagous to atomic_inc().
+ * Analagous to atomic_add().
*/
-static inline void percpu_ref_get(struct percpu_ref *ref)
+static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned long
nr)
{
unsigned long __percpu *pcpu_count;
rcu_read_lock_sched();
if (__pcpu_ref_alive(ref, _count))
- this_cpu_inc(*pcpu_count);
+ this_cpu_add(*pcpu_count, nr);
else
- atomic_long_inc(>count);
+ atomic_long_add(nr, >count);
rcu_read_unlock_sched();
}
/**
+ * percpu_ref_get - increment a percpu refcount
+ * @ref: percpu_ref to get
+ *
+ * Analagous to atomic_inc().
+ */
+static inline void percpu_ref_get(struct percpu_ref *ref)
+{
+ percpu_ref_get_many(ref, 1);
+}
+
+/**
* percpu_ref_tryget - try to increment a percpu refcount
* @ref: percpu_ref to try-get
*
@@ -191,27 +203,40 @@ static inline bool percpu_ref_tryget_live(struct
percpu_ref *ref)
}
/**
- * percpu_ref_put - decrement a percpu refcount
+ * percpu_ref_put_many - decrement a percpu refcount
* @ref: percpu_ref to put
+ * @nr: number of references to put
*
* Decrement the refcount, and if 0, call the release function (which was
passed
* to percpu_ref_init())
*/
-static inline void percpu_ref_put(struct percpu_ref *ref)
+static inline void percpu_ref_put_many(struct percpu_ref *ref, unsigned long
nr)
{
unsigned long __percpu *pcpu_count;
rcu_read_lock_sched();
if (__pcpu_ref_alive(ref, _count))
- this_cpu_dec(*pcpu_count);
- else if (unlikely(atomic_long_dec_and_test(>count)))
+ this_cpu_sub(*pcpu_count, nr);
+ else if (unlikely(atomic_long_sub_and_test(nr, >count)))
ref->release(ref);
rcu_read_unlock_sched();
}
/**
+ * percpu_ref_put - decrement a percpu refcount
+ * @ref: percpu_ref to put
+ *
+ * Decrement the refcount, and if 0, call the release function (which was
passed
+ * to percpu_ref_init())
+ */
+static inline void percpu_ref_put(struct percpu_ref *ref)
+{
+ percpu_ref_put_many(ref, 1);
+}
+
+/**
* percpu_ref_is_zero - test whether a percpu refcount reached zero
* @ref: percpu_ref to test
*
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 154161bb7d4c..b832c87ec43b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2317,6 +2317,7 @@ static void drain_stock(struct memcg_stock_pcp *stock)
page_counter_uncharge(>memory, stock->nr_pages);
if (do_swap_account)
page_counter_uncharge(>memsw,
[patch 0/3] mm: memcontrol: eliminate charge reparenting
Hi, we've come a looong way when it comes to the basic cgroups model, and the recent changes there open up a lot of opportunity to make drastic simplifications to memory cgroups as well. The decoupling of css from the user-visible cgroup, word-sized per-cpu css reference counters, and css iterators that include offlined groups means we can take per-charge css references, continue to reclaim from offlined groups, and so get rid of the error-prone charge reparenting. Combined with the higher-order reclaim fixes, lockless page counters, and memcg iterator simplification I sent on Friday, the memory cgroup core code is finally no longer the biggest file in mm/. Yay! These patches are based on mmotm + the above-mentioned changes + Tj's percpu-refcount conversion to atomic_long_t. Thanks! include/linux/cgroup.h | 26 +++ include/linux/percpu-refcount.h | 43 - mm/memcontrol.c | 337 ++ 3 files changed, 75 insertions(+), 331 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/3] mm: memcontrol: remove obsolete kmemcg pinning tricks
As charges now pin the css explicitely, there is no more need for
kmemcg to acquire a proxy reference for outstanding pages during
offlining, or maintain state to identify such "dead" groups.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 74 +
1 file changed, 1 insertion(+), 73 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b832c87ec43b..019a44ac25d6 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -471,7 +471,6 @@ struct mem_cgroup {
/* internal only representation about the status of kmem accounting. */
enum {
KMEM_ACCOUNTED_ACTIVE, /* accounted by this cgroup itself */
- KMEM_ACCOUNTED_DEAD, /* dead memcg with pending kmem charges */
};
#ifdef CONFIG_MEMCG_KMEM
@@ -485,22 +484,6 @@ static bool memcg_kmem_is_active(struct mem_cgroup *memcg)
return test_bit(KMEM_ACCOUNTED_ACTIVE, >kmem_account_flags);
}
-static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
-{
- /*
-* Our caller must use css_get() first, because memcg_uncharge_kmem()
-* will call css_put() if it sees the memcg is dead.
-*/
- smp_wmb();
- if (test_bit(KMEM_ACCOUNTED_ACTIVE, >kmem_account_flags))
- set_bit(KMEM_ACCOUNTED_DEAD, >kmem_account_flags);
-}
-
-static bool memcg_kmem_test_and_clear_dead(struct mem_cgroup *memcg)
-{
- return test_and_clear_bit(KMEM_ACCOUNTED_DEAD,
- >kmem_account_flags);
-}
#endif
/* Stuffs for move charges at task migration. */
@@ -2807,22 +2790,7 @@ static void memcg_uncharge_kmem(struct mem_cgroup *memcg,
if (do_swap_account)
page_counter_uncharge(>memsw, nr_pages);
- /* Not down to 0 */
- if (page_counter_uncharge(>kmem, nr_pages)) {
- css_put_many(>css, nr_pages);
- return;
- }
-
- /*
-* Releases a reference taken in kmem_cgroup_css_offline in case
-* this last uncharge is racing with the offlining code or it is
-* outliving the memcg existence.
-*
-* The memory barrier imposed by test is paired with the
-* explicit one in memcg_kmem_mark_dead().
-*/
- if (memcg_kmem_test_and_clear_dead(memcg))
- css_put(>css);
+ page_counter_uncharge(>kmem, nr_pages);
css_put_many(>css, nr_pages);
}
@@ -4805,40 +4773,6 @@ static void memcg_destroy_kmem(struct mem_cgroup *memcg)
{
mem_cgroup_sockets_destroy(memcg);
}
-
-static void kmem_cgroup_css_offline(struct mem_cgroup *memcg)
-{
- if (!memcg_kmem_is_active(memcg))
- return;
-
- /*
-* kmem charges can outlive the cgroup. In the case of slab
-* pages, for instance, a page contain objects from various
-* processes. As we prevent from taking a reference for every
-* such allocation we have to be careful when doing uncharge
-* (see memcg_uncharge_kmem) and here during offlining.
-*
-* The idea is that that only the _last_ uncharge which sees
-* the dead memcg will drop the last reference. An additional
-* reference is taken here before the group is marked dead
-* which is then paired with css_put during uncharge resp. here.
-*
-* Although this might sound strange as this path is called from
-* css_offline() when the referencemight have dropped down to 0 and
-* shouldn't be incremented anymore (css_tryget_online() would
-* fail) we do not have other options because of the kmem
-* allocations lifetime.
-*/
- css_get(>css);
-
- memcg_kmem_mark_dead(memcg);
-
- if (atomic_long_read(>kmem.count))
- return;
-
- if (memcg_kmem_test_and_clear_dead(memcg))
- css_put(>css);
-}
#else
static int memcg_init_kmem(struct mem_cgroup *memcg, struct cgroup_subsys *ss)
{
@@ -4848,10 +4782,6 @@ static int memcg_init_kmem(struct mem_cgroup *memcg,
struct cgroup_subsys *ss)
static void memcg_destroy_kmem(struct mem_cgroup *memcg)
{
}
-
-static void kmem_cgroup_css_offline(struct mem_cgroup *memcg)
-{
-}
#endif
/*
@@ -5443,8 +5373,6 @@ static void mem_cgroup_css_offline(struct
cgroup_subsys_state *css)
}
spin_unlock(>event_list_lock);
- kmem_cgroup_css_offline(memcg);
-
/*
* This requires that offlining is serialized. Right now that is
* guaranteed because css_killed_work_fn() holds the cgroup_mutex.
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: Add generic support passing secondary devices addresses
On 09/20/2014 06:49 PM, Wolfram Sang wrote: On Fri, Sep 05, 2014 at 04:02:19PM +0200, Jean-Michel Hautbois wrote: Some I2C devices have multiple addresses assigned, for example each address corresponding to a different internal register map page of the device. So far drivers which need support for this have handled this with a driver specific and non-generic implementation, e.g. passing the additional address via platform data. This raises the first question for me: Are the additional addresses configurable? Sadly, I can't find good documentation for the adv7604. Otherwise, if I know I have a adv7604 and know its addresses, this information should go into the driver and not the DT. They are. The current driver hard codes the other addresses, but that's not working when you have multiple adv7604s on the same I2C bus. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mtd: nand: support ONFI timings mode retrieval for non-ONFI NANDs
On Sat, Sep 20, 2014 at 01:29:43PM +0200, Boris BREZILLON wrote:
> On Fri, 19 Sep 2014 21:46:07 -0700
> Brian Norris wrote:
>
> > Since you were asking about this series, I have a comment:
> >
> > On Mon, Jul 28, 2014 at 11:16:51AM +0200, Boris BREZILLON wrote:
> > > Add an onfi_timing_mode_ds field to nand_chip and nand_flash_dev in order
> > > to support NAND timings definition for non-ONFI NAND.
> > >
> > > NAND that support better timings mode than the default one (timings mode
> > > 0)
> > > have to define a new entry in the nand_ids table.
> > >
> > > The timings mode should be deduced from timings description from the
> > > datasheet and the ONFI specification
> > > (www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
> > > "Timing Parameters").
> > > You should choose the closest mode that fit the timings requirements of
> > > your NAND chip.
> > >
> > > Signed-off-by: Boris BREZILLON
> > > ---
> > > drivers/mtd/nand/nand_base.c | 1 +
> > > include/linux/mtd/nand.h | 7 +++
> > > 2 files changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> > > index d8cdf06..c952c21 100644
> > > --- a/drivers/mtd/nand/nand_base.c
> > > +++ b/drivers/mtd/nand/nand_base.c
> > > @@ -3576,6 +3576,7 @@ static bool find_full_id_nand(struct mtd_info *mtd,
> > > struct nand_chip *chip,
> > > chip->options |= type->options;
> > > chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
> > > chip->ecc_step_ds = NAND_ECC_STEP(type);
> > > + chip->onfi_timing_mode_ds = type->onfi_timing_mode_ds;
> > >
> > > *busw = type->options & NAND_BUSWIDTH_16;
> > >
> > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > > index 3083c53..435c005 100644
> > > --- a/include/linux/mtd/nand.h
> > > +++ b/include/linux/mtd/nand.h
> > > @@ -587,6 +587,7 @@ struct nand_buffers {
> > > * @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds,
> > > * also from the datasheet. It is the recommended
> > > ECC step
> > > * size, if known; if unknown, set to zero.
> > > + * @onfi_timing_mode_ds:[INTERN] ONFI timing mode deduced from datasheet.
> >
> > Might want at least one space between '[INTERN]' and 'ONFI'?
>
> You mean between the colon and '[INTERN]', right ?
Yep! My mistake.
> >
> > > * @numchips:[INTERN] number of physical chips
> > > * @chipsize:[INTERN] the size of one chip for multichip
> > > arrays
> > > * @pagemask:[INTERN] page number mask = number of (pages /
> > > chip) - 1
> > > @@ -671,6 +672,7 @@ struct nand_chip {
> > > uint8_t bits_per_cell;
> > > uint16_t ecc_strength_ds;
> > > uint16_t ecc_step_ds;
> > > + int onfi_timing_mode_ds;
> >
> > I'm not sure if we'll just want a field specific to non-ONFI chips,
> > faking an ONFI timing mode; can we make this into a more generally
> > useful field, that represents something consistent across all NAND
> > types? I was thinking a "highest mode supported", but that actually
> > isn't great, since for true ONFI modes (except mode 0) require a SET
> > FEATURES command to change to a higher mode.
> >
> > Maybe just something like onfi_timing_mode_default, which we could then
> > use as mode 0 for ONFI chips.
> >
> > Ideally, we could centralize as much of this as possible, so that a NAND
> > driver only has to know the mechanics of "how do I translate an ONFI
> > mode to a timing configuration for my NAND controller,"
>
> I guess you meant "how do I translate a NAND timing config given by
> nand_sdr_timings to my specific NAND controller config", right ?
Yes.
> > instead of any
> > details of how to choose from one of many supported ONFI modes. i.e., it
> > could implement something like the following hook:
> >
> > int (*set_timing_mode)(struct nand_sdr_timings *timing);
>
> I'm not opposed to this solution (I actually think this is how it
> should be done :-), and, IIRC, Jason proposed to do the same kind of
> things a while ago), but this means the conversion would be done by the
> NAND FW and passed to the NAND driver, and this implies reworking the
> drivers already directly using ONFI modes to configure their NAND
> timings to make use nand_sdr_timings instead.
I think we can safely ignore most of how drivers already configured
timings (I see at least denali.c with its own custom boot parameter),
and try to work out a solution that can be used by more than one driver
eventually. Conversion may or may not happen for some drivers, so we
should plan to have some sort of opt-in or opt-out ability.
> Moreover, I think we should define a union to handle several kind of
> timings (ddr NAND are coming :-P):
>
> enum nand_timings_type /* or nand_bus_type or something else ;-) */ {
> SDR_NAND,
> DDR_NAND,
> }
>
> struct nand_timings {
> enum nand_timings_type type;
> union {
>
Re: linux-next: Tree for Sep 19
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so I used the version from
next-20140917.
The v4l-dvb tree lost its build failure.
The security tree gained a conflict against the file-locks tree.
Non-merge commits (relative to Linus' tree): 6014
5488 files changed, 217522 insertions(+), 129375 deletions(-)
parisc:defconfig, parisc:generic-32bit_defconfig:
--
Error log:
arch/parisc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
arch/parisc/kernel/ptrace.c:274:2: error: implicit declaration of function
'secure_computing' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/parisc/kernel/ptrace.o] Error 1
Bisect points to commit 273299fb6380 ('Merge branch 'x86/seccomp') which
obviously doesn't help much. Suspected culprit is c90f06943e05 ('parisc: Wire up
seccomp, getrandom and memfd_create syscalls') which seems to be missing an
include file.
I could not reproduce this error with current git head.
Nevertheless, it probably makes sense to #include in ptrace.c
to
avoid a dependency on other header files to include it instead.
I've added this patch to my for-next tree:
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=0f18557b017b3469e1f8edf5cf34c1cba856fdbe
Could you try again?
Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] sched: Use dl_bw_of() under RCU read lock
On Sat, Sep 20, 2014 at 11:25:39PM +0400, Kirill Tkhai wrote: > On 20.09.2014 22:57, Peter Zijlstra wrote: > > On Sat, Sep 20, 2014 at 08:51:28PM +0400, Kirill Tkhai wrote: > >> From: Kirill Tkhai > >> > >> dl_bw_of() dereferences rq->rd which has to have RCU read lock held. > >> Probability of use-after-free and memory corruption aren't zero here. > >> > > > > Additionally we might want to add something like: > > lockdep_assert_held_rcu() and put that in dl_bw_of() and other such > > places. > > Should we change (not now, in general) RCU-related pointers to use > rcu_dereference() to have unlocked RCU warnings in dmesg? To catch > a problems like that. > > This may make code worse readable though. Possibly, we should probably use rcu_assign_pointer() and rcu_dereference() on rq->rd. Sometimes you can avoid that if you're playing games with static objects, but I don't think that is true here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] sched: Use dl_bw_of() under RCU read lock
On 20.09.2014 22:57, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 08:51:28PM +0400, Kirill Tkhai wrote: >> From: Kirill Tkhai >> >> dl_bw_of() dereferences rq->rd which has to have RCU read lock held. >> Probability of use-after-free and memory corruption aren't zero here. >> > > Additionally we might want to add something like: > lockdep_assert_held_rcu() and put that in dl_bw_of() and other such > places. Should we change (not now, in general) RCU-related pointers to use rcu_dereference() to have unlocked RCU warnings in dmesg? To catch a problems like that. This may make code worse readable though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] sched: Use rq->rd in sched_setaffinity() under RCU read lock
On 20.09.2014 23:18, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 11:05:46PM +0400, Kirill Tkhai wrote: >> On 20.09.2014 22:59, Peter Zijlstra wrote: >>> On Sat, Sep 20, 2014 at 08:51:40PM +0400, Kirill Tkhai wrote: From: Kirill Tkhai task_rq(p)->rd and task_rq(p)->rd->span may be used-after-free here. Probability of NULL pointer derefference isn't zero in this place. >>> >>> I don't see NULL derefs, just use-after-free. >>> >> >> It's very paranod case :). Two pointers are here: >> >> task_rq(p)->rd (somebody zeroed it "rd") ->span > > What you're saying is: due to the reuse someone might have put a NULL > in there. Which is fair, but I'd still call it use-after-free because > that is the first order problem. Dereferencing 'unknown' memory can of > course cause all kinds of 'fun' problems :-) Yeah, it's logical, I'll update the description. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] sched: Use rq->rd in sched_setaffinity() under RCU read lock
On Sat, Sep 20, 2014 at 11:05:46PM +0400, Kirill Tkhai wrote: > On 20.09.2014 22:59, Peter Zijlstra wrote: > > On Sat, Sep 20, 2014 at 08:51:40PM +0400, Kirill Tkhai wrote: > >> From: Kirill Tkhai > >> > >> task_rq(p)->rd and task_rq(p)->rd->span may be used-after-free here. > >> Probability of NULL pointer derefference isn't zero in this place. > > > > I don't see NULL derefs, just use-after-free. > > > > It's very paranod case :). Two pointers are here: > > task_rq(p)->rd (somebody zeroed it "rd") ->span What you're saying is: due to the reuse someone might have put a NULL in there. Which is fair, but I'd still call it use-after-free because that is the first order problem. Dereferencing 'unknown' memory can of course cause all kinds of 'fun' problems :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] sched: Use rq->rd in sched_setaffinity() under RCU read lock
On 20.09.2014 22:59, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 08:51:40PM +0400, Kirill Tkhai wrote: >> From: Kirill Tkhai >> >> task_rq(p)->rd and task_rq(p)->rd->span may be used-after-free here. >> Probability of NULL pointer derefference isn't zero in this place. > > I don't see NULL derefs, just use-after-free. > It's very paranod case :). Two pointers are here: task_rq(p)->rd (somebody zeroed it "rd") ->span -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED_CTXSW)
On Sat, Sep 20, 2014 at 08:33:26PM +0200, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote: > > From: Kirill Tkhai > > > > We may pick a task which is in context_switch() on other cpu at the moment. > > Parallel using of a single stack by two processes is not a good idea. > > Please elaborate on who exactly that might happen. Its best to have > comprehensive changelogs for issues that fix races. typing hard, ugh. s/who/how/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED_CTXSW)
On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote: > From: Kirill Tkhai > > We may pick a task which is in context_switch() on other cpu at the moment. > Parallel using of a single stack by two processes is not a good idea. Please elaborate on who exactly that might happen. Its best to have comprehensive changelogs for issues that fix races. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] sched: Delete rq::skip_clock_update == -1
On Sat, Sep 20, 2014 at 08:51:46PM +0400, Kirill Tkhai wrote: > From: Kirill Tkhai > > Idle class task is always queued, so we can safely remove "-1" case here. Tag you're it :-) https://lkml.org/lkml/2014/4/8/295 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] sched: Use rq->rd in sched_setaffinity() under RCU read lock
On Sat, Sep 20, 2014 at 08:51:40PM +0400, Kirill Tkhai wrote: > From: Kirill Tkhai > > task_rq(p)->rd and task_rq(p)->rd->span may be used-after-free here. > Probability of NULL pointer derefference isn't zero in this place. I don't see NULL derefs, just use-after-free. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] sched: Use dl_bw_of() under RCU read lock
On Sat, Sep 20, 2014 at 08:51:28PM +0400, Kirill Tkhai wrote: > From: Kirill Tkhai > > dl_bw_of() dereferences rq->rd which has to have RCU read lock held. > Probability of use-after-free and memory corruption aren't zero here. > Additionally we might want to add something like: lockdep_assert_held_rcu() and put that in dl_bw_of() and other such places. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED_CTXSW)
On Sat, Sep 20, 2014 at 08:33:26PM +0200, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote: > > From: Kirill Tkhai > > > > We may pick a task which is in context_switch() on other cpu at the moment. > > Parallel using of a single stack by two processes is not a good idea. > > Please elaborate on who exactly that might happen. Its best to have > comprehensive changelogs for issues that fix races. FWIW IIRC we can remove UNLOCKED_CTXSW from IA64 and I forgot if I audited MIPS, but I suspect we can (and should) remove it there too. That would make this exception go away and clean up some of this ugly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Bisected Problem with LSI PCI FC Adapter
Bjorn Helgaas writes: > On Sat, Sep 13, 2014 at 09:41:34PM +0200, Dirk Gouders wrote: >> So, I did some tests on the VX50 which probably wasn't the worst idea, >> because it behaves different than the test machine. >> >> Summary: >> >> 1) Bjorn's back pocket patch works on the VX50. >> >>On the test machine it causes a trace, mount_root has to do with >>it. I tried to use netconsole but it complained the interface were >>not ready. > > OK, that's good. I put this revert patch in for-linus for v3.17. I regard > this as a temporary fix, not the real solution. My guess is the test > machine doesn't boot because you're missing a driver, so not related to the > revert patch. I assumed my limit-host-bridge-aperture-and-ignore-bridges-patch on top of your patch caused this, so I took a closer look. Your patch works fine with current rc5+ on the test machine -- with and without my additional patch. rc2 and "make oldconfig" somehow caused that the root partition couldn't be mounted. With rc5+ everything is fine, again, without touching the configuration myself. Other various today's test results (VX50) will be appended to bugzilla in a few moments. Dirk >> 3) Reset with Bjorn's commands >> >>DEV=00:0e.0 >>setpci -s$DEV BRIDGE_CONTROL.W=0x0040 >>sleep 1 >>setpci -s$DEV BRIDGE_CONTROL.W=0x >>sleep 1 >>echo 1 > /sys/bus/pci/rescan >> >>let the FC adapter appear but there are errors that I cannot really >>interpret. >> >> 4) Reset with Yinghai's patches and >> >>echo 1 > /sys/bus/pci/devices/\:00\:0e.0/pcie_link_disable >>echo 0 > /sys/bus/pci/devices/\:00\:0e.0/pcie_link_disable >>echo 1 > /sys/bus/pci/rescan >> >>gives a similar resut to 3). > > Resetting the device or simply disabling and re-enabling the link was > enough to fix things from the device's perspective. In both cases, it > responded as one would expect: > > pci_scan_child_bus: pci_bus :06: scanning bus > pci :06:00.0: [1000:0646] type 00 class 0x0c0400 > pci :06:00.0: reg 0x10: [io 0x-0x00ff] > pci :06:00.0: reg 0x14: [mem 0x-0x3fff 64bit] > pci :06:00.0: reg 0x1c: [mem 0x-0x 64bit] > pci :06:00.0: reg 0x30: [mem 0x-0x000f pref] > > Linux tried to assign MMIO space to the device, but failed: > > pci :06:00.0: BAR 6: assigned [mem 0xd420-0xd42f pref] > pci :06:00.0: BAR 3: no space for [mem size 0x0001 64bit] > pci :06:00.0: BAR 3: failed to assign [mem size 0x0001 64bit] > pci :06:00.0: BAR 1: no space for [mem size 0x4000 64bit] > pci :06:00.0: BAR 1: failed to assign [mem size 0x4000 64bit] > > The upstream bridge windows are: > > pci :00:0e.0: PCI bridge to [bus 06]# was originally to bus 0a > pci :00:0e.0: bridge window [io 0x3000-0x3fff] > pci :00:0e.0: bridge window [mem 0xd420-0xd42f] > > So the ROM BAR (reg 0x30/BAR 6) takes up the whole window, leaving nothing > for BARs 1 and 3. This is something that Linux could do better. For > example, we could assign normal BARs first, followed by ROM BARs, since the > normal ones are more important. It's possible we could also try to expand > the bridge window so all the BARs would fit. > > In any case, resetting the device is not a simple fix all by itself. So > our possibilities are: > > 1) Quirk to work around _CRS bug. This works but requires us to maintain > CPU-specific code that I really don't want. > > 2) Reset device when changing bus number. This works from the device > point of view, but would require additional Linux changes. > > 3) Revert 1820ffdccb9b. This works but is ugly because we're ignoring > some of what _CRS tells us. > > Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wlan-ng: remove unused 'result' var
> you have not mentioned any commit log Sorry. Patch against linux-next, commit d7cf2b3139909a354a71e2885c942e21a60ea062 > > @@ -734,11 +732,10 @@ static int prism2mib_priv(struct mibrec *mib, > > wpa.datalen = cpu_to_le16(pstr->len); > > memcpy(wpa.data, pstr->data, pstr->len); > > > > - result = > > - hfa384x_drvr_setconfig(hw, > > - HFA384x_RID_CNFWPADATA, > > - (u8 *) , > > - sizeof(wpa)); > > + hfa384x_drvr_setconfig(hw, > > + HFA384x_RID_CNFWPADATA, > > + (u8 *) , > if you check your patch with --strict option then you will see one warning > here. There are many styling offences in this file. I didn't want to include unrelated changes in one patch. Grzegorz Swirski. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: s5pv210: add missing call to samsung_clk_of_add_provider()
On 19.09.2014 11:00, Marek Szyprowski wrote:
> Commit d5e136a21b2028fb1f45143ea7112d5869bfc6c7 ("clk: samsung: Register
> clk provider only after registering its all clocks", merged to v3.17-rc1)
> modified a way that driver registers registers to core framework. This
> change has not been applied to s5pv210 clocks driver, which has been
> merged in parallel to that commit. This patch adds a missing call to
> samsung_clk_of_add_provider(), so the driver is operational again.
>
> Signed-off-by: Marek Szyprowski
> ---
> Hello!
>
> This is an important fix to v3.17-rcX. Without it support for Samsung
> S5PV210 SoCs is not functional.
>
> Mike, could you take it to the fixes branch?
Acked-by: Tomasz Figa
Mike, since it seems like this is the only fix to be queued for next -rc
release, I think it would be reasonable if you picked it up directly.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wlan-ng: remove unused 'result' var
On Sat, Sep 20, 2014 at 12:09:11PM +0100, Grzegorz Swirski wrote:
> Signed-off-by: Grzegorz Swirski
you have not mentioned any commit log
> ---
> drivers/staging/wlan-ng/prism2mib.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2mib.c
> b/drivers/staging/wlan-ng/prism2mib.c
> index f471708..0163e06 100644
> --- a/drivers/staging/wlan-ng/prism2mib.c
> +++ b/drivers/staging/wlan-ng/prism2mib.c
> @@ -717,8 +717,6 @@ static int prism2mib_priv(struct mibrec *mib,
> {
> p80211pstrd_t *pstr = (p80211pstrd_t *) data;
>
> - int result;
> -
> switch (mib->did) {
> case DIDmib_lnx_lnxConfigTable_lnxRSNAIE:{
> hfa384x_WPAData_t wpa;
> @@ -734,11 +732,10 @@ static int prism2mib_priv(struct mibrec *mib,
> wpa.datalen = cpu_to_le16(pstr->len);
> memcpy(wpa.data, pstr->data, pstr->len);
>
> - result =
> - hfa384x_drvr_setconfig(hw,
> -HFA384x_RID_CNFWPADATA,
> -(u8 *) ,
> -sizeof(wpa));
> + hfa384x_drvr_setconfig(hw,
> +HFA384x_RID_CNFWPADATA,
> +(u8 *) ,
if you check your patch with --strict option then you will see one warning here.
thanks
sudip
> +sizeof(wpa));
> }
> break;
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: git rid of [sched_delayed] message for printk_deferred
On Sat, Sep 20, 2014 at 12:30:01PM -0400, Steven Rostedt wrote: > On Sat, 20 Sep 2014 09:10:47 -0700 > Joe Perches wrote: > > > On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote: > > > On a whole, printk() is entirely useless for debugging these days, its > > > far too fragile/unreliable to be taken seriously so I really don't care > > > on that point either. > > > > That's unfortunate. > > > > Care to enumerate the issues that you believe make > > printk too fragile/unreliable for debugging? > > I seldom use printk these days. It's far too limited in its uses. For > one, most things worth debugging happen thousands of times a second, > and printk will just slow things down to a crawl if it is used. > Another, is that it can not be used in most critical sections (NMI > handlers and anything that deals with the scheduler). Also, as it no > longer blocks when another CPU is doing a printk, a bug can happen > which crashes the system and the output of that bug will never get > printed due to the delayed output from another CPU having the console > lock. If you're trying to debug a dying machine the early_serial_console which basically only does a stream of OUTBs to the right port is the only reliable thing. For anything else, trace_printk(). Now all I need to figure out is how to keep suspend from killing the early_serial_console setup :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ARM: mvebu: armada-xp: Configure ix4-300d PCIe0 to x4
The PCIe controller on Port 0 of Lenovo ix4-300d is configured as
quad-lane x4. Correct the marvell,pcie-lane property accordingly.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Bjorn Helgaas
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 86be971f8fec..11f483c960b0 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -249,6 +249,7 @@
/* Quad port SATA: Marvell 88SX7042 */
{
+ marvell,pcie-lane = <0 1 2 3>;
status = "okay";
};
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ARM: mvebu: armada-xp: Correct misnumbered PCIe port nodes
Currently, Armada XP PCIe nodes are numbered pcie@,0 with N just
incrementing. To reflect port/lane relationship, rename the nodes
to pcie@,. While at it, add node aliases to each of pcie
controller and port nodes and get rid of now redundant port/lane
comments.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Bjorn Helgaas
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/boot/dts/armada-xp-axpwifiap.dts| 11 ---
arch/arm/boot/dts/armada-xp-db.dts | 20 +++-
arch/arm/boot/dts/armada-xp-gp.dts | 11 ---
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 8 +++-
arch/arm/boot/dts/armada-xp-matrix.dts | 5 ++---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 12 ++--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 20 ++--
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 22 +++---
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 11 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 ++---
10 files changed, 53 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index 0e53fad111de..1b2dd3a4000b 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -37,24 +37,21 @@
ranges = ;
- pcie-controller {
+ pcie: pcie-controller {
status = "okay";
/* First mini-PCIe port */
- pcie@1,0 {
- /* Port 0, Lane 0 */
+ pcie00: pcie@0,0 {
status = "okay";
};
/* Second mini-PCIe port */
- pcie@2,0 {
- /* Port 0, Lane 1 */
+ pcie01: pcie@0,1 {
status = "okay";
};
/* Renesas uPD720202 USB 3.0 controller */
- pcie@3,0 {
- /* Port 0, Lane 3 */
+ pcie03: pcie@0,3 {
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 42ddb2864365..3cda0f6e5c37 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -71,35 +71,29 @@
};
};
- pcie-controller {
+ pcie: pcie-controller {
status = "okay";
/*
* All 6 slots are physically present as
* standard PCIe slots on the board.
*/
- pcie@1,0 {
- /* Port 0, Lane 0 */
+ pcie00: pcie@0,0 {
status = "okay";
};
- pcie@2,0 {
- /* Port 0, Lane 1 */
+ pcie01: pcie@0,1 {
status = "okay";
};
- pcie@3,0 {
- /* Port 0, Lane 2 */
+ pcie02: pcie@0,2 {
status = "okay";
};
- pcie@4,0 {
- /* Port 0, Lane 3 */
+ pcie03: pcie@0,3 {
status = "okay";
};
- pcie@9,0 {
- /* Port 2, Lane 0 */
+ pcie20: pcie@2,0 {
status = "okay";
};
- pcie@10,0 {
- /* Port 3, Lane 0 */
+ pcie30: pcie@3,0 {
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 0478c55ca656..30435e85ff33 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -81,23 +81,20 @@
};
};
- pcie-controller {
+ pcie: pcie-controller {
status = "okay";
/*
* The 3 slots are physically present as
* standard PCIe slots on the board.
*/
-
[PATCH 1/5] PCI: mvebu: Amend PCIe controler node documentation
Some PCIe controllers found on Armada XP SoCs can be configured as
either four single-lane x1 or one quad-lane x4 PCIe. The current
binding documentation is a bit unclear about it, so amend the
property description of "marvell,pcie-lane" to allow multiple lanes
to be passed. Also, rework the binding example to not only show x1
configuration but both x4 and x1. While at it, correct misnumbered
PCIe port nodes to reflect pcie@, numbering scheme.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Bjorn Helgaas
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/pci/mvebu-pci.txt | 93 --
1 file changed, 31 insertions(+), 62 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 08c716b2c6b6..0f09c933e025 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -74,14 +74,29 @@ PCIe interface, having the following mandatory properties:
define the mapping of the PCIe interface to interrupt numbers.
and the following optional properties:
-- marvell,pcie-lane: the physical PCIe lane number, for ports having
- multiple lanes. If this property is not found, we assume that the
- value is 0.
+- marvell,pcie-lane: array of physical PCIe lanes. If this property is
+ not found, we assume that the value is 0, i.e. x1 PCIe on lane 0.
- reset-gpios: optional gpio to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion
Example:
+/*
+ * Armada XP has two 4x1/1x4 PCIe controllers on Port 0 and 1 that can
+ * be configured either as four single-lane x1 or one quad-lane x4 PCIe.
+ * Ports 2 and 3 are single-lane x1 only.
+ *
+ * The pcie-controller node below describes Armada XP PCIe configured as
+ *
+ * - Quad PCIe x4 on Port 0, Lanes 0-3
+ * - Single PCIe x1 on Port 1, Lane 0
+ * - Single PCIe x1 on Port 1, Lane 1
+ * - Single PCIe x1 on Port 1, Lane 2
+ * - Single PCIe x1 on Port 1, Lane 3
+ * - Single PCIe x1 on Port 2
+ * - Single PCIe x1 on Port 3
+ */
+
pcie-controller {
compatible = "marvell,armada-xp-pcie";
status = "disabled";
@@ -128,7 +143,7 @@ pcie-controller {
0x8200 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM
*/
0x8100 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO
*/>;
- pcie@1,0 {
+ pcie@0,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x4 0 0x2000>;
reg = <0x0800 0 0 0 0>;
@@ -139,8 +154,9 @@ pcie-controller {
0x8100 0 0 0x8100 0x1 0 1 0>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 58>;
+ /* Quad lane PCIe x4 on Port 0, Lanes 0-3 */
marvell,pcie-port = <0>;
- marvell,pcie-lane = <0>;
+ marvell,pcie-lane = <0 1 2 3>;
/* low-active PERST# reset on GPIO 25 */
reset-gpios = < 25 1>;
/* wait 20ms for device settle after reset deassertion */
@@ -149,58 +165,7 @@ pcie-controller {
status = "disabled";
};
- pcie@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
- reg = <0x1000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x8200 0 0 0x8200 0x2 0 1 0
- 0x8100 0 0 0x8100 0x2 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 59>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <1>;
- clocks = < 6>;
- status = "disabled";
- };
-
- pcie@3,0 {
- device_type = "pci";
- assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
- reg = <0x1800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x8200 0 0 0x8200 0x3 0 1 0
- 0x8100 0 0 0x8100 0x3 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 60>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <2>;
- clocks = < 7>;
- status = "disabled";
- };
-
- pcie@4,0 {
- device_type = "pci";
- assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
- reg = <0x2000 0 0 0 0>;
- #address-cells = <3>;
-
[PATCH 4/5] ARM: mvebu: armada-xp: Use PCIe node aliases
Armada XP pcie controller and port nodes gained aliases, make use of them.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Bjorn Helgaas
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/boot/dts/armada-xp-axpwifiap.dts| 30 +++--
arch/arm/boot/dts/armada-xp-db.dts | 42 +---
arch/arm/boot/dts/armada-xp-gp.dts | 27 +--
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 24 ++
arch/arm/boot/dts/armada-xp-matrix.dts | 12 +++
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 30 +++--
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 13 +++-
7 files changed, 65 insertions(+), 113 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index 1b2dd3a4000b..88c63ec6f355 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -37,25 +37,6 @@
ranges = ;
- pcie: pcie-controller {
- status = "okay";
-
- /* First mini-PCIe port */
- pcie00: pcie@0,0 {
- status = "okay";
- };
-
- /* Second mini-PCIe port */
- pcie01: pcie@0,1 {
- status = "okay";
- };
-
- /* Renesas uPD720202 USB 3.0 controller */
- pcie03: pcie@0,3 {
- status = "okay";
- };
- };
-
internal-regs {
serial@12000 {
status = "okay";
@@ -126,6 +107,17 @@
};
};
+ { status = "okay"; };
+
+/* First mini-PCIe port */
+ { status = "okay"; };
+
+/* Second mini-PCIe port */
+ { status = "okay"; };
+
+/* Renesas uPD720202 USB 3.0 controller */
+ { status = "okay"; };
+
{
pinctrl-0 = <_phy_int>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 3cda0f6e5c37..58c2892783a7 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -71,33 +71,6 @@
};
};
- pcie: pcie-controller {
- status = "okay";
-
- /*
-* All 6 slots are physically present as
-* standard PCIe slots on the board.
-*/
- pcie00: pcie@0,0 {
- status = "okay";
- };
- pcie01: pcie@0,1 {
- status = "okay";
- };
- pcie02: pcie@0,2 {
- status = "okay";
- };
- pcie03: pcie@0,3 {
- status = "okay";
- };
- pcie20: pcie@2,0 {
- status = "okay";
- };
- pcie30: pcie@3,0 {
- status = "okay";
- };
- };
-
internal-regs {
serial@12000 {
status = "okay";
@@ -190,3 +163,18 @@
};
};
};
+
+/* All 6 slots are physically present as standard PCIe slots on the board. */
+ { status = "okay"; };
+
+ { status = "okay"; };
+
+ { status = "okay"; };
+
+ { status = "okay"; };
+
+ { status = "okay"; };
+
+ { status = "okay"; };
+
+ { status = "okay"; };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 30435e85ff33..ee92bcf0d4bd 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -81,24 +81,6 @@
};
};
- pcie: pcie-controller {
- status = "okay";
-
- /*
-* The 3 slots are physically present as
-* standard PCIe slots on the board.
-*/
- pcie00: pcie@0,0 {
- status = "okay";
- };
- pcie20: pcie@2,0 {
- status = "okay";
- };
- pcie30: pcie@3,0 {
- status = "okay";
- };
- };
-
internal-regs {
[PATCH 2/5] PCI: mvebu: Count number of lanes
Some PCIe controllers found on Armada XP SoCs can be configured as
either four single-lane x1 or one quad-lane x4 PCIe. Although we are
not (yet) interested in the physical configuration of the PCIe
controller, we will need it when proper PHY support for PCIe is added.
Adapt the driver to the amended DT semantic and count the number of
PCIe lanes.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Bjorn Helgaas
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/pci/host/pci-mvebu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index a8c6f1a92e0f..0feee6cd395c 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -115,6 +115,7 @@ struct mvebu_pcie_port {
void __iomem *base;
u32 port;
u32 lane;
+ int num_lanes;
int devfn;
unsigned int mem_target;
unsigned int mem_attr;
@@ -982,9 +983,17 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
continue;
}
- if (of_property_read_u32(child, "marvell,pcie-lane",
->lane))
+ /*
+* If there are multiple lanes, we are only interested in the
+* number of the first lane and the lane count.
+*/
+ if (of_property_read_u32_index(child, "marvell,pcie-lane",
+ 0, >lane))
port->lane = 0;
+ port->num_lanes = of_property_count_u32_elems(child,
+ "marvell,pcie-lane");
+ if (!port->num_lanes)
+ port->num_lanes = 1;
port->name = kasprintf(GFP_KERNEL, "pcie%d.%d",
port->port, port->lane);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
On Sat, Sep 20, 2014 at 10:15:50AM -0700, Kees Cook wrote: > On Sat, Sep 20, 2014 at 7:30 AM, Peter Zijlstra wrote: > > On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: > >> We should make the updating of this flag atomic. > > > >> /* Per-process atomic flags. */ > >> #define PFA_NO_NEW_PRIVS 0x0001 /* May not gain new privileges. */ > >> +#define PFA_SPREAD_PAGE 0x0002 /* Spread page cache over cpuset */ > >> +#define PFA_SPREAD_SLAB 0x0004 /* Spread some slab caches over > >> cpuset */ > > > > Ooh, I was not ware we had those.. /me checks where that came from. Hmm > > weird, while I did get that patch it had a seccomp prefix when landing > > in my inbox so I ignored it. However the commit has a sched prefix > > (which I would not have ignored). Dubious things happened here. > > The series went through a lot of revisions, so it probably gained the > sched prefix later in its life. Is there anything that needs changing > about how this has been implemented? No, don't think so, just got surprised. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: git rid of [sched_delayed] message for printk_deferred
On Sat, Sep 20, 2014 at 09:10:47AM -0700, Joe Perches wrote: > On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote: > > On a whole, printk() is entirely useless for debugging these days, its > > far too fragile/unreliable to be taken seriously so I really don't care > > on that point either. > > That's unfortunate. > > Care to enumerate the issues that you believe make > printk too fragile/unreliable for debugging? Look at what it takes to end up at console->write(), and then realize that some console implementations require scheduling and other nonsense to actually implement ->write(). The (only) reliable option is early_printk() with the early_serial_console driver. The rest is useless crap these days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty/serial: samsung: Add earlycon support
On 09/20/2014 08:39 AM, Tomasz Figa wrote: > Hi Alim, > > Please see my comments inline. > > On 16.09.2014 13:32, Alim Akhtar wrote: >> Add earlycon support for the samsung serial port. This allows enabling >> the samsung serial port for console when early_params are parse and >> processed. >> >> Signed-off-by: Alim Akhtar >> --- >> Documentation/kernel-parameters.txt |6 ++ >> drivers/tty/serial/Kconfig |1 + >> drivers/tty/serial/samsung.c| 17 + >> 3 files changed, 24 insertions(+) >> >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 5ae8608..e01c0e5 100644 >> --- a/Documentation/kernel-parameters.txt >> +++ b/Documentation/kernel-parameters.txt >> @@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be >> entirely omitted. >> must already be setup and configured. Options are not >> yet supported. >> >> +samsung, There will only ever be 1 samsung uart? This is an ABI to some extent, so you will be stuck with it. >> +Start an early, polled-mode console on a samsung serial >> +port at the specified address. The samsung serial port >> +must already be setup and configured. Options are not >> +yet supported. >> + > > Couldn't you simply parse this from DT? I believe there is already code > parsing stdout property in chosen node for earlycon purposes present in > the kernel. You should support both and it is just a OF_EARLYCON_DECLARE line to add. > Anyway, we already had a patch for this in our internal tree, but it > wasn't submitted because there was no support for early ioremap on ARM > at that time. I haven't been following it since then (and I'm no longer > at Samsung; Marek might be able to take this topic), is it already > available? No, but should be soonish. fixmap parts are being worked on by Kees. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 07/10] OF: Introduce helper function for getting PCI domain_nr
On 09/17/2014 08:30 PM, Liviu Dudau wrote:
> Add of_pci_get_domain_nr() to retrieve the PCI domain number
> of a given device from DT. If the information is not present,
> the function can be requested to allocate a new domain number.
>
> Cc: Bjorn Helgaas
> Cc: Arnd Bergmann
> Cc: Grant Likely
> Cc: Rob Herring
> Reviewed-by: Catalin Marinas
> Signed-off-by: Liviu Dudau
> ---
[...]
> +/**
> + * This function will try to obtain the host bridge domain number by
> + * using of_alias_get_id() call with "pci-domain" as a stem. If that
> + * fails, a local allocator will be used. The local allocator can
> + * be requested to return a new domain_nr if the information is missing
> + * from the device tree.
> + *
> + * @node: device tree node with the domain information
> + * @allocate_if_missing: if DT lacks information about the domain nr,
> + * allocate a new number.
> + *
> + * Returns the associated domain number from DT, or a new domain number
> + * if DT information is missing and @allocate_if_missing is true. If
> + * @allocate_if_missing is false then the last allocated domain number
> + * will be returned.
> + */
> +int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
> +{
> + int domain;
> +
> + domain = atomic_read(_domain_nr);
> + if (domain == -1) {
> + /* first run, get max defined domain nr in device tree */
> + domain = of_get_max_pci_domain_nr();
> + /* then set the start value for allocator to be max + 1 */
> + atomic_set(_domain_nr, domain + 1);
atomic_read followed by atomic_set is not an atomic operation.
As I previously said, I don't like how this function is a mixture of
data retrieval and domian # allocation. I think we need 2 functions.
> + }
> + domain = of_alias_get_id(node, "pci-domain");
I still do not like using aliases here. Just put pci-domain or
linux,pci-domain into the PCI node.
I think we should assume all PCI root buses either have a domain
property or they don't and a mixture is an error. I'm not sure if that
simplifies the code or not though.
In the interest of merging, I think you should just do a simple
allocation and add the DT domain handling as a second step. You will
also need to document the DT part.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: usdhi6rol0: Remove unnecessary header files
On Sat, 20 Sep 2014, Pramod Gurav wrote: > These headers are not required hence this change removes them from > the driver. > > Cc: Guennadi Liakhovetski > Cc: Chris Ball > Cc: Ulf Hansson > Cc: linux-...@vger.kernel.org > Signed-off-by: Pramod Gurav NAK. The fact, that code builds without certain headers doesn't mean, they aren't needed. E.g. string.h is needed for memcpy(), scatterlist.h is needed for struct scatterlist etc. Thanks Guennadi > --- > drivers/mmc/host/usdhi6rol0.c | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c > index f0a39eb..4094d8f 100644 > --- a/drivers/mmc/host/usdhi6rol0.c > +++ b/drivers/mmc/host/usdhi6rol0.c > @@ -12,21 +12,14 @@ > #include > #include > #include > -#include > #include > #include > -#include > #include > #include > -#include > #include > #include > #include > #include > -#include > -#include > -#include > -#include > #include > > #define USDHI6_SD_CMD0x > -- > 1.8.3.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/urgent] sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP
Commit-ID: 6a40281ab5c1ed8ba2253857118a5d400a2d084b
Gitweb: http://git.kernel.org/tip/6a40281ab5c1ed8ba2253857118a5d400a2d084b
Author: Chuck Ebbert
AuthorDate: Sat, 20 Sep 2014 10:17:51 -0500
Committer: Ingo Molnar
CommitDate: Sat, 20 Sep 2014 19:44:04 +0200
sched: Fix end_of_stack() and location of stack canary for architectures using
CONFIG_STACK_GROWSUP
Aaron Tomlin recently posted patches [1] to enable checking the
stack canary on every task switch. Looking at the canary code, I
realized that every arch (except ia64, which adds some space for
register spill above the stack) shares a definition of
end_of_stack() that makes it the first long after the
threadinfo.
For stacks that grow down, this low address is correct because
the stack starts at the end of the thread area and grows toward
lower addresses. However, for stacks that grow up, toward higher
addresses, this is wrong. (The stack actually grows away from
the canary.) On these archs end_of_stack() should return the
address of the last long, at the highest possible address for the stack.
[1] http://lkml.org/lkml/2014/9/12/293
Signed-off-by: Chuck Ebbert
Link: http://lkml.kernel.org/r/20140920101751.6c5166b6@as
Signed-off-by: Ingo Molnar
Tested-by: James Hogan [metag]
Acked-by: James Hogan
Acked-by: Aaron Tomlin
---
include/linux/sched.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..1f07040 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2608,9 +2608,22 @@ static inline void setup_thread_stack(struct task_struct
*p, struct task_struct
task_thread_info(p)->task = p;
}
+/*
+ * Return the address of the last usable long on the stack.
+ *
+ * When the stack grows down, this is just above the thread
+ * info struct. Going any lower will corrupt the threadinfo.
+ *
+ * When the stack grows up, this is the highest address.
+ * Beyond that position, we corrupt data on the next page.
+ */
static inline unsigned long *end_of_stack(struct task_struct *p)
{
+#ifdef CONFIG_STACK_GROWSUP
+ return (unsigned long *)((unsigned long)task_thread_info(p) +
THREAD_SIZE) - 1;
+#else
return (unsigned long *)(task_thread_info(p) + 1);
+#endif
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: usdhi6rol0: Remove unnecessary header files
These headers are not required hence this change removes them from the driver. Cc: Guennadi Liakhovetski Cc: Chris Ball Cc: Ulf Hansson Cc: linux-...@vger.kernel.org Signed-off-by: Pramod Gurav --- drivers/mmc/host/usdhi6rol0.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c index f0a39eb..4094d8f 100644 --- a/drivers/mmc/host/usdhi6rol0.c +++ b/drivers/mmc/host/usdhi6rol0.c @@ -12,21 +12,14 @@ #include #include #include -#include #include #include -#include #include #include -#include #include #include #include #include -#include -#include -#include -#include #include #define USDHI6_SD_CMD 0x -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Staging driver fixes for 3.17-rc6
The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.17-rc6 for you to fetch changes up to ed87c2b2e7dd34016017af183b8f3fbe28179bc1: staging: vt6655: buffer overflow in ioctl (2014-09-19 15:32:20 -0700) Staging / IIO fixes for 3.17-rc6 Here are some IIO and Staging driver fixes for 3.17-rc6. They are all pretty simple, and resolve reported issues. Signed-off-by: Greg Kroah-Hartman Dan Carpenter (1): staging: vt6655: buffer overflow in ioctl Denis CIOCCA (1): iio:magnetometer: bugfix magnetometers gain values Greg Kroah-Hartman (1): Merge tag 'iio-fixes-3.17a' of git://git.kernel.org/.../jic23/iio into staging-linus Johannes Pointner (1): iio:inkern: fix overwritten -EPROBE_DEFER in of_iio_channel_get_by_name Ludovic Desroches (1): iio: adc: at91: don't use the last converted data register Srinivas Pandruvada (8): iio:trigger: modify return value for iio_trigger_get iio: accel: bma180: Fix indio_dev->trig assignment iio: adc: ad_sigma_delta: Fix indio_dev->trig assignment iio: hid_sensor_hub: Fix indio_dev->trig assignment iio: st_sensors: Fix indio_dev->trig assignment iio: gyro: itg3200: Fix indio_dev->trig assignment iio: inv_mpu6050: Fix indio_dev->trig assignment iio: meter: ade7758: Fix indio_dev->trig assignment Subbaraya Sundeep Bhatta (1): iio: adc: xilinx-xadc: assign auxiliary channels address correctly drivers/iio/accel/bma180.c | 2 +- drivers/iio/adc/ad_sigma_delta.c | 2 +- drivers/iio/adc/at91_adc.c | 12 ++--- drivers/iio/adc/xilinx-xadc-core.c | 2 +- .../iio/common/hid-sensors/hid-sensor-trigger.c| 3 +- drivers/iio/common/st_sensors/st_sensors_trigger.c | 2 +- drivers/iio/gyro/itg3200_buffer.c | 2 +- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 2 +- drivers/iio/inkern.c | 2 +- drivers/iio/magnetometer/st_magn_core.c| 52 +- drivers/staging/iio/meter/ade7758_trigger.c| 2 +- drivers/staging/vt6655/hostap.c| 3 ++ include/linux/iio/trigger.h| 4 +- 13 files changed, 53 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] USB driver fixes for 3.17-rc6
The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.17-rc6 for you to fetch changes up to c80b4495c61636edc58fe1ce300f09f24db28e10: USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters (2014-09-19 15:01:38 -0700) USB fixes / quirks for 3.17-rc6 Here are some USB and PHY fixes and quirks for 3.17-rc6. Nothing major, just a few things that have been reported. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: EHCI: unlink QHs even after the controller has stopped Bartlomiej Zolnierkiewicz (2): phy: spear1310-miphy: fix driver dependencies phy: spear1340-miphy: fix driver dependencies Greg Kroah-Hartman (1): Merge tag 'for_3.17-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Lee Jones (1): phy: miphy365x: Fix off-by-one error Mark (3): USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters drivers/phy/Kconfig| 2 ++ drivers/phy/phy-miphy365x.c| 1 + drivers/usb/host/ehci-hcd.c| 2 -- drivers/usb/storage/unusual_devs.h | 32 4 files changed, 35 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] ftracetest: Initial commit for ftracetest
(2014/09/19 23:42), Steven Rostedt wrote: > On Fri, 19 Sep 2014 08:05:23 -0600 > Shuah Khan wrote: > > >> I am not concerned about the spacing. >> >> Thanks for doing running the make kselftest target and sharing >> the results. selftests don't get built or run in integ test >> rings. I am working on addressing this at the moment. >> >> Steven! >> >> Could you please take this through your tree. You have my >> >> Acked-by: Shuah Khan >> >> for the selftests Makefile > > OK, thanks! > > I'll start trying to get my own personal tests working here. Great :) > > It may take some work as my tests may run for 10s of minutes, as they > are more stress tests than a pass/fail thing. But I should have > something other people can use. I'll continue using both my own > personal tests as well as trying the new stuff that gets put here. I think you can also put your stress tests in the ftrace/ directory (or just make a sub-directory for them). Even ftracetest doesn't run them, we can update Makefile so that kselftest can run them. For example, I will add a testcase for my IPMODFIY as a separated test(ftrace/ipmodify), since it involves some special kernel modules and doesn't use ftrace debugfs interface but tests ftrace(function trace). Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 04/10] PCI: OF: Fix the conversion of IO ranges into IO resources.
On 09/17/2014 08:30 PM, Liviu Dudau wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account.
>
> In the process move the function into drivers/of/address.c as it now
> depends on pci_address_to_pio() code and make it return an error code.
> Also fix all the drivers that depend on the old behaviour by fetching
> the CPU physical address based on the port number.
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Arnd Bergmann
> Cc: Linus Walleij
> Cc: Thierry Reding
> Cc: Simon Horman
> Cc: Catalin Marinas
> Signed-off-by: Liviu Dudau
A few minor things below.
> ---
> arch/arm/mach-integrator/pci_v3.c | 23 ++--
> drivers/of/address.c | 46
> +++
> drivers/pci/host/pci-tegra.c | 10 ++---
> drivers/pci/host/pcie-rcar.c | 21 +-
> include/linux/of_address.h| 13 ++-
> 5 files changed, 82 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-integrator/pci_v3.c
> b/arch/arm/mach-integrator/pci_v3.c
> index 05e1f73..3321e1b 100644
> --- a/arch/arm/mach-integrator/pci_v3.c
> +++ b/arch/arm/mach-integrator/pci_v3.c
> @@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
> {
> unsigned long flags;
> unsigned int temp;
> + phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>
> pcibios_min_mem = 0x0010;
>
> @@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
> /*
>* Setup window 2 - PCI IO
>*/
> - v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
> + v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
> V3_LB_BASE_ENABLE);
> v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
>
> @@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
> static void __init pci_v3_postinit(void)
> {
> unsigned int pci_cmd;
> + phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>
> pci_cmd = PCI_COMMAND_MEMORY |
> PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
> @@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
> "interrupt: %d\n", ret);
> #endif
>
> - register_isa_ports(non_mem.start, io_mem.start, 0);
> + register_isa_ports(non_mem.start, io_address, 0);
> }
>
> /*
> @@ -867,33 +869,32 @@ static int __init pci_v3_probe(struct platform_device
> *pdev)
>
> for_each_of_pci_range(, ) {
> if (!range.flags) {
> - of_pci_range_to_resource(, np, _mem);
> + ret = of_pci_range_to_resource(, np, _mem);
> conf_mem.name = "PCIv3 config";
> }
> if (range.flags & IORESOURCE_IO) {
> - of_pci_range_to_resource(, np, _mem);
> + ret = of_pci_range_to_resource(, np, _mem);
> io_mem.name = "PCIv3 I/O";
> }
> if ((range.flags & IORESOURCE_MEM) &&
> !(range.flags & IORESOURCE_PREFETCH)) {
> non_mem_pci = range.pci_addr;
> non_mem_pci_sz = range.size;
> - of_pci_range_to_resource(, np, _mem);
> + ret = of_pci_range_to_resource(, np, _mem);
> non_mem.name = "PCIv3 non-prefetched mem";
> }
> if ((range.flags & IORESOURCE_MEM) &&
> (range.flags & IORESOURCE_PREFETCH)) {
> pre_mem_pci = range.pci_addr;
> pre_mem_pci_sz = range.size;
> - of_pci_range_to_resource(, np, _mem);
> + ret = of_pci_range_to_resource(, np, _mem);
> pre_mem.name = "PCIv3 prefetched mem";
> }
> - }
>
> - if (!conf_mem.start || !io_mem.start ||
> - !non_mem.start || !pre_mem.start) {
> - dev_err(>dev, "missing ranges in device node\n");
> - return -EINVAL;
> + if (ret < 0) {
> + dev_err(>dev, "missing ranges in device node\n");
> + return -EINVAL;
You should return ret rather than potentially changing the return value.
> + }
> }
>
> pci_v3.map_irq = of_irq_parse_and_map_pci;
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 2373a92..ff10b64 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -947,3 +947,49 @@ bool of_dma_is_coherent(struct device_node *np)
> return false;
> }
> EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/*
> + * of_pci_range_to_resource - Create a resource from an
Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
Hello,
On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote:
> > Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag?
> > The user is running cgrulesengd process in order to utilize cpuset cgroup.
> > Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process
> > writes someone's pid to /cgroup/cpuset/$group/tasks interface.
> >
> > cpuset_update_task_spread_flag() is updating other thread's
> > "struct task_struct"->flags without exclusion control or atomic
> > operations!
> >
> > -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c --
> > 300:/*
> > 301: * update task's spread flag if cpuset's page/slab spread flag is set
> > 302: *
> > 303: * Called with callback_mutex/cgroup_mutex held
> > 304: */
> > 305:static void cpuset_update_task_spread_flag(struct cpuset *cs,
> > 306:struct task_struct *tsk)
> > 307:{
> > 308:if (is_spread_page(cs))
> > 309:tsk->flags |= PF_SPREAD_PAGE;
> > 310:else
> > 311:tsk->flags &= ~PF_SPREAD_PAGE;
> > 312:if (is_spread_slab(cs))
> > 313:tsk->flags |= PF_SPREAD_SLAB;
> > 314:else
> > 315:tsk->flags &= ~PF_SPREAD_SLAB;
> > 316:}
>
> We should make the updating of this flag atomic.
Ugh, why do we even implement that in cpuset. This should be handled
by MPOL_INTERLEAVE. It feels like people have been using cpuset as
the dumpsite that people used w/o thinking much. Going forward, let's
please confine cpuset to collective cpu and memory affinity
configuration. It really shouldn't be implementing novel features for
scheduler or mm.
Anyways, yeah, the patch looks correct to me. Can you please send a
version w/ proper description and sob?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 1/4] ftracetest: Initial commit for ftracetest
(2014/09/19 23:05), Shuah Khan wrote: +TODO + + + * Fancy colored output :) + + * Integrate with selftest? >>> >>> The second TODO can be removed since it is moved under selftests?? >> >> Ah, I missed to remove that in this commit. It's already integrated. >> >> - * Integrate with selftest? >> >> Oops, and I removed it in 4/4 ... > > If you could fix this README, that would be great. Yeah, but I guess if all of this series are merged, it may be not such a big flaw... Steven, would I better resend updates? >>> If you haven't already done this, could you please make sure it >>> runs without hangs when run from the "make kselftest" target. >> >> OK, here is the last lines of the test result. >> >> == Testing sysctl behavior against /proc/sys/vm/swappiness == >> Writing test file ... ok >> Checking sysctl is not set to test value ... ok >> Writing sysctl from shell ... ok >> Resetting sysctl to original value ... ok >> Writing entire sysctl in single write ... ok >> Writing middle of sysctl after synchronized seek ... Writing beyond end of >> sysctl ... Writing sysctl with multiple long writes ... ok >> fw_filesystem: [FAIL] >> [1] Basic trace file check [PASS] >> [2] Basic test for tracers [PASS] >> [3] Basic trace clock test [PASS] >> [4] Kprobe dynamic event - adding and removing [PASS] >> [5] Kprobe dynamic event - busy event check [PASS] >> >> # of passed: 5 >> # of failed: 0 >> # of unresolved: 0 >> # of untested: 0 >> # of unsupported: 0 >> # of xfailed: 0 >> # of undefined(test bug): 0 >> >> Hmm, I think it should have a separation line before running ftracetest. >> > > I am not concerned about the spacing. OK, anyway I can make an update for that afterwords. > Thanks for doing running the make kselftest target and sharing > the results. selftests don't get built or run in integ test > rings. I am working on addressing this at the moment. > > Steven! > > Could you please take this through your tree. You have my > > Acked-by: Shuah Khan > > for the selftests Makefile Thanks! > > -- Shuah > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FIX ME in oxu210p-hcd.c
I found a unfixed FIX ME in the file stated in my above message. I am wondering what to set hcd->self.comtroller->dma_mask to as it's now been defined to NULL and clearly even as a newbie this seem incorrect. Regards Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17-rc5] Fix confusing PFA_NO_NEW_PRIVS constant.
On Sat, Sep 20, 2014 at 3:40 AM, Tetsuo Handa
wrote:
> Can you apply below patch before new PFA_* are defined?
> Cgroups code might want to define PFA_SPREAD_PAGE as 1 and PFA_SPREAD_SLAB as
> 2.
>
> >From 8543e68adb210142fa347d8bc9d83df0bb2c5291 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 20 Sep 2014 19:24:23 +0900
> Subject: [PATCH 3.17-rc5] Fix confusing PFA_NO_NEW_PRIVS constant.
>
> Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
> defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
> because it is used as bit number. Redefine it as decimal bit number.
>
> Signed-off-by: Tetsuo Handa
> ---
> include/linux/sched.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5c2c885..4557765 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1957,7 +1957,7 @@ static inline void memalloc_noio_restore(unsigned int
> flags)
> }
>
> /* Per-process atomic flags. */
> -#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
> +#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
>
> static inline bool task_no_new_privs(struct task_struct *p)
> {
Thanks, good catch.
Acked-by: Kees Cook
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
