Andy Lutomirski | 30 Oct 04:55 2014
Picon

Re: kdbus: add connection, queue handling and message validation code

On Wed, Oct 29, 2014 at 8:47 PM, Eric W. Biederman
<ebiederm@...> wrote:
> Greg Kroah-Hartman <gregkh@...> writes:
>
>> From: Daniel Mack <daniel@...>
>>
>> This patch adds code to create and destroy connections, to validate
>> incoming messages and to maintain the queue of messages that are
>> associated with a connection.
>>
>> Note that connection and queue have a 1:1 relation, the code is only
>> split in two parts for cleaner separation and better readability.
>
> You are not performing capability checks at open time.
>
> As such this API is suceptible to a host of file descriptor passing attacks.

To be fair, write(2) doesn't work on these fds, so the usual attacks
don't work.  But who knows what absurd things kdbus clients will do
with fd passing?

--Andy

>
>> Signed-off-by: Daniel Mack <daniel@...>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@...>
>> ---
>
>> +/*
>> + * Check for maximum number of messages per individual user. This
(Continue reading)

Greg Kroah-Hartman | 29 Oct 23:00 2014

[PATCH 00/12] 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 added by the first patch in this series is meant to
explain all protocol and API details comprehensively, but here's a terse
list of the kdbus key features:

 * Implemented as a char driver, which creates devices on demand when
   they are created.

 * Message transfer over shared memory areas in each of the peer's
   task to avoid unnecessary extra data copies during message exchanges.

 * Optional passing of file descriptors and sealed memfds along with
   messages.

 * No demarshalling of any message content from inside the kernel;
   the driver stays entirely agnostic to the transported payload.

 * Support for multiple domains, completely separated from each other,
   allowing multiple virtualized instances to be used at the same time.

 * Support for peer-to-peer unicast and multicast messages.

 * Attachment of trustable metadata to each message on demand, such as
   the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline,
   cgroup path, capabilities, security label, audit information, etc,
   each taken at the time the sender issued the ioctl to send the
   message. Which of those are actually recorded and attached is
(Continue reading)

Li Xi | 26 Oct 06:22 2014
Picon

[v5 0/5] quota: add project quota support for ext4

The following patches propose an implementation of project quota
support for ext4. A project is an aggregate of unrelated inodes
which might scatter in different directories. Inodes belongs to a
project possesses a same identification i.e. 'project ID', just
like every inode has its user/group identification. The following
patches adds project quota as supplement to the former uer/group
quota types.

The semantics of ext4 project quota is consistent with XFS. Each
directory can have EXT4_INODE_PROJINHERIT flag set. When the
EXT4_INODE_PROJINHERIT flag of a parent directory is not set, a
newly created inode under that directory will have a default project
ID (i.e. 0). And its EXT4_INODE_PROJINHERIT flag is not set either.
When this flag is set on a directory, following rules will be kept:

1) The newly created inode under that directory will inherit both
the EXT4_INODE_PROJINHERIT flag and the project ID from its parent
directory.

2) Hard-linking a inode with different project ID into that directory
will fail with errno EXDEV.

3) Renaming a inode with different project ID into that directory
will fail with errno EXDEV. However, 'mv' command will detect this
failure and copy the renamed inode to a new inode in the directory.
Thus, this new inode will inherit both the project ID and
EXT4_INODE_PROJINHERIT flag.

4) If the project quota of that ID is being enforced, statfs() on
that directory will take the quotas as another upper limits along
(Continue reading)

Mark Rutland | 24 Oct 15:56 2014

[RFC PATCH 0/1] arm64: Fix /proc/cpuinfo

Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
manner which prevents some otherwise portable applications from
functioning as expected. Specifically, the "Features" line describes the
64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
certain applications which attempt to parse /proc/cpuinfo to detect
features rather than directly using the hwcaps exposed via auxval.

Additionally, the arm64 /proc/cpuinfo format only provides identifying
information for a single CPU (unlike 32-bit), which is problematic for
systems with heterogeneous CPUs (i.e. big.LITTLE).

This patch attempts to solve both issues. I believe the contentious part
is what to do with the Features line, and for that there are a number of
possibilities:

[a] Only print the 64-bit hwcaps

    This would match our current behaviour. However certain 32-bit
    applications will not detect CPU features correctly, and could fail
    to launch. The appropriate hwcaps are available in auxval, but this
    will not be of help to existing binaries.

[b] Append the 64-bit and 32-bit hwcaps

    This would allow for a consistent format. However, some
    human-readable hwcap names have been reused for analogous
    instruction set features (e.g. "aes") despite 32-bit and 64-bit
    instruction set support being largely unrelated per the
    architecture. This could lead to applications mis-detecting
    instruction set support on some CPUs in future, and may be
(Continue reading)

Vitaly Kuznetsov | 24 Oct 12:20 2014
Picon

[PATCH] Drivers: hv: util: make struct hv_do_fcopy match Hyper-V host messages

An attempt to fix fcopy on i586 (bc5a5b0 Drivers: hv: util: Properly pack the data
for file copy functionality) led to a regression on x86_64 (and actually didn't fix
i586 breakage). Fcopy messages from Hyper-V host come in the following format:

struct do_fcopy_hdr   |   36 bytes
0000                  |    4 bytes
offset                |    8 bytes
size                  |    4 bytes
data                  | 6144 bytes

On x86_64 struct hv_do_fcopy matched this format without ' __attribute__((packed))'
and on i586 adding ' __attribute__((packed))' to it doesn't change anything. Keep
the structure packed and add padding to match re reality. Tested both i586 and x86_64
on Hyper-V Server 2012 R2.

Signed-off-by: Vitaly Kuznetsov <vkuznets@...>
---
 include/uapi/linux/hyperv.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
index 0a8e6ba..bb1cb73 100644
--- a/include/uapi/linux/hyperv.h
+++ b/include/uapi/linux/hyperv.h
 <at>  <at>  -134,6 +134,7  <at>  <at>  struct hv_start_fcopy {

 struct hv_do_fcopy {
 	struct hv_fcopy_hdr hdr;
+	__u32   pad;
 	__u64	offset;
(Continue reading)

Michael Ellerman | 23 Oct 07:07 2014
Picon

[PATCH 1/3] kcmp: Move kcmp.h into uapi

kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.

Signed-off-by: Michael Ellerman <mpe@...>
---
 include/linux/kcmp.h      | 13 +------------
 include/uapi/linux/Kbuild |  1 +
 include/uapi/linux/kcmp.h | 17 +++++++++++++++++
 3 files changed, 19 insertions(+), 12 deletions(-)
 create mode 100644 include/uapi/linux/kcmp.h

diff --git a/include/linux/kcmp.h b/include/linux/kcmp.h
index 2dcd1b3aafc8..9dfb23e1771b 100644
--- a/include/linux/kcmp.h
+++ b/include/linux/kcmp.h
 <at>  <at>  -1,17 +1,6  <at>  <at> 
 #ifndef _LINUX_KCMP_H
 #define _LINUX_KCMP_H

-/* Comparison type */
-enum kcmp_type {
-	KCMP_FILE,
-	KCMP_VM,
-	KCMP_FILES,
-	KCMP_FS,
-	KCMP_SIGHAND,
-	KCMP_IO,
-	KCMP_SYSVSEM,
-
(Continue reading)

Shuah Khan | 21 Oct 22:15 2014

system size test

Hi Tim,

You mentioned you have a size test you would like to send it for
inclusion under selftest? Are you still planning to do that?

thanks,
-- Shuah
--

-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@... | (970) 217-8978
Shuah Khan | 21 Oct 22:10 2014

rt-tester - move under selftests

Andrew/Ingo/Thomas,

You are all on the signed-off list for rt-tester. I have been poking
around the source tree looking for existing test and came across rt-tester.

What are your thoughts on rt-tester suitability to reside under
tools/testing/selftest and becoming part of kselftest target?
Would you like see it moved under the kselftest umbrella?

thanks,
-- Shuah
--

-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@... | (970) 217-8978
Prarit Bhargava | 21 Oct 18:47 2014
Picon

[PATCH V2] kernel, add bug_on_warn

There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system.  Sometimes this is easy to do, other times (such as
in the case of a remote admin) it is not trivial to send new images to the
user.

A much easier method would be a switch to change the WARN() over to a
BUG().  This makes debugging easier in that I can now test the actual
image the WARN() was seen on and I do not have to engage in remote
debugging.

This patch adds a bug_on_warn kernel parameter, which calls BUG() in the
warn_slowpath_common() path.  The function will still print out the
location of the warning.

An example of the bug_on_warn output:

The first line below is from the WARN_ON() to output the WARN_ON()'s location.
After that the new BUG() call is displayed.

 WARNING: CPU: 27 PID: 3204 at
/home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
[dummy_module]()
 bug_on_warn set, calling BUG()...
 ------------[ cut here ]------------
 kernel BUG at kernel/panic.c:434!
 invalid opcode: 0000 [#1] SMP
 Modules linked in: dummy_module(OE+) sg nfsv3 rpcsec_gss_krb5 nfsv4
dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel
(Continue reading)

Milosz Tanski | 20 Oct 23:52 2014

preadv2/pwritev2 rename

Christoph and/or Jeff,

I updated the patch for 3.18-rc1 and I'm going to resend it as non-RFC
as I didn't get comments last time.

I only have one stupid question... I'm going to rename the calls to
preadv6 and pwritev6 (so it's more like the other syscalls: dup3,
accept4, eventfd2) but I'm not sure if i should call it preadv5 or
pwritev6 since the offset argument is split into two different
arguments (upper and lower part).

Also, In our application we were able to get about 20%-30% reduction
in response time when using this before queuing in a IO thread pool on
the read path. It's a pretty nice win in the real world.

Best,
- Milosz

--

-- 
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016

p: 646-253-9055
e: milosz@...
Krzysztof Kozlowski | 20 Oct 14:34 2014

[PATCH v2 0/5] power/mfd: Add max77693 charger driver


Hi,

Changes since v1
================
1. Add patch 2/5: mfd: max77693: Map charger device to its own of_node
   (forgot to send it in v1)
2. Remove patches for DTS and configs. I'll send them later.
3. Add ack from Lee Jones (patch 3/5).

Description
===========
The patchset adds max77693 charger driver present on Trats2 board
(and Galaxy S III). The driver configures battery charger and exposes
power supply interface.

Driver is necessary to provide full charging stack on Trats2 device
(extcon, charger-manager etc.).

Everything rebased on next-20141020.

Best regards,
Krzysztof

Krzysztof Kozlowski (5):
  devicetree: mfd: max77693: Document new bindings for charger
  mfd: max77693: Map charger device to its own of_node
  mfd: max77693: Add defines for MAX77693 charger driver
  power: max77693: Add charger driver for Maxim 77693
  Documentation: charger: max77693: Document exported sysfs entry
(Continue reading)


Gmane