On Tue, Oct 15 2013, Christoph Lameter wrote:
> __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
On 2013/10/11 02:32AM, Chen Gong wrote:
> To satisfy the necessary of following patches and make related definition
> more clear, update some definitions about CPER. No functional changes.
>
> Signed-off-by: Chen, Gong
> ---
> drivers/acpi/apei/apei-internal.h | 12 -
>
On Tue, Oct 15 2013, Jeff Moyer wrote:
> Hi, Jens,
>
> blk_mq_update_queue_map does this:
>
> for_each_possible_cpu(i) {
> if (!cpu_online(i)) {
> map[i] = 0;
> continue;
> }
>
> ...
>
[devicetree to bcc]
Peter,
Please don't post driver/platform patches to the devicetree list. Only
bindings updates should be posted here.
Otherwise the volume of patches make the people who need to see the
and review the bindings run for the hills. :-)
-Olof
On Tue, Oct 15, 2013 at 8:14 AM,
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 76 ---
1 file changed, 35 insertions(+), 41 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 94df758..84ef3b8 100644
--- a/net/sctp/outqueue.c
+++
On Mon, Oct 14, 2013 at 01:31:23PM -0700, gre...@linuxfoundation.org wrote:
> If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
> potentionally return from the function without having freed these
> allocations. If we don't do the return, we over-write the previous
> allocation
__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
__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
__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
__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
__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
__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
__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
__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
__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
__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
__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
On Tue, 2013-10-15 at 19:48 +0200, Geert Uytterhoeven wrote:
> Print a list of pages to be copied if debugging is enabled.
> Consecutive entries are merged to reduce screen clutter.
[]
> diff --git a/kernel/kexec.c b/kernel/kexec.c
[]
> +static void kimage_print_block(const struct kimage_block
(Sorry for the repost -- mistyped Dave's email address the first time...)
Dave,
Please pull this batch of fixes intended for the 3.12 stream!
For the mac80211 bits, Johannes says:
"Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
probing on VLANs."
And also:
"This time
The following patches 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 rely on the __this_cpu_xxx_1/2/4/8 operations having no
preemption checks. We therefore do not have to duplicate these
V3->V4:
- Drop CONFIG_DEBUG_THIS_CPU_OPERATIONS
- Add support for logging the exact operation that caused the issue.
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 check before
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 use of raw_cpu ops.
Trace:
[0.668066] __this_cpu_write operation in
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
dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies
the use of raw_smp_processor_id() here
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 either. smp_raw_processor_id()
was used. See
On 10/15/2013 12:18 PM, Christoph Hellwig wrote:
> On Tue, Oct 15, 2013 at 01:14:47PM -0400, Benjamin LaHaise wrote:
>>> While I agree that getting that would be useful it is something that has
>>> nothing to do with issueing aio from kernel space and holding this
>>> patchset hostage for
** Resending using Comcast instead of Amazon SES.
This patchset introduces preemption checks for __this_cpu operations.
First we add new raw_cpu operations that perform this cpu operations
without preempt checks in the future.
Then those raw_cpu operations are used in a number of locations to
ip4_datagram_connect is called with BH processing enabled. Therefore
we cannot use IP_INC_STATS_BH but must use IP_INC_STATS which disables
BH handling before incrementing the counter.
The following trace is triggered without this patch:
[ 9293.806634] __this_cpu_add operation in preemptible
Hi Alan,
USB storage maybe just has to say that the abort occurred. By setting the
US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was
time out and the command is being aborted.
Now, it's arguable whether to change the implication of US_FLIDX_TIMED_OUT
bit for scsi - USB
Hi, Jens,
blk_mq_update_queue_map does this:
for_each_possible_cpu(i) {
if (!cpu_online(i)) {
map[i] = 0;
continue;
}
...
first_sibling = get_first_sibling(i);
if
On Tue, 15 Oct 2013, Kirill A. Shutemov wrote:
> Andrea Arcangeli wrote:
> > Hi Hugh,
> >
> > On Tue, Oct 15, 2013 at 04:08:28AM -0700, Hugh Dickins wrote:
> > > Occasionally we hit the BUG_ON(pmd_trans_huge(*pmd)) at the end of
> > > __split_huge_page_pmd(): seen when doing
On 10/14/2013 04:49 AM, Max Filippov wrote:
> Buddy allocator was used here prior to commit 6656920 [XTENSA] Add
> support for cache-aliasing I can only guess that the change was made
> to make allocated page tables have the same colour, but am not sure
> why this is needed. Chris?
Max, I think
Dave,
Please pull this batch of fixes intended for the 3.12 stream!
For the mac80211 bits, Johannes says:
"Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
probing on VLANs."
And also:
"This time I have two fixes from Emmanuel for RF-kill issues, and fixed
two issues
Signed-off-by: Geert Uytterhoeven
---
v2:
- KEXEC depends on M68KCLASSIC,
- Fix handling of virtual and physical addresses, for machines where
memory doesn't start at zero,
- Support for other CPUs than 68040.
arch/m68k/Kconfig | 17
On 10/15/2013 01:39 PM, Chang wrote:
On 10/15/2013 07:25 PM, Vlad Yasevich wrote:
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142
---
1 file changed, 68 insertions(+), 74
Add optional support to export the bootinfo used to boot the kernel in a
"bootinfo" file in procfs. This is useful with kexec.
This is based on the similar feature for ATAGS on ARM.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/Kconfig|7
This is a set of patches to add kexec support for m68k to the Linux kernel.
- Kexec only, no kdump support yet (do you have enough RAM to keep a
crashdump kernel in memory at all times? ;-)
- Tested on ARAnyM, with emulated 68040.
I tested the behavior for machines where memory
On Mon, Oct 14, 2013 at 5:52 PM, Linus Torvalds
wrote:
> So get your act together, and push back on the people you are supposed
> to manage. Because this is *not* acceptable for post-rc5, and I'm
> giving this single warning. Next time, I'll just ignore the sh*t you
> send me.
>
> Comprende?
On 10/15/2013 08:52 AM, Peter De Schrijver wrote:
> This patchset introduces common infrastructure for clocks which exist in
>
>
> several Tegra SoCs. We also also move Tegra20, Tegra30 and Tegra114 to
> this
Print a list of pages to be copied if debugging is enabled.
Consecutive entries are merged to reduce screen clutter.
Signed-off-by: Geert Uytterhoeven
Cc: Eric Biederman
---
kernel/kexec.c | 76
1 file changed, 76 insertions(+)
diff
On Tue, Oct 15, 2013 at 11:00:53PM +0530, Naveen N. Rao wrote:
> I thought the primary problem was the conflict with edac core itself.
> So, if I'm not mistaken, we would have to prevent all edac drivers
> from loading.
That too - I don't see the need for them if the firmware does the
decoding.
Currently, at each call of setns system call a new nsproxy is allocated,
the old nsproxy namespaces are copied into the new one and the old nsproxy
is freed if the task was the only one to use it.
It can creates large delays on hardware with large number of cpus since
to free a nsproxy a
On Tue, Oct 15, 2013 at 12:41:23PM +1100, Dave Chinner wrote:
> On Mon, Oct 14, 2013 at 05:42:50PM -0400, Johannes Weiner wrote:
> > Hi Dave,
> >
> > On Fri, Oct 11, 2013 at 11:39:30AM +1100, Dave Chinner wrote:
> > > On Thu, Oct 10, 2013 at 05:46:54PM -0400, Johannes Weiner wrote:
> > > >
On Mon, Oct 14, 2013 at 6:19 PM, Maximilian Güntner
wrote:
> The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
> levels of brightness)
> This driver supports configuration using platform_data.
>
> Signed-off-by: Maximilian Güntner
> ---
>
> v2:
>addresses Bryan Wu's
On 10/15/2013 07:25 PM, Vlad Yasevich wrote:
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142
---
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git
On Tue, 15 Oct 2013, Toshi Kani wrote:
> vmstat_cpuup_callback() is a CPU notifier callback, which
> marks N_CPU to a node at CPU online event. However, it
> does not update this N_CPU info at CPU offline event.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line
On Mon, Oct 14, 2013 at 05:09:17PM +0800, Hong Zhiguo wrote:
[..]
Hi Hong,
Thanks for the token based throttling implementation. In general it looks
good and it simplies the logic. Couple of comments/concerns below.
> @@ -133,14 +135,13 @@ struct throtl_grp {
> /* IOPS limits */
>
On 10/14/2013 11:50 PM, Ingo Molnar wrote:
>
> So if anyone can implement it using huge pages, with a really fast __va()
> and __pa() implementation, then it might be possible. But that's a pretty
> major surgery on x86.
>
Well, we already *have* a way to deal with that for Xen (by inserting
On 10/15/2013 10:30 PM, Borislav Petkov wrote:
On Tue, Oct 15, 2013 at 10:24:35PM +0530, Naveen N. Rao wrote:
On 2013/10/11 02:32AM, Chen Gong wrote:
Use trace interface to elaborate all H/W error related
information.
Signed-off-by: Chen, Gong
---
+TRACE_EVENT(extlog_mem_event,
+
On Tue, 2013-10-15 at 14:29 +, Kelleter, Günther wrote:
> Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
[]
> Wrong length calculation leads to rejection of CALL ACCEPT packets.
[]
> diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
[]
> @@ -98,7 +98,7 @@ int
On Tue, 2013-10-15 at 17:22 +, Christoph Lameter wrote:
> On Tue, 15 Oct 2013, Toshi Kani wrote:
>
> > Changed setup_vmstat() to mark N_CPU to the nodes with
> > online CPUs at boot, which is consistent with other
> > operations in vmstat_cpuup_callback(), i.e. start_cpu_timer()
> > and
Yes, I can try. The code is pretty much similar with some minor difference.
One thing I can do is to move the spin lock part (together with the
corresponding err handling into a common function.
The only problem I can see right now is we need the following
additional line for shm:
On 2013/10/11 02:32AM, Chen Gong wrote:
> In latest UEFI spec(by now it is 2.4) memory error definition
> for CPER (UEFI 2.4 Appendix N Common Platform Error Record)
> adds some new fields. These fields help people to locate
> memory error on actual DIMM location.
>
> Original-author: Tony Luck
On 10/15/2013 12:59 PM, Chang Xiangzhong wrote:
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142 ---
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 94df758..f10d848
On Tue, 15 Oct 2013, Toshi Kani wrote:
> Changed setup_vmstat() to mark N_CPU to the nodes with
> online CPUs at boot, which is consistent with other
> operations in vmstat_cpuup_callback(), i.e. start_cpu_timer()
> and refresh_zone_stat_thresholds().
Acked-by: Christoph Lameter
--
To
On Tue, Oct 15, 2013 at 9:03 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> On Mon, Oct 14, 2013 at 11:04 PM, Ingo Molnar wrote:
>> >
>> > * Kees Cook wrote:
>> >
>> >> On Mon, Oct 14, 2013 at 9:28 AM, H. Peter Anvin wrote:
>> >> > On 10/14/2013 07:19 AM, H. Peter Anvin wrote:
>> >> >> My
On 10/15/2013 04:07 AM, Russell King - ARM Linux wrote:
On Fri, Oct 11, 2013 at 02:45:34PM -0700, Alexandre Courbot wrote:
Trusted Foundations is a TrustZone-based secure monitor for ARM that
can be invoked using the same SMC-based API on all supported
platforms. This patch adds initial basic
On Tue, 15 Oct 2013, Krzysztof Kozlowski wrote:
> On Tue, 2013-10-15 at 02:59 -0700, Hugh Dickins wrote:
> > On Mon, 14 Oct 2013, Krzysztof Kozlowski wrote:
> >
> > > Fix race between swapoff and swapon resulting in setting blocksize of
> > > PAGE_SIZE for block devices during swapoff.
> > >
> >
On Tue, Oct 15, 2013 at 01:14:47PM -0400, Benjamin LaHaise wrote:
> > While I agree that getting that would be useful it is something that has
> > nothing to do with issueing aio from kernel space and holding this
> > patchset hostage for something you'd like to see but that was
> > complicated
vmstat_cpuup_callback() is a CPU notifier callback, which
marks N_CPU to a node at CPU online event. However, it
does not update this N_CPU info at CPU offline event.
Changed vmstat_cpuup_callback() to clear N_CPU when the last
CPU in the node is put into offline, i.e. the node no longer
has any
After a system booted, N_CPU is not set to any node as
has_cpu shows an empty line.
# cat /sys/devices/system/node/has_cpu
(show-empty-line)
setup_vmstat() registers its CPU notifier callback,
vmstat_cpuup_callback(), which marks N_CPU to a node when
a CPU is put into online. However,
node_stats[N_CPU] tracks which nodes have CPUs on the system.
vmstat.c updates this N_CPU information, but it has multiple
issues.
Patch 1/2 changes setup_vmstat() to set up the N_CPU info at
boot. Patch 2/2 changes vmstat_cpuup_callback() to udpate
the N_CPU info at CPU offline.
---
Toshi
+ LKML
On Sun, Oct 13, 2013 at 2:05 PM, Ezequiel Garcia
wrote:
> This patch moves the char and block major number definitions
> to major.h to be with the rest of the major numbers.
> While doing this, include major.h in the files that need it.
The patch looks good to me. It touches a common
On Tue, Oct 15, 2013 at 09:55:20AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 14, 2013 at 05:29:10PM -0400, Benjamin LaHaise wrote:
> > On Mon, Oct 14, 2013 at 08:07:01AM -0700, Christoph Hellwig wrote:
> > > Ben,
> > >
> > > are you fine with the series now? It's been in linux-next for a
On 10/15/2013 05:10 AM, Jisheng Zhang wrote:
Hi Sebastian,
On Mon, 14 Oct 2013 16:09:07 -0700
Sebastian Hesselbarth wrote:
On 10/08/2013 02:24 PM, Sebastian Hesselbarth wrote:
This adds known facts and rumors about the Marvell Berlin (88DE3xxx) SoC
family to the Marvell SoC documentation.
Apologies looks like I was on an earlier RC there and the users
that did this have been removed. I assume this patch can be
ignored sorry for the noise.
Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Mon, Oct 14, 2013 at 06:31:13PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 14, 2013 at 06:15:41PM +0100, Morten Rasmussen wrote:
> > > In fact, I don't see anything except a random bunch of hooks without an
> > > over-all picture of how to get less power used.
> >
> > I will follow up with a
On Tue, 15 Oct 2013, Vishal Annapurve wrote:
> Hi Alan,
>
> This issue seems more related to the devices using SCSI protocol and the
> changes otherwise will be at more places giving the same end result.
>
> I think as the comment says over the command_abort function,
> intentional result
On Tue, Oct 15, 2013 at 10:24:35PM +0530, Naveen N. Rao wrote:
> On 2013/10/11 02:32AM, Chen Gong wrote:
> > Use trace interface to elaborate all H/W error related
> > information.
> >
> > Signed-off-by: Chen, Gong
> > ---
>
> > +TRACE_EVENT(extlog_mem_event,
> > + TP_PROTO(u32 etype,
> > +
Currently, i2c1 and i2c5 defer probe due to pinctrl dependencies.
This changes the i2c ID each bus is registered with in i2c-dev
interface.
As a result of this, many userspace tools break and there is no
consistent manner to fix the same if the i2c dev interface have no
consistent numbering.
Signed-off-by: Xiangzhong Chang
---
net/sctp/outqueue.c | 142 ---
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 94df758..f10d848 100644
--- a/net/sctp/outqueue.c
+++
On Tue, Oct 15, 2013 at 09:49:06AM -0700, Tony Luck wrote:
> On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches wrote:
> > No guarantees are made about dmesg output.
>
> I'm with Joe here. Current users that parse dmesg have grumbled a bit
> that format changes - but they know that's the way life is.
On Mon, Oct 14, 2013 at 05:29:10PM -0400, Benjamin LaHaise wrote:
> On Mon, Oct 14, 2013 at 08:07:01AM -0700, Christoph Hellwig wrote:
> > Ben,
> >
> > are you fine with the series now? It's been in linux-next for a while
> > and it would be really helpful to get it in for the avarious places
>
On 2013/10/11 02:32AM, Chen Gong wrote:
> Use trace interface to elaborate all H/W error related
> information.
>
> Signed-off-by: Chen, Gong
> ---
> +TRACE_EVENT(extlog_mem_event,
> + TP_PROTO(u32 etype,
> + char *dimm_loc,
> + const uuid_le *fru_id,
> +
leroy christophe wrote on 2013/10/15 18:27:00:
>
>
> Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
> > "Linuxppc-dev"
> >
> > wrote on 2013/10/11 14:56:40:
> >> Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of
memory
> > at
> >> bootup instead of 8. It is needed for "big"
On 10/11/2013 01:57 PM, Andrew Morton wrote:
>
> I'm sure this was intended instead ;) The patch doesn't seem to make
> any difference in code generation with my gcc.
>
Which is odd, because doesn't unlikely() booleanize?
-hpa
--
To unsubscribe from this list: send the line
On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches wrote:
> No guarantees are made about dmesg output.
I'm with Joe here. Current users that parse dmesg have grumbled a bit
that format changes - but they know that's the way life is. Perhaps they'll
be too busy cheering about the TRACE formats that
I am announcing the release of the Linux 3.8.13.11 kernel.
The updated 3.8.y tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.8.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.8.y;a=shortlog
The diff from v3.8.13.10 is
On Tue, 2013-10-15 at 16:19 +0800, Libin wrote:
> From: Li Bin
>
> small codingstyle fix: '*' should be adjacent to the data name.
There are *tons* of these, go crazy.
>
> Signed-off-by: Li Bin
> ---
> ipc/sem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Tue, 2013-10-15 at 14:29 +0200, Borislav Petkov wrote:
> Once we exposed it to userspace, we cannot simply assume
> that nothing is using it.
Yes, we can.
No guarantees are made about dmesg output.
If guarantees were made, no typo could ever be fixed
nor could any conversion from printk to
BTW, please do not send out HTML email, as that gets blocked from going
to LKML.
On Tue, 15 Oct 2013 02:01:04 +
"Liu, Chuansheng" wrote:
> We meet one issue that during trigger all CPU backtrace, but during in the
> NMI handler arch_trigger_all_cpu_backtrace_handler,
> It hit the PAGE
On Tue, Oct 15, 2013 at 06:06:46PM +0200, Ingo Molnar wrote:
>
> splice() is very fast and should be able to process a lot of pages in one
> go, so the feedback loop should be pretty weak. mmap() triggers kernel
> code as well, every time we run out of the 64 MB window we got to remap
> it,
Thanks Andreas for the patch,
On Saturday 05 October 2013 04:47 PM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard
On Tue, 2013-10-15 at 19:44 +0800, Kefeng Wang wrote:
> Wrapper functions net_ratelimited_function() and net_XXX_ratelimited()
> are called to simplify code.
[]
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
[]
> @@ -465,10 +465,8 @@ void br_fdb_update(struct net_bridge *br, struct
>
Hi Alan,
This issue seems more related to the devices using SCSI protocol and the
changes otherwise will be at more places giving the same end result.
I think as the comment says over the command_abort function,
intentional result change should only happen in case of timeout.
Regards,
Vishal
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
"Linuxppc-dev"
wrote on 2013/10/11 14:56:40:
Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory
at
bootup instead of 8. It is needed for "big" kernels for instance when
activating
CONFIG_LOCKDEP_SUPPORT. This needs to
On Tue, Oct 15, 2013 at 05:07:36PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 15, 2013 at 04:32:27PM +0200, Peter Zijlstra wrote:
> >
> > This one seems to actually work and is somewhat simpler.
>
> And here's some hackery to avoid that atomic page inc frobbery.
Hmm, for some reason, I did not
On Tue, 2013-10-15 at 09:41 +0200, Ingo Molnar wrote:
> * Joe Perches wrote:
>
> > On Mon, 2013-10-14 at 15:44 -0700, Eric Dumazet wrote:
> > > On Mon, 2013-10-14 at 15:37 -0700, Joe Perches wrote:
> > > > On Mon, 2013-10-14 at 15:18 -0700, Eric Dumazet wrote:
> > > > > attached patch brings
On Tue, Oct 15 2013, Hong zhi guo wrote:
> Hi, Tejun,
>
> I did the test for 3 levels hierarchy. It works.
>
> Preparation
>
> 1) mount subsys blkio with "__DEVEL__sane_behavior"
> 2) Create 3 levels of directories under the blkio mount point:
> mkdir 1
> mkdir 1/2
>
This unified patch removes the following commits
for both kernel and perf tool:
6adb0b0 perf tools: Add default handler for mmap2 events
384c671 perf trace: Add mmap2 handler
5c5e854 perf tools: Add attr->mmap2 support
d008d52 perf: Fix up MMAP2 buffer space reservation
13d7a24 perf: Add
On Tue, Oct 15, 2013 at 08:55:20AM -0700, Dan Williams wrote:
> On Tue, Oct 15, 2013 at 11:31 AM, Youquan Song
> wrote:
> > On Sun, Oct 13, 2013 at 08:56:33PM +0530, Vinod Koul wrote:
> >> On Fri, Oct 11, 2013 at 06:33:43AM -0700, Greg KH wrote:
> >> > On Fri, Oct 11, 2013 at 05:42:17PM -0400,
On 10/15/13 10:06 AM, Ingo Molnar wrote:
splice() is very fast and should be able to process a lot of pages in one
go, so the feedback loop should be pretty weak. mmap() triggers kernel
code as well, every time we run out of the 64 MB window we got to remap
it, right?
Yes, 1 mmap, 1 munmap
On Tue, Oct 15, 2013 at 2:28 AM, Borislav Petkov wrote:
> We can even add a hint for the user like:
>
> "Above errors have been corrected by the hardware and require no
> further action."
>
> Btw, this is valid for both dmesg and trace event output.
>
> Because from my experience so far
On Thu, Oct 10, 2013 at 04:48:19PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> d_tmpfile() already swallowed the inode ref.
>
> Signed-off-by: Miklos Szeredi
> Cc: sta...@vger.kernel.org
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 10/15/2013 05:07 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 11, 2013 at 02:45:34PM -0700, Alexandre Courbot wrote:
>> Trusted Foundations is a TrustZone-based secure monitor for ARM that
>> can be invoked using the same SMC-based API on all supported
>> platforms. This patch adds initial
:) I'm very happy you got it working.
The firmware of our device seems so fragile still - and several QMI calls can
bring it to a crashing state, especially when asking a network scan to the NAS
service.
On Tue, 15 Oct 2013, Dan Williams wrote:
==Date: Tue, 15 Oct 2013 09:49:57 -0500
==From:
* David Ahern wrote:
> On 10/15/13 9:27 AM, Ingo Molnar wrote:
> >
> >* Peter Zijlstra wrote:
> >
> >>On Tue, Oct 15, 2013 at 11:32:45AM -0300, Arnaldo Carvalho de Melo wrote:
> >>
> >>>Jiri and PeterZ probaby will have comments here... ;-) :-)
> >>
> >>The only complication with splice is the
* Stephane Eranian wrote:
> On Tue, Oct 15, 2013 at 3:34 PM, Ingo Molnar wrote:
> >
> > * Stephane Eranian wrote:
> >
> >> On Tue, Oct 15, 2013 at 3:12 PM, Ingo Molnar wrote:
> >> >
> >> > * Stephane Eranian wrote:
> >> >
> >> >> Arnaldo,
> >> >>
> >> >> Could you revert all the mmap2
* Kees Cook wrote:
> On Mon, Oct 14, 2013 at 11:04 PM, Ingo Molnar wrote:
> >
> > * Kees Cook wrote:
> >
> >> On Mon, Oct 14, 2013 at 9:28 AM, H. Peter Anvin wrote:
> >> > On 10/14/2013 07:19 AM, H. Peter Anvin wrote:
> >> >> My guess is that the 95 addresses are randomized and the 82
> I get the csum_partial() if disabling prequeue.
At least in the ipoib case i would consider that a misconfiguration.
"don't do this if it hurts"
There may be more such problems.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Oct 15, 2013 at 05:48:27PM +0300, Kirill A. Shutemov wrote:
> Andrea Arcangeli wrote:
> > Hi Hugh,
> >
> > On Tue, Oct 15, 2013 at 04:08:28AM -0700, Hugh Dickins wrote:
> > > Occasionally we hit the BUG_ON(pmd_trans_huge(*pmd)) at the end of
> > > __split_huge_page_pmd(): seen when doing
301 - 400 of 1514 matches
Mail list logo
