On Mon, Aug 05, 2013 at 01:15:40PM +0100, Matt Fleming wrote:
> > +static __init int match_config_table(efi_guid_t *guid,
> > +unsigned long table,
> > +efi_config_table_type_t *table_types)
> > +{
> > + u8 str[38];
>
> Shouldn't th
On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+
> -Original Message-
> From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant
> Grundler
> Sent: Wednesday, August 07, 2013 1:07 AM
> To: Marek Szyprowski
>
> Hi Marek,
>
> On Tue, Aug 6, 2013 at 6:17 AM, Marek Szyprowski
> wrote:
> ...
> > IMHO it is much better to h
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> > I am objecting to moving the generic part of that code into memcg. The
> > memcg part and the additional complexity (all the parsing and conditions
> > for signalling)
Dear,
Our company manufactures a range of injectable and oral steroids products that
are used successfully in over 10 countries.
We are considering expanding our products to new markets and we would
appreciate you assistance.
In particular, we would like to look for product agents. We will quote
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> How is it specific to memcg? The fact only memcg uses the interface
> doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition* memcg
specific. It's the verbatim meaning of the
This patch splits the sam9x5 peripheral definitions into:
- a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
- several optional peripheral definitions which will be included by specific
sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
This provides a better representation of the real hardware (dro
My Latitude E6510 has the following graphics HW:
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit, non-
This driver supports the GPIO controller found in LSI ZEVIO SoCs.
It has been successfully tested on a TI nspire CX calculator.
---
.../devicetree/bindings/gpio/gpio-zevio.txt| 18 ++
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile
Hi,
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
@@ -0,0 +1,19 @@
+Zevio GPIO controller
+
+Required properties:
+- compatible = "lsi,zevio-gpio"
+- reg =
+- #gpio-cells = <2>
+- gpio-controller;
+
+Optional:
+- #ngpios = <32>: Number of GPIOs. Defaults to 32 if abs
On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
> Although all articles declare that rcu read site is deadlock-immunity.
> It is not true for rcu-preempt, it will be deadlock if rcu read site
> overlaps with scheduler lock.
The real rule is that if the scheduler does its outermost r
On Tue, Aug 06, 2013 at 11:34:35PM +0200, Mathias Krause wrote:
> Commit a5463cd3 "ARM: make vectors page inaccessible from userspace"
> introduced a typo making arch_vma_name() always return "[vectors]".
> Fix up that regression (of the hush-hush security fix).
And if you search the list archives
On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > But we already check `event->pmu != leader_pmu' in validate_event, so we
> > shouldn't get anywhere nearer calling get_event_idx in the case you
> > describe. It sounds m
netlink_send is supposed to send just the cn_msg+hv_kvp_msg via netlink.
Currently it sets an incorrect iovec size, as reported by valgrind.
In the case of registering with the kernel the allocated buffer is large
enough to hold nlmsghdr+cn_msg+hv_kvp_msg, no overrun happens. In the
case of respon
Hello, Michal.
On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of oom_control events
> registered per memcg. This might lead to an user triggered memory
> depletion if a regular user is allowed to register events.
>
> Let's be more strict a
On Tue, 06 Aug, at 08:45:00PM, Roy Franz wrote:
> Rename them to be more similar, as low_free() could be used to free
> memory allocated by both high_alloc() and low_alloc().
> high_alloc() -> efi_high_alloc()
> low_alloc() -> efi_low_alloc()
> low_free() -> efi_free()
>
> Signed-off-by: Roy Fr
On Tue, 06 Aug, at 08:44:59PM, Roy Franz wrote:
> Signed-off-by: Roy Franz
> ---
> arch/x86/boot/compressed/eboot.c | 38 +++--
> drivers/firmware/efi/efi-stub-helper.c | 96
> +---
> 2 files changed, 72 insertions(+), 62 deletions(-)
For future ref
**_usb_get_phy_**() APIs should generate equivalent
error codes in case of failure in getting phy. There's no
need of returning NULL pointer, like in devm_usb_get_phy()
or devm_usb_get_phy_dev(), since it's nowhere handled.
Earlier series of patches starting:
9ee1c7f usb: host: ohci-exynos: fix PH
On Tue, 06 Aug, at 08:45:06PM, Roy Franz wrote:
> Rename variables to be not initrd specific, as now the function
> loads arbitrary files.
>
> Signed-off-by: Roy Franz
> ---
> drivers/firmware/efi/efi-stub-helper.c | 92
>
> 1 file changed, 46 insertions(+), 4
On Tue, 06 Aug, at 08:45:08PM, Roy Franz wrote:
> The x86/AMD64 EFI stubs must us a call wrapper to convert between
> the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
> the ABIs are compatible, so we can directly invoke the function
> pointers. The functions that are used by the
On Tue, 30 Jul 2013 21:02:08 +0800
Xiao Guangrong wrote:
> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>*/
> kvm_flush_remote_tlbs(kvm);
>
> + if (kvm->arch.rcu_free_shadow_page) {
> + sp = list_first_entry(invalid_list, struct kvm_m
On Wed, Aug 07, 2013 at 09:08:36AM -0400, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > depletion if a
On 08/07/2013 09:09 PM, Takuya Yoshikawa wrote:
> On Tue, 30 Jul 2013 21:02:08 +0800
> Xiao Guangrong wrote:
>
>> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>> */
>> kvm_flush_remote_tlbs(kvm);
>>
>> +if (kvm->arch.rcu_free_shadow_page) {
>> +
Greetings
You are a beneficiary to my late clients Will and Testament, late James
Jampbell made his inheritance in your favour. i need your attention on this
issue.
Barr Colin Lee.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
Hello,
On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of threshold events registered
> per memcg. This might lead to an user triggered memory depletion if a
> regular user is allowed to register on memory.[memsw.]usage_in_bytes
> eventfd in
Hi
This is an alternative to the 'keep tracking' flag patch
which is here:
http://marc.info/?l=linux-kernel&m=137242545521246&w=2
perf tools is updated and a test added to demonstrate the
new event.
Adrian Hunter (3):
perf: add a dummy software event to keep tracking
perf t
Add support for the new dummy software event
PERF_COUNT_SW_DUMMY.
Signed-off-by: Adrian Hunter
---
tools/perf/util/parse-events.c | 4
tools/perf/util/parse-events.l | 1 +
tools/perf/util/python.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/
When an event is disabled the "tracking" events
selected by the 'mmap', 'comm' and 'task' bits of
struct perf_event_attr, are also disabled. However,
the information those events provide is necessary to
resolve symbols for when the main event is re-enabled.
The "tracking" events can be kept enabl
Add a test for the newly added PERF_COUNT_SW_DUMMY event.
The test checks that tracking events continue when an
event is disabled but a dummy software event is not
disabled.
Signed-off-by: Adrian Hunter
---
tools/perf/Makefile | 1 +
tools/perf/tests/builtin-test.c | 4 ++
tool
On Wed 07-08-13 08:43:21, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> > How is it specific to memcg? The fact only memcg uses the interface
> > doesn't imply it is memcg specific.
>
> I don't follow. It's only for memcg. That is *by defi
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, August 07, 2013 9:07 AM
> To: KY Srinivasan; gre...@linuxfoundation.org
> Cc: linux-kernel@vger.kernel.org; Olaf Hering
> Subject: [PATCH] Tools: hv: correct payload size in netlink_send
>
> netlink_send
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on this development board.
>
> Signed-off-by: Lee Jones
Patch applied to my ux500-dt branch.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> TPS61052 is a; boost converter, LED driver, LED flash driver and
> simple GPIO pin chip. It has no use here however, as it is not
> found on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
T
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Wednesday 07 August 2013 03:01:26 Jiri Kosina wrote:
> On Tue, 6 Aug 2013, Peter Wu wrote:
> > While debugging upowerd (with Logitech Unifying receiver via hidraw),
> > I came across this list corruption warning.
>
> Peter,
>
> does the patch below fix the problem you are seeing?
That one is a
On Wed, 7 Aug 2013, Peter Wu wrote:
> > does the patch below fix the problem you are seeing?
> That one is already in 3.11-rc4 as far as I can see. Also, that code can
> probably simplified by moving the mutex_unlock after the out label, removing
> the need to duplicate the mutex_unlock.
>
> Re
Hello, Michal.
On Wed, Aug 07, 2013 at 03:26:13PM +0200, Michal Hocko wrote:
> I would rather see it not changed unless it really is a big win in the
> cgroup core. So far I do not see anything like that (just look at
> __cgroup_from_dentry which needs to be exported to allow for the move).
The e
On Aug 7, 2013, at 7:09 PM, Tony Lindgren wrote:
> * Chen Baozi [130805 08:33]:
>> ping?
>>
>> On Aug 1, 2013, at 7:27 PM, Chen Baozi wrote:
>>
>>> The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
>>> rather than INCREMENTER_NUMERATOR_OFFSET.
>
> Maybe describe what
On Wed 07-08-13 09:08:36, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > depletion if a regular user is
On Mon 05-08-13 12:43:58, Andy Lutomirski wrote:
> My application fallocates and mmaps (shared, writable) a lot (several
> GB) of data at startup. Those mappings are mlocked, and they live on
> ext4. The first write to any given page is slow because
> ext4_da_get_block_prep can block. This means
The return type of ffs() is 'int' on all architectures except cris and
hexagon. This unifies the return type to 'int'.
The problem I'm seeing is that the following line generates a warning
on cris and hexagon because of the mismatch between format '%u' and
return type of ffs().
printk("b
On 8/5/13 3:17 AM, Namhyung Kim wrote:
I don't think this is a problem, its in line with Ingo's suggestion of a
new perf ioctl to ask the kernel to generate PERF_RECORD_MMAP events for
existing threads.
Hmm.. could you please give me a link of the thread?
I believe this is the thread being re
The return type of ffs() is 'int' on all architectures except cris and
hexagon. This unifies the return type to 'int'.
The problem I'm seeing is that the following line generates a warning
on cris and hexagon because of the mismatch between format '%u' and
return type of ffs().
printk("b
There is no need to have a nlmsghdr pointer to another temporary buffer.
Instead use a full struct nlmsghdr.
Signed-off-by: Olaf Hering
---
tools/hv/hv_kvp_daemon.c | 15 +--
tools/hv/hv_vss_daemon.c | 15 +--
2 files changed, 10 insertions(+), 20 deletions(-)
diff --git
On Wed 07-08-13 09:22:10, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of threshold events registered
> > per memcg. This might lead to an user triggered memory depletion if a
> > regular user is allowed to
Hello,
On Wed, Aug 07, 2013 at 03:37:46PM +0200, Michal Hocko wrote:
> > It isn't different from listening from epoll, for example.
>
> epoll limits the number of watchers, no?
Not that I know of. It'll be limited by max open fds but I don't
think there are other limits. Why would there be?
>
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> This must have been a merge error. There was a patch which renamed the
> u9540.dts to ccu9540.dts, however the u9540.dts was reincarnate with
> the same patches which created it in the first place. Let's kill it
> once and for all.
>
> Signed-of
Quoting Eric W. Biederman (ebied...@xmission.com):
>
> Since this still has not been addressed. I am going to repeat Andrews
> objection again.
>
> Isn't there a better way to get iptables information out than to use
> syslog. I did not have time to follow up on that but it did appear that
Bru
On Mon, Jul 22, 2013 at 12:52 PM, Lee Jones wrote:
> Signed-off-by: Lee Jones
None of these patches apply since I applied your other patch series
that rename all the files ... can you respin the ux500 "0x"-strip patches
on top of the rename set? My ux500-devicetree branch can be used
as a basel
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, August 07, 2013 9:45 AM
> To: KY Srinivasan; gre...@linuxfoundation.org
> Cc: linux-kernel@vger.kernel.org; Olaf Hering
> Subject: [PATCH] Tools: hv: use full nlmsghdr in netlink_send
>
> There is no need
On Thu, Aug 1, 2013 at 12:31 AM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
>
> Cc: Linus Walleij
> Signed-off-by: Stephen Boyd
For this patch (given the idea is accept
On Wed, Aug 07, 2013 at 02:00:27PM +0100, Will Deacon wrote:
> On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> > On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > > But we already check `event->pmu != leader_pmu' in validate_event, so we
> > > shouldn't get anywhere n
On Wed 07-08-13 09:47:41, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 03:37:46PM +0200, Michal Hocko wrote:
> > > It isn't different from listening from epoll, for example.
> >
> > epoll limits the number of watchers, no?
>
> Not that I know of. It'll be limited by max open fds but I
Hello,
On Wed, Aug 07, 2013 at 03:46:54PM +0200, Michal Hocko wrote:
> OK, I have obviously misunderstood your concern mentioned in the other
> email. Could you be more specific what is the DoS scenario which was
> your concern, then?
So, let's say the file is write-accessible to !priv user which
On Wed, 07 Aug 2013, Linus Walleij wrote:
> On Mon, Jul 22, 2013 at 12:52 PM, Lee Jones wrote:
>
> > Signed-off-by: Lee Jones
>
> None of these patches apply since I applied your other patch series
> that rename all the files ... can you respin the ux500 "0x"-strip patches
> on top of the rena
On Wed, Aug 07, 2013 at 03:57:34PM +0200, Michal Hocko wrote:
> On Wed 07-08-13 09:47:41, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Aug 07, 2013 at 03:37:46PM +0200, Michal Hocko wrote:
> > > > It isn't different from listening from epoll, for example.
> > >
> > > epoll limits the number of wat
HI, xfs maintainers,
any comments?
On Wed, Jul 31, 2013 at 4:42 PM, 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,
On 08/05/2013 06:59 AM, Xiao Guangrong wrote:
Current code always uses arch.mmu to check the reserved bits on guest gpte
which is valid only for L1 guest, we should use arch.nested_mmu instead when
we translate gva to gpa for the L2 guest
Fix it by using @mmu instead since it is adapted to the c
2013/8/3 Gerhard Sittig :
> On Wed, Jul 31, 2013 at 11:20 +0400, Alexander Popov wrote:
>>
> Please make sure to either cite
> properly or to properly mark changes as such. Don't spread false
> information, please. You are free to change what I submitted,
> but you should not pretend that I wrote
The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
rather than INCREMENTER_NUMERATOR_OFFSET.
This is more likely a typo, since INCREMENTER_DENUMERATOR_RELOAD[23:17] is
reserved. It seems that it won't make much trouble without this fix, because
the useful [11:0] bits are mas
2013/8/3 Gerhard Sittig :
> On Wed, Jul 31, 2013 at 11:21 +0400, Alexander Popov wrote:
>>
> You don't provide a lot of information to those you want to
> receive feedback from. You should keep a history and list the
> changes between versions. And you may want to somehow link this
> v3 to its pr
On Fri, Aug 02, 2013 at 11:37:24AM -0400, Johannes Weiner wrote:
> When the page allocator fails to get a page from all zones in its
> given zonelist, it wakes up the per-node kswapds for all zones that
> are at their low watermark.
>
> However, with a system under load the free pages in a zone ca
On Fri, Aug 02, 2013 at 11:37:25AM -0400, Johannes Weiner wrote:
> Allocations that do not have to respect the watermarks are rare
> high-priority events. Reorder the code such that per-zone dirty
> limits and future checks important only to regular page allocations
> are ignored in these extraord
On Fri, Jun 21, 2013 at 03:05:28PM +0800, Chew Chiau Ee wrote:
> From: Chew, Chiau Ee
>
> If both IC_EMPTYFIFO_HOLD_MASTER_EN and IC_RESTART_EN are set to 1, the
> Designware I2C controller doesn't generate RESTART unless user specifically
> requests it by setting RESTART bit in IC_DATA_CMD regis
On Wed 07-08-13 09:58:18, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 03:46:54PM +0200, Michal Hocko wrote:
> > OK, I have obviously misunderstood your concern mentioned in the other
> > email. Could you be more specific what is the DoS scenario which was
> > your concern, then?
>
> So,
Roland Dreier wrote:
From: Roland Dreier
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
This patch adds CPU0's clk driver for Tegra. It will be used by the generic
cpufreq-cpu0 driver to get/set cpu clk.
Most of the platform specific bits are picked from tegra-cpufreq.c.
Signed-off-by: Viresh Kumar
---
drivers/clk/tegra/Makefile | 1 +
drivers/clk/tegra/clk-cpu.c | 164
Hi Stephen,
This is the first attempt to get rid of tegra-cpufreq driver. This patchset
tries to add supporting infrastructure for tegra to use cpufreq-cpu0 driver.
I don't have hardware to test it and so is compiled tested only.. Few bits may
be missing as I couldn't think of all aspects and so
cpufreq-cpu0 driver is dependent on OPP library and hence we need to enable it
for Tegra as we are going to use cpufreq-cpu0.
Signed-off-by: Viresh Kumar
---
arch/arm/mach-tegra/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfi
cpufreq-cpu0 driver can be probed over DT only if a corresponding device node is
created for the SoC which wants to use it. Lets create a platform device for
cpufreq-cpu0 driver for Tegra.
Also it removes the Kconfig entry responsible to compiling tegra-cpufreq driver
and hence there will not be a
Tegra requires cpufreq-cpu0 driver to be compiled in and hence we select it from
the defconfig.
Signed-off-by: Viresh Kumar
---
arch/arm/configs/tegra_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 1effb43..
We are using generic cpufreq-cpu0 driver, so lets get rid of platform specific
tegra-cpufreq.c driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/Makefile| 1 -
drivers/cpufreq/tegra-cpufreq.c | 291
2 files changed, 292 deletions(-)
delet
On Wed 07-08-13 15:57:34, Michal Hocko wrote:
[...]
> Hmm, OK so you think that the fd limit is sufficient already?
Hmm, that would need to touch the code as well (the register callback
would need to make sure only one event is registered per cfile). But yes
this way would be better. I will send a
cpufreq-cpu0 driver needs OPPs to be present in DT which can be probed by it to
get frequency table. This patch adds OPPs and clock-latency to tegra cpu0 node
for multiple SoCs.
Voltage levels aren't used until now for tegra and so a flat value which would
eventually be ignored is used to represen
On Wed, Aug 07, 2013 at 12:06:32PM +0100, Lars Poeschel wrote:
> From: Lars Poeschel
>
> Following commit ff5c9059 and therefore other omap platforms using
> the gpio-omap driver correct the #interrupt-cells property on am33xx
> too. The omap gpio binding documentaion also states that
> the #inte
On Fri, Aug 02, 2013 at 11:37:26AM -0400, Johannes Weiner wrote:
> Each zone that holds userspace pages of one workload must be aged at a
> speed proportional to the zone size. Otherwise, the time an
> individual page gets to stay in memory depends on the zone it happened
> to be allocated in. As
This change adds support for avoiding recursive backtracer crashes;
we haven't seen this in practice other than when things are seriously
corrupt, but it may help avoid losing the root cause of a crash.
Also, don't abort kernel backtracers for invalid userspace PC's.
If we do, we lose the ability
As specified, the test wasn't correct, and in any case it should
be a BUILD_BUG_ON.
Signed-off-by: Chris Metcalf
---
arch/tile/mm/fault.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
index f7f99f9..6152819 100644
--- a/arch/til
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/intvec_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/kernel/intvec_32.S b/arch/tile/kernel/intvec_32.S
index cb52d66..25966af 100644
--- a/arch/tile/kernel/intvec_32.S
+++ b/arch/tile/kernel/intvec_32.S
@@ -160
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
---
include/linux/wor
On Wed, Jul 24, 2013 at 09:14:35AM +0200, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard
Applied to for-current, thanks!
And please, always send to the I2C list. I work heavily with patchwork
monitoring the I2C list; everything not there will easily be forgotten!
signature.asc
Description
This change adds support for the "memmap" boot parameter similar
to what x86 provides. The tile version supports "memmap=1G$5G",
for example, as a way to reserve a 1 GB range starting at PA 5GB.
The memory is reserved via bootmem during startup, and we create a
suitable "struct resource" marked as
This change improves and cleans up the tile console.
- We enable HVC_IRQ support on tilegx, with the addition of a new
Tilera hypervisor API for tilegx to allow a console IPI. If IPI
support is not available we fall back to the previous polling mode.
- We simplify the earlyprintk code to use
Pointed out by checkpatch. A few of the DEFINE() lines were
properly written without backslash continuation; fix the rest.
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/asm-offsets.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/tile
On Wed, 2013-08-07 at 07:06 +0200, Ondřej Bílka wrote:
> Add short_counter,long_counter and before increment counter before each
> jump. That way we will know how many short/long jumps were taken.
That's not trivial at all. The jump is a single location (in an asm
goto() statement) that happens
On Thu, Aug 01, 2013 at 02:10:46PM +0200, Sebastian Hesselbarth wrote:
> i2c_put_adapter dereferences i2c_adapter pointer passed without check
> for NULL. This adds a check for non-NULL pointer to allow i2c_put_adapter
> called with NULL and behave the same way i2c_release_client does already.
>
>
Hi Peter,
The patch I posted was solving slab memory corruption issue which was occurring
because of the race in device disconnect and device release. We found the some
of the device data structure being used after free. Later we figure out the
patch which was reverted earlier was solving our i
On Wednesday 07 August 2013 at 16:53:09, Mark Rutland wrote:
> On Wed, Aug 07, 2013 at 12:06:32PM +0100, Lars Poeschel wrote:
> > From: Lars Poeschel
> >
> > Following commit ff5c9059 and therefore other omap platforms using
> > the gpio-omap driver correct the #interrupt-cells property on am33xx
On Mon, Aug 05, 2013 at 04:19:34PM +0900, Nguyen Viet Dung wrote:
> This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
>
> Signed-off-by: Nguyen Viet Dung
Isn't it possible to distinguish between H1 and H2 somewhere in
hardware? Then we could skip the 'flags' variable
On Tue, Aug 06, 2013 at 01:38:31PM +0100, Jonas Jensen wrote:
> The MOXA ART SoC has a DMA controller capable of offloading expensive
> memory operations, such as large copies. This patch adds support for
> the controller including four channels. Two of these are used to
> handle MMC copy on the UC
On Wed, 7 Aug 2013, Will Deacon wrote:
> Ok, so the following quick hack below should solve the issue (can you confirm
> it please, since I don't have access to any hardware atm?)
>
> We should revisit this for 3.12 though, because I'm not sure that our
> validation code even does the right thing
On Thu 01-08-13 20:58:46, Davidlohr Bueso wrote:
> On Thu, 2013-08-01 at 22:33 +0200, Jan Kara wrote:
> > Hi,
> >
> > On Thu 01-08-13 13:14:19, Davidlohr Bueso wrote:
> > > FYI I'm seeing loads of the following messages with Linus' latest
> > > 3.11-rc3 (which includes 822dbba33458cd6ad)
> > T
From: Lars Poeschel
In case request_threaded_irq inside adnp_irq_setup fails, the driver
segfaults. This is because irq_domain_remove is called twice with
the same pointer. First time in adnp_irq_setup and then a second time
after leaving adnp_irq_setup in the error path of adnp_i2c_probe
inside
On Wed, 7 Aug 2013, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Will Deacon wrote:
>
> > Ok, so the following quick hack below should solve the issue (can you
> > confirm
> > it please, since I don't have access to any hardware atm?)
> >
> > We should revisit this for 3.12 though, because I'm not
Am 07.08.2013 07:52, schrieb Greg Kroah-Hartman:
On Tue, Aug 06, 2013 at 03:37:13PM +0200, Alexander Holler wrote:
Am 06.08.2013 12:14, schrieb Greg Kroah-Hartman:
What exactly is a platform device anyway?
Originally it was a "something that wasn't connected to a bus, but just
had memory-map
On 08/07/2013 08:20 AM, Jan Kara wrote:
On Thu 01-08-13 20:58:46, Davidlohr Bueso wrote:
On Thu, 2013-08-01 at 22:33 +0200, Jan Kara wrote:
Hi,
On Thu 01-08-13 13:14:19, Davidlohr Bueso wrote:
FYI I'm seeing loads of the following messages with Linus' latest
3.11-rc3 (which includes 822dbb
On Wed, 2013-08-07 at 11:18 +0100, Nix wrote:
> On 6 Aug 2013, Trond Myklebust verbalised:
> > True. How about something like the following instead. Note the change to
> > the original patch...
>
> Well, with those applied I could reboot without a panic for the first
> time since 3.8.x: looking go
Stephen Rothwell writes:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell
>> wrote:
>> >
>> > After merging the ext4 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > fs/ext4/i
201 - 300 of 848 matches
Mail list logo
