Re: a racy access flag clearing warning when calling mmap system call

On Fri, Dec 08, 2017 at 11:19:52AM +0800, chenjiankang wrote: > 在 2017/12/7 21:23, Will Deacon 写道: > > diff --git a/arch/arm64/include/asm/pgtable.h > > b/arch/arm64/include/asm/pgtable.h > > index 149d05fb9421..8fe103b1e101 100644 > > --- a/arch/arm64/include/asm/pgtable.h > > +++

Re: [PATCH v2] kmemleak: add scheduling point to kmemleak_scan

[ 220.794758] do_syscall_64+0x61/0x1a0 > [ 220.798411] entry_SYSCALL64_slow_path+0x25/0x25 > > Fix this by adding cond_resched every MAX_SCAN_SIZE. > > Suggested-by: Catalin Marinas <catalin.mari...@arm.com> > Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH v2] kmemleak: add scheduling point to kmemleak_scan

[ 220.794758] do_syscall_64+0x61/0x1a0 > [ 220.798411] entry_SYSCALL64_slow_path+0x25/0x25 > > Fix this by adding cond_resched every MAX_SCAN_SIZE. > > Suggested-by: Catalin Marinas > Signed-off-by: Yisheng Xie Acked-by: Catalin Marinas

Re: [PATCH] kmemcheck: add scheduling point to kmemleak_scan

Please fix the subject as the tool is called "kmemleak" rather than "kmemcheck". On Fri, Nov 17, 2017 at 03:03:56PM +0800, Yisheng Xie wrote: > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index e4738d5..e9f2e86 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -1523,6 +1523,8 @@ static

Re: [PATCH] kmemcheck: add scheduling point to kmemleak_scan

Please fix the subject as the tool is called "kmemleak" rather than "kmemcheck". On Fri, Nov 17, 2017 at 03:03:56PM +0800, Yisheng Xie wrote: > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index e4738d5..e9f2e86 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -1523,6 +1523,8 @@ static

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

On Mon, Nov 13, 2017 at 07:05:12PM +, Ben Hutchings wrote: > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Mark Rutland > > > >

Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

On Mon, Nov 13, 2017 at 07:05:12PM +, Ben Hutchings wrote: > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Mark Rutland > > > > commit

Re: linux-next: manual merge of the arm64 tree with Linus' tree

Hi Stephen, On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote: > On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell > wrote: > > Today's linux-next merge of the arm64 tree got a conflict in: > > > > drivers/acpi/arm64/iort.c > > > > between commit: > >

Re: linux-next: manual merge of the arm64 tree with Linus' tree

Hi Stephen, On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote: > On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell > wrote: > > Today's linux-next merge of the arm64 tree got a conflict in: > > > > drivers/acpi/arm64/iort.c > > > > between commit: > > > > 37f6b42e9c29

Re: [PATCH] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On Wed, Nov 08, 2017 at 11:00:29AM -0800, Stephen Boyd wrote: > The Kryo CPUs are also affected by the Falkor 1003 errata, so > we need to do the same workaround on Kryo CPUs. The MIDR is > slightly more complicated here, where the PART number is not > always the same when looking at all the bits

Re: [PATCH] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On Wed, Nov 08, 2017 at 11:00:29AM -0800, Stephen Boyd wrote: > The Kryo CPUs are also affected by the Falkor 1003 errata, so > we need to do the same workaround on Kryo CPUs. The MIDR is > slightly more complicated here, where the PART number is not > always the same when looking at all the bits

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Mon, Nov 06, 2017 at 03:59:18PM +, Catalin Marinas wrote: > On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote: > > Versions of gcc prior to gcc 5 emitted a __multi3 function call when > > dealing with TI types, resulting in failures when trying to lin

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Mon, Nov 06, 2017 at 03:59:18PM +, Catalin Marinas wrote: > On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote: > > Versions of gcc prior to gcc 5 emitted a __multi3 function call when > > dealing with TI types, resulting in failures when trying to lin

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote: > Versions of gcc prior to gcc 5 emitted a __multi3 function call when > dealing with TI types, resulting in failures when trying to link to > libgcc, and more generally, bad performance. However, since gcc 5, > the compiler

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote: > Versions of gcc prior to gcc 5 emitted a __multi3 function call when > dealing with TI types, resulting in failures when trying to link to > libgcc, and more generally, bad performance. However, since gcc 5, > the compiler

[GIT PULL] arm64 fix for 4.14

Hi Linus, Please pull the arm64 fix below. Thanks. The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984: Linux 4.14-rc7 (2017-10-29 13:58:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fix for 4.14

Hi Linus, Please pull the arm64 fix below. Thanks. The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984: Linux 4.14-rc7 (2017-10-29 13:58:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[PATCH] Documentation: Add Arm Ltd to kernel-enforcement-statement.rst

Adding a couple of names on behalf of Arm Ltd. Acked-by: Marc Zyngier <marc.zyng...@arm.com> Signed-off-by: Catalin Marinas <catalin.mari...@arm.com> --- Documentation/process/kernel-enforcement-statement.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/pr

[PATCH] Documentation: Add Arm Ltd to kernel-enforcement-statement.rst

Adding a couple of names on behalf of Arm Ltd. Acked-by: Marc Zyngier Signed-off-by: Catalin Marinas --- Documentation/process/kernel-enforcement-statement.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process

Re: [PATCH] mm: kmemleak: start address align for scan_large_block

trics_init+0x33/0x47 > tcp_init+0x27a/0x293 > inet_init+0x176/0x28a > do_one_initcall+0x51/0x1b0 > > Signed-off-by: Shu Wang <shuw...@redhat.com> Nice catch. Thanks. Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH] mm: kmemleak: start address align for scan_large_block

; inet_init+0x176/0x28a > do_one_initcall+0x51/0x1b0 > > Signed-off-by: Shu Wang Nice catch. Thanks. Reviewed-by: Catalin Marinas

Re: [PATCH v2] arm64: Expose support for optional ARMv8-A features

authentication in or not (probably the latter), I would really like to get the first patch in that series merged: http://lkml.kernel.org/r/1500480092-28480-2-git-send-email-mark.rutl...@arm.com Otherwise, for this patch: Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH v2] arm64: Expose support for optional ARMv8-A features

authentication in or not (probably the latter), I would really like to get the first patch in that series merged: http://lkml.kernel.org/r/1500480092-28480-2-git-send-email-mark.rutl...@arm.com Otherwise, for this patch: Reviewed-by: Catalin Marinas

[GIT PULL] arm64 fixes for 4.14-rc4

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux 4.14-rc3 (2017-10-01 14:54:54 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.14-rc4

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux 4.14-rc3 (2017-10-01 14:54:54 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH 1/2] arm64: Ensure the instruction emulation is ready for userspace

calls to core_initcalls, which are > guaranteed to be completed before we hit userspace. > > Cc: sta...@vger.kernel.org > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Matthias Brugger <mbrug...@suse.com> > Cc

Re: [PATCH 1/2] arm64: Ensure the instruction emulation is ready for userspace

calls to core_initcalls, which are > guaranteed to be completed before we hit userspace. > > Cc: sta...@vger.kernel.org > Cc: Catalin Marinas > Cc: Dave Martin > Cc: Matthias Brugger > Cc: James Morse > Reported-by: Matwey V. Kornilov > Signed-off-by: Suzuki K Poulose Both patches queued for 4.14. Thanks. -- Catalin

Re: [PATCH] kmemleak: clear stale pointers from task stacks

ack. */ > + memset(s->addr, 0, THREAD_SIZE); > +#endif > tsk->stack_vm_area = s; > return s->addr; > } Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH] kmemleak: clear stale pointers from task stacks

t;addr, 0, THREAD_SIZE); > +#endif > tsk->stack_vm_area = s; > return s->addr; > } Acked-by: Catalin Marinas

Re: [PATCH] kmemleak: change /sys/kernel/debug/kmemleak permissions from 0444 to 0644

if (!dentry) > pr_warn("Failed to create the debugfs kmemleak file\n"); Acked-by: Catalin Marinas <catalin.mari...@arm.com> -- Catalin

Re: [PATCH] kmemleak: change /sys/kernel/debug/kmemleak permissions from 0444 to 0644

it(void) > return -ENOMEM; > } > > - dentry = debugfs_create_file("kmemleak", S_IRUGO, NULL, NULL, > + dentry = debugfs_create_file("kmemleak", 0644, NULL, NULL, >_fops); > if (!dentry) >

Re: [PATCH] arm64: Enable MRS emulation early

On Wed, Oct 04, 2017 at 01:48:19PM +0100, Dave P Martin wrote: > On Wed, Oct 04, 2017 at 12:36:29PM +0100, Catalin Marinas wrote: > > On Wed, Oct 04, 2017 at 12:32:07PM +0100, Dave P Martin wrote: > > [...] > > > > I don't think the hwcaps shouldn't change after e

Re: [PATCH] arm64: Enable MRS emulation early

On Wed, Oct 04, 2017 at 01:48:19PM +0100, Dave P Martin wrote: > On Wed, Oct 04, 2017 at 12:36:29PM +0100, Catalin Marinas wrote: > > On Wed, Oct 04, 2017 at 12:32:07PM +0100, Dave P Martin wrote: > > [...] > > > > I don't think the hwcaps shouldn't change after e

Re: [PATCH] arm64: Enable MRS emulation early

On Wed, Oct 04, 2017 at 12:32:07PM +0100, Dave P Martin wrote: > On Wed, Oct 04, 2017 at 12:10:40PM +0100, Catalin Marinas wrote: > > On Wed, Oct 04, 2017 at 11:14:26AM +0100, Mark Rutland wrote: > > > On Wed, Oct 04, 2017 at 10:48:05AM +0100, Suzuki K Poulose wrote: > &g

Re: [PATCH] arm64: Enable MRS emulation early

On Wed, Oct 04, 2017 at 12:32:07PM +0100, Dave P Martin wrote: > On Wed, Oct 04, 2017 at 12:10:40PM +0100, Catalin Marinas wrote: > > On Wed, Oct 04, 2017 at 11:14:26AM +0100, Mark Rutland wrote: > > > On Wed, Oct 04, 2017 at 10:48:05AM +0100, Suzuki K Poulose wrote: > &g

Re: [PATCH] arm64: Enable MRS emulation early

the facility without crashing them. > > > > Fixes: commit 77c97b4ee2129 ("arm64: cpufeature: Expose CPUID registers by > > emulation") > > Reported-by: Matwey V. Kornilov <matwey.korni...@gmail.com> > > Cc: James Morse <james.mo...@arm.

Re: [PATCH] arm64: Enable MRS emulation early

the facility without crashing them. > > > > Fixes: commit 77c97b4ee2129 ("arm64: cpufeature: Expose CPUID registers by > > emulation") > > Reported-by: Matwey V. Kornilov > > Cc: James Morse > > Cc: Dave Martin > > Cc: Catalin Marinas

Re: [PATCH] [DEV] dma mapping : export caller to vmallocinfo

> --- > arch/arm64/mm/dma-mapping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) It looks fine to me. Will (cc'ed) should pick it up for 4.15. Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH] [DEV] dma mapping : export caller to vmallocinfo

a-mapping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) It looks fine to me. Will (cc'ed) should pick it up for 4.15. Acked-by: Catalin Marinas

[GIT PULL] arm64 fixes for 4.14-rc3

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit e19b205be43d11bff638cad4487008c48d21c103: Linux 4.14-rc2 (2017-09-24 16:38:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.14-rc3

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit e19b205be43d11bff638cad4487008c48d21c103: Linux 4.14-rc2 (2017-09-24 16:38:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.14-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.14-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [PATCH] drivers/perf: arm_pmu_acpi: Release memory obtained by kasprintf

On Fri, Sep 22, 2017 at 11:54:06AM +0100, Will Deacon wrote: > On Wed, Sep 20, 2017 at 12:26:38PM +0530, Arvind Yadav wrote: > > Free memory region, if arm_pmu_acpi_probe is not successful. > > > > Signed-off-by: Arvind Yadav > > --- > > drivers/perf/arm_pmu_acpi.c |

Re: [PATCH] drivers/perf: arm_pmu_acpi: Release memory obtained by kasprintf

On Fri, Sep 22, 2017 at 11:54:06AM +0100, Will Deacon wrote: > On Wed, Sep 20, 2017 at 12:26:38PM +0530, Arvind Yadav wrote: > > Free memory region, if arm_pmu_acpi_probe is not successful. > > > > Signed-off-by: Arvind Yadav > > --- > > drivers/perf/arm_pmu_acpi.c | 1 + > > 1 file changed, 1

Re: [v5 00/12] soc/fsl/qbman: Enable QBMan on ARM Platforms

On Mon, Sep 18, 2017 at 04:39:35PM -0400, Roy Pledge wrote: > Madalin Bucur (4): > soc/fsl/qbman: Drop set/clear_bits usage > soc/fsl/qbman: add QMAN_REV32 > soc/fsl/qbman: different register offsets on ARM > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM > > Roy Pledge (5): >

Re: [v5 00/12] soc/fsl/qbman: Enable QBMan on ARM Platforms

On Mon, Sep 18, 2017 at 04:39:35PM -0400, Roy Pledge wrote: > Madalin Bucur (4): > soc/fsl/qbman: Drop set/clear_bits usage > soc/fsl/qbman: add QMAN_REV32 > soc/fsl/qbman: different register offsets on ARM > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM > > Roy Pledge (5): >

Re: [v5 08/12] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

M. This also fixes the code so sparse checking is clean. > > Signed-off-by: Roy Pledge <roy.ple...@nxp.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [v5 08/12] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

M. This also fixes the code so sparse checking is clean. > > Signed-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [v5 06/12] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On Mon, Sep 18, 2017 at 04:39:41PM -0400, Roy Pledge wrote: > From: Claudiu Manoil <claudiu.man...@nxp.com> > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil <claudiu.man...@nxp.com> > Signed-off-by: Roy Pledge <roy.ple.

Re: [v5 06/12] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On Mon, Sep 18, 2017 at 04:39:41PM -0400, Roy Pledge wrote: > From: Claudiu Manoil > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [v5 07/12] soc/fsl/qbman: Fix ARM32 typo

Manoil <claudiu.man...@nxp.com> > Signed-off-by: Roy Pledge <roy.ple...@nxp.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [v5 07/12] soc/fsl/qbman: Fix ARM32 typo

On Mon, Sep 18, 2017 at 04:39:42PM -0400, Roy Pledge wrote: > From: Valentin Rothberg > > The Kconfig symbol for 32bit ARM is 'ARM', not 'ARM32'. > > Signed-off-by: Valentin Rothberg > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [v5 05/12] soc/fsl/qbman: Drop set/clear_bits usage

bu...@nxp.com> > Signed-off-by: Claudiu Manoil <claudiu.man...@nxp.com> > Signed-off-by: Roy Pledge <roy.ple...@nxp.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [v5 05/12] soc/fsl/qbman: Drop set/clear_bits usage

igned-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [v5 03/12] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations

On Mon, Sep 18, 2017 at 04:39:38PM -0400, Roy Pledge wrote: > Use the shared-memory-pool mechanism for frame queue descriptor and > packed frame descriptor record area allocations. > > Signed-off-by: Roy Pledge <roy.ple...@nxp.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [v5 03/12] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations

On Mon, Sep 18, 2017 at 04:39:38PM -0400, Roy Pledge wrote: > Use the shared-memory-pool mechanism for frame queue descriptor and > packed frame descriptor record area allocations. > > Signed-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [v5 01/12] soc/fsl/qbman: Add common routine for QBMan private allocations

R PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED > AND > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > THIS > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF S

Re: [v5 01/12] soc/fsl/qbman: Add common routine for QBMan private allocations

R PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED > AND > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > THIS > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ Pretty verbose header, I guess GPLv2 would do but IANAL. Anyway: Reviewed-by: Catalin Marinas

Re: [v5 02/12] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

On Mon, Sep 18, 2017 at 04:39:37PM -0400, Roy Pledge wrote: > Use the shared-memory-pool mechanism for free buffer proxy record > area allocation. > > Signed-off-by: Roy Pledge <roy.ple...@nxp.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [v5 02/12] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

On Mon, Sep 18, 2017 at 04:39:37PM -0400, Roy Pledge wrote: > Use the shared-memory-pool mechanism for free buffer proxy record > area allocation. > > Signed-off-by: Roy Pledge Reviewed-by: Catalin Marinas

Re: [PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

On Wed, Sep 20, 2017 at 07:58:34PM +0900, Masahiro Yamada wrote: > 2017-09-08 1:46 GMT+09:00 Catalin Marinas <catalin.mari...@arm.com>: > > On Thu, Aug 31, 2017 at 06:56:23PM +0900, Masahiro Yamada wrote: > >> Aarch64 instructions must be word aligned. The current 16 byt

Re: [PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

On Wed, Sep 20, 2017 at 07:58:34PM +0900, Masahiro Yamada wrote: > 2017-09-08 1:46 GMT+09:00 Catalin Marinas : > > On Thu, Aug 31, 2017 at 06:56:23PM +0900, Masahiro Yamada wrote: > >> Aarch64 instructions must be word aligned. The current 16 byte > >> alignment

Re: [PATCH v8 00/20] ILP32 for ARM64

On Mon, Sep 04, 2017 at 02:54:50PM +0300, Yury Norov wrote: > This is 4.13-based and next-20170901-based ilp32 patches. > https://github.com/norov/linux/tree/ilp32-4.13 Thanks. I'll mirror it on kernel.org sometime this week after doing some tests (I've been mostly away for the past two weeks).

Re: [PATCH v8 00/20] ILP32 for ARM64

On Mon, Sep 04, 2017 at 02:54:50PM +0300, Yury Norov wrote: > This is 4.13-based and next-20170901-based ilp32 patches. > https://github.com/norov/linux/tree/ilp32-4.13 Thanks. I'll mirror it on kernel.org sometime this week after doing some tests (I've been mostly away for the past two weeks).

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On Thu, Sep 14, 2017 at 07:07:50PM +, Roy Pledge wrote: > On 9/14/2017 10:00 AM, Catalin Marinas wrote: > > On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: > >> @@ -123,23 +122,34 @@ static int bman_portal_probe(struct platform_device > >> *pdev) > &

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On Thu, Sep 14, 2017 at 07:07:50PM +, Roy Pledge wrote: > On 9/14/2017 10:00 AM, Catalin Marinas wrote: > > On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: > >> @@ -123,23 +122,34 @@ static int bman_portal_probe(struct platform_device > >> *pdev) > &

Re: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion

_for_cpu_fn+0x14/0x20 > process_one_work+0x149/0x360 > worker_thread+0x1d8/0x3c0 > kthread+0x109/0x140 > ret_from_fork+0x25/0x30 > > Signed-off-by: Shu Wang <shuw...@redhat.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> Thanks. -- Catalin

Re: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion

rocess_one_work+0x149/0x360 > worker_thread+0x1d8/0x3c0 > kthread+0x109/0x140 > ret_from_fork+0x25/0x30 > > Signed-off-by: Shu Wang Reviewed-by: Catalin Marinas Thanks. -- Catalin

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: > diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c > index ff8998f..e31c843 100644 > --- a/drivers/soc/fsl/qbman/bman.c > +++ b/drivers/soc/fsl/qbman/bman.c > @@ -154,7 +154,7 @@ struct bm_mc { > }; > > struct

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: > diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c > index ff8998f..e31c843 100644 > --- a/drivers/soc/fsl/qbman/bman.c > +++ b/drivers/soc/fsl/qbman/bman.c > @@ -154,7 +154,7 @@ struct bm_mc { > }; > > struct

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: > From: Claudiu Manoil > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge > --- >

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: > From: Claudiu Manoil > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge > --- > drivers/soc/fsl/qbman/dpaa_sys.h | 4 > 1 file changed, 4 deletions(-) > >

Re: [v4 03/11] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

On Thu, Aug 24, 2017 at 04:37:47PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- >

Re: [v4 03/11] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

On Thu, Aug 24, 2017 at 04:37:47PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- >

Re: [v4 01/11] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

On Thu, Aug 24, 2017 at 04:37:45PM -0400, Roy Pledge wrote: > --- a/drivers/soc/fsl/qbman/bman_ccsr.c > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c [...] > @@ -201,6 +202,38 @@ static int fsl_bman_probe(struct platform_device *pdev) > return -ENODEV; > } > > + /* > + *

Re: [v4 01/11] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

On Thu, Aug 24, 2017 at 04:37:45PM -0400, Roy Pledge wrote: > --- a/drivers/soc/fsl/qbman/bman_ccsr.c > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c [...] > @@ -201,6 +202,38 @@ static int fsl_bman_probe(struct platform_device *pdev) > return -ENODEV; > } > > + /* > + *

Re: [PATCH] megaraid: kmemleak: Track page allocation for fusion

es); > + kmemleak_free(fusion); > + } Apart from Bart's comments on braces and comment before kmemleak_alloc(), I'd call kmemleak_free() before free_pages(), otherwise it may not interact nicely with other tools checking for use after free. With that: Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> -- Catalin

Re: [PATCH] megaraid: kmemleak: Track page allocation for fusion

_free(fusion); > + } Apart from Bart's comments on braces and comment before kmemleak_alloc(), I'd call kmemleak_free() before free_pages(), otherwise it may not interact nicely with other tools checking for use after free. With that: Reviewed-by: Catalin Marinas -- Catalin

Re: kmemleak not always catching stuff

On Tue, Sep 05, 2017 at 10:15:45AM -0400, Steven Rostedt wrote: > On Mon, 4 Sep 2017 11:09:05 +0100 > Catalin Marinas <catalin.mari...@arm.com> wrote: > > On Fri, Sep 01, 2017 at 06:33:11PM -0400, Steven Rostedt wrote: > > > Now I was thinking that it may be due to t

Re: kmemleak not always catching stuff

On Tue, Sep 05, 2017 at 10:15:45AM -0400, Steven Rostedt wrote: > On Mon, 4 Sep 2017 11:09:05 +0100 > Catalin Marinas wrote: > > On Fri, Sep 01, 2017 at 06:33:11PM -0400, Steven Rostedt wrote: > > > Now I was thinking that it may be due to the fact that the trampoli

Re: [PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

On Thu, Aug 31, 2017 at 06:56:23PM +0900, Masahiro Yamada wrote: > Aarch64 instructions must be word aligned. The current 16 byte > alignment is more than enough. Relax it into 4 byte alignment. > > Signed-off-by: Masahiro Yamada > --- > > I do not know why

Re: [PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

On Thu, Aug 31, 2017 at 06:56:23PM +0900, Masahiro Yamada wrote: > Aarch64 instructions must be word aligned. The current 16 byte > alignment is more than enough. Relax it into 4 byte alignment. > > Signed-off-by: Masahiro Yamada > --- > > I do not know why arm64 Linux requires 16 byte

Re: [PATCH] arm64: Convert pr_warning to standard pr_warn

On Wed, Sep 06, 2017 at 10:21:26AM +0100, Mark Rutland wrote: > On Tue, Sep 05, 2017 at 11:38:23AM -0700, Joe Perches wrote: > > On Tue, 2017-09-05 at 10:10 +0100, Mark Rutland wrote: > > > On Tue, Sep 05, 2017 at 10:28:38AM +0800, chengjian c00427203 wrote: > > > > Convert pr_warning to standard

Re: [PATCH] arm64: Convert pr_warning to standard pr_warn

On Wed, Sep 06, 2017 at 10:21:26AM +0100, Mark Rutland wrote: > On Tue, Sep 05, 2017 at 11:38:23AM -0700, Joe Perches wrote: > > On Tue, 2017-09-05 at 10:10 +0100, Mark Rutland wrote: > > > On Tue, Sep 05, 2017 at 10:28:38AM +0800, chengjian c00427203 wrote: > > > > Convert pr_warning to standard

[GIT PULL] arm64 updates for 4.14

arm64: assembler: allow adr_this_cpu to use the stack pointer Arnd Bergmann (2): arm64: fix pmem interface definition ACPI/IORT: Fix build regression without IOMMU Catalin Marinas (12): arm64: neon: Temporarily add a kernel_mode_begin_partial() definition arm64: neon

[GIT PULL] arm64 updates for 4.14

arm64: assembler: allow adr_this_cpu to use the stack pointer Arnd Bergmann (2): arm64: fix pmem interface definition ACPI/IORT: Fix build regression without IOMMU Catalin Marinas (12): arm64: neon: Temporarily add a kernel_mode_begin_partial() definition arm64: neon

Re: kmemleak not always catching stuff

On Tue, Sep 05, 2017 at 04:23:47PM +0200, Dmitry Vyukov wrote: > On Mon, Sep 4, 2017 at 12:09 PM, Catalin Marinas > <catalin.mari...@arm.com> wrote: > > I also need to find > > some time to implement a "stopscan" command which uses stop_machine() > > and

Re: kmemleak not always catching stuff

On Tue, Sep 05, 2017 at 04:23:47PM +0200, Dmitry Vyukov wrote: > On Mon, Sep 4, 2017 at 12:09 PM, Catalin Marinas > wrote: > > I also need to find > > some time to implement a "stopscan" command which uses stop_machine() > > and skips the heuristics for reduci

Re: [PATCH 1/2] arm64: stacktrace: avoid listing stacktrace functions in stacktrace

9 ("ARM: stacktrace: avoid > > listing stacktrace functions in stacktrace") > > I can take this (with acks, please?) In case you haven't picked it up already: Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH 1/2] arm64: stacktrace: avoid listing stacktrace functions in stacktrace

id > > listing stacktrace functions in stacktrace") > > I can take this (with acks, please?) In case you haven't picked it up already: Acked-by: Catalin Marinas

Re: kmemleak not always catching stuff

Hi Steve, On Fri, Sep 01, 2017 at 06:33:11PM -0400, Steven Rostedt wrote: > Recently kmemleak discovered a bug in my code where an allocated > trampoline for a ftrace function tracer wasn't freed due to an exit > path. The thing is, kmemleak was able to catch this 100% when it was > triggered by

Re: kmemleak not always catching stuff

Hi Steve, On Fri, Sep 01, 2017 at 06:33:11PM -0400, Steven Rostedt wrote: > Recently kmemleak discovered a bug in my code where an allocated > trampoline for a ftrace function tracer wasn't freed due to an exit > path. The thing is, kmemleak was able to catch this 100% when it was > triggered by

Re: [PATCH v2 0/2] cleanup {COMPAT_,}SET_PERSONALITY

On Sun, Aug 20, 2017 at 01:20:46PM +0300, Yury Norov wrote: > This patchset is the result of discussion: > https://lkml.org/lkml/2017/7/31/454 > > First patch introduces MMCF flags for mm_context_t ->flags to separate it from > TIF ones. And second patch moves personality-related setup code from

Re: [PATCH v2 0/2] cleanup {COMPAT_,}SET_PERSONALITY

On Sun, Aug 20, 2017 at 01:20:46PM +0300, Yury Norov wrote: > This patchset is the result of discussion: > https://lkml.org/lkml/2017/7/31/454 > > First patch introduces MMCF flags for mm_context_t ->flags to separate it from > TIF ones. And second patch moves personality-related setup code from

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

clarify the expected behaviour of this function. > This is to set clear semantics for architecture specific implementations > of huge_pte_offset(). > > Signed-off-by: Punit Agrawal <punit.agra...@arm.com> > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Naoya

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

clarify the expected behaviour of this function. > This is to set clear semantics for architecture specific implementations > of huge_pte_offset(). > > Signed-off-by: Punit Agrawal > Cc: Catalin Marinas > Cc: Naoya Horiguchi > Cc: Steve Capper > Cc: Will Deacon

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

ize parameter > > doesn't match the hugepage size at this level of the page table. > > > > Document the behaviour to clarify the expected behaviour of this function. > > This is to set clear semantics for architecture specific implementations > > of huge_pte_offset().

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

ize parameter > > doesn't match the hugepage size at this level of the page table. > > > > Document the behaviour to clarify the expected behaviour of this function. > > This is to set clear semantics for architecture specific implementations > > of huge_pte_offset(). > &

Re: [PATCHv3] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

On Thu, Aug 17, 2017 at 11:24:27AM +0900, Hoeun Ryu wrote: > Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > version in panic path) introduced crash_smp_send_stop() which is a weak > function and can be overridden by architecture codes to fix the side effect > caused by

<    9   10   11   12   13   14   15   16   17   18   >