On Thu, 2014-01-16 at 23:23 +0530, Srikanth Thokala wrote:
Hi,
This is the driver for Xilinx AXI Video Direct Memory Access Engine.
It is a soft IP core, which provides high-bandwidth direct memory
access between memory and AXI4-Stream video type target peripherals
including peripherals
This patch fixes a problem with the handling of the newly
introduced optional event unit. The following cmdline
caused a segfault:
$ perf stat -e cpu/event-0x3c/ ls
This patch fixes the problem with the default setting
for alias-unit which was eventually causing the segfault.
Signed-off-by:
This patch fixes a memory corruption problem with the xyarray when
the evsel fds get closed at the end of the run_perf_stat() call.
It could be triggered with:
# perf stat -a -e power/energy-cores/ ls
When cpumask are used by events (.e.g, RAPL or uncores) then
the evsel fds are allocated based
This short patch series fixes two problems:
- segfault for perf stat -e cpu/event=0x3c ls
- memory corruption via xyarray of evsel-fd.
The patch is relative to tip.get
Stephane Eranian (2):
perf stat: fix NULL pointer reference bug with event unit
perf stat: fix memory corruption of
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Convert uses of __get_cpu_var for creating a address from a percpu
offset to this_cpu_ptr.
The two cases where get_cpu_var is used to actually access a percpu
variable are changed to use this_cpu_read/raw_cpu_read.
CC:
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form __get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current
[Patch depends on another patch in this series that introduces raw_cpu_ops]
The RT_CACHE_STAT_INC macro triggers the new preemption checks
for __this_cpu ops.
I do not see any other synchronization that would allow the use
of a __this_cpu operation here however in commit
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form __get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
No user is left in the kernel source tree. Therefore we can
drop the definitions.
[Patch should not be merged until all the replacement patches have been
merged. Probably this means hold until the 3.15 merge window]
Signed-off-by: Christoph Lameter c...@linux.com
Index:
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form __get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Most of these are the uses of __raw_get_cpu_var for address calculation.
touch_softlockup_watchdog_sync() uses __raw_get_cpu_var to write to
per cpu variables. Use __this_cpu_write instead.
Cc: Wim Van Sebroeck
On Fri, Jan 17, 2014 at 01:38:12PM +0200, Mika Westerberg wrote:
On Thu, Jan 16, 2014 at 04:19:11PM -0800, David Cohen wrote:
- * Copyright (c) 2008, 2009, 2013, Intel Corporation.
+ * Copyright (c) 20014 Intel Corporation.
Heh, it should probably be 2014 :)
Thanks for pointing that out.
From: David Daney david.da...@cavium.com
The use of __this_cpu_inc() requires a fundamental integer type, so
change the type of all the counters to unsigned long, which is the
same width they were before, but not wrapped in local_t.
Signed-off-by: David Daney david.da...@cavium.com
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form __get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
[Patch depends on another patch in this series that introduces raw_cpu_ops]
We define a check function in order to avoid trouble with the
include files. Then the higher level __this_cpu macros are
modified to invoke the preemption check.
Acked-by: Ingo Molnar mi...@kernel.org
Signed-off-by:
Arnaldo,
I just sent the patches I wrote to fix the bugs I ran into since yesterday.
On Fri, Jan 17, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
a...@redhat.com wrote:
Em Fri, Jan 17, 2014 at 10:00:20AM +0100, Stephane Eranian escreveu:
The issue boils down to the fact that evsels have their
On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
On Thu, 16 Jan 2014, Michal Hocko wrote:
From 543df5c82f6eec622f669ea322ba6ff03924fded Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Thu, 16 Jan 2014 16:17:13 +0100
Subject: [PATCH] memcg: fix css reference leak from
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details, as well as a set of wrapper functions
for u8, u16, u32 and u64.
On Fri, Jan 17, 2014 at 11:48:32AM +, Al Viro wrote:
On Fri, Jan 17, 2014 at 10:49:30AM +0100, Miklos Szeredi wrote:
Can't we just move the fuse_dev_pipe_buf_ops to some non-modular
place (splice.c). It's a hack, yes, but it seems to be the simplest
fix.
Umm... Not even that
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Convert all uses of __get_cpu_var for address calculation to use
this_cpu_ptr instead.
Cc: Peter Zijlstra pet...@infradead.org
Acked-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Christoph Lameter c...@linux.com
[Patch depends on another patch in this series that introduces raw_cpu_ops]
The initialization of a structure is not subject to synchronization.
The use of __this_cpu would trigger a false positive with the
additional preemption checks for __this_cpu ops.
So simply disable the check through the
When timestamping is enabled, stmmac_tx_clean will call
stmmac_get_tx_hwtstamp to get tx TS.
But the skb can be NULL because the last of its tx_skbuff is NULL
if this packet frame is filled in more than one descriptors.
To fix the issue, change the code:
- Store TX skb to the tx_skbuff[] of
On Fri, Jan 17, 2014 at 09:37:56AM +0200, Jarkko Nikula wrote:
On 01/16/2014 09:46 PM, Mark Brown wrote:
This is needed for ACPI because we rewrite the device names to give us
stable names. With OF for I2C and SPI nothing bus specific is done that
affects this stuff so the default behaviour
Vivek, Ben, Eric,
Please take a look at a proposed patch to intel-iommu: [PATCHv3 0/6] Crashdump
Accepting Active IOMMU
This is specifically for kdump; however, would some small variation of this
technique be applicable to kexec ?
Thanks,
Bill
-Original Message-
From: kexec
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Use raw_cpu_ptr instead.
Signed-off-by: Christoph Lameter c...@linux.com
Index: linux/arch/s390/include/asm/percpu.h
===
---
On Fri, Jan 17, 2014 at 04:17:23AM -0800, Christoph Hellwig wrote:
On Wed, Jan 15, 2014 at 10:17:49AM -0500, J. Bruce Fields wrote:
From: J. Bruce Fields bfie...@redhat.com
d_splice_alias can create duplicate directory aliases (in the !new
case), or (in the new case) d_move without
On 01/17/2014 04:31 PM, Hannes Reinecke wrote:
On 01/17/2014 04:17 PM, Miller, Mike (OS Dev) wrote:
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, January 17, 2014 9:14 AM
To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
Cc: LKML;
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: Friday, January 17, 2014 9:31 AM
To: Miller, Mike (OS Dev)
Cc: Tomas Henzl; Andrew Morton; James E. J. Bottomley; LKML; LKML-scsi;
Stephen M. Cameron
Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
[+cc Jens, James, Ben, Fujita (authors of PCI_DMA_BUS_IS_PHYS usage)]
On Fri, Jan 17, 2014 at 5:24 AM, Hanjun Guo hanjun@linaro.org wrote:
Not all the ARM64 targets that are using ACPI have PCI, so introduce
some stub functions to make PCI optional for ACPI, and make ACPI core
run without
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
On 01/17/2014 04:33 PM, Peter Zijlstra wrote:
On Fri, Jan 17, 2014 at 04:26:13PM +0100, Daniel Lezcano wrote:
Ah, ok. Let me try it.
http://programming.kicks-ass.net/sekrit/patches.tar.bz2
has a queue that applies to tip/master.
The patches as on lkml need a little help in applying.
On Fri, 17 Jan 2014, Sebastian Andrzej Siewior wrote:
On 01/17/2014 03:59 PM, Nicholas Mc Guire wrote:
On Fri, 17 Jan 2014, Sebastian Andrzej Siewior wrote:
This is what I am going to apply. It also dropped the get_cpu_light()
call which was added in a patch to remove the get_cpu_var()
On Fri, Jan 17, 2014 at 04:26:13PM +0100, Daniel Lezcano wrote:
Ah, ok. Let me try it.
http://programming.kicks-ass.net/sekrit/patches.tar.bz2
has a queue that applies to tip/master.
The patches as on lkml need a little help in applying.
They've not been near a compiler yet though :/
--
* Nicholas Mc Guire | 2013-12-27 21:00:24 [+0100]:
- A patch from Thomas Gleixner not to raise the timer softirq
unconditionally (only if a timer is pending)
This one seems to deadlock early in the boot sequence on x86
(i3/i7/Phenom-4x here and Carsten Emde also had boot failures)
after
[Patch depends on another patch in this series that introduces raw_cpu_ops]
With the preempt checking logic for __this_cpu_ops we will get false
positives from locations in the code that use numa_node_id.
Before the __this_cpu ops where introduced there were
no checks for preemption present
Convert to the use of this_cpu_ptr().
Cc: James E.J. Bottomley j...@parisc-linux.org
Cc: Helge Deller del...@gmx.de
Cc: linux-par...@vger.kernel.org
Signed-off-by: Christoph Lameter c...@linux.com
Index: linux/arch/parisc/lib/memcpy.c
On 01/17/2014 04:17 PM, Miller, Mike (OS Dev) wrote:
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, January 17, 2014 9:14 AM
To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
Cc: LKML; LKML-scsi; h...@suse.de; Stephen M. Cameron
The patches following this one will add preemption checks to __this_cpu
ops so we need to have an alternative way to use this_cpu operations
without preemption checks.
raw_cpu_ops will be the basis for all other ops since these will be the
operations that do not implement any checks.
Primitive
On Fri, Jan 17, 2014 at 04:56:18PM +0900, Namhyung Kim wrote:
Hi Arnaldo and Frederic,
On Thu, 16 Jan 2014 17:47:34 -0200, Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 16, 2014 at 06:34:58PM +0100, Frederic Weisbecker escreveu:
On Thu, Jan 16, 2014 at 10:17:53AM +0900, Namhyung Kim wrote:
On Thu, Jan 16, 2014 at 01:32:30PM -0600, Nishanth Menon wrote:
Certain platforms such as DRA7 have quirky memory maps such as:
PRM_ABBLDO_DSPEVE_CTRL0x4ae07e20
PRM_ABBLDO_IVA_CTRL 0x4ae07e24
other-registers
PRM_ABBLDO_DSPEVE_SETUP 0x4ae07e30
PRM_ABBLDO_IVA_SETUP 0x4ae07e34
On Fri, Jan 17, 2014 at 14:11 +, Waibel Georg wrote:
From cb384950a1153e856ec03109a5156e660a89bf6d Mon Sep 17 00:00:00 2001
From: Georg Waibel georg.wai...@sensor-technik.de
Date: Fri, 17 Jan 2014 14:51:38 +0100
Subject: [PATCH 1/1] iMX gpio: Allow reading back of pin status if
On Thursday 16 January 2014, Srikanth Thokala wrote:
@@ -0,0 +1,71 @@
+Xilinx AXI VDMA engine, it does transfers between memory and video devices.
+It can be configured to have one channel or two channels. If configured
+as two channels, one is to transmit to the video device and another is
A bunch of unknown NMIs have popped up on a Pentium4 recently when booting
into a kdump kernel. This was exposed because the watchdog timer went
from 60 seconds down to 10 seconds (increasing the ability to reproduce
this problem).
What is happening is on boot up of the second kernel (the kdump
On Fri, Jan 17, 2014 at 10:51:07AM +, Will Deacon wrote:
Actually, I have removed strnlen_user for 3.14. Could you try your test case
with our for-next branch please?
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
This will work fine, I believe (I can't
On 01/17/2014 02:18 AM, Borislav Petkov wrote:
We also cannot carry *every* erratum workaround in the kernel just
because people don't update firmware. Firmware is becoming ubiquitous,
sadly, and because of that, admins should provision for firmware
upgrades too.
Besides, *even* if we put
Commit 7b92b4f (PCI/MSI: Remove pci_enable_msi_block_auto())
introduced a regression - in case multiple MSIs initialization
fails the code falls back to INTx rather than to single MSI.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
drivers/ata/ahci.c |4 +++-
1 files changed, 3
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
There is no need to call pci_disable_msi() or pci_disable_msix()
in case the call to pci_enable_msi() or pci_enable_msix() failed.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
drivers/scsi/ipr.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git
This series is against next branch in Bjorn's repo:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
Changes from v1 to v2:
- added a regression fix ahci: Fix broken fallback to single
MSI mode as patch 1/9;
- the series is reordered to move the regression fix in front;
-
In case MSI-X and MSI initialization failed the function
irq_set_affinity_hint() is called with uninitialized value
in dev-entry[0].vector. This update fixes the issue.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
drivers/block/nvme-core.c | 12 ++--
1 files changed, 6
As result deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
This update also fixes a stylistic (naming and messaging
On 01/16, Alan Stern wrote:
On Thu, 16 Jan 2014, Peter Zijlstra wrote:
On Thu, Jan 16, 2014 at 06:43:48PM +0100, Oleg Nesterov wrote:
Perhaps we should change the meaning of lockdep_set_novalidate_class?
(perhaps with rename). What do you think about the patch below?
With this
On 01/13/2014 02:38 AM, Borislav Petkov wrote:
On Mon, Jan 13, 2014 at 11:17:15AM +0800, Ren Qiaowei wrote:
Yes, I run this with lockdep enabled.
Ok, but you still are doing memory allocation in the exception handler,
AFAICT:
Sure... what is the problem with that? We do that in several
On Fri, 17 Jan 2014 16:33:23 +0100
Nicholas Mc Guire der.h...@hofr.at wrote:
On Fri, 17 Jan 2014, Sebastian Andrzej Siewior wrote:
On 01/17/2014 03:59 PM, Nicholas Mc Guire wrote:
On Fri, 17 Jan 2014, Sebastian Andrzej Siewior wrote:
This is what I am going to apply. It also
On 01/17/2014 07:18 AM, Christoph Lameter wrote:
Cc: Thomas Gleixner t...@linutronix.de
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Acked-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Christoph Lameter c...@linux.com
Acked-by: H. Peter Anvin h...@linux.intel.com
--
To
cppcheck reported memory leak in device_authorizatio()
within hdpvr-core.c.
When the debug option is specified and the code jump to
unlock: label, print_buf was not freed.
Confirm the module succesfully compiled without error.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
On 01/17/2014 04:33 PM, Peter Zijlstra wrote:
On Fri, Jan 17, 2014 at 04:26:13PM +0100, Daniel Lezcano wrote:
Ah, ok. Let me try it.
http://programming.kicks-ass.net/sekrit/patches.tar.bz2
has a queue that applies to tip/master.
The patches as on lkml need a little help in applying.
On 17.01.2014 14:55, Dorau, Lukasz wrote:
On Friday, January 17, 2014 2:37 PM Dorau, Lukasz lukasz.do...@intel.com
wrote:
Hi
My story is very simply...
I applied the following patch:
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
--- a/drivers/scsi/isci/init.c
+++
I have tested your patch.
There is a (non blocking) error message regarding .idle_bias_off, but I
assume that should not have something to do with your patch. Can we just
set idle_bias_off to false here?
Otherwise, it looks good to me.
On 01/14/2014 08:34 PM, Daniel Matuschek wrote:
WM8804 can
Hi Rob,
On Jan 17, 2014, at 4:49 PM, Rob Herring wrote:
On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li li.xi...@freescale.com wrote:
The of_update_property() is intent to update a property in a node
[ snip ]
return of_add_property(np, newprop);
Isn't there also a race that
The pick_next_task function prototype changed with the previous patches.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index
From: Peter Zijlstra pet...@infradead.org
With the previous patches, we have no ambiguity on going to idle. So we can
return directly the idle task instead of looking up all the domains which will
in
any case return the idle_task.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Hi Akashi,
On Fri, Jan 17, 2014 at 08:13:17AM +, AKASHI Takahiro wrote:
Generic audit code also support compat system calls now.
This patch adds a small piece of architecture dependent code.
[...]
static inline int syscall_get_nr(struct task_struct *task,
@@ -109,6 +110,15 @@ static
On 01/17/2014 10:08 AM, Mark Brown wrote:
On Thu, Jan 16, 2014 at 01:32:30PM -0600, Nishanth Menon wrote:
Certain platforms such as DRA7 have quirky memory maps such as:
PRM_ABBLDO_DSPEVE_CTRL 0x4ae07e20
PRM_ABBLDO_IVA_CTRL 0x4ae07e24
other-registers
PRM_ABBLDO_DSPEVE_SETUP
On Fri, Jan 17, 2014 at 08:31:16AM -0800, H. Peter Anvin wrote:
As long as the exception originates from user space there shouldn't
be any issue.
And if it originates from kernel space?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To
On Fri, Jan 17, 2014 at 02:47:15PM +, Ren, Qiaowei wrote:
do_bounds
|-do_mpx_bt_fault
|-allocate_bt
|-sys_mmap_pgoff
|-vm_mmap_pgoff
|-do_mmap_pgoff
|-mmap_region
|- kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
On Friday 17 January 2014, Chen-Yu Tsai wrote:
diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
new file mode 100644
index 000..8a07ea4
--- /dev/null
+++
On 01/17/2014 08:48 AM, Borislav Petkov wrote:
On Fri, Jan 17, 2014 at 08:31:16AM -0800, H. Peter Anvin wrote:
As long as the exception originates from user space there shouldn't
be any issue.
And if it originates from kernel space?
We shouldn't have any BOUND or MPX instructions in
On Wednesday 15 January 2014, Feng Kan wrote:
+static int __init xgene_reboot_init(void)
{
arm_pm_restart = xgene_restart;
return 0;
}
device_initcall(xgene_reboot_init);
This won't work on a generic kernel, since you unconditionally set the
pm_restart function to your
On Fri, Jan 17, 2014 at 03:44:14PM +, Heiko Stübner wrote:
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details,
On 01/17/2014 08:47 AM, Borislav Petkov wrote:
Right, so Steve and I played a couple of scenarios in IRC with this. So
#BR is comparable with #PF, AFAICT, and as expected we don't take any
locks when handling page faults in kernel space as we might deadlock.
Now, what happens if a thread
On Fri, Jan 17, 2014 at 08:51:31AM -0800, H. Peter Anvin wrote:
We shouldn't have any BOUND or MPX instructions in kernel space. Panic.
How do we enforce that?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the
On 01/17/2014 08:56 AM, Borislav Petkov wrote:
On Fri, Jan 17, 2014 at 08:51:31AM -0800, H. Peter Anvin wrote:
We shouldn't have any BOUND or MPX instructions in kernel space. Panic.
How do we enforce that?
#BR exception from kernel space - panic.
We have tons of rules on kernel code...
Пятница, 17 января 2014, 17:52 +01:00 от Arnd Bergmann a...@arndb.de:
On Wednesday 15 January 2014, Feng Kan wrote:
+static int __init xgene_reboot_init(void)
{
arm_pm_restart = xgene_restart;
return 0;
}
device_initcall(xgene_reboot_init);
This won't work on a
* Mike Galbraith | 2013-12-24 16:47:47 [+0100]:
I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
core box. I haven't seen RCU grip yet, but I just checked on it after
3.5 hours into this boot/beat (after fixing crash+kdump setup), and
found it in the process of dumping.
Change missleading comment to actual shift value provided by the chip.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/power/ds2782_battery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/ds2782_battery.c b/drivers/power/ds2782_battery.c
On Fri, Jan 17, 2014 at 08:58:49AM -0800, H. Peter Anvin wrote:
#BR exception from kernel space - panic.
We have tons of rules on kernel code... e.g. no FPU usage. This one is
minor in comparison.
So basically review should catch those wrong BOUND usages?
--
Regards/Gruss,
Boris.
On Thu, Jan 16, 2014 at 01:14:01PM -0500, Joseph Salisbury wrote:
On 01/16/2014 01:12 PM, Bjorn Helgaas wrote:
On Thu, Jan 16, 2014 at 10:53 AM, Joseph Salisbury
joseph.salisb...@canonical.com wrote:
Hi Bjorn,
A kernel bug was opened against Ubuntu [0]. After a kernel bisect, it
was
On Fri, Jan 17, 2014 at 08:23:24AM -0800, H. Peter Anvin wrote:
Actually I by and large disagree with that. There is a limit, of
course, but when it comes to flipping an MSR in init code, the bar is
pretty darn low. We have quirks for all kind of hardware, and this is
just another example.
On Thursday 16 January 2014, Mark Brown wrote:
On Thu, Jan 16, 2014 at 12:19:00PM +0100, Arnd Bergmann wrote:
1. Other platforms also require the syscon driver to be active before
the regular device driver probing starts. Michal Simek has the same
issue in the zynq clock driver that you
On Jan 15, 2014, at 11:42 PM, Prabhakar Kushwaha prabha...@freescale.com
wrote:
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/memory
and fix the header file includes.
Also remove
On Friday, January 17, 2014 5:40 PM Sebastian Riemer
sebastian.rie...@profitbricks.com wrote:
On 17.01.2014 14:55, Dorau, Lukasz wrote:
Some additional information:
The loop 'for' in macro ' for_each_isci_host ' defined as
(drivers/scsi/isci/host.h:313):
#define
Without DMA_PRIVATE the driver is not able to allocate more than one channel.
Since it uses dma_get_any_slave_channel that calls private_candidate,
the second allocation fails at
/* some channels are already publicly allocated */
Maybe it should be fixed in the core, but at least this fixes the
On Fri, Jan 17, 2014 at 10:41:41AM -0500, Don Zickus wrote:
I tested this on a P4 we have in our lab. After two or three crashes, I could
normally reproduce the problem. Now after 10 crashes, everything continues
to boot correctly.
Cc: Dave Young dyo...@redhat.com
Cc: Vivek Goyal
On Fri, 17 Jan 2014 17:47:36 +0100
Borislav Petkov b...@alien8.de wrote:
On Fri, Jan 17, 2014 at 02:47:15PM +, Ren, Qiaowei wrote:
do_bounds
|-do_mpx_bt_fault
|-allocate_bt
|-sys_mmap_pgoff
|-vm_mmap_pgoff
|-do_mmap_pgoff
* Mike Galbraith | 2013-12-25 18:37:37 [+0100]:
On Tue, 2013-12-24 at 23:55 -0800, Paul E. McKenney wrote:
On Wed, Dec 25, 2013 at 04:07:34AM +0100, Mike Galbraith wrote:
Having sufficiently recovered from turkey overdose to be able to slither
upstairs (bump bump bump) to check on the box,
On Fri, 17 Jan 2014 08:51:03 -0800
H. Peter Anvin h...@zytor.com wrote:
On 01/17/2014 08:47 AM, Borislav Petkov wrote:
Right, so Steve and I played a couple of scenarios in IRC with this. So
#BR is comparable with #PF, AFAICT, and as expected we don't take any
locks when handling page
Alkaen Dr.David Ashton
Brondesbury , North West
Lontoo Englanti
Rakas ystävä .
Olen Dr.David Ashton Brondesbury , North West London , täällä Englannissa
. Työskentelen UBS Investment Bank London Branch . Olen kirjallisesti
sinua työhuoneestani että tulee olemaanvaltava hyötyä meille molemmille
* Mike Galbraith | 2013-12-26 11:03:32 [+0100]:
On Wed, 2013-12-25 at 04:07 +0100, Mike Galbraith wrote:
On Tue, 2013-12-24 at 11:36 -0800, Paul E. McKenney wrote:
So which code do you think deserves the big lump of coal? ;-)
Sebastian's NO_HZ_FULL locking fixes.
Whack-a-mole hasn't yet
Hi Stephen,
On Fri, Jan 17, 2014 at 02:30:35PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/clocksource/cadence_ttc_timer.c between commit c1dcc927dae0
(clocksource: cadence_ttc: Fix mutex taken inside interrupt context)
from
On Sun, 12 Jan 2014 20:26:21 +0100
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
On 01/12/2014 07:51 PM, Jean-Francois Moine wrote:
On Sat, 11 Jan 2014 19:35:21 +0100
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
At least for the DT part, I'd suggest to not
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details, as well as a set of wrapper functions
for u8, u16, u32 and u64.
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the
On 01/13/2014 08:53 AM, tip-bot for Dario Faggioli wrote:
Commit-ID: d50dde5a10f305253cbc3855307f608f8a3c5f73
Gitweb: http://git.kernel.org/tip/d50dde5a10f305253cbc3855307f608f8a3c5f73
Author: Dario Faggioli raist...@linux.it
AuthorDate: Thu, 7 Nov 2013 14:43:36 +0100
Committer:
On 01/17/2014 09:04 AM, Borislav Petkov wrote:
On Fri, Jan 17, 2014 at 08:58:49AM -0800, H. Peter Anvin wrote:
#BR exception from kernel space - panic.
We have tons of rules on kernel code... e.g. no FPU usage. This one is
minor in comparison.
So basically review should catch those wrong
We need barriers to guarantee this pattern works as intended:
[w] req-rc, 1 [r] req-status, 1
wmb rmb
[w] req-status, 1 [r] req-rc
Where the wmb ensures that rc gets written before status,
and the rmb ensures that if you observe status == 1, rc is the new value.
Hi,
This patch addresses the race I'm describing below.
It currently mostly affects trans_rdma, but the fix has to go in the
common part of the code.
virtio and tcp really aren't consciously protected though, so I believe
this can't hurt. They *might* be safe at the moment because other
changes
901 - 1000 of 1228 matches
Mail list logo
