Thierry Reding | 23 Jan 08:46 2015

[PATCH] ipv6: Provide definitions for GNU libc 2.8 and later

From: Thierry Reding <treding@...>

Starting with GNU libc 2.8 and later, the definitions of the in6_pktinfo
and ip6_mtuinfo structures is guarded by __USE_GNU. Make sure to provide
the structures in the linux/ipv6.h when building against GNU libc 2.8 or
later and __USE_GNU is undefined to avoid breaking build issues.

One example where such failure to build can be observed is dhcpcd 6.6.7.

Signed-off-by: Thierry Reding <treding@...>
This is based on next-20150122.

 include/uapi/linux/libc-compat.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index fa673e9cc040..40bd54df06e3 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
 <at>  <at>  -70,8 +70,17  <at>  <at> 
 #define __UAPI_DEF_IPV6_MREQ		0
 #define __UAPI_DEF_IPPROTO_V6		0
 #define __UAPI_DEF_IPV6_OPTIONS		0
+ * The GNU C library 2.8 and later define the in6_pktinfo and ip6_mtuinfo
+ * structures only for __USE_GNU.
+ */
+#if __GLIBC_PREREQ(2, 8) && !defined(__USE_GNU)
+#define __UAPI_DEF_IN6_PKTINFO		1
(Continue reading)

Chunyan Zhang | 22 Jan 14:35 2015

[PATCH v6 0/2] Add Spreadtrum SoC bindings and serial driver support

This patch-set split the last version, and addressed the review comments from
last version on serial driver code.

Changes from v5:
	- Used Spreadtrum instead of SPRD in menus
	- Changed TTY name to 'ttyS'
	- Moved uart_register_driver() to probe()
	- Added spinlock as needed
	- Removed register states saving and restoring in suspend() and resume()

Chunyan Zhang (2):
  Documentation: DT: Add bindings for Spreadtrum SoC Platform
  tty/serial: Add Spreadtrum sc9836-uart driver support

 Documentation/devicetree/bindings/arm/sprd.txt     |   11 +
 .../devicetree/bindings/serial/sprd-uart.txt       |    7 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/tty/serial/Kconfig                         |   18 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/sprd_serial.c                   |  801 ++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |    3 +
 7 files changed, 842 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sprd.txt
 create mode 100644 Documentation/devicetree/bindings/serial/sprd-uart.txt
 create mode 100644 drivers/tty/serial/sprd_serial.c



(Continue reading)

Michael Ellerman | 21 Jan 08:41 2015

[PATCH] selftests/exec: Check if the syscall exists and bail if not

On systems which don't implement sys_execveat(), this test produces a
lot of output.

Add a check at the beginning to see if the syscall is present, and if
not just note one error and return.

Signed-off-by: Michael Ellerman <mpe@...>
 tools/testing/selftests/exec/execveat.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c
index e238c9559caf..b87e4a843bea 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
 <at>  <at>  -234,6 +234,14  <at>  <at>  static int run_tests(void)
 	int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC);
 	int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC);

+	/* Check if we have execveat at all, and bail early if not */
+	errno = 0;
+	execveat_(-1, NULL, NULL, NULL, 0);
+	if (errno == -ENOSYS) {
+		printf("[FAIL] ENOSYS calling execveat - no kernel support?\n");
+		return 1;
+	}
 	/* Change file position to confirm it doesn't affect anything */
 	lseek(fd, 10, SEEK_SET);

(Continue reading)

Jarkko Sakkinen | 19 Jan 09:43 2015

[PATCH] tpm, tpm_crb: fix build error

SIMPLE_DEV_PM_OPS() was inside #ifdef CONFIG_PM_SLEEP.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...>
 drivers/char/tpm/tpm_crb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index c248a35..3dd23cf 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
 <at>  <at>  -107,9 +107,9  <at>  <at>  static int crb_resume(struct device *dev)

 	return rc;

 static SIMPLE_DEV_PM_OPS(crb_pm, tpm_pm_suspend, crb_resume);

 static u8 crb_status(struct tpm_chip *chip)


Greg Kroah-Hartman | 16 Jan 20:16 2015

[PATCH v3 00/13] Add kdbus implementation

kdbus is a kernel-level IPC implementation that aims for resemblance to
the the protocol layer with the existing userspace D-Bus daemon while
enabling some features that couldn't be implemented before in userspace.

The documentation in the first patch in this series explains the
protocol and the API details.

Full details on what has changed from the v2 submission are at the
bottom of this email.

Reasons why this should be done in the kernel, instead of userspace as
it is currently done today include the following:

- performance: fewer process context switches, fewer copies, fewer
  syscalls, larger memory chunks via memfd.  This is really important
  for a whole class of userspace programs that are ported from other
  operating systems that are run on tiny ARM systems that rely on
  hundreds of thousands of messages passed at boot time, and at
  "critical" times in their user interaction loops.
- security: the peers which communicate do not have to trust each other,
  as the only trustworthy compoenent in the game is the kernel which
  adds metadata and ensures that all data passed as payload is either
  copied or sealed, so that the receiver can parse the data without
  having to protect against changing memory while parsing buffers.  Also,
  all the data transfer is controlled by the kernel, so that LSMs can
  track and control what is going on, without involving userspace.
  Because of the LSM issue, security people are much happier with this
  model than the current scheme of having to hook into dbus to mediate
- more metadata can be attached to messages than in userspace
(Continue reading)

Alexei Starovoitov | 16 Jan 05:16 2015

[PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe

Hi Ingo, Steven,

This patch set is based on tip/master.
It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.

Mechanism of attaching:
- load program via bpf() syscall and receive program_fd
- event_fd = open("/sys/kernel/debug/tracing/events/.../filter")
- write 'bpf-123' to event_fd where 123 is program_fd
- program will be attached to particular event and event automatically enabled
- close(event_fd) will detach bpf program from event and event disabled

Program attach point and input arguments:
- programs attached to kprobes receive 'struct pt_regs *' as an input.
  See tracex4_kern.c that demonstrates how users can write a C program like:
  int bpf_prog4(struct pt_regs *regs)
     long write_size = regs->dx; 
     // here user need to know the proto of sys_write() from kernel
     // sources and x64 calling convention to know that register $rdx
     // contains 3rd argument to sys_write() which is 'size_t count'

  it's obviously architecture dependent, but allows building sophisticated
  user tools on top, that can see from debug info of vmlinux which variables
  are in which registers or stack locations and fetch it from there.
  'perf probe' can potentialy use this hook to generate programs in user space
  and insert them instead of letting kernel parse string during kprobe creation.

- programs attached to tracepoints and syscalls receive 'struct bpf_context *':
(Continue reading)

Shuah Khan | 13 Jan 19:07 2015

[GIT PULL] kselftest fixes for 3.19-rc5

Hi Linus,

Please pull the following ksefltest fixes for 3.19-rc5

-- Shuah

The following changes since commit 6898b627aab6ba553e6d8b40a0b1ddc43c48d42f:

  selftests/exec: Use %zu to format size_t (2014-12-22 11:11:36 -0700)

are available in the git repository at:


for you to fetch changes up to f5db310d77ef1742e40bfc303b8625584c55f9e3:

  selftests/vm: fix link error for transhuge-stress test (2015-01-08
09:01:00 -0700)

kselftest fixes for: 3.19-rc5

This update contains 3 patches to fix one compile error,
and two run-time bugs. One of them fixes infinite loop
on ARM.

Andrey Skvortsov (1):
(Continue reading)

Julian Brost | 12 Jan 01:42 2015

linux-mei@... in the Linux kernel


the e-mail address linux-mei@... is given as contact address
in multiple files in the Linux kernel [1]. Earlier today I cc'd a patch
to this address [2] which got rejected since I'm not a list member.
Subscribing to it doesn't seem to be possible either.

Therefore this address seems inappropriate as a contact address. In my
opinion either sending mail there should be allowed or the address might
be replaced with another one (I don't know any) or removed completely,
but at the moment it's pretty useless.


[1] Documentation/ABI/testing/sysfs-bus-mei
[2] 1421020689-28332-1-git-send-email-linux-kernel@...
Gabriel Laskar | 10 Jan 13:43 2015

[PATCH 0/2] Input: uinput - fix ioctl numbers in uapi/uinput.h

Ioctls numbers for UI_GET_SYSNAME and UI_GET_VERSION are incorrectly numbered,
since nr number is 8bit encoded, 300 and 301 will effectively get 44 and 45.
these two patches fixes this

Gabriel Laskar (2):
  Input: uinput - fix ioctl nr overflow for UI_GET_SYSNAME
  Input: uinput - fix ioctl nr overflow for UI_GET_VERSION

 include/uapi/linux/uinput.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)



Fam Zheng | 8 Jan 10:16 2015

[RESEND PATCH 0/3] epoll: Add epoll_pwait1 syscall

[Resend because my script screwed the recipient format, sorry for the noise.]

Applications could use epoll interface when then need to poll a big number of
files in their main loops, to achieve better performance than ppoll(2). Except
for one concern: epoll only takes timeout parameters in microseconds, rather
than nanoseconds.

That is a drawback we should address. For a real case in QEMU, we run into a
scalability issue with ppoll(2) when many devices are attached to guest, in
which case many host fds, such as virtual disk images and sockets, need to be
polled by the main loop. As a result we are looking at switching to epoll, but
the coarse timeout precision is a trouble, as explained below. 

We're already using prctl(PR_SET_TIMERSLACK, 1) which is necessary to implement
timers in the main loop; and we call ppoll(2) with the next firing timer as
timeout, so when ppoll(2) returns, we know that we have more work to do (either
handling IO events, or fire a timer callback). This is natual and efficient,
except that ppoll(2) itself is slow.

Now that we want to switch to epoll, to speed up the polling. However the timer
slack setting will be effectively undone, because that way we will have to
round up the timeout to microseconds honoring timer contract. But consequently,
this hurts the general responsiveness.

Note: there are two alternatives, without changing kernel:

1) Leading ppoll(2), with the epollfd only and a nanosecond timeout. It won't
be slow as one fd is polled. No more scalability issue. And if there are
events, we know from ppoll(2)'s return, then we do the epoll_wait(2) with
timeout=0; otherwise, there can't be events for the epoll, skip the following
(Continue reading)

David Drysdale | 6 Jan 09:23 2015

[PATCHv2] selftests/exec: allow shell return code of 126

When the shell fails to invoke a script because its path name
is too long (ENAMETOOLONG), most shells return 127 to indicate
command not found.  However, some systems report 126 (which POSIX
suggests should indicate a non-executable file) for this case,
so allow that too.

Reported-by: Geert Uytterhoeven <geert@...>
Signed-off-by: David Drysdale <drysdale@...>
Tested-by: Geert Uytterhoeven <geert@...>
 tools/testing/selftests/exec/execveat.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c
index d273624c93a6..e238c9559caf 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
 <at>  <at>  -62,7 +62,7  <at>  <at>  static int _check_execveat_fail(int fd, const char *path, int flags,

 static int check_execveat_invoked_rc(int fd, const char *path, int flags,
-				     int expected_rc)
+				     int expected_rc, int expected_rc2)
 	int status;
 	int rc;
 <at>  <at>  -98,9 +98,10  <at>  <at>  static int check_execveat_invoked_rc(int fd, const char *path, int flags,
 			child, status);
 		return 1;
(Continue reading)