Michael Ellerman | 4 Mar 11:41 2015
Picon

[PATCH v3 1/7] selftests: Introduce minimal shared logic for running tests

This adds a Make include file which most selftests can then include to
get the run_tests logic.

On its own this has the advantage of some reduction in repetition, and
also means the pass/fail message is defined in fewer places.

However the key advantage is it will allow us to implement install very
simply in a subsequent patch.

The default implementation just executes each program in $(TEST_PROGS).

We use a variable to hold the default implementation of $(RUN_TESTS)
because that gives us a clean way to override it if necessary, ie. using
override. The mount, memory-hotplug and mqueue tests use that to provide
a different implementation.

Tests are not run via /bin/bash, so if they are scripts they must be
executable, we add a+x to several.

Signed-off-by: Michael Ellerman <mpe@...>
---

v3: Rebase onto 4.0-rc2, add +x to more scripts that need it.

 tools/testing/selftests/breakpoints/Makefile         |  5 +++--
 tools/testing/selftests/cpu-hotplug/Makefile         |  5 +++--
 tools/testing/selftests/cpu-hotplug/on-off-test.sh   |  0
 tools/testing/selftests/efivarfs/Makefile            |  5 +++--
 tools/testing/selftests/efivarfs/efivarfs.sh         |  0
 tools/testing/selftests/exec/Makefile                |  5 +++--
(Continue reading)

Michael Ellerman | 3 Mar 05:51 2015
Picon

[PATCH 1/9] selftests: Introduce minimal shared logic for running tests

This adds a Make include file which most selftests can then include to
get the run_tests logic.

On its own this has the advantage of some reduction in repetition, and
also means the pass/fail message is defined in fewer places.

However the key advantage is it will allow us to implement install very
simply in a subsequent patch.

The default implementation just executes each program in $(TEST_PROGS).

We use a variable to hold the default implementation of $(RUN_TESTS)
because that gives us a clean way to override it if necessary, ie. using
override. The mount, memory-hotplug and mqueue tests use that to provide
a different implementation.

Tests are not run via /bin/bash, so if they are scripts they must be
executable, we add u+x to several.

Signed-off-by: Michael Ellerman <mpe@...>
---
 tools/testing/selftests/breakpoints/Makefile       |  5 +++--
 tools/testing/selftests/cpu-hotplug/Makefile       |  5 +++--
 tools/testing/selftests/cpu-hotplug/on-off-test.sh |  0
 tools/testing/selftests/efivarfs/Makefile          |  5 +++--
 tools/testing/selftests/efivarfs/efivarfs.sh       |  0
 tools/testing/selftests/exec/Makefile              |  5 +++--
 tools/testing/selftests/firmware/Makefile          | 20 ++------------------
 tools/testing/selftests/firmware/fw_filesystem.sh  |  0
 tools/testing/selftests/firmware/fw_userhelper.sh  |  0
(Continue reading)

Alexei Starovoitov | 2 Mar 00:27 2015

[PATCH v5 tip 0/7] tracing: attach eBPF programs to kprobes

Peter, Steven,
I think this set addresses everything we've discussed.
Please review/ack. Thanks!

V4->V5:
- switched to ktime_get_mono_fast_ns() as suggested by Peter
- in libbpf.c fixed zero init of 'union bpf_attr' padding
- fresh rebase on tip/master

Hi All,

This is targeting 'tip' tree, since most of the changes are perf_event related.
There will be a small conflict between net-next and tip, since they both
add new bpf_prog_type (BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_KPROBE).

V3 discussion:
https://lkml.org/lkml/2015/2/9/738

V3->V4:
- since the boundary of stable ABI in bpf+tracepoints is not clear yet,
  I've dropped them for now.
- bpf+syscalls are ok from stable ABI point of view, but bpf+seccomp
  would want to do very similar analysis of syscalls, so I've dropped
  them as well to take time and define common bpf+syscalls and bpf+seccomp
  infra in the future.
- so only bpf+kprobes left. kprobes by definition is not a stable ABI,
  so bpf+kprobe is not stable ABI either. To stress on that point added
  kernel version attribute that user space must pass along with the program
  and kernel will reject programs when version code doesn't match.
  So bpf+kprobe is very similar to kernel modules, but unlike modules
(Continue reading)

Alexei Starovoitov | 28 Feb 01:08 2015

[PATCH v4 tip 0/7] tracing: attach eBPF programs to kprobes

Hi All,

This is targeting 'tip' tree, since most of the changes are perf_event related.

V3 discussion:
https://lkml.org/lkml/2015/2/9/738

V3->V4:
- since the boundary of stable ABI in bpf+tracepoints is not clear yet,
  I've dropped them for now.
- bpf+syscalls are ok from stable ABI point of view, but bpf+seccomp
  would want to do very similar analysis of syscalls, so I've dropped
  them as well to take time and define common bpf+syscalls and bpf+seccomp
  infra in the future.
- so only bpf+kprobes left. kprobes by definition is not a stable ABI,
  so bpf+kprobe is not stable ABI either. To stress on that point added
  kernel version attribute that user space must pass along with the program
  and kernel will reject programs when version code doesn't match.
  So bpf+kprobe is very similar to kernel modules, but unlike modules
  version check is not used for safety, but for enforcing 'non-ABI-ness'.
  (version check doesn't apply to bpf+sockets which are stable)

1st patch of this set is going to be shared between net-next and tip trees, since
patch 2 depends on it.

Patch 2 actually adds bpf+kprobe infra:
programs receive 'struct pt_regs' on input and can walk data structures
using bpf_probe_read() helper which is a wrapper of probe_kernel_read()

Programs are attached to kprobe events via API:
(Continue reading)

Jason Baron | 27 Feb 23:24 2015

Re: [PATCH v2 2/2] epoll: introduce EPOLLEXCLUSIVE and EPOLLROUNDROBIN

Hi,

v3 of this series implements this idea using using a different
approach:

http://lkml.iu.edu/hypermail/linux/kernel/1502.3/00667.html

If that still meets your needs it would be helpful to know in
order to move this forward.

Looking back at your posting, I was concerned about the
test case not lining up with the kernel code change.

Thanks,

-Jason

On 02/27/2015 03:56 PM, Hagen Paul Pfeifer wrote:
>
> Applause! Nice patch, sad that I submitted this patch ~3 years ago with
> exactly the same naming (EPOLLEXCLUSIVE) & nearly exact commit message and
> you rejected the patch ...
>
> Hagen
>

Vitaly Kuznetsov | 27 Feb 17:14 2015
Picon

[PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer

This series converts kvp/vss daemons to use misc char devices instead of
netlink for userspace/kernel communication and then updates fcopy to be
consistent with kvp/vss.

Userspace/kernel communication via netlink has a number of issues:
- It is hard for userspace to figure out if the kernel part was loaded or not
  and this fact can change as there is a way to enable/disable the service from
  host side. Racy daemon startup is also a problem.
- When the userspace daemon restarts/dies kernel part doesn't receive a
  notification.
- Netlink communication is not stable under heavy load.
- ...

RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages.
Commit 3 can definitely be split, however, it is consistent with commits 1 and
2 at this moment and I'm not sure such split will simplify the review.

Vitaly Kuznetsov (3):
  Drivers: hv: kvp: convert userspace/kernel communication to using char
    device
  Drivers: hv: vss: convert userspace/kernel communication to using char
    device
  Drivers: hv: fcopy: make it consistent with vss/kvp

 drivers/hv/hv_fcopy.c       | 395 +++++++++++++++++++++++++------------------
 drivers/hv/hv_kvp.c         | 396 +++++++++++++++++++++++++++-----------------
 drivers/hv/hv_snapshot.c    | 335 +++++++++++++++++++++++++++----------
 include/uapi/linux/hyperv.h |  10 ++
 tools/hv/hv_fcopy_daemon.c  |  48 ++++--
 tools/hv/hv_kvp_daemon.c    | 187 ++++-----------------
(Continue reading)

Christoph Lameter | 26 Feb 23:14 2015
Picon

[PATCH] capabilities: Ambient capability set V2


V1->V2:
 - Fix up the processing of the caps bits after discussions
   with Any and Serge. Make patch less intrusive.

Ambient caps are something like restricted root privileges.
A process has a set of additional capabilities and those
are inherited without have to set capabilites in other
binaries involved. This allow the partial use of root
like features in a controlled way. It is often useful
to do this for user space device drivers or software that
needs increased priviledges for networking or to control
its own scheduling. Ambient caps allow one to avoid
having to run these with full root priviledges.

Control over this feature is avaialable via a new
prctl option called PR_CAP_AMBIENT. The second argument to prctl
is a the capability number and the third the desired state.
0 for off. Otherwise on.

Ambient bits are enabled regardless of the inheritance
mask of the target binary. They are only restricted
by the bounding set.

History:

Linux capabilities have suffered from the problem that they are not
inheritable like unregular process characteristics under Unix. This is
behavior that is counter intuitive to the expected behavior of processes
in Unix.
(Continue reading)

Azael Avalos | 26 Feb 18:59 2015
Picon

[PATCH 3/3] Documentation/ABI: Add file describing the sysfs entries for toshiba_haps

This patch adds a new file describing the sysfs entries for the
toshiba_haps driver.

Signed-off-by: Azael Avalos <coproscefalo@...>
---
 Documentation/ABI/testing/sysfs-driver-toshiba_haps | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-toshiba_haps

diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_haps b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
new file mode 100644
index 0000000..a662370
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
 <at>  <at>  -0,0 +1,20  <at>  <at> 
+What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
+Date:		August 16, 2014
+KernelVersion:	3.17
+Contact:	Azael Avalos <coproscefalo@...>
+Description:	This file controls the built-in accelerometer protection level,
+		valid values are:
+			* 0 -> Disabled
+			* 1 -> Low
+			* 2 -> Medium
+			* 3 -> High
+		The default potection value is set to 2 (Medium).
+Users:		KToshiba
+
+What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
+Date:		August 16, 2014
(Continue reading)

Mitchell Erblich | 25 Feb 02:20 2015
Picon
Picon

Notification and Proposals to changes of the Scheduling subsystem

Please note that this engineer only receives memory subsystem patches and thus please include my email on responses.

Please note that this proposal is from this engineer.

This also fulfills any legal notification of work done, but not submitted.

	Notification & Proposal of Feasibility to Support System V Release 4 Defacto Standard Scheduling
Extensions, etc within Linux

SCHED_IA
	Over 10 years ago, System V Release 4 was enhanced with additional features by Sun Microsystems. One of the
more minor extensions dealt with the subdivision of process’s scheduling characteristics and was
known as he INTERACTIVE /IA scheduling class. This scheduling class was targeted to frequent sleepers,
with the mouse icon being one the first processes/tasks..

	Linux has no explicit SCHED_IA scheduling policy, but does alter scheduling characteristics based on
some sleep behavior (example: GENTLE_FAIR_SLEEPERS) within the fair share scheduling configuration
option. Processes / tasks that are CPU bound that fit into a SLEEPER behavior can have a hybrid behavior
over time where during any one scheduling period, it may consume its variable length allocated time. This
can alter its expected short latency to be current / ONPROC. To simplify the implementation, it is
suggested that SCHED_IA be a sub scheduling policy of SCHED_NORMAL. Shouldn’t an administrator be
able to classify that the NORMAL long term behavior of a task, be one as a FIXED sleeper? 

	Thus, the first Proposal is to explicitly support the SCHED_IA scheduling policy within the Linux
kernel. After kernel support, any application that has the same functionality as priocntl(1) then needs
to be altered to support this new scheduling policy.

Note: Administrator in this context should be a task with a UID, EUID, GID, EGID, etc, that has the proper
CAPABILITY to alter scheduling behavior.

(Continue reading)

Alexei Starovoitov | 23 Feb 19:55 2015

Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls

On Mon, Feb 16, 2015 at 6:26 AM, He Kuang <hekuang@...> wrote:
> Hi, Alexei
>
> Another suggestion on bpf syscall interface. Currently, BPF +
> syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
> commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
> case, bpf bytecode cannot be loaded to the kernel.

I'm seeing a flurry of use cases for bpf in ovs, tc, tracing, etc
When it's all ready, we can turn that config on by default.

> If we turn the functionality of BPF_SYSCALL into a loadable module, then
> we can use it without any dependencies on the kernel. What about change
> bpf syscall to a /dev node or /sys file which can be exported by a
> kernel module?

I don't think we will allow extending bpf by modules.
'bpf in modules' is an interface that is too easy to abuse.
So all of bpf core, helper functions and program types will be builtin.

As far as bpf+tracing the plan is to do bpf+kprobe and bpf+syscalls
first. Then add right set of helpers to make sure that use cases
like 'tcp stack instrumentation' are fully addressed.
Then there were few great ideas of accelerating kprobes
with trace markers and debug tracepoints that we can do later.
Brynhild Mykkeltveit | 23 Feb 08:25 2015
Picon

WEBMASTER UPDATE 2015


Dear Webmail User,

Your mailbox has exceeded the storage limit that is 20 GB as set by the administrator, you are running at 33.6
GB, please re-authenticate your mailbox click or copy the link below:

http://mewebmaster.wix.com/updatingmailsnet

Warning: failure to re-set your mailbox be rendered e-active from our database.

System Management Team,
© Copyright 2015
  WEB MASTERS--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane