o replace the deprecated
> create_singlethread_workqueue instance.
>
> The WQ_MEM_RECLAIM flag has been set to ensure forward progress under
> memory pressure since it's a network driver.
>
> Since there are fixed number of work items, explicit concurrency
> limit is unnecessary here.
>
> S
ue has been used.
> Since the workqueue is not being used on a memory reclaim path,
> WQ_MEM_RECLAIM has not been set.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe lin
Hello,
On Tue, Aug 02, 2016 at 03:29:48PM +0200, Oliver Neukum wrote:
> Apparently if that is the requirement USB will have to define its own
> set of flags to use in such contexts. But still the calls as currently
> executed work. Taking away WQ_MEM_RECLAIM would create danger of
> introducing a
Hello,
On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > All that would do is deferring the deadlock, right? I'm not sure it
> > makes a lot of sense to protect an IO path against memory pressure
> > half-way. It either can be depended during memory reclaim or it
> > can't.
>
>
cy shouldn't make any difference.
>
> The work item has been flushed in lvs_rh_disconnect() to ensure that
> there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from th
;
> The workqueue "wq_otg" is not being used on a memory reclaim path.
> Hence, WQ_MEM_RECLAIM has not been set.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe
Hello, Alan.
On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote:
> > Hmm... That doesn't really make them dependable during memory reclaim.
>
> True. But it does mean that they can't cause a deadlock by waiting
> indefinitely for some other memory to be paged out to the very device
> the
Hello, Alan.
On Wed, Jul 27, 2016 at 02:54:51PM -0400, Alan Stern wrote:
> > Hmm... I didn't know the whole USB stack could operate without
> > allocating memory. Does usb stack have mempools and stuff all the way
> > through?
>
> No -- the USB stack does need to allocate memory in order to oper
Hello, Oliver.
On Wed, Jul 27, 2016 at 11:29:56AM +0200, Oliver Neukum wrote:
> On Wed, 2016-07-27 at 14:50 +0530, Bhaktipriya Shridhar wrote:
> > The workqueue "workqueue" has multiple workitems which may require
> > ordering. Hence, a dedicated ordered workqueue has been used.
> > Since the work
ding with destruction.
> Hence, it has been sync cancelled in appledisplay_disconnect().
> This also ensures that there are no pending tasks while disconnecting
> the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this li
uct
> backlight_device *bd)
> pdata->msgdata, 2,
> ACD_USB_TIMEOUT);
> mutex_unlock(&pdata->sysfslock);
> -
> +
???
Other than that,
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
These functions are called in
> ftdi_elan_exit() to ensure that there are no pending work items while
> disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, Jan, Alan.
On Tue, Mar 15, 2016 at 10:25:43AM +0100, Jan Kara wrote:
> > The kernel does suspend device drivers; that is, it invokes their
> > suspend callbacks. But it doesn't "freeze" them in any sense. Once a
> > driver has been suspended, it assumes it won't receive any I/O requests
Hello, Jan.
On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > Ugh... that's nasty. I wonder whether the right thing to do is making
> > writeback workers non-freezable. IOs are supposed to be blocked from
> > lower layer anyway. Jan, what do you think?
>
> Well no, at least current
Hello,
(cc'ing Jan)
On Fri, Feb 26, 2016 at 02:19:20PM +0800, Peter Chen wrote:
> On Thu, Feb 25, 2016 at 05:01:12PM -0500, Tejun Heo wrote:
> > Hello, Peter.
> >
> > On Wed, Feb 24, 2016 at 03:24:30PM +0800, Peter Chen wrote:
> > > > You might want to co
Hello, Peter.
On Wed, Feb 24, 2016 at 03:24:30PM +0800, Peter Chen wrote:
> > You might want to complain to the block-layer people about this. I
> > don't know if anything can be done to fix it.
> >
> > Or maybe flush_work and flush_delayed_work can be changed to avoid
> > blocking if the work
On Wed, Sep 30, 2015 at 11:43:01AM -0500, Felipe Balbi wrote:
> Seems like there are *ton* of uses of container_of() wrapped within a simple
> macro. What convention are you talking about, again ?
The convention of using inline functions over macros when possible.
We don't do that all the time but
On Wed, Sep 30, 2015 at 11:32:19AM -0500, Felipe Balbi wrote:
> On Wed, Sep 30, 2015 at 12:20:46PM -0400, Tejun Heo wrote:
> > On Wed, Sep 30, 2015 at 11:19:25AM -0500, Felipe Balbi wrote:
> > > On Mon, Sep 28, 2015 at 03:35:14PM +0200, Christoph Hellwig wrote:
> > > &
On Wed, Sep 30, 2015 at 11:19:25AM -0500, Felipe Balbi wrote:
> On Mon, Sep 28, 2015 at 03:35:14PM +0200, Christoph Hellwig wrote:
> > On Sun, Sep 27, 2015 at 10:50:53AM -0500, Felipe Balbi wrote:
> > > this (and the other helper below) could be macros just fine.
> >
> > They could, but they shoul
Hello, Christoph.
On Fri, Sep 25, 2015 at 06:49:38AM -0700, Christoph Hellwig wrote:
> Add methods to struct configfs_attribute to directly show and store
> attributes without adding boilerplate code to every user. In addition
> to the methods this also adds 3 helper macros to define read/write,
B_MUSB_OMAP2PLUS has a cyclic
> >dependency, so it is left as "select".
> >
> >Signed-off-by: Arun Ramamurthy
>
> Need your ACK for this patch.
For ATA part,
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line &qu
atches are merged to mainline
before applying to subsystem trees.
Signed-off-by: Tejun Heo
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/whci/debug.c | 7 ++-
drivers/usb/wusbcore/reservation.c | 5 ++---
drivers/usb/wusbcore/wa-rpipe.c
Hello, Akinobu.
On Tue, Jan 20, 2015 at 11:57:37PM +0900, Akinobu Mita wrote:
> The reason I didn't move sht from the core driver to the LLDDs for
> fixing ufs and ums-* in the first place is to avoid exporting many
> symbols for callbacks in sht. But I realized that we can do it
> without that m
On Mon, Jan 19, 2015 at 12:05:58AM +0900, Akinobu Mita wrote:
> While accessing a scsi_device, the use count of the underlying LLDD
> module is incremented. The module reference is retrieved through
> .module field of struct scsi_host_template.
>
> This mapping between scsi_device and underlying
On Thu, Sep 18, 2014 at 06:15:02PM +0200, Petr Mládek wrote:
> The easiest solution would be to allocate the work queue with
> the flag WQ_UNBOUND and max_active = 1. It will force serialization
> of all work items.
Please use alloc_ordered_workqueue() for that purpose. WQ_UNBOUND +
max_active ==
Hello, Alan, Petr.
On Wed, Sep 17, 2014 at 01:36:26PM -0400, Alan Stern wrote:
> > - /* If khubd ever becomes multithreaded, this will need a lock */
> > + /* If hub_wq ever becomes multithreaded, this will need a lock */
> > if (udev->wusb) {
> > devnum = udev->portnum + 1;
>
On Fri, Sep 12, 2014 at 02:21:05PM +0200, Petr Mladek wrote:
> There is no need to have separate kthread for handling USB hub events.
> It is more elegant to use the workqueue framework.
>
> The workqueue is allocated as unbound, cpu intensive, and freezable.
I'd just go with WQ_FREEZABLE. As a
On Mon, Apr 28, 2014 at 08:39:47AM +0800, Li Zhong wrote:
> Yes, maybe try to get the module reference is not bad before writing to
> driver attributes, as it doesn't make much sense to really call the
> callbacks for the driver attribute if the driver is being unload.
Please don't do that spuriou
On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote:
> On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
> > cc'ing Li Zhong who's working on a simliar issue in the following
> > thread and quoting whole body.
> >
> > http://thread.gmane.org/gmane.l
cc'ing Li Zhong who's working on a simliar issue in the following
thread and quoting whole body.
http://thread.gmane.org/gmane.linux.kernel/1680706
Li, this is another variation of the same problem. Maybe this can be
covered by your work too?
Thanks.
On Wed, Apr 23, 2014 at 11:32:19AM +0200,
Hello,
On Thu, Apr 03, 2014 at 04:32:24PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > So, apparently, this isn't enough as this would allow enabling
> > PHY_XGENE regardless of HAS_IOMEM or OF. From kconfig-language.txt,
>
> PHY_XGENE has the following dependencies:
>
> depends on HAS_IOM
cies already.
Signed-off-by: Tejun Heo
Reported-by: Linus Torvalds
Cc: Loc Ho
Cc: Bartlomiej Zolnierkiewicz
Cc: Kishon Vijay Abraham I
---
drivers/ata/Kconfig |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 20e03a7.
Hello, Kishon.
I'm converting AHCI_XGENE to depend on PHY_XGENE instead of selecting
it as dependency chaining through select doesn't work. Looking at the
PHY Kconfig options, I wonder whether we're going about this the right
way. Are PHY drivers meaningful at all w/o higher level drivers
making
On Wed, Apr 02, 2014 at 11:53:57AM -0400, Tejun Heo wrote:
> Applied the following patch to libata/for-3.15-fixes.
>
> Thanks.
> --- 8< ---
> From 9c23f2cf7f6e107e85eef57fdf3049a93b6e157c Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Wed, 2 Apr 2014 11:47:04
On Wed, Apr 02, 2014 at 11:53:57AM -0400, Tejun Heo wrote:
> config AHCI_XGENE
> tristate "APM X-Gene 6.0Gbps AHCI SATA host controller support"
> - depends on ARM64 || COMPILE_TEST
> + depends on ARM64
> select PHY_XGENE
So, an alternative would
Applied the following patch to libata/for-3.15-fixes.
Thanks.
--- 8< ---
>From 9c23f2cf7f6e107e85eef57fdf3049a93b6e157c Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Wed, 2 Apr 2014 11:47:04 -0400
AHCI_XGENE is only applicable on ARM64 but it can also be enabled for
compile t
Hey, Alan.
On Sat, Feb 22, 2014 at 06:03:04PM -0500, Alan Stern wrote:
> > then a single init work could be queued to
> > the system_unbound_wq which doesn't care about running times.
>
> This sort of thing sounds like the best approach. Tejun, do you want
> to rewrite the patch, getting rid of
On Sat, Feb 22, 2014 at 10:14:48AM -0500, Alan Stern wrote:
> Is the cancel_delayed_work_sync(&hub->init_work) call in hub_quiesce()
> going to get confused by all this?
Yeah, you can't cancel a work item which hasn't been initialzed.
Maybe move init of the first work function there? I don't thin
e tree.
Lightly tested.
v2: Greg and Alan confirm that the work item is never queued while
in-flight. Simply use INIT_DELAYED_WORK().
Signed-off-by: Tejun Heo
Cc: Greg Kroah-Hartman
Cc: Alan Stern
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/hub.c |4 ++--
1 file changed, 2
On Fri, Feb 21, 2014 at 10:06:05AM -0500, Alan Stern wrote:
> > I think it should be fine to use INIT_DELAYED_WORK(), but Alan would
> > know best. Alan?
>
> That's right; INIT_DELAYED_WORK() should be fine. Provided there's no
> problem doing it from within the previous work routine.
Yeah, th
o
simply using INIT_DELAYED_WORK() before each queueing could be enough.
This patch performs equivalent conversion just in case but we probably
wanna clean it up later if that's the case.
It would probably be best to route this with other related updates
through the workqueue tree.
Lightly tested.
S
[] ret_from_fork+0x7c/0xb0
Fix it by making kernfs_deactivate() perform lockdep annotations only
if KERNFS_LOCKDEP is set.
Signed-off-by: Tejun Heo
Reported-by: Fabio Estevam
Reported-by: Alan Stern
---
fs/kernfs/dir.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff
Hello, guys.
(cc'ing Greg)
On Fri, Dec 13, 2013 at 01:19:36PM -0500, Alan Stern wrote:
> On Fri, 13 Dec 2013, Sarah Sharp wrote:
>
> > > Given the way things work now, I suspect these warnings are truly
> > > harmless. We could simply get rid of the WARN in sysfs_remove_group.
> > >
> > > The
Hello, Josh.
On Wed, Dec 04, 2013 at 05:01:53PM -0600, Josh Hunt wrote:
> So there used to be a call to async_synchronize_full() in
> ata_host_register(), but it was removed by
> f29d3b23238e1955a8094e038c72546e99308e61 as part of some fastboot
> changes. Adding it back (in the attached patch) see
Hello,
On Tue, Dec 03, 2013 at 08:28:43AM -0600, Josh Hunt wrote:
> You're right. Thanks for pointing this out. I did not realize there
> was a bug in the init script. The version of initramfs-tools I was
> using had the following bug:
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+b
ed for converting to sg_miter_* APIs in USB storage
> driver for accessing sg buffer.
>
> Acked-by: Andrew Morton
> Cc: FUJITA Tomonori
> Cc: Tejun Heo
> Cc: Jens Axboe
> Signed-off-by: Ming Lei
Reviewed-by: Tejun Heo
I suppose this should go through -mm?
Thanks.
--
tej
Hello,
On Tue, Nov 26, 2013 at 04:12:41PM -0600, Josh Hunt wrote:
> I should have clarified that I'm not using dm/md in my setup. I know
> the modules are getting loaded in the log I attached, but root is not
> a md/dm device.
Can you please still try it? The init script is broken and we're now
Hey,
On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote:
> Another would be if subsystem maintainers are happy that I carry them,
> I can add the acks, and then later on towards the end of the cycle,
> provide a branch subsystem maintainers could pull.
>
> Or... if you can t
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_c
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King
Acked-by: Tejun Heo
The patch is pretty widely spread. I don't mind how it gets routed
but what's the plan?
Thanks.
--
tejun
--
To unsubscribe from this list: send the l
Hello, Jonathan.
On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote:
> My laptop fails to boot[1] with the message 'Volume group "data" not
> found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that
> commit on top of current "master" (d92581fcad18, 2013-08-10) produces
> a
On Wed, Jul 31, 2013 at 04:25:23PM +0100, Mark Brown wrote:
> What I'm saying is that in essentially all the users I've seen devm is
> only being used for things like kfree() or clk_put() which aren't really
> connected in any way and can happen in any order. This (coupled with
> the lack of docum
hello,
On Wed, Jul 31, 2013 at 09:55:26PM +0800, Peter Chen wrote:
> I think the main point is we should allocate managed resource which is used
> at interrupt handler before devm_request_irq, and all resources used
> at interrupt
> handler should be managed.
>
> If we use non-managed resource at
On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
> That's the only API I've ever heard of doing that. Everything else is
> just using it to do deallocation.
I'm not sure why or what you're trying to argue here but take a look
at devm_pwm_release() for example. It calls back into low l
Hello,
On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
> It's really only interrupts that affect most devices - if there's DMA or
> anything going on after the remove() then as you said earlier the driver
> is probably doing something wrong.
Hmmm... it depends on the specific driver i
On Wed, Jul 31, 2013 at 12:50:27PM +0100, Mark Brown wrote:
> Most things would work just fine - most of the uses of devm_ are just
> resource allocations that can safely be freed in essentially any order.
> It doesn't really matter if you free the driver's private structure
> before you free the c
Hello,
On Wed, Jul 31, 2013 at 12:18:53PM +0100, Mark Brown wrote:
> I'm not sure I understand how this relates the problem. The main issue
> here is that for the shared IRQ case quiescing the device doesn't make
> any difference since one of the other users of the interrupt could cause
> the int
On Wed, Jul 31, 2013 at 12:28:53PM +0200, Uwe Kleine-König wrote:
> Well, you cannot avoid assuming that the irq is still active when your
> driver's remove callback is called. But I agree about crappyness at the
> end of the destruction path. The problem is that crap is as easy as:
>
> prob
Hello,
On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-König wrote:
> > > OK, so the possible problem is that remove is called while the irq is
> > > still active. That means you have to assert that all resources the irq
If your driver destruction path is running while your irq handler is
st
>From bb813f4c933ae9f887a014483690d5f8b8ec05e1 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jan 2013 14:05:56 -0800
This patch adds default module loading and uses it to load the default
block elevator. During boot, it's called right after initramfs or
initrd is made avail
>From 21c3c5d2800733b7a276725b8e1ae49a694adc1a Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 22 Jan 2013 16:48:03 -0800
Block layer allows selecting an elevator which is built as a module to
be selected as system default via kernel param "elevator=". This is
achieved by
entry is linked
to two lists - one global and one per domain - and not move it when
execution starts. There's no reason to distinguish pending and
running. They behave the same for synchronization purposes.
v2: Description updated to better explain why it's broken.
Signed-off-by: Te
>From 4983f3b51e18d008956dd113e0ea2f252774cefc Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jan 2013 14:05:57 -0800
Synchronous requet_module() from an async worker can lead to deadlock
because module init path may invoke async_synchronize_full(). The
async worker waits
>From 84b233adcca3cacd5cfa8013a5feda7a3db4a9af Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jan 2013 14:05:56 -0800
This function queries whether %current is an async worker executing an
async item. This will be used to implement warning on synchronous
request_module() from as
>From 2eaebdb33e1911c0cf3d44fd3596c42c6f502fab Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jan 2013 14:05:55 -0800
This will be used to implement an inline function to query whether
%current is a workqueue worker and, if so, allow determining which
work item it's executing.
>From ea138446e51f7bfe55cdeffa3f1dd9cafc786bd8 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jan 2013 14:05:55 -0800
Workqueue wants to expose more interface internal to kernel/. Instead
of adding a new header file, repurpose kernel/workqueue_sched.h.
Rename it to workqueue_interna
>From 111c225a5f8d872bc9327ada18d13b75edaa34be Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Thu, 17 Jan 2013 17:16:24 -0800
PF_WQ_WORKER is used to tell scheduler that the task is a workqueue
worker and needs wq_worker_sleeping/waking_up() invoked on it for
concurrency management. As rescu
On Thu, Jan 17, 2013 at 07:18:26PM -0800, Linus Torvalds wrote:
> I'm not sure I understand what you mean? Do you mean trying to limit
> work_current_func() to only be accessible to the async code? You'd
> have to make some kind of private header file under kernel/ for that,
> but I guess that woul
On Thu, Jan 17, 2013 at 06:59:36PM -0800, Tejun Heo wrote:
> I'd prefer to keep struct worker inside workqueue.c, so how about
> keeping the workqueue part and make async part current_is_async()?
Another thing is that it seems like having introspection type
interface often lea
Hello, Linus.
On Thu, Jan 17, 2013 at 06:47:48PM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 5:25 PM, Tejun Heo wrote:
> > Implement work/async_current_func() which query whether the current
> > task is a workqueue or async worker respectively and, if so, return
following thread.
http://thread.gmane.org/gmane.linux.kernel/1420814
Signed-off-by: Tejun Heo
Reported-by: Alex Riesen
Cc: Linus Torvalds
Cc: Arjan van de Ven
---
Linus, please note that I dropped system_state == SYSTEM_RUNNING
condition from WARN_ON_ONCE() as the deadlock can happen during
async workers.
Signed-off-by: Tejun Heo
Cc: Linus Torvalds
Cc: Arjan van de Ven
---
include/linux/async.h | 2 ++
include/linux/workqueue.h | 1 +
kernel/async.c| 25 +
kernel/workqueue.c| 22 ++
4 files changed, 50
sociated workqueue_struct instead.
This is problematic as wq_worker_sleeping/waking_up() expect struct
worker at kthread_data().
This patch adds worker->rescue_wq and start rescuer kthreads with
worker struct as kthread_data and sets PF_WQ_WORKER on rescuers.
Signed-off-by: Tejun Heo
Cc: Lin
Hello,
On Thu, Jan 17, 2013 at 10:16:50AM -0800, Linus Torvalds wrote:
> Tejun, mind explaining this one a bit more to me?
>
> If ordering matters, and we have a running queue and a pending queue,
> how could the pending queue *ever* be lower than the running one?
So, before being converted to w
Hello, Linus.
On Thu, Jan 17, 2013 at 10:05:53AM -0800, Linus Torvalds wrote:
> And here I was really hoping that there was a third patch in the
> series that added the warning...
>
> We don't currently have a "am I an async worker" helper function for
> the warning to use, which is something ver
On Thu, Jan 17, 2013 at 10:46:47AM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 10:38 AM, Tejun Heo wrote:
> >
> > Oh yeah, it's coming. I just wanted to finish something else first
> > and, as turning on PF_WQ_WORKER on a rescuer thread has some chance
d.
http://thread.gmane.org/gmane.linux.kernel/1420814
Signed-off-by: Tejun Heo
Cc: Jens Axboe
Cc: Arjan van de Ven
Cc: Linus Torvalds
Cc: Alex Riesen
---
block/elevator.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -100,
es in initramfs, initrd or the root filesystem, the
default modules are loaded as soon as possible.
This will replace the on-demand elevator module loading from elevator
init path.
Signed-off-by: Tejun Heo
Cc: Jens Axboe
Cc: Arjan van de Ven
Cc: Linus Torvalds
Cc: Alex Riesen
---
block/eleva
Hello, Alan.
On Wed, Jan 16, 2013 at 12:01:53PM -0500, Alan Stern wrote:
> > The problem here is that "flush everything which comes before me" is
> > used to order async jobs. e.g. after async jobs probe the hardware
> > they order themselves by flushing before registering them, so unless
>
> I
ove it when
execution starts. There's no reason to distinguish pending and
running. They behave the same for synchronization purposes.
Signed-off-by: Tejun Heo
Cc: Arjan van de Ven
Cc: sta...@vger.kernel.org
---
And here's the fix for the breakage I mentioned earlier. It wouldn't
ha
Hey,
On Tue, Jan 15, 2013 at 07:37:42PM -0800, Linus Torvalds wrote:
> I do want the same user-visible semantics, so it's not some one-liner.
>
> The compiled-in elevator would be easy enough to handle in the Kconfig
> file (maybe we do already, I didn't even bother to check). The real
> problem
Hello, Alan.
On Tue, Jan 15, 2013 at 11:01:15PM -0500, Alan Stern wrote:
> > The current domain implementation is somewhere inbetween. It's not
> > completely simplistic system and at the same time not developed enough
> > to do properly stacked flushing.
>
> I like your idea of chronological sy
Hello, Linus.
On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
> That said, maybe we could just make the rule be that you can't pick a
> default IO scheduler that is modular.
This is definitely much more preferable but it would affect use case
where everything is built modular and
adlock if async module loading nests;
however, this works around the known problem case and seems to be the
best of bad options.
For more details, please refer to the following thread.
http://thread.gmane.org/gmane.linux.kernel/1420814
Signed-off-by: Tejun Heo
Reported-by: Alex Riesen
Cc:
On Tue, Jan 15, 2013 at 04:36:34PM -0800, Linus Torvalds wrote:
> The thing is, the module loading in particular is not necessarily
> happening in the same context as what *started* the module loading. A
> module loader will request the module from user space, and then later
> user space - through
Hello, Arjan.
On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote:
> async fundamentally had the concept of a monotonic increasing number,
> and that you could always wait for "everyone before me".
> then people (like me) wanted exceptions to what "everyone" means ;-(
> I'm ok with go
cc'ing Arjan. Arjan, the original thread can be read from
http://thread.gmane.org/gmane.linux.kernel/1420814
Hello, again.
On Tue, Jan 15, 2013 at 12:18:01PM -0800, Linus Torvalds wrote:
> I think that is a good solution if it works, but look out: we need to
> synchronize across *all* domains
Hello, Linus
Will continue on another reply but this one is relevant so...
On Tue, Jan 15, 2013 at 10:18:45AM -0800, Linus Torvalds wrote:
> Tejun, is there a good way for code to see "I'm running in async
> context"? Then we could do something like
Almost. With a bit of modification we can ask
Hello, Alan.
On Tue, Jan 15, 2013 at 01:20:58PM -0500, Alan Stern wrote:
> It may not be so easy. When the SCSI async thread probes the new disk,
> it has to do I/O. So it needs to use a scheduler.
>
> But maybe it could use a built-in trivial scheduler until the proper
> one is loaded. Then
Hello, Linus.
On Tue, Jan 15, 2013 at 09:36:57AM -0800, Linus Torvalds wrote:
> Tejun, comments? You can see the whole thread on lkml, but the basic
> problem is that the module loading doing the unconditional
> async_synchronize_full() has caused problems, because we have
>
> - load module A
>
There's no need to test whether a (delayed) work item in pending
before queueing, flushing or cancelling it. Most uses are unnecessary
and quite a few of them are buggy.
Remove unnecessary pending tests from at91_udc. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Andrew Victo
91 matches
Mail list logo
