Nicolas Pitre | 24 Jul 17:30 2016

[PATCH v5 00/15] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable
binaries meant for no-MMU systems to actually run on systems with a MMU.
Also thrown in are various cleanups to binfmt_flat.c.

This can also be found in the following git repo:

	git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu

*Why?*

Because developing and testing natively on a large system with lots of
RAM makes it so much more convenient to use all the existing profiling
tools and debugging facilities that a kernel with lots of RAM can give.
And incidentally, those systems with lots of RAM all have a MMU.

*Why not use elf_fdpic?*

The flat executable format is simple with very small footprint
overhead, either in the executables themselves or kernel support.
This makes the flat format more suitable than elf_fdpic for very small
single user-app embedded systems.

And while elf_fdpic binaries can run on MMU systems, flat binaries still
couldn't, which just felt wrong.

So here it is. The no-MMU support should remain unaffected, confirmed by
Greg Ungerer. Tested with MMU on ARM and M68K.

Changes since v4:

(Continue reading)

Greg Ungerer | 22 Jul 02:40 2016

[PATCH 0/3] m68k: flat file load fix and cleanup


The following 3 patches fix m68k loading of flat binaries on MMU-enabled
systems, and then based on that we can cleanup and combine some common
code.

Signed-off-by: Greg Ungerer <gerg <at> linux-m68k.org>
---
 b/arch/m68k/include/asm/flat.h      |    8 +++++++-
 b/arch/m68k/include/asm/processor.h |   15 +--------------
 2 files changed, 8 insertions(+), 15 deletions(-)

Geert Uytterhoeven | 20 Jul 10:34 2016
Gravatar

[git pull] m68k updates for 4.8

	Hi Linus,

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git tags/m68k-for-v4.8-tag1

for you to fetch changes up to 6bd80f372371a7b3f5ff13e4e8a560066299c001:

  m68k/defconfig: Update defconfigs for v4.7-rc2 (2016-07-19 09:35:54 +0200)

----------------------------------------------------------------
m68k updates for 4.8

  - Assorted spelling fixes,
  - Defconfig updates.

----------------------------------------------------------------
Andrea Gelmini (1):
      m68k: Assorted spelling fixes

Geert Uytterhoeven (1):
      m68k/defconfig: Update defconfigs for v4.7-rc2

 arch/m68k/coldfire/head.S            | 2 +-
 arch/m68k/coldfire/m5272.c           | 2 +-
 arch/m68k/coldfire/pci.c             | 2 +-
(Continue reading)

Financial Service | 13 Jul 14:27 2016
Picon

Fast Loans

Hae lainaa 3% vastaus tähän viestiin lisätietoja

Apply for a loan at 3% reply to this Email for more Info
Krzysztof Kozlowski | 13 Jul 10:39 2016

[PATCH v6 00/46] dma-mapping: Use unsigned long for dma_attrs

Hi,

The fifth version of this patchset was merged by Andrew Morton
few days ago.  It was rebased on v4.7-rc5 so it missed some ongoing
changes.

This is just rebase on next-20160713.

For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v6

Changes since v5
================
1. New patches:
   1/46:  [media] mtk-vcodec: Remove unused dma_attrs
   44/46: remoteproc: qcom: Use unsigned long for dma_attrs
2. 19/46: rebased on next, some more changes inside
3. Added accumulated acks: Marek Szyprowski, Richard Kuo,
   Konrad Rzeszutek Wilk, Daniel Vetter and Joerg Roedel.

Changes since v4
================
1. Collect some acks. Still need more.
2. Minor fixes pointed by Robin Murphy.
3. Applied changes from Bart Van Assche's comment.
4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).

Changes since v3
================
(Continue reading)

Krzysztof Kozlowski | 30 Jun 10:23 2016

[PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

Hi,

This is fifth approach for replacing struct dma_attrs with unsigned
long.

The main patch (1/44) doing the change is split into many subpatches
for easier review (2-42).  They should be squashed together when
applying.

Rebased on v4.7-rc5.

For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v5

Changes since v4
================
1. Collect some acks. Still need more.
2. Minor fixes pointed by Robin Murphy.
3. Applied changes from Bart Van Assche's comment.
4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).

Changes since v3
================
1. Collect some acks.
2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
   the value of DMA_ATTR_WEAK_ORDERING").
3. Minor fix pointed out by Michael Ellerman.

Changes since v2
(Continue reading)

Reid Lindsay | 11 Jun 07:54 2016

Issues with vmalloc and ebtables on ColdFire V4e

Hi,

We are having some stability issues on our ColdFire V4e based board and hope
this forum can provide some advice on how to track the issue down.

The CPU is the 54415 running a 2.6.38 kernel with BSP patches and bug fixes
provided by Freescale. 64MiB SRAM and 64MiB NAND Flash. The compiler is GCC
4.4.1-cs4.4-54.

The problem is that when modifying the ebtables structures by
adding/flushing the rules, sooner or later a segfault occurs in a (seemingly
random) userspace process, with the faulting address within a region of
memory vmalloc'ed by ebtables (for our BSP, the vmalloc region is
0xc0000000-0xcfffffff). The fault does not occur right after modifying the
rules, it occurs some time (sometimes up to hours) later.

I was able to avoid the segfaults by replacing all vmalloc/vfree calls with
kmalloc/kfree in net/bridge/netfilter/ebtables.c.

Although other kernel subsystems make use of vmalloc, these regions seem to
be allocated once and never free'd during runtime.

For example:

cat /proc/vmallocinfo

0xc0026000-0xc0048000  139264 ubi_attach_mtd_dev+0x436/0x9d0 pages=16
pfn=41891 vmalloc
0xc004a000-0xc006c000  139264 ubi_attach_mtd_dev+0x44a/0x9d0 pages=16
pfn=4188e vmalloc
(Continue reading)

Krzysztof Kozlowski | 10 Jun 12:11 2016

[PATCH v4 00/44] dma-mapping: Use unsigned long for dma_attrs

Hi,

This is fourth approach for replacing struct dma_attrs with unsigned
long.

The main patch (1/44) doing the change is split into many subpatches
for easier review (2-42).  They should be squashed together when
applying.

*Important:* Patchset is tested on my ARM platforms and *only* build
tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc.
Please kindly provide reviewes and tests for other platforms.

Rebased on next-20160607.

For easier testing the patchset is available here:
repo:   https://github.com/krzk/linux
branch: for-next/dma-attrs-const-v4

Changes since v3
================
1. Collect some acks.
2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
   the value of DMA_ATTR_WEAK_ORDERING").
3. Minor fix pointed out by Michael Ellerman.

Changes since v2
================
1. Follow Christoph Hellwig's comments (don't use BIT add
   documentation, remove dma_get_attr).
(Continue reading)

Geert Uytterhoeven | 6 Jun 09:45 2016
Gravatar

[PATCH] m68k/defconfig: Update defconfigs for v4.7-rc2

Signed-off-by: Geert Uytterhoeven <geert <at> linux-m68k.org>
---
To be folded into m68k/defconfig: Update defconfigs for v4.7-rc1
---
 arch/m68k/configs/amiga_defconfig    | 1 +
 arch/m68k/configs/apollo_defconfig   | 1 +
 arch/m68k/configs/atari_defconfig    | 1 +
 arch/m68k/configs/bvme6000_defconfig | 1 +
 arch/m68k/configs/hp300_defconfig    | 1 +
 arch/m68k/configs/mac_defconfig      | 1 +
 arch/m68k/configs/multi_defconfig    | 1 +
 arch/m68k/configs/mvme147_defconfig  | 1 +
 arch/m68k/configs/mvme16x_defconfig  | 1 +
 arch/m68k/configs/q40_defconfig      | 1 +
 arch/m68k/configs/sun3_defconfig     | 1 +
 arch/m68k/configs/sun3x_defconfig    | 1 +
 12 files changed, 12 insertions(+)

diff --git a/arch/m68k/configs/amiga_defconfig b/arch/m68k/configs/amiga_defconfig
index 2a8f5ee65f763ba5..8f5b6f7dd1366024 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
 <at>  <at>  -555,6 +555,7  <at>  <at>  CONFIG_TEST_STRING_HELPERS=m
 CONFIG_TEST_KSTRTOX=m
 CONFIG_TEST_PRINTF=m
 CONFIG_TEST_BITMAP=m
+CONFIG_TEST_UUID=m
 CONFIG_TEST_RHASHTABLE=m
 CONFIG_TEST_HASH=m
 CONFIG_TEST_LKM=m
(Continue reading)

Mel Gorman | 2 Jun 14:21 2016
Picon

[PATCH] mm, page_alloc: Recalculate the preferred zoneref if the context can ignore memory policies

The optimistic fast path may use cpuset_current_mems_allowed instead of
of a NULL nodemask supplied by the caller for cpuset allocations. The
preferred zone is calculated on this basis for statistic purposes and
as a starting point in the zonelist iterator.

However, if the context can ignore memory policies due to being atomic or
being able to ignore watermarks then the starting point in the zonelist
iterator is no longer correct. This patch resets the zonelist iterator in
the allocator slowpath if the context can ignore memory policies. This will
alter the zone used for statistics but only after it is known that it makes
sense for that context. Resetting it before entering the slowpath would
potentially allow an ALLOC_CPUSET allocation to be accounted for against
the wrong zone. Note that while nodemask is not explicitly set to the
original nodemask, it would only have been overwritten if cpuset_enabled()
and it was reset before the slowpath was entered.

Signed-off-by: Mel Gorman <mgorman <at> techsingularity.net>
Acked-by: Vlastimil Babka <vbabka <at> suse.cz>
---
 mm/page_alloc.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 557549c81083..b17358617a1b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
 <at>  <at>  -3598,6 +3598,17  <at>  <at>  __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 	 */
 	alloc_flags = gfp_to_alloc_flags(gfp_mask);

(Continue reading)

Mel Gorman | 31 May 12:08 2016
Picon

[PATCH] mm, page_alloc: Reset zonelist iterator after resetting fair zone allocation policy

Geert Uytterhoeven reported the following problem that bisected to commit
c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a
zonelist twice") on m68k/ARAnyM

    BUG: scheduling while atomic: cron/668/0x10c9a0c0
    Modules linked in:
    CPU: 0 PID: 668 Comm: cron Not tainted 4.6.0-atari-05133-gc33d6c06f60f710f #364
    Stack from 10c9a074:
            10c9a074 003763ca 0003d7d0 00361a58 00bcf834 0000029c 10c9a0c0 10c9a0c0
            002f0f42 00bcf5e0 00000000 00000082 0048e018 00000000 00000000 002f0c30
            000410de 00000000 00000000 10c9a0e0 002f112c 00000000 7fffffff 10c9a180
            003b1490 00bcf60c 10c9a1f0 10c9a118 002f2d30 00000000 10c9a174 10c9a180
            0003ef56 003b1490 00bcf60c 003b1490 00bcf60c 0003eff6 003b1490 00bcf60c
            003b1490 10c9a128 002f118e 7fffffff 00000082 002f1612 002f1624 7fffffff
    Call Trace: [<0003d7d0>] __schedule_bug+0x40/0x54
     [<002f0f42>] __schedule+0x312/0x388
     [<002f0c30>] __schedule+0x0/0x388
     [<000410de>] prepare_to_wait+0x0/0x52
     [<002f112c>] schedule+0x64/0x82
     [<002f2d30>] schedule_timeout+0xda/0x104
     [<0003ef56>] set_next_entity+0x18/0x40
     [<0003eff6>] pick_next_task_fair+0x78/0xda
     [<002f118e>] io_schedule_timeout+0x36/0x4a
     [<002f1612>] bit_wait_io+0x0/0x40
     [<002f1624>] bit_wait_io+0x12/0x40
     [<002f12c4>] __wait_on_bit+0x46/0x76
     [<0006a06a>] wait_on_page_bit_killable+0x64/0x6c
     [<002f1612>] bit_wait_io+0x0/0x40
     [<000411fe>] wake_bit_function+0x0/0x4e
     [<0006a1b8>] __lock_page_or_retry+0xde/0x124
(Continue reading)


Gmane