David Howells | 3 Feb 16:17 2016

[PATCH] KEYS: CONFIG_KEYS_DEBUG_PROC_KEYS is no longer an option

CONFIG_KEYS_DEBUG_PROC_KEYS is no longer an option as /proc/keys is now
mandatory if the keyrings facility is enabled (it's used by libkeyutils in

The defconfig references were removed with:

	perl -p -i -e 's/CONFIG_KEYS_DEBUG_PROC_KEYS=y\n//' \
	    `git grep -l CONFIG_KEYS_DEBUG_PROC_KEYS=y`

and the integrity Kconfig fixed by hand.

Signed-off-by: David Howells <dhowells <at> redhat.com>
cc: Andreas Ziegler <andreas.ziegler <at> fau.de>
cc: Dmitry Kasatkin <dmitry.kasatkin <at> huawei.com>

 arch/arm/configs/colibri_pxa270_defconfig   |    1 -
 arch/arm/configs/iop13xx_defconfig          |    1 -
 arch/arm/configs/iop32x_defconfig           |    1 -
 arch/arm/configs/trizeps4_defconfig         |    1 -
 arch/microblaze/configs/mmu_defconfig       |    1 -
 arch/microblaze/configs/nommu_defconfig     |    1 -
 arch/mips/configs/bigsur_defconfig          |    1 -
 arch/mips/configs/ip22_defconfig            |    1 -
 arch/mips/configs/ip27_defconfig            |    1 -
 arch/mips/configs/ip32_defconfig            |    1 -
 arch/mips/configs/jazz_defconfig            |    1 -
 arch/mips/configs/lemote2f_defconfig        |    1 -
 arch/mips/configs/rm200_defconfig           |    1 -
 arch/mips/configs/sb1250_swarm_defconfig    |    1 -
(Continue reading)

Arnd Bergmann | 3 Feb 14:21 2016

[PATCH] [RFC] ARM: modify pgd_t definition for TRANSPARENT_HUGEPAGE_PUD

I ran into build errors on ARM after Willy's newly added generic
TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
on ARM at all, but the patch causes a build error anyway:

In file included from ../kernel/memremap.c:17:0:
../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
 pud_t pud_mkdevmap(pud_t pud);

We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
in turn is defined as

typedef unsigned long pgd_t[2];

on NOMMU and on 2-level MMU configurations. There is an (unused)
other definition using a struct around the array, which happens to
work fine here.

There is a comment in the file about the fact the other version
is "easier on the compiler", and I've traced that version back
to linux-2.1.80 when ARM support was first merged back in 1998.

It's probably a safe assumption that this is no longer necessary:
The same logic existed in asm-i386 at the time but was removed
a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
also ended up getting copied into these files:

(Continue reading)

Bjorn Helgaas | 2 Feb 20:53 2016

[PATCH 0/2] GPIO: Clean up asm/gpio.h

Many arches supply an asm/gpio.h that contains only this:

  #warning Include linux/gpio.h instead of asm/gpio.h
  #include <linux/gpio.h>

These two patches change all the places that include asm/gpio.h
so they include linux/gpio.h instead, and then remove the asm/gpio.h

There are several arches that supply asm/gpio.h with useful
arch-specific content; I didn't touch those.

I assume Mark was heading this direction with 7563bbf89d06
("gpiolib/arches: Centralise bolierplate asm/gpio.h").


Bjorn Helgaas (2):
      gpio: Include linux/gpio.h instead of asm/gpio.h
      gpio: Remove unused asm/gpio.h files

 arch/alpha/include/asm/gpio.h                   |    4 ----
 arch/avr32/boards/merisc/setup.c                |    1 -
 arch/avr32/mach-at32ap/pio.c                    |    2 +-
 arch/blackfin/kernel/debug-mmrs.c               |    2 +-
 arch/blackfin/mach-bf538/boards/ezkit.c         |    2 +-
 arch/blackfin/mach-bf538/ext-gpio.c             |    2 +-
 arch/blackfin/mach-bf548/boards/cm_bf548.c      |    2 +-
 arch/blackfin/mach-bf548/boards/ezkit.c         |    2 +-
 arch/blackfin/mach-bf609/boards/ezkit.c         |    2 +-
(Continue reading)

Ganapatrao Kulkarni | 2 Feb 11:09 2016

[PATCH v10 0/8] arm64, numa: Add numa support for arm64 platforms

	- Incorporated review comments from Rob Herring.
	- Moved numa binding and implementation to devicetree core.
	- Added cleanup patch to remove redundant NODE_DATA macro from asm header files
	- Include numa balancing support for arm64 patch in this series.
	- Fix tile build issue reported by the kbuild robot(patch 7)

v9:	- Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus
	  as suggested from Will Deacon and Bjorn Helgaas.
	- Including patch to Make pci-host-generic driver numa aware.
	- Incorporated comment from Shannon Zhao.

	- Incorporated review comments of Mark Rutland and Will Deacon.
	- Added pci helper function and macro for numa.

	- managing numa memory mapping using memblock.
	- Incorporated review comments of Mark Rutland.

	- defined and implemented the numa dt binding using
	node property proximity and device node distance-map.
	- renamed dt_numa to of_numa

        - created base verion of numa.c which creates dummy numa without using dt
          on single socket platforms. Then added patches for dt support.
        - Incorporated review comments from Hanjun Guo.

(Continue reading)

Jeffrey Merkey | 1 Feb 21:45 2016

[PATCH v2 2/4] Add WARN_XX() debugging options

This patch series adds config options which can be set during compile to
direct the compiler to output a breakpoint instruction anywhere a BUG()
or WARN() macro has been placed in the kernel to trigger the system to
enter a debugger if a bug is detected by the system.  Use of this
compile time option also allows conditional breakpoints to be set in the
kernel with these currently used macros.

This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger, and other areas of the

Signed-off-by: Jeffrey Merkey <jeffmerkey <at> gmail.com>
 include/asm-generic/bug.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 630dd23..ed86cd2 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
 <at>  <at>  -90,14 +90,26  <at>  <at>  extern void warn_slowpath_null(const char *file, const int line);

 #ifndef WARN
-#define WARN(condition, format...) ({						\
+#define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
 	if (unlikely(__ret_warn_on))					\
(Continue reading)

Interfax | 1 Feb 15:04 2016

You have new fax, document 0000838479

You have received a new fax.

Please, download fax document attached to this email.

Filesize:             258 Kb
Processed in:         52 seconds
Scanned:              Mon, 1 Feb 2016 05:59:27 +0300
Pages sent:           6
Sender:               Alexander Whitaker
Resolution:           100 DPI
File name:            scanned-0000838479.doc

Thanks for using Interfax service!

Attachment (scanned-0000838479.zip): application/zip, 1967 bytes
linux-arch@vger.kernel.org | 1 Feb 13:32 2016

Клиентские базы!!! Тел\Viber\Whatsapp:+79133913837 Skype:prodawez389 Email:zradionova92 <at> gmail.com Узнайте подробнее!!!

Соберем для Вас по интернет базу данных
потенциальных клиентов для Вашего Бизнеса!!! Много!
Быстро! Не дорого! Узнайте об этом подробнее по
Тел\Viber\Whatsapp:+79133913837 Skype:prodawez389 Email:opotapova53 <at> gmail.com  
Dave Hansen | 29 Jan 19:16 2016

[PATCH 00/31] x86: Memory Protection Keys (v9)

Memory Protection Keys for User pages is a CPU feature which will
first appear on Skylake Servers, but will also be supported on
future non-server parts (there is also a QEMU implementation).  It
provides a mechanism for enforcing page-based protections, but
without requiring modification of the page tables when an
application changes wishes to change permissions.

This set introduces supported limited to:
1. Allows "execute-only" memory
2. Enables KVM to run Protection-Key-enabled guests

This set contains the vast majority of of the code, with the
small but tricky explicit user interface parts left off.  We can
have a more focused review on those at a later time in a (much
smaller) follow-on series.

Changes from v8:
 * Reorganization of get_user_pages() patch with awesome feedback
   from Vlastimil Babka and suggestions from Jan Kara.
 * fix EXPORT_SYMBOL() and use get_current_user_page() in nommu.c

Changes from v7:
 * Fixed merge issue with cpu feature bitmap definitions
 * Fixed up some comments in get_user_pages() and smaps patches
   (thanks Vlastimil!)

Changes from v6:
 * fix up ??'s showing up in in smaps' VmFlags field
 * added execute-only support
 * removed all the new syscalls from this set.  We can discuss
(Continue reading)

Will Deacon | 27 Jan 19:22 2016

[PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation

As much as we'd like to live in a world where RELEASE -> ACQUIRE is
always cheaply ordered and can be used to construct UNLOCK -> LOCK
definitions with similar guarantees, the grim reality is that this isn't
even possible on x86 (thanks to Paul for bringing us crashing down to

This patch handles the issue by introducing a new barrier macro,
smp_mb__after_release_acquire, that can be placed after an ACQUIRE that
either reads from a RELEASE or is in program-order after a RELEASE. The
barrier upgrades the RELEASE-ACQUIRE pair to a full memory barrier,
implying global transitivity. At the moment, it doesn't have any users,
so its existence serves mainly as a documentation aid and a potential
stepping stone to the reintroduction of smp_mb__after_unlock_lock() used
by RCU.

Documentation/memory-barriers.txt is updated to describe more clearly
the ACQUIRE and RELEASE ordering in this area and to show some examples
of the new barrier in action.

Cc: Boqun Feng <boqun.feng <at> gmail.com>
Cc: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz <at> infradead.org>
Signed-off-by: Will Deacon <will.deacon <at> arm.com>

Based on Paul's patch to describe local vs global transitivity:

  http://lkml.kernel.org/r/20160115173912.GU3818 <at> linux.vnet.ibm.com

 Documentation/memory-barriers.txt   | 63 +++++++++++++++++++++++++++++++++----
(Continue reading)

Will Deacon | 27 Jan 16:00 2016

LATENCYTOP not building on ia64

Hi all,

After da48d094ce5d ("Kconfig: remove HAVE_LATENCYTOP_SUPPORT"),
CONFIG_LATENCYTOP can be selected on all architectures. Unfortunately,
viro reported that this breaks the build for ia64:

  arch/ia64/kernel/entry.S: Assembler messages:
  arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
  arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
  arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
  make[1]: *** [arch/ia64/kernel/entry.o] Error 1

This is because the task_struct is over 8K thanks to the latency_record
array, which means that the 14-bit immediate offset expected by the adds
instruction to grab hold of the thread info flags is now out-of-range on
ia64. I had a quick go at fixing it in entry.S, but I ended up with
worse code due to the need to perform the offset calculation as a
separate step (which introduces a hazard).

We could simply revert da48d094ce5d to make the problem disappear, but
I'd be interested to know whether or not this is an ia64-specific problem
and therefore whether LATENCYTOP should be opt-out as opposed to opt-in
for a given architecture.

Prior to da48d094ce5d, arc, arm, metag, microblaze, parisc, powerpc,
s390, sh, sparc, unicore32 and x86 all selected HAVE_LATENCYTOP_SUPPORT
so assumedly they don't run into problems. arm64 also works ok with the
option enabled.

(Continue reading)

Arnd Bergmann | 25 Jan 16:41 2016

[PATCH] mtd: only use __xipram annotation when XIP_KERNEL is set

When XIP_KERNEL is enabled, some functions are defined in the .data
ELF section because we require them to be in RAM whenever we communicate
with the flash chip. However this causes problems when FTRACE is
enabled and gcc emits calls to __gnu_mcount_nc in the function

drivers/built-in.o: In function `cfi_chip_setup':
:(.data+0x272fc): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined
in .text section in arch/arm/kernel/built-in.o
drivers/built-in.o: In function `cfi_probe_chip':
:(.data+0x27de8): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined
in .text section in arch/arm/kernel/built-in.o
/tmp/ccY172rP.s: Assembler messages:
/tmp/ccY172rP.s:70: Warning: ignoring changed section attributes for .data
/tmp/ccY172rP.s: Error: 1 warning, treating warnings as errors
make[5]: *** [drivers/mtd/chips/cfi_probe.o] Error 1
/tmp/ccK4rjeO.s: Assembler messages:
/tmp/ccK4rjeO.s:421: Warning: ignoring changed section attributes for .data
/tmp/ccK4rjeO.s: Error: 1 warning, treating warnings as errors
make[5]: *** [drivers/mtd/chips/cfi_util.o] Error 1
/tmp/ccUvhCYR.s: Assembler messages:
/tmp/ccUvhCYR.s:1895: Warning: ignoring changed section attributes for .data
/tmp/ccUvhCYR.s: Error: 1 warning, treating warnings as errors

Specifically, this does not work because the .data section is not
marked executable, which leads LD to not generate trampolines for
long calls.

This moves the __xipram functions into their own .xiptext section instead.
The section is still placed next to .data and located in RAM but is marked
(Continue reading)