On Fri, 2012-12-21 at 18:43 -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Nov 2012 20:39:33 +0900
> YAMANE Toshiaki escreveu:
>
> > fixed below checkpatch error.
> > - ERROR: trailing statements should be on next line
> >
> > Signed-off-by: YAMANE Toshiaki
> > ---
> > drivers/staging/media/
On 21.12.2012 16:36, Thierry Reding wrote:
> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>> +static struct platform_driver tegra_drm_platform_driver = {
>> +.driver = {
>> +.name = "tegradrm",
>
> This should be "tegra-drm" to match the module name.
We've actu
On Sat, Dec 22, 2012 at 12:21:11AM -0500, Simon Marchi wrote:
> It is needed when we turn on HAVE_ARCH_TRACEHOOK.
... and if you check the mainline, you'll see it (and other missing
user_stack_pointer() instances) already in place, as part of infrastructure
for sigaltstack series.
--
To unsubscrib
Signed-off-by: Axel Lin
---
drivers/dma/intel_mid_dma.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/dma/intel_mid_dma.c b/drivers/dma/intel_mid_dma.c
index bc764af..1a83d1d 100644
--- a/drivers/dma/intel_mid_dma.c
+++ b/drivers/dma/intel_mid_dma.c
@@ -13
On Fri, Dec 21, 2012 at 3:51 PM, Rik van Riel wrote:
> Subject: x86,smp: auto tune spinlock backoff delay factor
>
> Many spinlocks are embedded in data structures; having many CPUs
> pounce on the cache line the lock is in will slow down the lock
> holder, and can cause system performance to fall
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 493c8c6..87c55d0 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/d
On Fri, Dec 21, 2012 at 12:23:41PM -0800, Stephen Boyd wrote:
> On 12/21/12 11:12, Dmitry Voytik wrote:
> > Add vi-style keys for menu navigation: press j/k for down/up navigation
> > and l for entering to a submenu. Unfortantely h key is reserved for
> > the items help.
>
> Maybe you can just add
Looks like we have everything needed for that.
Signed-off-by: Simon Marchi
---
arch/tile/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..8cab409 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -21,6 +
Call tracehook functions for syscall tracing.
The check for TIF_SYSCALL_TRACE was removed, because the same check is
done right before in the assembly file.
Signed-off-by: Simon Marchi
---
arch/tile/kernel/intvec_32.S |6 --
arch/tile/kernel/intvec_64.S |6 --
arch/tile/kernel/p
It is needed when we turn on HAVE_ARCH_TRACEHOOK.
Signed-off-by: Simon Marchi
---
arch/tile/include/asm/ptrace.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/tile/include/asm/ptrace.h b/arch/tile/include/asm/ptrace.h
index 5ce052e..4be42fb 100644
--- a/arch/t
On Fri, Dec 21, 2012 at 6:42 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 17, 2012 at 11:15:32PM -0800, Yinghai Lu wrote:
>> Now we have limit kdump reseved under 896M, because kexec has the limitation.
>> and also bzImage need to stay under 4g.
>>
>> To make kexec/kdump could use range above 4g
On Fri, Dec 21, 2012 at 7:25 PM, H. Peter Anvin wrote:
> On 12/21/2012 07:23 PM, Eric W. Biederman wrote:
>>
>> In this case YH has been working on the case of loading a kernel
>> completely above 4G, and apparently he has also been testing the case of
>> running a kernel with no memory below 4G.
On Fri, Dec 21, 2012 at 6:42 PM, Eric W. Biederman
wrote:
> Konrad Rzeszutek Wilk writes:
>
>> On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
>>> So use could disable swiotlb from command line, even swiotlb support
>>> is compiled in. Just like we have intel_iommu=on and intel_iommu
On Fri, Dec 21, 2012 at 6:18 PM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Dec 13, 2012 at 02:02:18PM -0800, Yinghai Lu wrote:
>> So use could disable swiotlb from command line, even swiotlb support
>> is compiled in. Just like we have intel_iommu=on and intel_iommu=off.
>
> Does this have any usage
While testing the pid namespace code I hit this nasty warning.
[ 176.262617] [ cut here ]
[ 176.263388] WARNING: at
/home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160
local_bh_enable_ip+0x7a/0xa0()
[ 176.265145] Hardware name: Bochs
[ 176.265677] Modul
Oleg pointed out that in a pid namespace the sequence.
- pid 1 becomes a zombie
- setns(thepidns), fork,...
- reaping pid 1.
- The injected processes exiting.
Can lead to processes attempting access their child reaper and
instead following a stale pointer.
That waitpid for init can return before
The sequence:
unshare(CLONE_NEWPID)
clone(CLONE_THREAD|CLONE_SIGHAND|CLONE_VM)
Creates a new process in the new pid namespace without setting
pid_ns->child_reaper. After forking this results in a NULL
pointer dereference.
Avoid this and other nonsense scenarios that can show up after
creating a
Oleg assuming I am not blind these patches should fix the issues you
spotted in the pid namespace as well as one additional one that I found
during testing.
Anyone with an extra set of eyeballs that wants to look over this code
and double check to make certain I am not doing something stupid woul
On Fri, Dec 21, 2012 at 3:51 PM, Rik van Riel wrote:
> Subject: x86,smp: proportional backoff for ticket spinlocks
>
> Simple fixed value proportional backoff for ticket spinlocks.
> By pounding on the cacheline with the spin lock less often,
> bus traffic is reduced. In cases of a data structure
On 12/21/2012 11:40 PM, Michel Lespinasse wrote:
On Fri, Dec 21, 2012 at 3:50 PM, Rik van Riel wrote:
@@ -53,12 +55,11 @@ static __always_inline void
__ticket_spin_lock(arch_spinlock_t *lock)
inc = xadd(&lock->tickets, inc);
+ if (inc.head == inc.tail)
+ goto
On Fri, Dec 21, 2012 at 3:50 PM, Rik van Riel wrote:
> diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
> index 33692ea..2a45eb0 100644
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock.h
> @@ -34,6 +34,8 @@
> # define UNLOCK_LOCK_PREFIX
>
Hi Linus,
This is the pull request for dmaengine. I just saw that you have declared rc1
couple of hours ago, so I missed the window narrowly... I can try to make an
excuse that I am vacation and was traveling so this got delayed. And was
counting on your Christmas deadline :(
Please do consider m
From: Thomas Gleixner
If the policy and priority remain unchanged a possible modification of
sched_reset_on_fork gets lost in the early exit path.
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Cc: stable...@vger.kernel.org
---
kernel/sched/core.c |6 --
1 file changed, 4 in
From: Thomas Gleixner
Retry loops on RT might loop forever when the modifying side was
preempted. Steven also observed a live lock when there was a
concurrent priority boosting going on.
Use cpu_chill() instead of cpu_relax() to let the system
make progress.
Signed-off-by: Thomas Gleixner
Cc:
Dear RT Folks,
This is the RT stable review cycle of patch 3.4.24-rt36-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release cand
From: Thomas Gleixner
The following scenario does not work correctly:
Runqueue of CPUx contains two runnable and pinned tasks:
T1: SCHED_FIFO, prio 80
T2: SCHED_FIFO, prio 80
T1 is on the cpu and executes the following syscalls (classic priority
ceiling scenario):
sys_sched_setscheduler(pid
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 366440d..a7827dc 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt35
+-rt36-rc1
--
1.7.10.4
--
To unsubscribe from this lis
From: Thomas Gleixner
If a PI boosted task policy/priority is modified by a setscheduler()
call we unconditionally dequeue and requeue the task if it is on the
runqueue even if the new priority is lower than the current effective
boosted priority. This can result in undesired reordering of the
pr
On 12/20/2012 07:49 PM, Michel Lespinasse wrote:
On most architectures, def_flags is either 0 or VM_LOCKED depending on
whether mlockall(MCL_FUTURE) was called. However, this is not an absolute
rule as kvm support on s390 may set the VM_NOHUGEPAGE flag in def_flags.
We don't want mlockall to clea
On Fri, Dec 21, 2012 at 05:57:11PM -0800, Tejun Heo wrote:
> 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 max3100. Only compi
On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote:
> diff --git a/include/trace/events/host1x.h b/include/trace/events/host1x.h
> index d98d74c..e087910 100644
> --- a/include/trace/events/host1x.h
> +++ b/include/trace/events/host1x.h
> @@ -37,6 +37,214 @@ DECLARE_EVENT_CLASS(host1x,
>
On 12/21/2012 10:49 PM, Steven Rostedt wrote:
On Fri, Dec 21, 2012 at 09:51:35PM -0500, Rik van Riel wrote:
However, since spinlock contention should not be the
usual state, and all a scalable lock does is make sure
that N+1 CPUs does not perform worse than N CPUs, using
scalable locks is a st
Acked-by: Steve Wise
--
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/
Hi, all
I want ask a question.
As we know, structure buffer_head has a member called b_state.
And this state could be defined by many flags.
The question is that, I want to know the relationship between BH_Uptodate
& BH_Dirty.
If a data is verified, the BH_Dirty will setup, and what about BH_Up
On Fri, Dec 21, 2012 at 09:51:35PM -0500, Rik van Riel wrote:
> On 12/21/2012 07:47 PM, David Daney wrote:
>
> >>+#define MIN_SPINLOCK_DELAY 1
> >>+#define MAX_SPINLOCK_DELAY 1000
> >>+DEFINE_PER_CPU(int, spinlock_delay) = { MIN_SPINLOCK_DELAY };
> >
> >
> >This gives the same delay for all locks
On 12/21/2012 10:33 PM, Steven Rostedt wrote:
On Fri, Dec 21, 2012 at 06:56:13PM -0500, Rik van Riel wrote:
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 4e44840..e44c56f 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -113,19 +113,62 @@ static atomic_t stopp
On 12/21/2012 10:14 PM, Steven Rostedt wrote:
OK, I replied here before reading patch 3 (still reviewing it). Why have
this patch at all? Just to test if you broke something between this and
patch 3? Or perhaps patch 3 may not get accepted? In that case, you
would still need a comment.
Either e
On 12/21/2012 10:29 PM, Eric Dumazet wrote:
On Fri, 2012-12-21 at 18:56 -0500, Rik van Riel wrote:
+ int *delay_ptr = &per_cpu(spinlock_delay, smp_processor_id());
+ int delay = *delay_ptr;
int delay = __this_cpu_read(spinlock_delay);
}
+ *delay_ptr = delay;
__thi
On Fri, Dec 21, 2012 at 06:56:13PM -0500, Rik van Riel wrote:
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index 4e44840..e44c56f 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -113,19 +113,62 @@ static atomic_t stopping_cpu = ATOMIC_INIT(-1);
> static bo
On Fri, 2012-12-21 at 18:56 -0500, Rik van Riel wrote:
> + int *delay_ptr = &per_cpu(spinlock_delay, smp_processor_id());
> + int delay = *delay_ptr;
int delay = __this_cpu_read(spinlock_delay);
> }
> + *delay_ptr = delay;
__this_cpu_write(spinlock_delay, delay);
--
To unsubs
On 12/21/2012 07:23 PM, Eric W. Biederman wrote:
>
> In this case YH has been working on the case of loading a kernel
> completely above 4G, and apparently he has also been testing the case of
> running a kernel with no memory below 4G.
>
It is worth noting that we cannot run with *no* memory be
Konrad Rzeszutek Wilk writes:
> On Fri, Dec 21, 2012 at 06:42:47PM -0800, Eric W. Biederman wrote:
>> Konrad Rzeszutek Wilk writes:
>>
>> > On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
>> >> So use could disable swiotlb from command line, even swiotlb support
>> >> is compiled in
From: Namjae Jeon
Since, the memory for the object of dirty_seglist_info is allocated
using kzalloc - which returns zeroed out memory. So, there is no need
to initialize the nr_dirty values with zeroes.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/segment.c |1 -
1
From: Namjae Jeon
We can directly return '0' from the function, instead of introducing a
'ret' variable.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/super.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index
From: Namjae Jeon
In function find_fsync_dnodes() - the fsync inodes gets added to the list, but
in one path suppose f2fs_iget results in error, in such case - error gets added
to the fsync inode list.
In next call to recover_data()->get_fsync_inode()
entry = list_entry(this, struct fsync_inode_e
From: Namjae Jeon
In case f2fs_iget_nowait returns error, it results in truncate_hole being
called with 'error' value as inode pointer. There is no check in truncate_hole
for valid inode, so it could result in crash due "invalid access to memory".
Avoid this by handling error condition properly.
On Fri, Dec 21, 2012 at 10:07:56PM -0500, Steven Rostedt wrote:
> > diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> > index 20da354..4e44840 100644
> > --- a/arch/x86/kernel/smp.c
> > +++ b/arch/x86/kernel/smp.c
> > @@ -118,9 +118,11 @@ static bool smp_no_nmi_ipi = false;
> > void tic
On Fri, Dec 21, 2012 at 06:42:47PM -0800, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk writes:
>
> > On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
> >> So use could disable swiotlb from command line, even swiotlb support
> >> is compiled in. Just like we have intel_iommu=on and
From: Namjae Jeon
Added few informative prints in the mount path, to convey proper error
in case of mount failure.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/super.c | 46 --
1 file changed, 36 insertions(+), 10 deletions(
Hi Kukjin,
Thank you for your review.
I was confused a little bit about bootargs what is better removing or
including it in the board file, obviously I saw error message failing
mount the root file system if I remove bootargs from board file and
with default bootargs from u-boot.
What I thought
On Fri, Dec 21, 2012 at 06:51:15PM -0500, Rik van Riel wrote:
> Subject: x86,smp: proportional backoff for ticket spinlocks
>
> Simple fixed value proportional backoff for ticket spinlocks.
> By pounding on the cacheline with the spin lock less often,
> bus traffic is reduced. In cases of a data s
Tejun Heo wrote:
>
> 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 exynos_dp_core. Only compile
> tested.
>
> Signed-off-by:
On Fri, Dec 21, 2012 at 06:50:38PM -0500, Rik van Riel wrote:
> Subject: x86,smp: move waiting on contended ticket lock out of line
>
> Moving the wait loop for congested loops to its own function allows
> us to add things to that wait loop, without growing the size of the
> kernel text appreciabl
Earlyprintk please?
Konrad Rzeszutek Wilk wrote:
>On Mon, Dec 17, 2012 at 11:15:32PM -0800, Yinghai Lu wrote:
>> Now we have limit kdump reseved under 896M, because kexec has the
>limitation.
>> and also bzImage need to stay under 4g.
>>
>> To make kexec/kdump could use range above 4g, we need
On Fri, Dec 21, 2012 at 06:00:58PM -0800, Linus Torvalds wrote:
> The longest night of the year is upon us (*), and what better thing to
> do than get yourself some nice mulled wine, sit back, relax, and play
> with the most recent rc kernel?
>
> This has been a big merge window: we've got more co
On 12/21/2012 07:18 PM, Eric Dumazet wrote:
On Fri, 2012-12-21 at 18:56 -0500, Rik van Riel wrote:
Argh, the first one had a typo in it that did not influence
performance with fewer threads running, but that made things
worse with more than a dozen threads...
+
+ /*
+
On 12/21/2012 07:48 PM, Eric Dumazet wrote:
On Fri, 2012-12-21 at 18:56 -0500, Rik van Riel wrote:
Argh, the first one had a typo in it that did not influence
performance with fewer threads running, but that made things
worse with more than a dozen threads...
Please let me know if you can break
"Junchang(Jason) Wang" wrote:
> We still believe this is a bug in epoll system even though we can't
> prove that so far. Both Andi and I are very interested in this problem
> and helping you experts solve this it. Just let us know if we can
> help.
I'm just another epoll user, definitely not an e
On 12/21/2012 07:47 PM, David Daney wrote:
+#define MIN_SPINLOCK_DELAY 1
+#define MAX_SPINLOCK_DELAY 1000
+DEFINE_PER_CPU(int, spinlock_delay) = { MIN_SPINLOCK_DELAY };
This gives the same delay for all locks in the system, but the amount of
work done under each lock is different. So, for an
Konrad Rzeszutek Wilk writes:
> On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
>> So use could disable swiotlb from command line, even swiotlb support
>> is compiled in. Just like we have intel_iommu=on and intel_iommu=off.
>
> You really need to spell out why this is useful.
YH wh
On Mon, Dec 17, 2012 at 11:15:32PM -0800, Yinghai Lu wrote:
> Now we have limit kdump reseved under 896M, because kexec has the limitation.
> and also bzImage need to stay under 4g.
>
> To make kexec/kdump could use range above 4g, we need to make bzImage and
> ramdisk could be loaded above 4g.
>
On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
> So use could disable swiotlb from command line, even swiotlb support
> is compiled in. Just like we have intel_iommu=on and intel_iommu=off.
You really need to spell out why this is useful.
>
> Signed-off-by: Yinghai Lu
> ---
> Doc
Fixed compile warning cast to pointer from integer of different size
Signed-off-by: Stefan Hasko
---
drivers/infiniband/hw/cxgb4/device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c
b/drivers/infiniband/hw/cxgb4/device.c
index cb4e
On Wed, Dec 19, 2012 at 01:58:57PM -0800, Yinghai Lu wrote:
> On Wed, Dec 19, 2012 at 12:57 PM, Borislav Petkov wrote:
> > On Tue, Dec 18, 2012 at 07:44:55PM -0800, Yinghai Lu wrote:
> >
> > So this explains what you're doing but I'd like to know why?
> >
> > Why do you need to free some more room
Hello, Andrew.
On Fri, Dec 21, 2012 at 06:15:23PM -0800, Andrew Morton wrote:
> On Fri, 21 Dec 2012 17:57:15 -0800 Tejun Heo wrote:
>
> > 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 fe
On Thu, Dec 13, 2012 at 02:02:17PM -0800, Yinghai Lu wrote:
> Normal boot path on system with iommu support:
> swiotlb buffer will be allocated early at first and then try to initialize
> iommu, if iommu for intel or amd could setup properly, swiotlb buffer
> will be freed.
>
> The early allocatin
On Thu, Dec 13, 2012 at 02:02:18PM -0800, Yinghai Lu wrote:
> So use could disable swiotlb from command line, even swiotlb support
> is compiled in. Just like we have intel_iommu=on and intel_iommu=off.
Does this have any usage besides testing?
And also pls in the future use scripts/get_maintain
On Fri, Dec 21, 2012 at 5:59 PM, Michel Lespinasse wrote:
> On Fri, Dec 21, 2012 at 5:09 PM, Andy Lutomirski wrote:
>> On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse wrote:
>>> On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski
>>> wrote:
Something's buggy here. My evil test case is st
On Fri, 21 Dec 2012 17:57:15 -0800 Tejun Heo wrote:
> 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.
> - if (!work_pending(&ipc_memory_wq))
> -
On Fri, Dec 21, 2012 at 03:52:53PM -0800, Yinghai Lu wrote:
> On Fri, Dec 21, 2012 at 3:39 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Dec 21, 2012 at 02:44:39PM -0800, Yinghai Lu wrote:
> >>
> >> maybe we can change the subject of this patch to:
> >>
> >> Subject: [PATCH] x86, 64bit: Don't set
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 sja1000. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Wolfgang Grandegger
Cc: "D
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 devfreq. Only compile tested.
Signed-off-by: Tejun Heo
Cc: MyungJoo Ham
Cc: Kyungmin
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 and rewrite _setup_polling() so that
it uses mod_delayed_work() if the next polling interval i
* delayed_work_pending() test in lbs_cfg_scan() is spurious as
priv->scan_req can't be NULL w/ scan_work pending; otherwise,
lbs_scan_worker() will segfault. Drop it. BTW, the synchronization
around scan_work seems racy. There's nothing synchronizing accesses
to scan related fields in lb
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 x86/mce. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Tony Luck
Cc: Borislav Pet
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 rfkill. Only compile
tested.
Signed-off-by: Tejun Heo
Cc: "John W. Linville"
Cc: linu
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 pm autosleep and qos. Only
compile tested.
Signed-off-by: Tejun Heo
Cc: "Rafael J. Wys
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 thinkpad_acpi. Only compile
tested.
Signed-off-by: Tejun Heo
Cc: Henrique de Moraes Ho
wait_for_kprobe_optimizer() seems largely broken. It uses
optimizer_comp which is never re-initialized, so
wait_for_kprobe_optimizer() will never wait for anything once
kprobe_optimizer() finishes all pending jobs for the first time.
Also, aside from completion, delayed_work_pending() is %false o
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 wl1251. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Luciano Coelho
Cc: linux-wi
The longest night of the year is upon us (*), and what better thing to
do than get yourself some nice mulled wine, sit back, relax, and play
with the most recent rc kernel?
This has been a big merge window: we've got more commits than any
other kernel in the v3.x kernel series (although v3.2-rc1 w
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 wm97xx. Instead of testing
work_pending(), use the return value of queue_work() to decid
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 power domains. Only compile
tested.
Signed-off-by: Tejun Heo
Cc: Rafael J. Wysocki
Cc
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 caif. Only compile tested.
Signed-off-by: Tejun Heo
---
Please let me know how this pa
i2400m_net_wake_tx() sets ->wake_tx_skb with the given skb if
->wake_tx_ws is not pending; however, i2400m_wake_tx_work() could have
just started execution and haven't fetched ->wake_tx_skb handling.
* i2400m_net_wake_tx() now tests whether the previous ->wake_tx_skb
has been consumed by ->wake_
On Fri, Dec 21, 2012 at 5:09 PM, Andy Lutomirski wrote:
> On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse wrote:
>> On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski wrote:
>>> Something's buggy here. My evil test case is stuck with lots of
>>> threads spinning at 100% system time.
>>>
>>> Th
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.
Reimplement l2cap_set_timer() such that it uses mod_delayed_work() or
schedule_delayed_work() depending on a new param @overrid
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 exynos_dp_core. Only compile
tested.
Signed-off-by: Tejun Heo
Cc: Kukjin Kim
---
Plea
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 debugobjects. While at it,
change @sched to bool and move kevent_up() test to later for
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 ipc. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Andrew Morton
---
Please let m
The vmlinux doesn't always live in the same directory as the
source files and so 'make O=obj checkstack' fails with a missing
vmlinux file. Fix checkstack so that this is possible.
Signed-off-by: Stephen Boyd
---
It would also be nice if this depended on vmlinux and modules being built
already b
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 Victor
Cc: Nicolas
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 max3100. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Greg Kroah-Hartman
Cc: Jir
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 tmio mmc. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Guennadi Liakhovetski
Cc:
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 wm8350. Only compile tested.
Signed-off-by: Tejun Heo
Cc: Mark Brown
Cc: patc...@open
* Drop unnesssary delayd_work_pending() tests.
* Unify scan_event_{now|later} by using mod_delayed_work() w/ 0 delay
for scan_event_now.
* Make ipw2200 scan_event handling match ipw2100 - use
mod_delayed_work() w/ 0 delay for immediate scanning.
Only compile tested.
Signed-off-by: Tejun Heo
Drop work_pending() test from mwifiex_sdio_card_reset(). As
work_pending() becomes %false before sdio_card_reset_worker() starts
executing, it doesn't really protect anything. reset_host may change
between mmc_remove_host() and mmc_add_host(). Make
sdio_card_reset_worker() cache the target mmc_h
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 ab8500_charger. Only compile
tested.
Signed-off-by: Tejun Heo
Cc: Srinidhi Kasagar
Cc
Hello,
Given the current set of workqueue APIs, there are very few cases
where [delayed_]work_pending() are actually necessary; however, it's
seemingly somewhat popular for a few purposes including skipping
queue/flush/cancel depending on the current state for optimization.
work_pending() could b
On Fri, 21 Dec 2012, Andi Kleen wrote:
> > I hate to sound like a broken record here, but, again, what's the
> > rationalization for not using libpfm4 here?
>
> Personally I always hated the libpfm4 syntax. It's even worse than
> oprofile.
how so? The libpfm4 event names are more or less the s
1 - 100 of 429 matches
Mail list logo
