Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 7:51 AM, Takashi Iwai ti...@suse.de wrote: This field isn't used anywhere actually in the patch...? Yeah sorry that is not needed, I avoided that by adding the simple bool on the struct device, forgot to nuke that. Will spin v2 unless I hear otherwise. Luis -- To

Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 03:12:11PM +, Yuval Mintz wrote: +static int __driver_probe_device(struct device_driver *drv, struct +device *dev) { + if (drv-delay_probe !dev-init_delayed_probe) { + dev_info(dev, Driver %s requests probe deferral on init\n, +

Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 03:46:32PM +, Yuval Mintz wrote: Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init On Mon, Jul 28, 2014 at 03:12:11PM +, Yuval Mintz wrote: Perhaps this is a silly question, but what guarantees that the deferred

Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 06:52:48PM +0200, Luis R. Rodriguez wrote: On Mon, Jul 28, 2014 at 03:46:32PM +, Yuval Mintz wrote: Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init On Mon, Jul 28, 2014 at 03:12:11PM +, Yuval Mintz wrote

[PATCH v2 3/4] cxgb4: ask for deferred probe

2014-07-28 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com cxgb4 probe can take up to over 1 minute when the firmware is is written and installed on the device. Use the new delayed probe preference so that cxgb4 gets probed on the deferred workqueue. Without this devices that require the update on firmware

[PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Tetsuo bisected and found that commit 786235ee kthread: make kthread_create() killable modified kthread_create() to bail as soon as SIGKILL is received. This is causing some issues with some drivers and at times boot. Joseph then found that failures occur

[PATCH v2 0/4] driver core: allow explicit deferred probe preference

2014-07-28 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This adds support to let device drivers explicitly request to be probed on the deferred workqueue. Note that another ideal solution on top of this would be if we could detect somehow if kthread_create() was SIGKILL'd for a modprobe, and also

[PATCH v2 4/4] mptsas: ask for deferred probe

2014-07-28 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Its reported that mptsas can at times take over 30 seconds to recognize SCSI storage devices [0], this is done on the driver's probe path. Use the the deferred probe workqueue to allow long init sequences to complete. [0] https://bugs.launchpad.net/ubuntu

[PATCH v2 1/4] driver core: move deferred probe add / remove helpers down a bit

2014-07-28 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com We need to do this if we want to use the trigger at a later point. This change has introduces no functional changes. Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp Cc: Joseph Salisbury joseph.salisb...@canonical.com Cc: One Thousand Gnomes gno

Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 06:30:29PM +, Yuval Mintz wrote: On Mon, Jul 28, 2014 at 06:52:48PM +0200, Luis R. Rodriguez wrote: On Mon, Jul 28, 2014 at 03:46:32PM +, Yuval Mintz wrote: Sorry for not being clear, but I didn't meant 'what guarantees that the device

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 11:55 AM, Greg KH gre...@linuxfoundation.org wrote: So, what drivers are having problems in their init sequence, and why aren't they using async firmware loading? Fixing drivers is one thing, fixing drivers *now* because *now* drivers are failing due to a regression is

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Mon, Jul 28, 2014 at 11:55 AM, Greg KH gre...@linuxfoundation.org wrote: So, what drivers are having problems in their init sequence, and why aren't they using async firmware loading? Fixing drivers is one

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 4:46 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jul 28, 2014 at 12:48:32PM -0700, Luis R. Rodriguez wrote: On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Mon, Jul 28, 2014 at 11:55 AM, Greg KH gre...@linuxfoundation.org

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-28 Thread Luis R. Rodriguez
On Mon, Jul 28, 2014 at 5:35 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jul 28, 2014 at 05:26:34PM -0700, Luis R. Rodriguez wrote: On Mon, Jul 28, 2014 at 4:46 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jul 28, 2014 at 12:48:32PM -0700, Luis R. Rodriguez wrote: On Mon

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-07-29 Thread Luis R. Rodriguez
On Tue, Jul 29, 2014 at 04:14:22PM -0700, Greg KH wrote: On Mon, Jul 28, 2014 at 06:13:43PM -0700, Luis R. Rodriguez wrote: Why not just put the initial register the device in a single-shot workqueue or thread or something like that so that modprobe returns instantly back

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probefrom init

2014-07-29 Thread Luis R. Rodriguez
On Tue, Jul 29, 2014 at 03:25:29PM -0700, Benjamin Poirier wrote: On 2014/07/29 21:07, Tetsuo Handa wrote: Luis R. Rodriguez wrote: On Mon, Jul 28, 2014 at 5:35 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jul 28, 2014 at 05:26:34PM -0700, Luis R. Rodriguez wrote

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probefrom init

2014-07-30 Thread Luis R. Rodriguez
On Wed, Jul 30, 2014 at 11:22:14AM +0900, Tetsuo Handa wrote: Luis R. Rodriguez wrote: Tetsuo is it possible / desirable to allow tasks to not kill unless the reason is OOM ? Its unclear if this was discussed before, sorry if it was, have just been a bit busy today to review the archive

Re: [RFC 0/2] vfs / btrfs: add support for ustat()

2014-07-16 Thread Luis R. Rodriguez
On Tue, Jul 15, 2014 at 10:29:19PM -0700, Christoph Hellwig wrote: Isn't this the problem again the btrfs uses different assignments for st_dev than s_dev? I don't even want to think about a mess like this before that is fixed. As much as I'd like to see that happen based on discussions so

Re: [RFC 0/2] vfs / btrfs: add support for ustat()

2014-07-16 Thread Luis R. Rodriguez
On Tue, Jul 15, 2014 at 04:07:03PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com ustat() does not work for btrfs, the reason is the VFS layer cannot get to the super block from the anonymous bdevs. The way these are used within btrfs though are to actually use

[RFC v2 0/2] vfs / btrfs: add support for ustat()

2014-07-16 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This makes the implementation simpler by stuffing the struct on the driver and just letting the driver iinsert it and remove it onto the sb list. This avoids the kzalloc() completely. Luis R. Rodriguez (2): fs/super.c: add new super block sub devices

[RFC v2 2/2] btrfs: use the new VFS super_block_dev

2014-07-16 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Use the new VFS layer struct super_block_dev instead of carrying the anonymous bdev's on our own. This makes the VFS layer aware of all of our anonymous dev's on the super block. Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- fs/btrfs/ctree.h | 7

[RFC v2 1/2] fs/super.c: add new super block sub devices super_block_dev

2014-07-16 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Modern filesystems are using the get_anon_bdev() for internal notions of volumes, snapshots for a single super block but never exposing them directly to the VFS layer. While this works its leaves the VFS layer growing dumb over what filesystems are doing

Re: [RFC v2 0/2] vfs / btrfs: add support for ustat()

2014-07-17 Thread Luis R. Rodriguez
On Thu, Jul 17, 2014 at 01:03:01AM -0700, Christoph Hellwig wrote: On Wed, Jul 16, 2014 at 02:37:56PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com This makes the implementation simpler by stuffing the struct on the driver and just letting the driver iinsert

Re: dell rbu driver and FW_LOADER_USER_HELPER

2014-08-26 Thread Luis R. Rodriguez
On Tue, Aug 26, 2014 at 07:09:46PM +0200, Luis R. Rodriguez wrote: When Christian tried removing the udev firmware loader it was detected that the Dell rbu driver still required use of FW_LOADER_USER_HELPER [0]. This driver needed reworking to not be tied to the firmware loader, curious

[PATCH v3 0/3] module loading: add module_long_probe_init()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com systemd-udevd will cause a driver to fail to load if it doesn't load within the set default timeout, right now 30 seconds. Although we now have a way to increase the timeout at run time we need a way to both annotate drivers that need fixing and a way

[PATCH v3 3/3] mptsas: use module_long_probe_init()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Its reported that mptsas can at times take over 30 seconds to recognize SCSI storage devices [0], this is done on the driver's probe path. Use the the new module_long_probe_init() to annotate this driver's probe is broken and require some love, but makes

[PATCH v3 2/3] cxgb4: use module_long_probe_init()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com cxgb4 probe can take up to over 1 minute when the firmware is is written and installed on the device, even after this the device driver still does some device probing and can take quite a bit. This driver needs fixing but right now it simply wont' work

[PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Tetsuo bisected and found that commit 786235ee kthread: make kthread_create() killable modified kthread_create() to bail as soon as SIGKILL is received. This is causing some issues with some drivers and at times boot. Joseph then found that failures occur

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-14 Thread Luis R. Rodriguez
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote: On 08/12, Luis R. Rodriguez wrote: +/* To be used by modules which can take over 30 seconds at probe */ Probably the comment should explain that this hack should only be used if the driver is buggy and is wating for real fix

Re: [PATCH v3 2/2] x86: Add make tinyconfig to configure the tiniest possible kernel

2014-08-14 Thread Luis R. Rodriguez
On Mon, Aug 11, 2014 at 09:36:06PM +0200, Sam Ravnborg wrote: On Mon, Aug 11, 2014 at 11:15:21AM -0700, j...@joshtriplett.org wrote: On Fri, Aug 08, 2014 at 06:22:20PM -0700, Linus Torvalds wrote: On Fri, Aug 8, 2014 at 5:10 PM, Josh Triplett j...@joshtriplett.org wrote: Since commit

Re: [RFC v2 0/2] vfs / btrfs: add support for ustat()

2014-08-14 Thread Luis R. Rodriguez
On Thu, Jul 17, 2014 at 1:49 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Jul 17, 2014 at 01:03:01AM -0700, Christoph Hellwig wrote: On Wed, Jul 16, 2014 at 02:37:56PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com This makes the implementation simpler

[RFC v3 0/2] vfs / btrfs: add support for ustat()

2014-08-14 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This v3 has this small fix identified by Filipe Manana on the btrfs specific patch. The v2 series was briefly discussed but upon providing a use case and reasoning for the way things were changed I haven't gotten any more further advice or feedback

[RFC v3 2/2] btrfs: use the new VFS super_block_dev

2014-08-14 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Use the new VFS layer struct super_block_dev instead of carrying the anonymous bdev's on our own. This makes the VFS layer aware of all of our anonymous dev's on the super block. Signed-off-by: Luis R. Rodriguez mcg...@suse.com Signed-off-by: Filipe Manana

[RFC v3 1/2] fs/super.c: add new super block sub devices super_block_dev

2014-08-14 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Modern filesystems are using the get_anon_bdev() for internal notions of volumes, snapshots for a single super block but never exposing them directly to the VFS layer. While this works its leaves the VFS layer growing dumb over what filesystems are doing

Re: [PATCH] printk: Don't bother using LOG_CPU_MAX_BUF_SHIFT on !SMP

2014-08-08 Thread Luis R. Rodriguez
On Fri, Aug 08, 2014 at 05:20:44PM +0200, Geert Uytterhoeven wrote: When configuring a uniprocessor kernel, don't bother the user with an irrelevant LOG_CPU_MAX_BUF_SHIFT question, and don't build the unused code. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Luis R

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-08-09 Thread Luis R. Rodriguez
On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com Date: Mon, 28 Jul 2014 11:28:28 -0700 Tetsuo bisected and found that commit 786235ee kthread: make kthread_create() killable modified kthread_create() to bail as soon as SIGKILL

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-08-10 Thread Luis R. Rodriguez
On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote: On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote: On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com Date: Mon, 28 Jul 2014 11:28:28 -0700 Tetsuo

Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-08-11 Thread Luis R. Rodriguez
On Mon, Aug 11, 2014 at 11:27 AM, Takashi Iwai ti...@suse.de wrote: Luis R. Rodriguez wrote: On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote: On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote: On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote: From

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-15 Thread Luis R. Rodriguez
On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote: On 08/15, Luis R. Rodriguez wrote: On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote: On 08/12, Luis R. Rodriguez wrote: +/* To be used by modules which can take over 30 seconds at probe */ Probably

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-17 Thread Luis R. Rodriguez
On Sun, Aug 17, 2014 at 02:55:05PM +0200, Oleg Nesterov wrote: Damn, sorry for noise ;) I was going to suggest to introduce module_put_and_exit() to simplify this and potentially other users, but it already exists. So this code can use it too without additional complications. In the last

Re: [RFC v3 0/2] vfs / btrfs: add support for ustat()

2014-08-17 Thread Luis R. Rodriguez
On Fri, Aug 15, 2014 at 10:29:50AM +0100, Al Viro wrote: On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote: Christoph had noted that this seemed associated to the problem that the btrfs uses different assignments for st_dev than s_dev, but much as I'd like to see

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-18 Thread Luis R. Rodriguez
On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov o...@redhat.com wrote: And, again, I do not really know which version is better. In Chicago right now -- feedback was it seems the that generally splitting up probe from init might be good in the end, if we do this we won't need a work around for

git tag for counting uses of Coccinelle

2014-10-23 Thread Luis R. Rodriguez
In order to help be able to easily count uses of Coccinelle for kernel development I'd like to propose the use of the tag: Generated-by: Coccinelle SmPL This would save space on commits where it seems more than the above number of words are used to describe this exact thing. Luis -- To

Re: [PATCH v2 1/7] taint: add TAINT_DEBUG for invasive debugging features

2014-10-20 Thread Luis R. Rodriguez
On Wed, Oct 15, 2014 at 04:05:06PM +1030, Rusty Russell wrote: Luis R. Rodriguez mcg...@do-not-panic.com writes: From: Luis R. Rodriguez mcg...@suse.com At times we may add module parameters or debugging / testing kernel features, when enabled though we don't really want to be spending

Re: [RFC v2 2/6] driver-core: add driver async_probe support

2014-10-20 Thread Luis R. Rodriguez
diff --git a/drivers/base/bus.c b/drivers/base/bus.c index 83e910a..49fe573 100644 --- a/drivers/base/bus.c +++ b/drivers/base/bus.c @@ -10,6 +10,7 @@ * */ +#include linux/async.h #include linux/device.h #include linux/module.h #include linux/errno.h @@ -547,15 +548,12 @@ void

Re: [RFC v1 0/3] driver-core: add asynch module loading support

2014-09-04 Thread Luis R. Rodriguez
On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote: On Sun, Aug 31, 2014 at 01:14:07PM -0700, Dmitry Torokhov wrote: On Sun, Aug 31, 2014 at 12:31:40PM -0700, Greg KH wrote: On Sun, Aug 31, 2014 at 12:24:46PM -0700, Arjan van de Ven wrote: before we added the current async approach

[RFC v2 2/6] driver-core: add driver async_probe support

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com We now have two documented use cases for probing asynchronously: 0) since we bundle together driver init() and probe() systemd's new 30 second timeout has put a limit on the amount of time a driver probe routine can take, we need to enable drivers

[RFC v2 1/6] driver-core: generalize freeing driver private member

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This will be used later. Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- drivers/base/bus.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/base/bus.c b/drivers/base/bus.c index 83e910a..a5f41e4 100644

[RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com The new umh kill option has allowed kthreads to receive kill signals but they are generally accepting all sources of kill signals while the original motivation was to enable through the OOM from sending the kill. One particular user which has been found

[RFC v2 0/6] driver-core: add asynch probe support

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Here's a complete reimplementation of asynch loading support, it discards completely the hippie / pipe dream idea that we need asynch loading of modules / subsystems in general and just addresses running probe asynchronously. This respin is based on Tejun's

[RFC v2 4/6] cxgb4: use async probe

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com cxgb4 probe can take up to over 1 minute when the firmware is is written and installed on the device, even after this the device driver still does some device probing and can take quite a bit. systemd will kill this driver when probe does take over 30

[RFC v2 6/6] pata_marvell: use async probe

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Alexander reported that on his Sony VAIO VPCZ23A4R laptop experiences long delays on boot when connected to its dock station on pre 3.9 kernels but anything after 3.9 will cause the device to not be detected at all ending with: [ 38.065673] pata_marvell

[RFC v2 5/6] mptsas: use async probe

2014-09-05 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Its reported that mptsas can at times take over 30 seconds to recognize SCSI storage devices [0], this is done on the driver's probe path. Use the the new asynch probe to circumvent systemd from killing this driver. [0] https://bugs.launchpad.net/ubuntu

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-05 Thread Luis R. Rodriguez
On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo t...@kernel.org wrote: On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote: ... + /* + * I got SIGKILL, but wait for 60 more seconds for completion + * unless chosen by the OOM killer. This delay

Re: [RFC v2 2/6] driver-core: add driver async_probe support

2014-09-05 Thread Luis R. Rodriguez
On Fri, Sep 05, 2014 at 01:24:17PM +0200, Oleg Nesterov wrote: On 09/04, Luis R. Rodriguez wrote: struct driver_private { struct kobject kobj; struct klist klist_devices; struct klist_node knode_bus; struct module_kobject *mkobj; + struct driver_attach_work

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-05 Thread Luis R. Rodriguez
On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote: On 09/04, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com The new umh kill option has allowed kthreads to receive kill signals but they are generally accepting all sources of kill signals And I think

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-05 Thread Luis R. Rodriguez
On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo t...@kernel.org wrote: Hello, On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote: Which problem are we talking about here though? It does solve the slow device stalling the rest if the kernel booting (non-module case) for me. The other

Re: Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

2014-09-05 Thread Luis R. Rodriguez
. On Tue, Jun 10 2014, Luis R. Rodriguez wrote: On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy lis...@gmail.com wrote: Dear Luis; Thank you for the introduction in the wireless-regdb mailing-list. On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: Rostislav, can you provide

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Fri, Sep 5, 2014 at 3:40 PM, Tejun Heo t...@kernel.org wrote: Hello, Luis. On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote: Meanwhile we are allowing a major design consideration such as a 30 second timeout for both init + probe all of a sudden become a hard requirement

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo t...@kernel.org wrote: On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: I'm not too convinced this is such a difficult problem to figure out. We already have most of logic in place and the only thing missing is how to switch it. Wouldn't

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:29 PM, Tejun Heo t...@kernel.org wrote: On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote: Alternatively, add a module-generic param async_probe or whatever and use that to switch the behavior should work too. I don't know which way is better

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:47 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote: OK then one only concern I would have with this is that the presence of such a flag doesn't necessarily mean that all drivers on a system have been

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 7:39 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote: Given that the behvaior change is from driver core and that device probing can happen post-loading anyway, Ah but lets not forget Dmitry's requirement

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 8:03 PM, Tejun Heo t...@kernel.org wrote: On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote: I think we just should make exceptions sensible so that it works fine in practice for now (and I don't think that'd be too hard). So, the only cooperation

Re: [Cocci] [PATCH] coccinelle: add pycocci wrapper for multithreaded support

2014-08-27 Thread Luis R. Rodriguez
On Thu, Apr 10, 2014 at 09:32:34PM +0200, Julia Lawall wrote: On Thu, 10 Apr 2014, Luis R. Rodriguez wrote: On Thu, Apr 10, 2014 at 07:51:29PM +0200, Johannes Berg wrote: On Thu, 2014-04-10 at 10:48 -0700, Luis R. Rodriguez wrote: You just pass it a cocci file, a target dir

Re: [Cocci] [PATCH] coccinelle: add pycocci wrapper for multithreaded support

2014-08-28 Thread Luis R. Rodriguez
On Thu, Aug 28, 2014 at 08:15:16PM +0200, Julia Lawall wrote: On Thu, 28 Aug 2014, Luis R. Rodriguez wrote: On Thu, Apr 10, 2014 at 09:32:34PM +0200, Julia Lawall wrote: On Thu, 10 Apr 2014, Luis R. Rodriguez wrote: On Thu, Apr 10, 2014 at 07:51:29PM +0200, Johannes

Re: randconfig build error with next-20140829, in drivers/media/usb/dvb-usb/technisat-usb2.c

2014-08-30 Thread Luis R. Rodriguez
On Fri, Aug 29, 2014 at 09:19:42AM -0700, Jim Davis wrote: Building with the attached random configuration file, LD init/built-in.o drivers/built-in.o: In function `technisat_usb2_set_voltage': technisat-usb2.c:(.text+0x3b4919): undefined reference to `stv090x_set_gpio' make: ***

[RFC v1 1/3] driver-core: split module_init() and module_exit()

2014-08-31 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com module_init() currently is the default caller used for all other types of *_init() calls for modules. If we want to do something a bit different for init groups though we are implicating that onto the other ones. Lets instead use a generic drv_init() which

[RFC v1 2/3] async: move synchronous caller into a helper

2014-08-31 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This will be reused later. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Tejun Heo t...@kernel.org Cc: Arjan van de Ven ar...@linux.intel.com Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- kernel/async.c | 22 +++--- 1 file

[RFC v1 0/3] driver-core: add asynch module loading support

2014-08-31 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com While reviewing Wu Zhangjin's solution to async probe [0] and his ideas on creating async groups I decided to try following the init levels on the kernel to try to help with synchronization at least on some level. This borrows ideas discussed

[RFC v1 3/3] async: add driver asynch levels

2014-08-31 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Joseph bisected and found that Tetsuo Handa's commit 786235ee kthread: make kthread_create() killable modified kthread_create() to bail as soon as SIGKILL is received [0] [1]. This is causing some issues with some drivers and at times boot. There are other

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-11 Thread Luis R. Rodriguez
On Thu, Sep 11, 2014 at 1:53 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Thu, Sep 11, 2014 at 01:42:20PM -0700, Luis R. Rodriguez wrote: On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: There are elements in common, but by and large

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-11 Thread Luis R. Rodriguez
On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen t...@jklm.no wrote: On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: More than two years have gone by on growing design and assumptions on top of that original commit. I'm not sure if *systemd folks* yet believe

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-12 Thread Luis R. Rodriguez
On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen t...@jklm.no wrote: How about simply introducing a new flag to finit_module() to indicate

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-12 Thread Luis R. Rodriguez
On Tue, Sep 9, 2014 at 4:03 PM, Tejun Heo t...@kernel.org wrote: On Tue, Sep 09, 2014 at 12:25:29PM +0900, Tejun Heo wrote: Hello, On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote: On the systemd side of things it should enable this sysctl and for older kernels what should

Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-07 Thread Luis R. Rodriguez
On Tue, Oct 07, 2014 at 01:34:04PM -0400, Tejun Heo wrote: Hello, On Tue, Oct 07, 2014 at 01:10:46AM +0200, Luis R. Rodriguez wrote: On Mon, Oct 06, 2014 at 05:01:18PM -0400, Tejun Heo wrote: For in-kernel stuff, we already have a clear synchronization point where we already

Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-07 Thread Luis R. Rodriguez
On Tue, Oct 7, 2014 at 10:55 AM, Tejun Heo t...@kernel.org wrote: Hello, On Tue, Oct 07, 2014 at 07:50:10PM +0200, Luis R. Rodriguez wrote: On Tue, Oct 07, 2014 at 01:34:04PM -0400, Tejun Heo wrote: But you can create a new workqueue and queue all the async probing work items

Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-07 Thread Luis R. Rodriguez
On Tue, Oct 7, 2014 at 11:55 AM, Luis R. Rodriguez mcg...@suse.com wrote: OK I'll just kill bus.enable_kern_async=1 to enable built-in async probe support *and* also have prefer_async_probe *always* be respected, whether modular or not. Well and I just realized you *do* want to flush, so

Re: [PATCH v1 3/5] amd64_edac: enforce synchronous probe

2014-10-02 Thread Luis R. Rodriguez
On Thu, Oct 02, 2014 at 11:18:00AM +0200, Borislav Petkov wrote: On Thu, Oct 02, 2014 at 12:39:59AM +0200, Luis R. Rodriguez wrote: ... and my system was still useless and even end up in some fun page faults, but again I think this is all related. I reviewed sysfs / kernfs code and didn't

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-02 Thread Luis R. Rodriguez
now. On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: On Tue, Sep 30, 2014 at 5:24 PM, Luis R. Rodriguez mcg...@suse.com wrote: commit e64fae5573e566ce4fd9b23c68ac8f3096603314 Author: Kay Sievers kay.siev...@vrfy.org Date: Wed Jan 18 05:06:18 2012 +0100 udevd: kill

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-02 Thread Luis R. Rodriguez
On Tue, Sep 30, 2014 at 09:21:59AM +0200, Luis R. Rodriguez wrote: On Mon, Sep 29, 2014 at 05:26:01PM -0400, Tejun Heo wrote: Hello, Luis. On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote: + /* For now lets avoid stupid bug reports */ + if (!strcmp(bus

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-02 Thread Luis R. Rodriguez
On Tue, Sep 30, 2014 at 09:15:55AM +0200, Luis R. Rodriguez wrote: Can you provide an example code path hit here? I'll certainly like to address that as well. I managed to enable built-in driver support on top of this series, I'll send them as part of the next series but I suspect we'll want

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-03 Thread Luis R. Rodriguez
On Fri, Oct 3, 2014 at 1:23 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: Making kmod a special case is of course possible. However, as long

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-03 Thread Luis R. Rodriguez
On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: + queue_work(system_unbound_wq, priv-attach_work-work); Tejun, based on my testing so far using system_highpri_wq instead of system_unbound_wq yields close to par / better boot times than synchronous probe support for all

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-10-03 Thread Luis R. Rodriguez
On Fri, Oct 03, 2014 at 10:11:26PM +0200, Luis R. Rodriguez wrote: On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: + queue_work(system_unbound_wq, priv-attach_work-work); Tejun, based on my testing so far using system_highpri_wq instead of system_unbound_wq yields

[PATCH v2 4/7] amd64_edac: enforce synchronous probe

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com While testing asynchronous PCI probe on this driver I noticed it failed so enforce just synchronouse probe for now. Asynchronous probe is not used by default and requires userepace intervention. Patches for its support will be merged later. The reason

[PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com At times we may wish to express the desire to prefer to have a device driver probe asynchronously by default. We cannot simply enable all device drivers to do this without vetting that userspace is prepared for this though given that some old userspace

[PATCH v2 6/7] driver-core: add driver module asynchronous probe support

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Some init systems may wish to express the desire to have device drivers run their device driver's bus probe() run asynchronously. This implements support for this and allows userspace to request async probe as a preference through a generic shared device

[PATCH v2 5/7] driver-core: generalize freeing driver private member

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This will be used later. Cc: Tejun Heo t...@kernel.org Cc: Arjan van de Ven ar...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- drivers/base/bus.c

[PATCH v2 2/7] module: add extra argument for parse_params() callback

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This adds an extra argument onto parse_params() to be used as a way to make the unused callback a bit more useful and generic by allowing the caller to pass on a data structure of its choice. An example use case is to allow us to easily make module

[PATCH v2 3/7] driver-core: enable drivers to opt-out of async probe

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com We'll soon add generic support for asynchronous probe, before that gets merged lets let drivers annotate if they should never probe asynchronously. Cc: Tejun Heo t...@kernel.org Cc: Arjan van de Ven ar...@linux.intel.com Cc: Greg Kroah-Hartman gre

[PATCH v2 1/7] taint: add TAINT_DEBUG for invasive debugging features

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com At times we may add module parameters or debugging / testing kernel features, when enabled though we don't really want to be spending time debugging them. Add a taint flag for this to avoid spurious bug reports. Cc: Rusty Russell ru...@rustcorp.com.au Cc

[PATCH v2 0/7] driver-core: async probe support

2014-10-03 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com This second series addresses all comments from the v1 series, it removed the white list, tidies up the commit logs, adds documentation for the kernel parameters, adds a new debug taint flag and uses it for the testing kernel parameters we have added

Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-06 Thread Luis R. Rodriguez
On Mon, Oct 06, 2014 at 04:19:26PM -0400, Tejun Heo wrote: Hello, Luis. The patchset generally looks good to me. Please feel free to add Reviewed-by: Tejun Heo t...@kernel.org Will do. A question below. On Fri, Oct 03, 2014 at 02:44:43PM -0700, Luis R. Rodriguez wrote

Re: [Cocci] [PATCH v2 2/7] module: add extra argument for parse_params() callback

2014-10-06 Thread Luis R. Rodriguez
On Sat, Oct 04, 2014 at 02:55:38PM +0200, SF Markus Elfring wrote: This adds an extra argument onto parse_params() to be used as a way to make the unused callback a bit more useful and generic by allowing the caller to pass on a data structure of its choice. How do you think about to

Re: [Cocci] [PATCH v2 2/7] module: add extra argument for parse_params() callback

2014-10-06 Thread Luis R. Rodriguez
On Mon, Oct 06, 2014 at 11:06:34PM +0200, SF Markus Elfring wrote: How do you think about to work with more data type definitions for such callback functions? Sorry I don't understand what you mean. Can a specific typedef help in corresponding software maintenance? Do you find

Re: [PATCH v2 7/7] driver-core: add preferred async probe option for built-in and modules

2014-10-06 Thread Luis R. Rodriguez
On Mon, Oct 06, 2014 at 05:01:18PM -0400, Tejun Heo wrote: Hello, On Mon, Oct 06, 2014 at 10:36:27PM +0200, Luis R. Rodriguez wrote: Do we intend to keep this param permanently? Isn't this more of a temp tool to be used during development? If so, maybe we should make that clear

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-09-30 Thread Luis R. Rodriguez
On Sun, Sep 28, 2014 at 12:22:47PM -0700, Dmitry Torokhov wrote: Hi Luis, On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: +static bool drv_enable_async_probe(struct device_driver *drv, + struct bus_type *bus) +{ + struct module *mod

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

2014-09-30 Thread Luis R. Rodriguez
On Mon, Sep 29, 2014 at 05:26:01PM -0400, Tejun Heo wrote: Hello, Luis. On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote: + /* For now lets avoid stupid bug reports */ + if (!strcmp(bus-name, pci) || + !strcmp(bus-name, pci_express

Re: [PATCH v1 3/5] amd64_edac: enforce synchronous probe

2014-09-30 Thread Luis R. Rodriguez
On Sun, Sep 28, 2014 at 10:41:23AM -0400, Tejun Heo wrote: On Fri, Sep 26, 2014 at 02:57:15PM -0700, Luis R. Rodriguez wrote: ... [ 14.414746] [814d2cf9] ? dump_stack+0x41/0x51 [ 14.414790] [81061972] ? warn_slowpath_common+0x72/0x90 [ 14.414834] [810619d7

<    1   2   3   4   5   6   7   8   9   10   >