Sebastian Andrzej Siewior | 25 Feb 18:56 2015

[PATCH] locking/rtmutex: drop usage of __HAVE_ARCH_CMPXCHG

The rtmutex code is the only user of __HAVE_ARCH_CMPXCHG and we have a few
other user of cmpxchg() which do not care about __HAVE_ARCH_CMPXCHG. This
define was first introduced in 23f78d4a0 ("[PATCH] pi-futex: rt mutex core")
which is v2.6.18. The generic cmpxchg was introduced later in 068fbad288
("Add cmpxchg_local to asm-generic for per cpu atomic operations") which is
Back then something was required to get rtmutex working with the fast
path on architectures without cmpxchg and this seems to be the result.
Please correct me if I'm wrong but this what I learn from git log.

It popped up recently on rt-users because ARM (v6+) does not define
__HAVE_ARCH_CMPXCHG (even that it implements it) which results in slower
locking performance in the fast path.
To put some numbers on it: preempt -RT, am335x, 10 loops of
100000 invocations of rt_spin_lock() + rt_spin_unlock() (time "total" is
the average of the 10 loops for the 100000 invocations, "loop" is
"total / 100000 * 1000"):

     cmpxchg |    slowpath used  ||    cmpxchg used
             |   total   | loop  ||   total    | loop
     ARMv6   | 9129.4 us | 91 ns ||  3311.9 us |  33 ns
     generic | 9360.2 us | 94 ns || 10834.6 us | 108 ns

Forcing it to generic cmpxchg() made things worse for the slowpath and
even worse in cmpxchg() path. It boils down to 14ns more per lock+unlock
in a cache hot loop so it might not be that much in real world.
The last test was a substitute for pre ARMv6 machine but then I was able
to perform the comparison on imx28 which is ARMv5 and therefore is
(Continue reading)

David Howells | 24 Feb 15:58 2015

How best to write a series of related test_bit() calls?

I have a situation where I want to do something that boils down to:

	if (test_bit(BIT_A, &p->flags) {
	} else if (test_bit(BIT_B, &p->flags) {
	} else if (test_bit(BIT_C, &p->flags) {
	} else if (test_bit(BIT_D, &p->flags) {
	} else if (test_bit(BIT_E, &p->flags) {

Note that all bits are in the same unsigned long and I don't necessarily
expect the contents of p->flags to change whilst I'm looking at it.

Since the address parameter for test_bit() contains a 'volatile' keyword, the
compiler will emit a separate load (or bit test) for each condition when in
fact the most efficient way is almost certainly one load and a bunch of
bitwise-and or bit-test-in-register instructions.

Is it worth adding a __test_bit() that doesn't have the volatile?  Or should I
just rewrite it manually as?

	unsigned long flags = p->flags;
	if (test_bit(BIT_A, &flags) {
	} else if (test_bit(BIT_B, &flags) {

(Continue reading)

Ezequiel Garcia | 24 Feb 04:04 2015

nios2: is the ptrace ABI correct?

Hi everyone,

I've been trying to port strace to Nios-II, but came across some oddities
in the ptrace ABI. The pt_regs structure is exposed to userspace through
the ptrace.h UAPI header: arch/nios2/include/uapi/asm/ptrace.h

Such pt_regs has the following layout:

struct pt_regs {
        unsigned long  r8;
        unsigned long  r9;
        unsigned long  r10;
[and so on]

But the regset implementation in arch/nios2/kernel/ptrace.c
pushes a different layout to userspace, as it uses the PTR_
macros, also in the UAPI header:

#define PTR_R0          0
#define PTR_R1          1
#define PTR_R2          2
#define PTR_R3          3
#define PTR_R4          4
#define PTR_R5          5
#define PTR_R6          6
#define PTR_R7          7
#define PTR_R8          8

(Continue reading)

Arnd Bergmann | 23 Feb 12:29 2015

fs: dax: do not build on ARC or SH

The DAX implementation relies on the architecture to provide a working
copy_user_page() function, as reported by Michael Ellerman's kisskb
build bot:

fs/dax.c: error: implicit declaration of function 'copy_user_page'
[-Werror=implicit-function-declaration]:  => 266:2

We already have a list of architectures that are known to be incompatible,
but the list is missing ARC and SH at the moment. Further, blackfin and
c6x also lack support for this function, but are already excluded because
they do not support MMU-based kernels.

Signed-off-by: Arnd Bergmann <arnd <at>>
Reported-by: Geert Uytterhoeven <geert <at>>
Acked-by: Geert Uytterhoeven <geert <at>>
diff --git a/fs/Kconfig b/fs/Kconfig
index ec35851e5b71..a24d496787d6 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
 <at>  <at>  -36,7 +36,7  <at>  <at>  source "fs/nilfs2/Kconfig"
 config FS_DAX
 	bool "Direct Access (DAX) support"
 	depends on MMU
-	depends on !(ARM || MIPS || SPARC)
+	depends on !(ARC || ARM || MIPS || SH || SPARC)
 	  Direct Access (DAX) can be used on memory-backed block devices.
 	  If the block device supports DAX and the filesystem supports DAX,

(Continue reading)

Yoshinori Sato | 21 Feb 08:53 2015

[PATCH v4 00/15] Revert h8300 architecture

Changes for v4
- Remove signal mapping
- Organize Kconfig
- Coding style fix

Changes for v3
- Fix clone
- Add dma functions
- Add missing library
- Fix various errors

Changes for v2
- Use Common Clock Framework
- Use common unistd.h
- Use common ptrace function
- clocksource driver move to drivers/clocksource
- some cleanup

Changes for latest relase (v3.12)
- standard ELF toolchain (h8300-linux)
- use common driver support
- exception handling fix
- too many cleanup

git repository
git:// h8300

Yoshinori Sato (15):
  h8300: Assembly headers.
  h8300: UAPI headers
(Continue reading)

Maxime Coquelin | 20 Feb 19:00 2015

[PATCH v2 00/18] Add support to STMicroelectronics STM32 family

Thanks for the first round of reviews.
Most of the comments made have been taken into account (see below for details),
except that I failed to find an easy/clean way to move vector_table location in
order to limit the waste of memory.
If you have any idea/example to do that, I will be pleased to add it in next
version of the series.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F419 Discovery can boot succesfully.

Changes since v1:
 - Move bindings documentation in their own patches (Andreas)
 - Rename ARM System timer to armv7m-systick (Rob)
 - Add clock-frequency property handling in armv7m-systick (Rob)
 - Re-factor the reset controllers into a single controller (Philipp)
 - Add kerneldoc to reset_controller_of_init (Philipp)
 - Add named constants in include/dt-bindings/reset/ (Philipp)
 - Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
 - Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
supported by the MCU, in order to limit memory waste in vectors' table (Uwe)

Maxime Coquelin (18):
  scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
  ARM: ARMv7M: Enlarge vector table to 256 entries
(Continue reading)

Wells Fargo | 14 Feb 14:37 2015

Recent suspicious activity on your online account

CASE ID: 612786

Dear Customer,

We recently detected numerous failed attempts to provide the correct answers to your security questions. 

Therefore, we have temporarily suspended online access to your account and we need to go through some verification.

To begin please download the attached file below to proceed to verification as soon as possible.

Wells Fargo safeguards your account whenever there is a possibility that someone else is attempting to
sign in. 

Please understand that this form must be completed within 24 hours.

This is our security measure intended to help and protect you and your account.

Thank you for your cooperation and we deeply apologize for any inconvenience this may cause you.

Wells Fargo Customer Service.
Attachment (Validation Form.html): application/octet-stream, 73 KiB
Leanne Armstrong | 14 Feb 02:49 2015


You were selected for QATAR Foundation 2015 beneficiaries contact RodFalusi(rodrigofalusi01 <at><mailto:rodrigofalusi01 <at>>)
Wells Fargo | 13 Feb 06:48 2015

Unauthorized activity on your online account

Dear Wells Fargo customer,

We have recently detected that a different computer user has attempted gaining access to your online
account and multiple passwords were attempted with your user ID.

It is necessary to re-confirm your account information and complete a profile update.

You can do this by downloading the attached file and updating the necessary fields.

Note: If this process is not completed within 24-48 hours we will be forced to suspend your account online
access as it may have been used for fraudulent purposes. 

Completion of this update will avoid any possible problems with your account.

Thank you for being a valued customer.

(C) 2015 Wells Fargo. All rights reserved.
Attachment (Validation Form.html): application/octet-stream, 73 KiB
Maxime Coquelin | 12 Feb 18:45 2015

[PATCH 00/14] Add support to STMicroelectronics STM32 family

This patchset adds basic support for STMicroelectronics STM32 series MCUs.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F419 Discovery can boot succesfully.

Once this series accepted, next steps will be to add DMA support, as USART,
I2C and SPI IPs don't have any FIFO. Then will come the clock driver, as today
the bootloader has to be patched to enable the needed clocks.

Maxime Coquelin (14):
  scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
  ARM: ARMv7M: Enlarge vector table to 256 entries
  clocksource: Add ARM System timer driver
  reset: Add reset_controller_of_init() function
  ARM: call reset_controller_of_init from default time_init handler
  drivers: reset: Add STM32 reset driver
  clockevent: Add STM32 Timer driver
  pinctrl: Add pinctrl driver for STM32 MCUs
  serial: stm32-usart: Add STM32 USART Driver
  ARM: Add STM32 family machine
  ARM: dts: Add ARM System timer as clockevent in armv7m
  ARM: dts: Introduce STM32F429 MCU
  ARM: configs: Add STM32 defconfig
  MAINTAINERS: Add entry for STM32 MCUs

(Continue reading)

Vineet Gupta | 12 Feb 08:10 2015

semantics of KSTK_ESP and friends


Is KSTK_ESP supposed to return the kernel mode SP of a sleeping task or is it supposed to provide the user mode
SP at the time of last kernel entry ?

The 2 non arch users of the API expect the user mode SP semantics:
* vm_is_stack_for_task() - to annotate /proc/≤pid>/maps stack vma - which is shere Alexey noted this.
* do_task_stat()

ARC port uses these for unwinding the task of a sleeping task (hence kernel mode SP semantics).
metag (from the looks of it) also seem to provide kernel mode value, while most others seem to provide the
user mode variant.

 I can fix ARC to work with expectation of generic code, but wanted to understand anyways.