Re: [PATCH -next] unicore32: Fix build error

> Since the oldabi syscall interface was first introduced, the > infrastructure > changed and the patch no longer compiles. See commit f56141e3e2d9a ("all > arches, signal: move restart_block to struct task_struct") for details. > > Fixes: 1ace5d1e3d4b4 ("unicore32-oldabi: add oldabi syscall

Re: [PATCH -next] unicore32: Fix build error

> Since the oldabi syscall interface was first introduced, the > infrastructure > changed and the patch no longer compiles. See commit f56141e3e2d9a ("all > arches, signal: move restart_block to struct task_struct") for details. > > Fixes: 1ace5d1e3d4b4 ("unicore32-oldabi: add oldabi syscall

[PATCH v2 4/5] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to

[PATCH v2 4/5] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to

[no subject]

From: Nicolas Pitre Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP

[PATCH v2 2/5] kconfig: introduce the "suggest" keyword

Similar to "imply" but with no added restrictions on the target symbol's value. Useful for providing a default value to another symbol. Suggested by Edward Cree. Signed-off-by: Nicolas Pitre --- Documentation/kbuild/kconfig-language.txt | 6 ++ scripts/kconfig/expr.h

[no subject]

From: Nicolas Pitre Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP clock subsystem should be

[PATCH v2 2/5] kconfig: introduce the "suggest" keyword

Similar to "imply" but with no added restrictions on the target symbol's value. Useful for providing a default value to another symbol. Suggested by Edward Cree. Signed-off-by: Nicolas Pitre --- Documentation/kbuild/kconfig-language.txt | 6 ++ scripts/kconfig/expr.h|

[PATCH v2] staging: vc04_services: Replace dmac_map_area with dmac_map_sg

The original arm implementation uses dmac_map_area which is not portable. Replace it with an architecture neutral version which uses dma_map_sg. As you can see that for larger page sizes, the dma_map_sg implementation is faster then the original unportable dma_map_area implementation. Test

[PATCH v2] staging: vc04_services: Replace dmac_map_area with dmac_map_sg

The original arm implementation uses dmac_map_area which is not portable. Replace it with an architecture neutral version which uses dma_map_sg. As you can see that for larger page sizes, the dma_map_sg implementation is faster then the original unportable dma_map_area implementation. Test

Re: [LKP] [lkp] [perf powerpc] 18d1796d0b: [No primary change]

Peter Zijlstra writes: > On Tue, Oct 25, 2016 at 02:40:13PM +0800, kernel test robot wrote: >> [will-it-scale] perf-stat.branch-miss-rate +7.4% regression >> Reply-To: kernel test robot >> User-Agent: Heirloom mailx 12.5 6/20/10 >> >> >> FYI, we

Re: [LKP] [lkp] [perf powerpc] 18d1796d0b: [No primary change]

Peter Zijlstra writes: > On Tue, Oct 25, 2016 at 02:40:13PM +0800, kernel test robot wrote: >> [will-it-scale] perf-stat.branch-miss-rate +7.4% regression >> Reply-To: kernel test robot >> User-Agent: Heirloom mailx 12.5 6/20/10 >> >> >> FYI, we noticed a +7.4% regression of

Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu

on 10/25/2016 06:09 PM, Marc Zyngier wrote: > On 15/10/16 08:23, Cheng Chao wrote: >> On 10/15/2016 01:33 AM, Marc Zyngier wrote: on 10/13/2016 11:31 PM, Marc Zyngier wrote: > On Thu, 13 Oct 2016 18:57:14 +0800 > Cheng Chao wrote: > >> GIC can

Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu

on 10/25/2016 06:09 PM, Marc Zyngier wrote: > On 15/10/16 08:23, Cheng Chao wrote: >> On 10/15/2016 01:33 AM, Marc Zyngier wrote: on 10/13/2016 11:31 PM, Marc Zyngier wrote: > On Thu, 13 Oct 2016 18:57:14 +0800 > Cheng Chao wrote: > >> GIC can distribute an interrupt to

[PATCH] include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When mutex_destroy is indirectly used by non-GPL kernel modules that use inline functions such as reservation_object_fini(), users can use a kernel with DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol mutex_destroy.

[PATCH] include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When mutex_destroy is indirectly used by non-GPL kernel modules that use inline functions such as reservation_object_fini(), users can use a kernel with DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol mutex_destroy.

[RFC] HID:hid-lg4ff: Delay to allow wheels to center after plug-in

A number of wheels (G27/etc) do a little full right/full left 'dance' when first plugged in. This patch inserts a delay so that this 'dance' is completed before we disable (set to zero) the autocenter spring. A side benefit is that the DFGT was confused without the delay, and is now correctly

[RFC] HID:hid-lg4ff: Delay to allow wheels to center after plug-in

A number of wheels (G27/etc) do a little full right/full left 'dance' when first plugged in. This patch inserts a delay so that this 'dance' is completed before we disable (set to zero) the autocenter spring. A side benefit is that the DFGT was confused without the delay, and is now correctly

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

Andrei Vagin writes: > On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote: >> That is certainly interesting. The problem is that the reason we were >> going slow is that there were in fact mounts that had not been traversed >> in the share group. > > You are

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

Andrei Vagin writes: > On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote: >> That is certainly interesting. The problem is that the reason we were >> going slow is that there were in fact mounts that had not been traversed >> in the share group. > > You are right. > >> >> And

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 6:33 PM, Linus Torvalds wrote: > > Completely untested. Maybe there's some reason we can't write to the > whole thing like that? That hack boots and seems to work for me, but doesn't show anything. Dave, mind just trying that oneliner?

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 6:33 PM, Linus Torvalds wrote: > > Completely untested. Maybe there's some reason we can't write to the > whole thing like that? That hack boots and seems to work for me, but doesn't show anything. Dave, mind just trying that oneliner? Linus

Re: taint/module: Clean up global and module taint flags handling

Jiri Kosina writes: > On Fri, 23 Sep 2016, Jessica Yu wrote: > >> Hm, quick question, which tree would this patch go to? Though the >> cleanup is for modules, there is an indirect cross-tree dependency >> (taint_flag.module needs to be true for TAINT_LIVEPATCH for Josh's >>

Re: taint/module: Clean up global and module taint flags handling

Jiri Kosina writes: > On Fri, 23 Sep 2016, Jessica Yu wrote: > >> Hm, quick question, which tree would this patch go to? Though the >> cleanup is for modules, there is an indirect cross-tree dependency >> (taint_flag.module needs to be true for TAINT_LIVEPATCH for Josh's >> patch to still work as

Re: [RFC PATCH 1/2] module: Ensure a module's state is set accordingly during module coming cleanup code

Aaron Tomlin writes: > In load_module() in the event of an error, for e.g. unknown module > parameter(s) specified we go to perform some module coming clean up > operations. At this point the module is still in a "formed" state > when it is actually going away. > > This patch

Re: [RFC PATCH 1/2] module: Ensure a module's state is set accordingly during module coming cleanup code

Aaron Tomlin writes: > In load_module() in the event of an error, for e.g. unknown module > parameter(s) specified we go to perform some module coming clean up > operations. At this point the module is still in a "formed" state > when it is actually going away. > > This patch updates the module's

Re: [RFC PATCH 2/2] module: When modifying a module's text ignore modules which are going away too

Aaron Tomlin writes: > By default, during the access permission modification of a module's core > and init pages, we only ignore modules that are malformed. There is no > reason not to extend this to modules which are going away too. Well, it depends on all the callers (ie.

Re: [RFC PATCH 2/2] module: When modifying a module's text ignore modules which are going away too

Aaron Tomlin writes: > By default, during the access permission modification of a module's core > and init pages, we only ignore modules that are malformed. There is no > reason not to extend this to modules which are going away too. Well, it depends on all the callers (ie. ftrace): is that also

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 5:27 PM, Dave Jones wrote: > > DaveC: Do these look like real problems, or is this more "looks like > random memory corruption" ? It's been a while since I did some stress > testing on XFS, so these might not be new.. Andy, do you think we could

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 5:27 PM, Dave Jones wrote: > > DaveC: Do these look like real problems, or is this more "looks like > random memory corruption" ? It's been a while since I did some stress > testing on XFS, so these might not be new.. Andy, do you think we could just do some poisoning of

Re: [RFC PATCH] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Wed, Sep 21, 2016 at 2:22 PM, Bjorn Helgaas wrote: > On Mon, Sep 19, 2016 at 06:07:37PM -0700, Duc Dang wrote: >> On Mon, Sep 19, 2016 at 1:06 PM, Bjorn Helgaas wrote: >> > On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote: > >> This patch only

Re: [RFC PATCH] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Wed, Sep 21, 2016 at 2:22 PM, Bjorn Helgaas wrote: > On Mon, Sep 19, 2016 at 06:07:37PM -0700, Duc Dang wrote: >> On Mon, Sep 19, 2016 at 1:06 PM, Bjorn Helgaas wrote: >> > On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote: > >> This patch only adds the ability for X-Gene PCIe

[RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

PCIe controllers in X-Gene SoCs is not ECAM compliant: software needs to configure additional controller's register to address device at bus:dev:function. This patch depends on "ECAM quirks handling for ARM64 platforms" series (http://www.spinics.net/lists/arm-kernel/msg530692.html, the series

[RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

PCIe controllers in X-Gene SoCs is not ECAM compliant: software needs to configure additional controller's register to address device at bus:dev:function. This patch depends on "ECAM quirks handling for ARM64 platforms" series (http://www.spinics.net/lists/arm-kernel/msg530692.html, the series

[PATCH 4/7] powerpc/vdso: introduce init_vdso{32,64}_pagelist

Common code with allocation/initialization of vDSO's pagelist. Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc:

[PATCH 4/7] powerpc/vdso: introduce init_vdso{32,64}_pagelist

Common code with allocation/initialization of vDSO's pagelist. Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc: linuxppc-...@lists.ozlabs.org Cc: linux...@kvack.org Signed-off-by: Dmitry Safonov ---

Re: [PATCH v8 0/8] power: add power sequence library

On Tue, Oct 18, 2016 at 02:35:38AM +0200, Rafael J. Wysocki wrote: > On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote: > > On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote: > > > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote: > > > > Hi all, > > > > > > > >

Re: [PATCH v8 0/8] power: add power sequence library

On Tue, Oct 18, 2016 at 02:35:38AM +0200, Rafael J. Wysocki wrote: > On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote: > > On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote: > > > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote: > > > > Hi all, > > > > > > > >

[PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fixed typo in commit text * Fixed potential NULL deref drivers/devfreq/devfreq.c | 9 +++-- 1 file

[PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fixed typo in commit text * Fixed potential NULL deref drivers/devfreq/devfreq.c | 9 +++-- 1 file changed, 7 insertions(+), 2

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

If I change it to, for example: removed iterations: 20% Is that OK? Thanks Jin Yao On 10/26/2016 9:19 AM, Andi Kleen wrote: | | | |--29.93%--main div.c:39 (predicted:50.6%, cycles:1, removed loops:12954) Removed loops should be divided by

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

If I change it to, for example: removed iterations: 20% Is that OK? Thanks Jin Yao On 10/26/2016 9:19 AM, Andi Kleen wrote: | | | |--29.93%--main div.c:39 (predicted:50.6%, cycles:1, removed loops:12954) Removed loops should be divided by

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

>| | >| |--29.93%--main div.c:39 (predicted:50.6%, > cycles:1, removed loops:12954) Removed loops should be divided by the number of samples to normalize it. Also I would call it "iterations" -Andi

Re: [PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

>| | >| |--29.93%--main div.c:39 (predicted:50.6%, > cycles:1, removed loops:12954) Removed loops should be divided by the number of samples to normalize it. Also I would call it "iterations" -Andi

[PATCH v3 4/6] perf report: Show branch info in callchain entry for stdio mode

If the branch is 100% predicated then the "predicated" is hide. Similarly, if there is no branch tsx abort, the "abort" is hide. There is only cycles shown (cycle is supported on skylake platform, older platform would be 0). If no removed loops, the "removed loops" is hide. One example is:

[PATCH v3 4/6] perf report: Show branch info in callchain entry for stdio mode

If the branch is 100% predicated then the "predicated" is hide. Similarly, if there is no branch tsx abort, the "abort" is hide. There is only cycles shown (cycle is supported on skylake platform, older platform would be 0). If no removed loops, the "removed loops" is hide. One example is:

[PATCH v3 3/6] perf report: Create a symbol_conf flag for showing branch flag counting

Create a new flag show_branchflag_count in symbol_conf. The flag is used to control if showing the branch flag counting information. The flag depends on if the perf.data has branch data and if user chooses the "branch-history" option in perf report command line. Signed-off-by: Jin Yao

[PATCH v3 3/6] perf report: Create a symbol_conf flag for showing branch flag counting

Create a new flag show_branchflag_count in symbol_conf. The flag is used to control if showing the branch flag counting information. The flag depends on if the perf.data has branch data and if user chooses the "branch-history" option in perf report command line. Signed-off-by: Jin Yao ---

[PATCH v3 6/6] perf report: Display columns Predicted/Abort/Cycles in --branch-history

Use current sort mechanism but the real .se_cmp() just returns 0 so that new columns "Predicted", "Abort" and "Cycles" are created in display but actually these keys are not the sort keys. For example: Overhead Source:Line SymbolShared Object Predicted Abort Cycles

[PATCH v3 1/6] perf report: Add branch flag to callchain cursor node

Since the branch ip has been added to call stack for easier browsing, this patch adds more branch information. For example, add a flag to indicate if this ip is a branch, and also add with the branch flag. Then we can know if the cursor node represents a branch and know what the branch flag it

[PATCH v3 6/6] perf report: Display columns Predicted/Abort/Cycles in --branch-history

Use current sort mechanism but the real .se_cmp() just returns 0 so that new columns "Predicted", "Abort" and "Cycles" are created in display but actually these keys are not the sort keys. For example: Overhead Source:Line SymbolShared Object Predicted Abort Cycles

[PATCH v3 1/6] perf report: Add branch flag to callchain cursor node

Since the branch ip has been added to call stack for easier browsing, this patch adds more branch information. For example, add a flag to indicate if this ip is a branch, and also add with the branch flag. Then we can know if the cursor node represents a branch and know what the branch flag it

[PATCH v3 5/6] perf report: Show branch info in callchain entry for browser mode

If the branch is 100% predicated then the "predicated" is hide. Similarly, if there is no branch tsx abort, the "abort" is hide. There is only cycles shown (cycle is supported on skylake platform, older platform would be 0). If no removed loops, the "removed loops" is hide. Signed-off-by: Jin

[PATCH v3 5/6] perf report: Show branch info in callchain entry for browser mode

If the branch is 100% predicated then the "predicated" is hide. Similarly, if there is no branch tsx abort, the "abort" is hide. There is only cycles shown (cycle is supported on skylake platform, older platform would be 0). If no removed loops, the "removed loops" is hide. Signed-off-by: Jin

[PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

v3: 1. Display the count for tsx abort, remove the abort percentage. 2. Since the branch history code has a loop detection that removes small loops in util/machine.c:remove_loops(). It would be nice to note how many loops were removed. So it adds the note on some

[PATCH v3 2/6] perf report: Caculate and return the branch flag counting

Create some branch counters in per callchain list entry. Each counter is for a branch flag. For example, predicted_count counts all the *predicted* branches. The counters get updated by processing the callchain cursor nodes. It also provides functions to retrieve or print the values of counters

[PATCH v3 2/6] perf report: Caculate and return the branch flag counting

Create some branch counters in per callchain list entry. Each counter is for a branch flag. For example, predicted_count counts all the *predicted* branches. The counters get updated by processing the callchain cursor nodes. It also provides functions to retrieve or print the values of counters

[PATCH v3 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view

v3: 1. Display the count for tsx abort, remove the abort percentage. 2. Since the branch history code has a loop detection that removes small loops in util/machine.c:remove_loops(). It would be nice to note how many loops were removed. So it adds the note on some

Re: linux-next: Tree for Oct 25

On Mon, Oct 24, 2016 at 11:31 PM, Stephen Rothwell wrote: > Hi all, > > There will probably be no linux-next releases next week while I attend > the Kernel Summit. > > Changes since 20161024: > > The pm tree gained a conflict against the imx-mxs tree. > > The mali-dp tree

Re: linux-next: Tree for Oct 25

On Mon, Oct 24, 2016 at 11:31 PM, Stephen Rothwell wrote: > Hi all, > > There will probably be no linux-next releases next week while I attend > the Kernel Summit. > > Changes since 20161024: > > The pm tree gained a conflict against the imx-mxs tree. > > The mali-dp tree gained a conflict

Re: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes

On Tue, Oct 25, 2016 at 7:20 AM, Lv Zheng wrote: > This patchset improves ACPICA intepreter lock order fixes. Including > several urgent regression fixes [PATCH 0-3]. OK, thanks! So patches [4-6/6] appear to be cleanups and I'd prefer them to be applied in a usual way (ie.

Re: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes

On Tue, Oct 25, 2016 at 7:20 AM, Lv Zheng wrote: > This patchset improves ACPICA intepreter lock order fixes. Including > several urgent regression fixes [PATCH 0-3]. OK, thanks! So patches [4-6/6] appear to be cleanups and I'd prefer them to be applied in a usual way (ie. via the upstream

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote: I still believe we need your changes, I was wondering if we've tested it against normal memory nodes and checked if any memblock allocations end up there. Michael showed me some memblock allocations on node 1 of a two node machine

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote: I still believe we need your changes, I was wondering if we've tested it against normal memory nodes and checked if any memblock allocations end up there. Michael showed me some memblock allocations on node 1 of a two node machine

Re: [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

Ard Biesheuvel writes: > The symbol CRCs are emitted as ELF symbols, which allows us to easily > populate the kcrctab sections by relying on the linker to associate > each kcrctab slot with the correct value. > > This has two downsides: > - given that the CRCs are

Re: [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

Ard Biesheuvel writes: > The symbol CRCs are emitted as ELF symbols, which allows us to easily > populate the kcrctab sections by relying on the linker to associate > each kcrctab slot with the correct value. > > This has two downsides: > - given that the CRCs are treated as pointers, we waste 4

Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

AKASHI Takahiro writes: > On Thu, Oct 20, 2016 at 01:48:15PM -0700, Kees Cook wrote: >> On Wed, Oct 19, 2016 at 11:24 PM, AKASHI Takahiro >> wrote: >> > The current "rodata=off" parameter disables read-only kernel mappings >> > under

Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

AKASHI Takahiro writes: > On Thu, Oct 20, 2016 at 01:48:15PM -0700, Kees Cook wrote: >> On Wed, Oct 19, 2016 at 11:24 PM, AKASHI Takahiro >> wrote: >> > The current "rodata=off" parameter disables read-only kernel mappings >> > under CONFIG_DEBUG_RODATA: >> > commit d2aa1acad22f ("mm/init:

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

On Sat, Oct 22, 2016 at 02:42:03PM -0500, Eric W. Biederman wrote: > > Andrei, > > This fixes the issue you have reported and through a refactoring > makes the code simpler and easier to verify. That said I find your > last test case very interesting. While looking at it in detail > I have

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

On Sat, Oct 22, 2016 at 02:42:03PM -0500, Eric W. Biederman wrote: > > Andrei, > > This fixes the issue you have reported and through a refactoring > makes the code simpler and easier to verify. That said I find your > last test case very interesting. While looking at it in detail > I have

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 09:42:39AM -0400, Chris Mason wrote: > > > Well crud, we're back to wondering if this is Btrfs or the stack > > > corruption. Since the pagevecs are on the stack and this is a new > > > crash, my guess is you'll be able to trigger it on xfs/ext4 too. But we > > >

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 09:42:39AM -0400, Chris Mason wrote: > > > Well crud, we're back to wondering if this is Btrfs or the stack > > > corruption. Since the pagevecs are on the stack and this is a new > > > crash, my guess is you'll be able to trigger it on xfs/ext4 too. But we > > >

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

On Tue, Oct 11, 2016 at 02:28:39AM -0700, Krister Johansen wrote: > If dso__load_kcore frees all of the existing maps, but one has already > been attached to a callchain cursor node, then we can get a SIGSEGV in > any function that happens to try to use this invalid cursor. Use the > existing map

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

On Tue, Oct 11, 2016 at 02:28:39AM -0700, Krister Johansen wrote: > If dso__load_kcore frees all of the existing maps, but one has already > been attached to a callchain cursor node, then we can get a SIGSEGV in > any function that happens to try to use this invalid cursor. Use the > existing map

Re: [PATCH v4 3/3] Make core_pattern support namespace

On Tue, Oct 25, 2016 at 03:28:56PM +0800, Cao Shufeng wrote: > From: Zhao Lei > It will bring us following benefit: > 1: Each container can change their own coredump setting >based on operation on /proc/sys/kernel/core_pattern > 2: Coredump setting changed in host will

Re: [PATCH v4 3/3] Make core_pattern support namespace

On Tue, Oct 25, 2016 at 03:28:56PM +0800, Cao Shufeng wrote: > From: Zhao Lei > It will bring us following benefit: > 1: Each container can change their own coredump setting >based on operation on /proc/sys/kernel/core_pattern > 2: Coredump setting changed in host will not affect >running

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

On Wed, 2016-10-26 at 01:57 +0200, Abdelrhman Ahmed wrote: > > What is the issue you want to fix exactly ? > > Please describe the use case. > > When netfilter hook uses skb_push to add a specific header between network > header and hardware header. > For the first time(s) before caching

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

On Wed, 2016-10-26 at 01:57 +0200, Abdelrhman Ahmed wrote: > > What is the issue you want to fix exactly ? > > Please describe the use case. > > When netfilter hook uses skb_push to add a specific header between network > header and hardware header. > For the first time(s) before caching

[PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to

[PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to

drivers/edac/amd64_edac.c:3012:1: warning: the frame size of 1100 bytes is larger than 1024 bytes

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions with __latent_entropy date: 2 weeks ago config: i386-randconfig-h1-10260742

drivers/edac/amd64_edac.c:3012:1: warning: the frame size of 1100 bytes is larger than 1024 bytes

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions with __latent_entropy date: 2 weeks ago config: i386-randconfig-h1-10260742

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote: > Andrei Vagin writes: > > > On Sat, Oct 22, 2016 at 02:42:03PM -0500, Eric W. Biederman wrote: > >> > >> Andrei, > >> > >> This fixes the issue you have reported and through a refactoring > >> makes the

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

> What is the issue you want to fix exactly ? > Please describe the use case. When netfilter hook uses skb_push to add a specific header between network header and hardware header. For the first time(s) before caching hardware header, this header will be removed / overwritten by hardware

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote: > Andrei Vagin writes: > > > On Sat, Oct 22, 2016 at 02:42:03PM -0500, Eric W. Biederman wrote: > >> > >> Andrei, > >> > >> This fixes the issue you have reported and through a refactoring > >> makes the code simpler and easier

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

> What is the issue you want to fix exactly ? > Please describe the use case. When netfilter hook uses skb_push to add a specific header between network header and hardware header. For the first time(s) before caching hardware header, this header will be removed / overwritten by hardware

[PATCH 1/2] perf, x86-mm: Add exit-fault tracing

Signed-off-by: Alexis Berlemont --- arch/x86/include/asm/trace/exceptions.h | 21 + arch/x86/mm/fault.c | 1 + 2 files changed, 22 insertions(+) diff --git a/arch/x86/include/asm/trace/exceptions.h

[PATCH 2/2] perf: add page fault duration measures in perf trace

Signed-off-by: Alexis Berlemont --- tools/perf/Documentation/perf-trace.txt | 4 +- tools/perf/builtin-trace.c | 225 2 files changed, 202 insertions(+), 27 deletions(-) diff --git

[PATCH 0/2] perf: measure page fault duration in perf trace

Hi, Here are 2 small patches which try to fulfill a point in the perf todo list: * Forward port the page fault tracepoints and use it in 'trace'.

[PATCH 1/2] perf, x86-mm: Add exit-fault tracing

Signed-off-by: Alexis Berlemont --- arch/x86/include/asm/trace/exceptions.h | 21 + arch/x86/mm/fault.c | 1 + 2 files changed, 22 insertions(+) diff --git a/arch/x86/include/asm/trace/exceptions.h b/arch/x86/include/asm/trace/exceptions.h index

[PATCH 2/2] perf: add page fault duration measures in perf trace

Signed-off-by: Alexis Berlemont --- tools/perf/Documentation/perf-trace.txt | 4 +- tools/perf/builtin-trace.c | 225 2 files changed, 202 insertions(+), 27 deletions(-) diff --git a/tools/perf/Documentation/perf-trace.txt

[PATCH 0/2] perf: measure page fault duration in perf trace

Hi, Here are 2 small patches which try to fulfill a point in the perf todo list: * Forward port the page fault tracepoints and use it in 'trace'.

[PATCH] ARM: mvebu: Update comment for main PLL frequency

The actual frequency was updated in commit ae142bd99765 ("ARM: mvebu: Fix the main PLL frequency on Armada 375, 38x and 39x SoCs") but the comment was not updated. Update it now. Signed-off-by: Chris Packham --- arch/arm/boot/dts/armada-375.dtsi | 2 +-

[PATCH] ARM: mvebu: Update comment for main PLL frequency

The actual frequency was updated in commit ae142bd99765 ("ARM: mvebu: Fix the main PLL frequency on Armada 375, 38x and 39x SoCs") but the comment was not updated. Update it now. Signed-off-by: Chris Packham --- arch/arm/boot/dts/armada-375.dtsi | 2 +- arch/arm/boot/dts/armada-38x.dtsi | 2 +-

[PULL] modules: begin maintainer transition

The following changes since commit 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942: Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2016-10-24 21:34:13 -0700) are available in the git repository at:

[PULL] modules: begin maintainer transition

The following changes since commit 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942: Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2016-10-24 21:34:13 -0700) are available in the git repository at:

Re: [PATCH] mm: remove unnecessary __get_user_pages_unlocked() calls

The holdout for unexporting __get_user_pages_unlocked() is its invocation in mm/process_vm_access.c: process_vm_rw_single_vec(), as this definitely _does_ seem to invoke VM_FAULT_RETRY behaviour which get_user_pages_remote() will not trigger if we were to replace it with the latter. I'm not sure

Re: [PATCH] mm: remove unnecessary __get_user_pages_unlocked() calls

The holdout for unexporting __get_user_pages_unlocked() is its invocation in mm/process_vm_access.c: process_vm_rw_single_vec(), as this definitely _does_ seem to invoke VM_FAULT_RETRY behaviour which get_user_pages_remote() will not trigger if we were to replace it with the latter. I'm not sure

[PATCH] mm: remove unnecessary __get_user_pages_unlocked() calls

In hva_to_pfn_slow() we are able to replace __get_user_pages_unlocked() with get_user_pages_unlocked() since we can now pass gup_flags. In async_pf_execute() we need to pass different tsk, mm arguments so get_user_pages_remote() is the sane replacement here (having added manual acquisition and

[PATCH] mm: remove unnecessary __get_user_pages_unlocked() calls

In hva_to_pfn_slow() we are able to replace __get_user_pages_unlocked() with get_user_pages_unlocked() since we can now pass gup_flags. In async_pf_execute() we need to pass different tsk, mm arguments so get_user_pages_remote() is the sane replacement here (having added manual acquisition and

<    1   2   3   4   5   6   7   8   9   10   >