> In order to make sure the patch without involving unexpected issues beyond
> I can understand, I will confirm with our expert about it.
>
> so please pend the patch going to mainline. If the patch can move on, I
> think I will also provide other patch changing, like direct EOI.
Hi Yinghai and I
On Tue, 13 Aug 2013 19:32:37 -0400 Chris Metcalf wrote:
> On 8/13/2013 7:29 PM, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Aug 13, 2013 at 06:53:32PM -0400, Chris Metcalf wrote:
> >> int lru_add_drain_all(void)
> >> {
> >> - return schedule_on_each_cpu(lru_add_drain_per_cpu);
> >> + return s
Encountered this while building custom embedded distribution with the yocto
project build system.
This has never happened before for me, but google search showed quite a few
similar reports.
Aug 13 15:42:12 quadpc kernel: [263676.682558] [ cut here
]
Aug 13 15:42:12 qua
Am 13.08.2013 21:15, schrieb Benjamin Tissoires:
On Tue, Aug 13, 2013 at 8:37 PM, Alexander Holler wrote:
Another problem is that I don't have any commercial sensor hub and I'm
therefor not a very relvant as tester (I've implemented the firmware for my
HID (sensor hub) device too). Therefor
On 2013/8/14 13:06, Andy Lutomirski wrote:
> On Tue, Aug 13, 2013 at 10:04 PM, Rui Xiang wrote:
>> The level of init_user_ns shoule be 1.
>
> What's wrong with zero?
>
No problem. It is just consistent with commit 8742f229b63, IMHO.
but the initialization of level should be necessary.
Thanks.
On Wed, Aug 14, 2013 at 01:59:02PM +0800, Zhi Yong Wu wrote:
> On Wed, Aug 14, 2013 at 1:35 PM, Dave Chinner wrote:
> > On Wed, Jul 31, 2013 at 04:42:45PM +0800, zwu.ker...@gmail.com wrote:
> >> From: Zhi Yong Wu
> >>
> >> It can take a long time to run log recovery operation because it is
> >>
On 8/14/13 12:46 AM, Linn Crosetto wrote:
Type SETUP_PCI, added by setup_efi_pci(), may advertise a ROM size
larger than early_memremap() is able to handle, which is currently
limited to 256kB. If this occurs it leads to a NULL dereference in
parse_setup_data().
To avoid this, remap the setup_da
On 8/14/13 6:44 AM, Tang Chen wrote:
In setup_arch() of x86, it set memblock.current_limit directly.
We should use memblock_set_current_limit(). If the implementation
is changed, it is easy to maintain.
Signed-off-by: Tang Chen
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in
drivers/pci/host/pci-mvebu.c between commit f48fbf9c7e89 ("PCI: mvebu:
Convert to use devm_ioremap_resource") from the pci tree and commit
826727641b2a ("PCI: mvebu: move clock enable before register access")
from the mvebu tree.
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in
drivers/pci/host/Kconfig between commit 5477a33b51b7 ("PCI: mvebu: Make
Marvell PCIe driver depend on OF") from the pci tree and commit
31d896ade95d ("PCI: mvebu: add support for Marvell Dove SoCs") from the
mvebu tree.
I fixed
From: Sonic Zhang
Update Blackfin arch branch maintainer's email as well.
Signed-off-by: Sonic Zhang
---
MAINTAINERS | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..9578c2c 100644
--- a/MA
On 8/13/2013 4:23 AM, Greg KH wrote:
On Mon, Aug 12, 2013 at 12:43:50PM +0530, akhil.go...@freescale.com wrote:
From: Akhil Goyal
The radio device framework introduces a way to accommodate the
RF(radio frequency) signal paths. One signal path is represented
as a RF device (rf0, rf1 etc), and i
On Wed, Aug 14, 2013 at 1:35 PM, Dave Chinner wrote:
> On Wed, Jul 31, 2013 at 04:42:45PM +0800, zwu.ker...@gmail.com wrote:
>> From: Zhi Yong Wu
>>
>> It can take a long time to run log recovery operation because it is
>> single threaded and is bound by read latency. We can find that it took
>
Now zsmalloc needs exported unmap_kernel_range for building it
as module. In detail, here it is.
https://lkml.org/lkml/2013/1/18/487
We didn't send patch to make unmap_kernel_range exportable at that time.
Because zram is staging stuff and we didn't think make VM function
exportable for staging st
zram from driver/staging to driver/blocks, finally.
It touches mm, staging, blocks so I am not sure who is right position
maintainer so I will Cc Andrw, Jens and Greg.
This patch is based on next-20130813.
Thanks.
Minchan Kim (4):
zsmalloc: add Kconfig for enabling page table method
zsmallo
From: Nitin Cupta
This patch adds lots of comments and it will help others
to review and enhance.
Signed-off-by: Seth Jennings
Signed-off-by: Nitin Gupta
Signed-off-by: Minchan Kim
---
drivers/staging/zsmalloc/zsmalloc-main.c | 66 +-
drivers/staging/zsmalloc/zs
Zsmalloc has two methods 1) copy-based and 2) pte based to
access objects that span two pages.
You can see history why we supported two approach from [1].
But it was bad choice that adding hard coding to select arch
which want to use pte based method because there are lots of
SoC in an architecure
On Tue, Aug 13, 2013 at 9:28 PM, Jonathan Cameron wrote:
> On 08/13/13 16:44, Oleksandr Kravchenko wrote:
>> This patch adds IIO driver for Bosch BMA180 triaxial
>> acceleration sensor.
>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
>> Sensors/Accelerometers/BST-BMA180-DS000-07_2
Now zsmalloc needs exported unmap_kernel_range for building it
as module. In detail, here it is.
https://lkml.org/lkml/2013/1/18/487
We didn't send patch to make unmap_kernel_range exportable at that time.
Because zram is staging stuff and we didn't think make VM function
exportable for staging st
From: Nitin Cupta
This patch adds lots of comments and it will help others
to review and enhance.
Signed-off-by: Seth Jennings
Signed-off-by: Nitin Gupta
Signed-off-by: Minchan Kim
---
drivers/staging/zsmalloc/zsmalloc-main.c | 66 +-
drivers/staging/zsmalloc/zs
zram from driver/staging to driver/blocks, finally.
It touches mm, staging, blocks so I am not sure who is right position
maintainer so I will Cc Andrw, Jens and Greg.
This patch is based on next-20130813.
Thanks.
Minchan Kim (4):
zsmalloc: add Kconfig for enabling page table method
zsmallo
Zsmalloc has two methods 1) copy-based and 2) pte based to
access objects that span two pages.
You can see history why we supported two approach from [1].
But it was bad choice that adding hard coding to select arch
which want to use pte based method because there are lots of
SoC in an architecure
On Tue, Aug 13, 2013 at 08:13:56PM +, Luck, Tony wrote:
> Generic tracepoints are architected to be able to fire at very high
> rates and log huge amounts of information. So we'd need something
> special to say just log these special tracepoints to network/serial.
>
> > Which reminds me, pstore
On Wed, Jul 31, 2013 at 04:42:45PM +0800, zwu.ker...@gmail.com wrote:
> From: Zhi Yong Wu
>
> It can take a long time to run log recovery operation because it is
> single threaded and is bound by read latency. We can find that it took
> most of the time to wait for the read IO to occur, so if o
Hi,
On Wednesday 14 August 2013 12:43 AM, Stephen Warren wrote:
> On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote:
>> The Palmas device contains only a USB VID detector, so added a
>> compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
>
> s/Dint/Didn't/
>
>> diff --git
On 13 August 2013 12:39, Xiaoguang Chen wrote:
> cpufreq_add_policy_cpu, __cpufreq_remove_dev and __cpufreq_set_policy
> have operations for governor stop and start.
> Only do the start operation when the previous stop operation succeeds.
>
> Signed-off-by: Xiaoguang Chen
> ---
> drivers/cpufreq
From: Sonic Zhang
One peripheral may share part of its pins with the 2nd
peripheral and the other pins with the 3rd. If it requests all pins
when part of them has already be requested and owned by the 2nd
peripheral, this request fails and pinmux_disable_setting() is called.
The pinmux_disable_se
On 13 August 2013 12:39, Xiaoguang Chen wrote:
> __cpufreq_governor operation needs to be executed one by one.
> If one operation is ongoing, the other operation can't be executed.
> If the order is not guaranteed, there may be unexpected behavior.
What order??
> For example, governor is in ena
On Tue, Aug 13, 2013 at 10:04 PM, Rui Xiang wrote:
> The level of init_user_ns shoule be 1.
What's wrong with zero?
--Andy
>
> Signed-off-by: Rui Xiang
> ---
> kernel/user.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/user.c b/kernel/user.c
> index 69b4c3d..32da187 100644
The level of init_user_ns shoule be 1.
Signed-off-by: Rui Xiang
---
kernel/user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/user.c b/kernel/user.c
index 69b4c3d..32da187 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -48,6 +48,7 @@ struct user_namespace init_user_ns = {
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
are available in the git repository at:
git://git.linaro.org/people/mturquette/linux.git tags/clk-fixes-for-linus
for you to fetch changes up to a701fe3851d9c7f6bd27bc0b92
A large free page buddy block will continue many times, so if the page
is free, skip the whole page buddy block instead of one page.
Signed-off-by: Xishi Qiu
---
mm/compaction.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index
Hi Prabhakar,
On 8/11/2013 3:04 PM, Prabhakar Lad wrote:
> Hi Sekhar,
>
> On Fri, Jun 14, 2013 at 3:50 PM, Philip, Avinash wrote:
>> On Fri, Jun 14, 2013 at 15:13:36, Philip, Avinash wrote:
>>> With conversion of GPIO davinci driver to platform driver, gpio-davinci
>>> driver
>>> can support DT
Commit-ID: 2449f343e4adc778de1c3d45b5aa14fe788663f5
Gitweb: http://git.kernel.org/tip/2449f343e4adc778de1c3d45b5aa14fe788663f5
Author: Tang Chen
AuthorDate: Wed, 14 Aug 2013 11:44:04 +0800
Committer: H. Peter Anvin
CommitDate: Tue, 13 Aug 2013 21:27:02 -0700
x86: Use memblock_set_curre
Shared LRCLK initialization does not survive wm8960_reset,
so place it after the reset.
Signed-off-by: Ma Haijun
---
sound/soc/codecs/wm8960.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 368d39f..
Signed-off-by: Ma Haijun
---
sound/soc/codecs/wm8960.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 0a4ffdd..368d39f 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -263,8 +263,8 @@ SO
Commit b55ae0a9 added code-reading.c which fails to compile on Fedora 16
with compiler version:
$ gcc --version
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
Failure message is:
tests/code-reading.c: In function ‘do_sort_something’:
tests/code-reading.c:305:13: error: stack protector not protecting
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/video/simplefb.c between commit dbb5ff4c2300 ("simplefb: add
support for a8b8g8r8 pixel format") from the omap_dss2 tree and commit
5ef76da644bf ("fbdev: simplefb: add init through platform_data") from the
tip tree.
I fixe
In setup_arch() of x86, it set memblock.current_limit directly.
We should use memblock_set_current_limit(). If the implementation
is changed, it is easy to maintain.
Signed-off-by: Tang Chen
---
arch/x86/kernel/setup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/a
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &pdev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &of_dev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-o
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &pdev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-of
unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Libo Chen
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &pdev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &of->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-b
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &of->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-b
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &ofdev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-of
Hi Dimitry,
On Tue, Aug 13, 2013 at 09:46:09AM -0700, Dmitry Torokhov wrote:
> Hi Michael,
>
> On Tue, Aug 13, 2013 at 02:14:30PM +0200, Michael Grzeschik wrote:
> > In case of devicetree, we currently don't have a way to append pdata for
> > the touchscreen. The current approach is to bail out i
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with &pdev->dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
changelog:
On Fri, Aug 09, 2013 at 06:20:59PM +0200, Frederic Weisbecker wrote:
> On Fri, Jul 26, 2013 at 04:19:23PM -0700, Paul E. McKenney wrote:
> > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > index 3edae39..ff84bed 100644
> > --- a/kernel/rcutree_plugin.h
> > +++ b/kernel/rcutree_pl
Michal Marek writes:
> Added Rusty to CC.
>
> Dne 9.8.2013 21:45, Andi Kleen napsal(a):
>> From: Andi Kleen
>>
>> For some reason I managed to trick gcc into create CRC symbols that
>> are not absolute anymore, but weak.
>>
>> Make modpost handle this case.
>>
>> Andrew, this should fix the bi
David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, August 14, 2013 7:41 AM
> To: oneu...@suse.de
> Cc: Hayeswang; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH net-next 1/3] net/usb/r8152: support aggregation
>
[...]
> > I don'
On 14 August 2013 01:31, Rafael J. Wysocki wrote:
> On Tuesday, August 13, 2013 07:01:04 PM Viresh Kumar wrote:
> Are the three patches in this series prerequisite for the big target_index
> one? If so, I think they can go into 3.12 actually, if they are ACKed by the
> appropriate platform maint
On Tue, Aug 13, 2013 at 3:54 PM, Skidmore, Donald C
wrote:
> We were unable to recreate your failure here locally so I have some
> additional questions. First off you mentioned it was failing as far back as
> v3.9, was it ever working for you? If so bisecting would be really helpful
> as I m
When cpuidle_idle_call() return 0, it shows that linux system is using
idle framwork driver. Now, local irq has already been enabled in
cpuidle_idle_call(). So, it need not enable local irq again, when return 0.
The code is introduced by commit:
97a5b81fa4d3a11dcdf224befc577f2e0abadc0b ("x86: Fix
From: Asbjørn Sloth Tønnesen
Date: Mon, 12 Aug 2013 16:24:06 +
> Let's start with a little history:
I've applied your kernel patch, but the detailed analysis you put
here, belongs in the commit message.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Tue, Aug 13, 2013 at 6:44 PM, Roy Franz wrote:
>
> Thanks Dave - comments inline, and I have an updated head.S diff at the end.
>
> Roy
>
>
> On Tue, Aug 13, 2013 at 7:19 AM, Dave Martin wrote:
>>
>> On Fri, Aug 09, 2013 at 04:26:16PM -0700, Roy Franz wrote:
>> > This patch adds EFI stub suppo
On 2013/8/13 23:05, Tejun Heo wrote:
> On Tue, Aug 13, 2013 at 09:17:53AM +0800, Li Zefan wrote:
>> Now cgroup core gets a reference to the css when a cgroup file is
>> opened(), and the reference is dropped at file release. so it's
>> guaranteed the cpuset is online during the write function.
>
>
On 08/13/2013 04:32 PM, H. Peter Anvin wrote:
On 08/01/2013 08:50 PM, David Gibson wrote:
On Wed, Jul 31, 2013 at 05:26:47PM -0400, jonsm...@gmail.com
wrote:
On Wed, Jul 31, 2013 at 4:48 PM, Russell King - ARM Linux
wrote:
On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsm...@gmail.com
wrote:
Hi Bob, Rafael,
I think these patches are unnecessary now. mm guys have decided to do
memory hotplug in another way, an easier way that we don't need to touch
ACPICA code.
So please ignore this patch-set.
Thanks for the help and suggestions. :)
On 08/08/2013 11:39 AM, Tang Chen wrote:
[Probl
Fix to read the wrong register when checking whether the RTC timer has
reached or not.
Signed-off-by: Sangjung Woo
Signed-off-by: Myugnjoo Ham
Reviewed-by: Jonghwa Lee
---
drivers/rtc/rtc-max77686.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-max7
Hi Russell,
Today's linux-next merge of the arm-current tree got a conflict in
arch/arm/kernel/perf_event.c between commit b88a2595b6d8 ("perf/arm: Fix
armpmu_map_hw_event()") from Linus' tree and commit d9f966357b14 ("ARM:
7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()")
fr
On Tue, Aug 13, 2013 at 9:17 PM, Steven Rostedt wrote:
> On Tue, 13 Aug 2013 20:34:58 -0300
> Lucas De Marchi wrote:
>
>
>> so in kcmdline we would have modulename.param instead of modulename.param=1?
>>
>> I guess we need to update kmod then, because currently we ignore and
>> treat this case as
On Tue, Aug 13, 2013 at 10:00 PM, Lucas De Marchi
wrote:
> On Tue, Aug 13, 2013 at 9:17 PM, Steven Rostedt wrote:
>> On Tue, 13 Aug 2013 20:34:58 -0300
>> Lucas De Marchi wrote:
>>
>>
>>> so in kcmdline we would have modulename.param instead of modulename.param=1?
>>>
>>> I guess we need to upda
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
> This is to reserve a capablity number for upcoming support
> of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
> which support mulptiple DMA map/unmap operations per one call.
Gleb, any chance you can put this (and the next on
>From ae7f164a09408bf21ab3c82a9e80a3ff37aa9e3e Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Aug 2013 20:22:50 -0400
Currently, css (cgroup_subsys_state) lifetime is tied to that of the
associated cgroup. With the planned unified hierarchy, css's will be
dynamically created and destroye
On Tue, Aug 13, 2013 at 5:07 PM, Andi Kleen wrote:
>
> 32bit already did this correctly by duplicating the code.
I wonder how much of this could be in asm/uaccess.h? We already do all
the fixed-size get_user/put_user stuff in that generic x86 code, and
I'm wondering why we don't do the "__builtin
On Tue, 13 Aug 2013 20:34:58 -0300
Lucas De Marchi wrote:
> so in kcmdline we would have modulename.param instead of modulename.param=1?
>
> I guess we need to update kmod then, because currently we ignore and
> treat this case as a wrong token. From a quick look, allowing it in
> kmod would b
Hello Christoph,
On Tue, Aug 13, 2013 at 04:21:30PM +, Christoph Lameter wrote:
> On Tue, 13 Aug 2013, Minchan Kim wrote:
>
> > VM sometime want to migrate and/or reclaim pages for CMA, memory-hotplug,
> > THP and so on but at the moment, it could handle only userspace pages
> > so if above e
On Tue, Aug 13, 2013 at 11:20:05PM +0100, Ian Campbell wrote:
> On Tue, 2013-08-13 at 21:59 +0100, Ian Campbell wrote:
>
> > > What it should be is:
> > > > >
> > > > > void xen_raw_console_write(const char *str)
> > > > > {
> > > > > - dom0_write_console(0, str, strlen(str));
> > > > > +
The x86 user access functions (*_user) were originally very well tuned,
with partial inline code and other optimizations.
Then over time various new checks -- particularly the sleep checks for
a voluntary preempt kernel -- destroyed a lot of the tunings
A typical user access operation is now doin
From: Andi Kleen
These are really related to scheduling, so they should be in sched.h
Users usually will need to schedule anyways.
The advantage of having them there is that we can access some of the
scheduler inlines to make their fast path more efficient. This will come
in a followon patch.
S
From: Andi Kleen
might_sleep is moving from linux/kernel.h to linux/sched.h, so any users
need to include linux/sched.h
This was done with a mechanistic script and some uses may be redundant
(already included in some other include file). However it's good practice
to always include any needed sy
Hello Benjamin,
On Tue, Aug 13, 2013 at 10:23:38AM -0400, Benjamin LaHaise wrote:
> On Tue, Aug 13, 2013 at 11:46:42AM +0200, Krzysztof Kozlowski wrote:
> > Hi Minchan,
> >
> > On wto, 2013-08-13 at 16:04 +0900, Minchan Kim wrote:
> > > patch 2 introduce pinpage control
> > > subsystem. So, subsy
From: Andi Kleen
_cond_resched is very common in kernel calls, e.g. it's used in every user
access. Usually it does at least two explicit calls just to decide to do
nothing: _cond_resched and should_resched(). Inline a need_resched()
into the caller to avoid these calls in the common case of no r
From: Andi Kleen
uaccess.h uses might_sleep, but there is currently no explicit include for this.
Since a upcoming patch moves might_sleep into sched.h include sched.h here.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/uaccess.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x8
From: Andi Kleen
As suggested by Linus, remove cond_resched() from the x86 uaccess code.
Now we only do might_fault() in debug kernels.
This means *_user() is not a reschedule point anymore for
CONFIG_PREEMPT_VOLUNTARY, only explicit cond_resched()s are.
Even in the debug kernels we should prob
From: Andi Kleen
At least gcc 4.6 and some earlier ones does not inline this function.
Since it's small and on relatively hot paths force inline it.
Signed-off-by: Andi Kleen
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kerne
From: Andi Kleen
Add a might_fault_debug_only() that only does something in the PROVE_LOCKING
case, but does not cond_resched for PREEMPT_VOLUNTARY. This is for
cases when the cond_resched is done elsewhere
Signed-off-by: Andi Kleen
---
include/linux/sched.h | 2 ++
1 file changed, 2 insertion
From: Andi Kleen
The 64bit __copy_{from,to}_user_inatomic always called
copy_from_user_generic, but skipped the special optimizations for 1/2/4/8
byte accesses.
This especially hurts the futex call, which accesses the 4 byte futex
user value with a complicated fast string operation in a function
From: Alexey Brodkin
Date: Tue, 13 Aug 2013 17:04:36 +0400
> Initially I improperly set a boundary for maximum number of input
> packets to process on NAPI poll ("work") so it might be more than
> expected amount ("weight").
>
> This was really harmless but seeing WARN_ON_ONCE on every device bo
Hey, Kent.
On Tue, Aug 13, 2013 at 04:51:33PM -0700, Kent Overstreet wrote:
> Should probably be almost as good, yeah... in theory, but the space
> efficiency still isn't going to be as good, and it'll probably be more
> code... and at this point I really just don't want to futz with it more.
> At
On Tue, Aug 13, 2013 at 4:10 PM, Nathan Zimmer wrote:
>
> The only mm structure we are adding to is a new flag in page->flags.
> That didn't seem too much.
I don't agree.
I see only downsides, and no upsides. Doing the same thing *without*
the downsides seems straightforward, so I simply see no
Hello Krzysztof,
On Tue, Aug 13, 2013 at 11:46:42AM +0200, Krzysztof Kozlowski wrote:
> Hi Minchan,
>
> On wto, 2013-08-13 at 16:04 +0900, Minchan Kim wrote:
> > patch 2 introduce pinpage control
> > subsystem. So, subsystems want to control pinpage should implement own
> > pinpage_xxx functions
On Tue, Aug 13, 2013 at 07:22:11PM -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 13, 2013 at 03:59:27PM -0700, Kent Overstreet wrote:
> > > Well, it's not necessarily about requiring it but more about surviving
> > > it with some grace when things don't go as expected, which is an
> > > importa
On Tue, Aug 13, 2013 at 07:44:55PM -0400, Chris Metcalf wrote:
> int lru_add_drain_all(void)
> {
> static struct cpumask mask;
Instead of cpumask,
> static DEFINE_MUTEX(lock);
you can DEFINE_PER_CPU(struct work_struct, ...).
> for_each_online_cpu(cpu) {
>
On 8/13/2013 7:29 PM, Tejun Heo wrote:
> It won't nest and doing it simultaneously won't buy anything, right?
> Wouldn't it be better to protect it with a mutex and define all
> necessary resources statically (yeah, cpumask is pain in the ass and I
> think we should un-deprecate cpumask_t for stati
From: Oliver Neukum
Date: Tue, 13 Aug 2013 17:17:10 +0200
> On Tue, 2013-08-13 at 20:32 +0800, hayeswang wrote:
>> Oliver Neukum [mailto:oneu...@suse.de]
>> > Sent: Tuesday, August 13, 2013 4:49 PM
>> > To: Hayeswang
>> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> > linux-...
On Tue, Aug 13, 2013 at 6:02 PM, Steven Rostedt wrote:
> Rusty,
>
> I'm looking at porting my "enable tracepoints in module load" patches
> and one of the comments you gave me (long ago) was to not have:
>
> trace_foo=1
>
> but to just have:
>
> trace_foo
>
> as a parameter name. I went and impl
On Tue, Aug 13, 2013 at 01:55:57PM +0200, Stephane Eranian wrote:
> This patch adds support for the new PERF_RECORD_MMAP2
> record type exposed by the kernel. This is an extended
> PERF_RECORD_MMAP record. It adds for each file-backed
> mapping the device major, minor number and the inode
> number.
On 08/01/2013 08:50 PM, David Gibson wrote:
> On Wed, Jul 31, 2013 at 05:26:47PM -0400, jonsm...@gmail.com
> wrote:
>> On Wed, Jul 31, 2013 at 4:48 PM, Russell King - ARM Linux
>> wrote:
>>> On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsm...@gmail.com
>> wrote:
> [snip]
>> Alternatively you may b
On 8/13/2013 7:29 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 13, 2013 at 06:53:32PM -0400, Chris Metcalf wrote:
>> int lru_add_drain_all(void)
>> {
>> -return schedule_on_each_cpu(lru_add_drain_per_cpu);
>> +return schedule_on_each_cpu_cond(lru_add_drain_per_cpu,
>> +
From: Vlad Yasevich
Date: Tue, 13 Aug 2013 19:06:37 -0400
> ast explained it in his header message (Bridge VLAN kernel/iproute2
> incompatibility)
That's not a header message.
Header messages have a subject prefix of the form "[PATCH 0/N]".
If he had done this I wouldn't have had to ask such si
Hello,
On Tue, Aug 13, 2013 at 06:53:32PM -0400, Chris Metcalf wrote:
> int lru_add_drain_all(void)
> {
> - return schedule_on_each_cpu(lru_add_drain_per_cpu);
> + return schedule_on_each_cpu_cond(lru_add_drain_per_cpu,
> + lru_add_drain_cond, NULL);
When building kernels for a preliminary hardware target, having to add a
kernel command-line option can prove inconvenient. Add a Kconfig option
that changes the default of this option to 1.
Signed-off-by: Josh Triplett
---
I dropped the indication of the default in the module parameter
documen
Hello,
On Tue, Aug 13, 2013 at 03:59:27PM -0700, Kent Overstreet wrote:
> > Well, it's not necessarily about requiring it but more about surviving
> > it with some grace when things don't go as expected, which is an
> > important characteristic for common library stuff.
>
> The patch I posted sho
On Tue, 13 Aug 2013 17:02:28 -0400
Steven Rostedt wrote:
> Rusty,
>
> I'm looking at porting my "enable tracepoints in module load" patches
> and one of the comments you gave me (long ago) was to not have:
>
> trace_foo=1
>
> but to just have:
>
> trace_foo
>
> as a parameter name. I went
On Tue, Aug 13, 2013 at 10:51:37AM -0700, Linus Torvalds wrote:
> I realize that benchmarking cares, and yes, I also realize that some
> benchmarks actually want to reboot the machine between some runs just
> to get repeatability, but if you're benchmarking a 16TB machine I'm
> guessing any serious
On Tue, 13 Aug 2013 18:34:53 -0400
Mathieu Desnoyers wrote:
> What I like about this approach, if applied to kernel modules, is that
> it does not require users to interact with module load parameters to
> specify which tracepoints should be enabled: this is all done through
> the regular tracer
This change makes lru_add_drain_all() only selectively interrupt
the cpus that have per-cpu free pages that can be drained.
This is important in nohz mode where calling mlockall(), for
example, otherwise will interrupt every core unnecessarily.
Signed-off-by: Chris Metcalf
---
v7: try a version
1 - 100 of 813 matches
Mail list logo
