The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Joern Engel
CC: Prasad Joshi
Cc: Al Viro
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Jes Sorensen
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Signed-off-by:
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ralf Baechle
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Russell King
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Kalle Valo
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
On Wed, Jan 16, 2013 at 03:00:00AM +0100, Jan Kara wrote:
> On Mon 14-01-13 21:43:05, Darrick J. Wong wrote:
> > This provides a band-aid to provide stable page writes on jbd without
> > needing
> > to backport the fixed locking and page writeback bit handling schemes of
> > jbd2.
> > The
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: David Woodhouse
Cc: Al Viro
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ohad Ben-Cohen
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Dave Airlie
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Rob Landley
CC: Randy Dunlap
Cc: Greg Kroah-Hartman
Signed-off-by: Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: FUJITA Tomonori
Cc: Alex Dubov
Cc: Greg Kroah-Hartman
Signed-off-by: Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: FUJITA Tomonori
Cc: Alex Dubov
Cc: Greg Kroah-Hartman
Signed-off-by: Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Evgeniy Dushistov
Cc: Al Viro
Cc: Greg Kroah-Hartman
Signed-off-by: Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Andrew Morton
CC: KAMEZAWA Hiroyuki
CC: Jan Beulich
CC: Mel Gorman
CC:
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Stanislav Yakovlev
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Stefano Brivio
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Kumar Gala
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Christian Lamparter
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Christian Lamparter
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Samuel Ortiz
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Signed-off-by:
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Grant Likely
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ben Dooks
CC: Kukjin Kim
CC: Russell King
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: Larry Finger
Cc: Chaoming Li
Cc: "John W. Linville"
Cc: "David S. Miller"
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Arnd Bergmann
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: Luciano Coelho
Cc: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ivo van Doorn
CC: Gertjan van Wingerde
CC: Helmut Schaa
CC: "John W.
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Adam Belay
CC: Bjorn Helgaas
Cc: Greg Kroah-Hartman
Signed-off-by: Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Russell King
CC: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Avi Kivity
CC: Marcelo Tosatti
CC: Chris Metcalf
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: Neil Brown
Cc: "J. Bruce Fields"
Cc: Al Viro
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Florian Tobias Schandinat
CC: Mathieu Poirier
CC: Jiri Kosina
CC: Paul
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Len Brown
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ralf Baechle
CC: Jiri Kosina
CC: Paul Bolle
Cc: Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Karsten Keil
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Matthew Garrett
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Andrew Morton
CC: "Paul E. McKenney"
CC: Dmitry Kasatkin
CC: James Morris
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Alexander Graf
CC: Avi Kivity
CC: Marcelo Tosatti
CC: Benjamin
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Paul Mundt
CC: Tejun Heo
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Steve French
CC: Al Viro
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Joerg Roedel
CC: Hiroshi DOYU
CC: Jiri Kosina
CC: Kukjin Kim
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ulrich Kunitz
CC: "John W. Linville"
Cc: "David S. Miller"
Cc: Greg
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
Cc: Greg Kroah-Hartman
Here's what's left of the "remove experimental" tree. (We're down from
193 patches! Thanks everyone!)
This set of patches have either gone without Acks in the prior two
sendings, or introduce a new removal of EXPERIMENTAL where it was
recently added.
https://lkml.org/lkml/2012/10/23/580
-Kees
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Signed-off-by: Kees Cook
---
On Tue, Jan 15, 2013 at 04:33:59PM -0800, Andrew Morton wrote:
> On Tue, 15 Jan 2013 16:22:46 -0800
> "Darrick J. Wong" wrote:
>
> > > > This patchset has been tested on 3.8.0-rc3 on x64 with ext3, ext4, and
> > > > xfs.
> > > > What does everyone think about queueing this for 3.9?
> > >
> > >
On Wed, Jan 16, 2013 at 10:35:12AM +0100, Takashi Iwai wrote:
> At Wed, 16 Jan 2013 10:21:46 +0100,
> Sedat Dilek wrote:
> >
> > On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai wrote:
> > > At Sat, 5 Jan 2013 13:13:27 +0100,
> > > Sedat Dilek wrote:
> > >>
> > >> Hi Jiri,
> > >>
> > >> ...known
Josh Boyer writes:
>> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
>> index 86e2f4a..7acca64 100644
>> --- a/drivers/iommu/dmar.c
>> +++ b/drivers/iommu/dmar.c
>> @@ -230,7 +230,7 @@ dmar_parse_one_rhsa(struct acpi_dmar_header *header)
>> }
>> }
>> WARN_TAINT(
"Michael S. Tsirkin" writes:
> On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> >> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
>> >> +{
>> >> + struct iovec *new;
>> >> + unsigned int new_num = iov->max * 2;
>> >
>> > We must limit
srcip_matches() previously had code like this:
srcip_matches(..., struct sockaddr *rhs) {
/* ... */
struct sockaddr_in6 *vaddr6 = (struct sockaddr_in6 *)
return ipv6_addr_equal(..., >sin6_addr);
}
which interpreted the values on the stack after the 'rhs' pointer as an
ipv6
In ntfs_mft_data_extend_allocation_nolock(), if an error condition occurs
prior to 'ctx' being set to a non-NULL value, avoid dereferencing the NULL
'ctx' pointer by jumping to later cleanup code.
Signed-off-by: Nickolai Zeldovich
---
fs/ntfs/mft.c |8
1 file changed, 4
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/zram/zram_drv.c between commit 397c60668aa5 ("staging:
zram: fix invalid memory references during disk write") from Linus' tree
and commit d178a07c4bd3 ("staging: zram: drop zram_stat_dec/inc
functions") from
On Wed, Jan 16, 2013 at 10:20 AM, Yinghai Lu wrote:
> On Wed, Jan 16, 2013 at 9:38 AM, H. Peter Anvin wrote:
>> On 01/16/2013 09:31 AM, Yinghai Lu wrote:
>>>
>>>
>>
>> The first sentence here doesn't parse, and this description doesn't give any
>> hint to anyone who is researching this code in
> > to know which commit to revert:-(. Lots of lost productivity:-(
> >
> > Simon, the offending commit:
> >
> > 6d3ef6b drivers/pinctrl: grab default handles from device core
> >
> > is still in next-20130116. Can you please remove it?
>
>
Alan Stern wrote:
On Tue, 15 Jan 2013, Woody Suwalski wrote:
Another important change is that the EHCI driver is now split into two
modules. That can slow down loading and affect the timing.
Alan Stern
My testcase is a live initramfs + squash root.
The boot logic is as stable as can be -
On 01/16/2013 01:57 PM, David Miller wrote:
> From: Mike Frysinger
> Date: Wed, 16 Jan 2013 12:04:56 -0500
>
>> certainly true, but the current expectation is that you don't mix your ABIs.
>>
>> if you're programming with the C library API, then use the C library
>> headers.
>> if you're
Lockdep complains about recursive deadlock of zram->init_lock.
[1] made it false positive because we can't request IO to zram
before setting disksize. Anyway, we should shut lockdep up to
avoid many reporting from user.
This patch allocates zram's metadata out of lock so we can fix it.
In
1) User of zram normally do mkfs.xxx or mkswap before using
the zram block device(ex, normally, do it at booting time)
It ends up allocating such metadata of zram before real usage so
benefit of lazy initialzation would be mitigated.
2) Some user want to use zram when memory pressure is
Now zram document syas "set disksize is optional"
but partly it's wrong. When you try to use zram firstly after
booting, you must set disksize, otherwise zram can't work because
zram gendisk's size is 0. But once you do it, you can use zram freely
after reset because reset doesn't reset to zero
> The vout address for buck[1|2] can be easily calculated,
> thus remote these arrays.
>
> Signed-off-by: Axel Lin
Acked-by: Milo Kim
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in
drivers/tty/serial/8250/8250_dw.c between commit 68e56cb3a068 ("tty:
8250_dw: Fix inverted arguments to serial_out in IRQ handler") from the
tty.current tree and commit 30046df26187 ("serial: 8250_dw: Set FIFO size
dynamically")
From: Carlos O'Donell
Date: Wed, 16 Jan 2013 20:58:47 -0500
> So I just went down the rabbit hole, and the further I get the
> closer I get to having two exact copies of the same definitions
> in both glibc and the kernel and using whichever one was included
> first.
>
> Is anyone opposed to
On Wed, Jan 16, 2013 at 11:49 PM, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/rtc/rtc-hid-sensor-time.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-hid-sensor-time.c
> b/drivers/rtc/rtc-hid-sensor-time.c
> index 0438c9e..31c5728 100644
> ---
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in
drivers/staging/sb105x/Kconfig between commit db210312f77b ("staging:
Make SystemBase PCI Multiport UART only for x86") from the tree and
commit e27a7d7977b0 ("Staging: sb105x: mark it BROKEN") from the tty tree.
I fixed it up
On 01/16/2013 04:45 PM, David Miller wrote:
> From: Ben Hutchings
> Date: Wed, 16 Jan 2013 15:47:12 +
>
>> On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
>>> Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h
The vout address for buck[1|2] can be easily calculated,
thus remote these arrays.
Signed-off-by: Axel Lin
---
drivers/regulator/lp8788-buck.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp8788-buck.c
On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and
Signed-off-by: Axel Lin
---
drivers/rtc/rtc-hid-sensor-time.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
index 0438c9e..31c5728 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++
Forgot to cc Jens and Jeff.
Jens, Jeff, the patchset itself probably won't interest you guys too
much but it's part of effort towards worker pool w/ custom attributes.
I'm working toward a design where the custom pools are integral part
of workqueue which share all the interface and semantics,
On 01/02/2013 08:27 PM, Minchan Kim wrote:
This patch adds new system call m[no]volatile.
If someone asks is_volatile system call, it could be added, too.
So some nits below from my initial playing around with this patchset.
+/*
+ * Return -EINVAL if range doesn't include a right vma at all.
There are currently two worker pools per cpu (including the unbound
cpu) and they are the only pools in use. New class of pools are
scheduled to be added and some pool related APIs will be added
inbetween. Call the existing pools the standard pools and prefix them
with std_. Do this early so
Make GCWQ_DISASSOCIATED a pool flag POOL_DISASSOCIATED. This patch
doesn't change locking - DISASSOCIATED on both pools of a CPU are set
or clear together while holding gcwq->lock. It shouldn't cause any
functional difference.
This is part of an effort to remove global_cwq and make worker_pool
Add worker_pool->id which is allocated from worker_pool_idr. This
will be used to record the last associated worker_pool in work->data.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/kernel/workqueue.c
Make GCWQ_FREEZING a pool flag POOL_FREEZING. This patch doesn't
change locking - FREEZING on both pools of a CPU are set or clear
together while holding gcwq->lock. It shouldn't cause any functional
difference.
This leaves gcwq->flags w/o any flags. Removed.
While at it, convert BUG_ON()s in
Hello,
Currently, on the backend side, there are two layers of abstraction.
For each CPU and the special unbound wq-specific CPU, there's one
global_cwq. gcwq in turn hosts two worker_pools - one for normal
priority, the other for highpri - each of which actually serves the
work items.
This function no longer has any external users. Unexport it. It will
be removed later on.
Signed-off-by: Tejun Heo
---
include/linux/workqueue.h | 1 -
kernel/workqueue.c| 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/workqueue.h
Move gcwq->cpu to pool->cpu. This introduces a couple places where
gcwq->pools[0].cpu is used. These will soon go away as gcwq is
further reduced.
This is part of an effort to remove global_cwq and make worker_pool
the top level abstraction, which in turn will help implementing worker
pools
Currently, when a work item is off-queue, work->data records the CPU
it was last on, which is used to locate the last executing instance
for non-reentrance, flushing, etc.
We're in the process of removing global_cwq and making worker_pool the
top level abstraction. This patch makes work->data
Currently, when a work item is off queue, high bits of its data
encodes the last CPU it was on. This is scheduled to be changed to
pool ID, which will make it impossible to use WORK_CPU_NONE to
indicate no association.
This patch limits the number of bits which are used for off-queue cpu
number
Instead of holding locks from both pools and then processing the pools
together, make freezing/thwaing per-pool - grab locks of one pool,
process it, release it and then proceed to the next pool.
While this patch changes processing order across pools, order within
each pool remains the same. As
The only remaining user of pool->gcwq is std_worker_pool_pri().
Reimplement it using get_gcwq() and remove worker_pool->gcwq.
This is part of an effort to remove global_cwq and make worker_pool
the top level abstraction, which in turn will help implementing worker
pools with user-specified
Remove remaining references to gcwq.
* __next_gcwq_cpu() steals __next_wq_cpu() name. The original
__next_wq_cpu() became __next_cwq_cpu().
* s/for_each_gcwq_cpu/for_each_wq_cpu/
s/for_each_online_gcwq_cpu/for_each_online_wq_cpu/
* s/gcwq_mayday_timeout/pool_mayday_timeout/
*
Rename per-cpu and unbound nr_running variables such that they match
the pool variables.
This patch doesn't introduce any functional changes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/workqueue.c
global_cwq is now nothing but a container for per-pcu standard
worker_pools. Declare the worker pools directly as
cpu/unbound_std_worker_pools[] and remove global_cwq.
* get_gcwq() is replaced with std_worker_pools() which returns the
pointer to the standard pool array for a given CPU.
*
for_each_std_worker_pool() takes @cpu instead of @gcwq.
This is part of an effort to remove global_cwq and make worker_pool
the top level abstraction, which in turn will help implementing worker
pools with user-specified attributes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 39
Instead of holding locks from both pools and then processing the pools
together, make hotplug processing per-pool - grab locks of one pool,
process it, release it and then proceed to the next pool.
rebind_workers() is updated to take and process @pool instead of @gcwq
which results in a lot of
Move gcwq->lock to pool->lock. The conversion is mostly
straight-forward. Things worth noting are
* In many places, this removes the need to use gcwq completely. pool
is used directly instead. get_std_worker_pool() is added to help
some of these conversions. This also leaves
There's no functional necessity for the two pools on the same CPU to
share the busy hash table. It's also likely to be a bottleneck when
implementing pools with user-specified attributes.
This patch makes busy_hash per-pool. The conversion is mostly
straight-forward. Changes worth noting are,
Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
the event
This is not a technical point of view. This is a more or less political
and user point of view. And for any replies, I'm not subscribed (haven't
been now for years).
As a user, I was in need for an iSCSI target. Actually, I needed to
export a SAS tape device (Ultrium 5) - which is one of the
On Thu, Jan 17, 2013 at 7:37 AM, Andrew Morton
wrote:
> On Sat, 5 Jan 2013 10:25:38 +0800
> Ming Lei wrote:
>
>> This patchset try to solve one deadlock problem which might be caused
>> by memory allocation with block I/O during runtime PM and block device
>> error handling path. Traditionly,
On 01/15/13 06:50, werner wrote:
> We are now on -rc3 and someone should correct this, finally
>
> This is a regression, it was not before, on 3.6
>
> This messes up any compilation of the whole kernel, it results in don't be
> produced vmlinuz
>
> arch/x86/kernel/cpu/perf_event_p6.o depends
On 01/17/2013 01:03 AM, Michael S. Tsirkin wrote:
> On Wed, Jan 16, 2013 at 11:44:38PM +0800, Jason Wang wrote:
>> We forbid polling, writing and reading when the file were detached, this may
>> complex the user in several cases:
>>
>> - when guest pass some buffers to vhost/qemu and then disable
Use general name, 'list' rather than 'next_trig'.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/led-triggers.c | 12 ++--
include/linux/leds.h|3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/led-triggers.c
There are two list_heads for handling LED trigger function.
'trig_list' of led_classdev and 'led_cdevs' of led_trigger.
Those are added/removed with led_trigger_set().
To find exact LED device, those are scanned in led_trigger_event() and
led_trigger_blink_setup().
But without additional
Fixed a leading whitespace coding style issue.
Signed-off-by: Jake Champlin
---
drivers/staging/comedi/drivers/ni_tio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/ni_tio.c
b/drivers/staging/comedi/drivers/ni_tio.c
index 98f8789..73e7cbe
101 - 200 of 1847 matches
Mail list logo
