Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On Mon, Apr 25, 2016 at 3:56 PM, Christophe Varoqui < christophe.varo...@opensvc.com> wrote: > Distributors can't be asked to agree on a common udev ruleset. > Of course, there is no pressure on downstream distributor on what configuration/udev rules should be used. Yet it's always good to have

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >Hi, >Those example udev rules are indeed unmaintained and should be removed not >to confuse distributors. >Distributors can't be asked to agree on a common udev ruleset. Ben, >Hannes, Xosé, Peter are you ok

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On 04/25/2016 02:56 PM, Christophe Varoqui wrote: > Those example udev rules are indeed unmaintained and should be > removed not to confuse distributors. > > Distributors can't be asked to agree on a common udev ruleset. > Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules

[dm-devel] [PATCH v3 01/21] fs: fix a posible leak of allocated superblock

From: Pavel Tikhomirov We probably need to fix superblock leak in patch (v4 "fs: Add user namesapace member to struct super_block"): Imagine posible code path in sget_userns: we iterate through type->fs_supers and do not find suitable sb, we drop sb_lock to allocate s

[dm-devel] [PATCH v3 18/21] fuse: Add support for pid namespaces

When the userspace process servicing fuse requests is running in a pid namespace then pids passed via the fuse fd are not being translated into that process' namespace. Translation is necessary for the pid to be useful to that process. Since no use case currently exists for changing namespaces

[dm-devel] [PATCH v3 19/21] fuse: Support fuse filesystems outside of init_user_ns

In order to support mounts from namespaces other than init_user_ns, fuse must translate uids and gids to/from the userns of the process servicing requests on /dev/fuse. This patch does that, with a couple of restrictions on the namespace: - The userns for the fuse connection is fixed to the

[dm-devel] [PATCH v3 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces

Both of these filesystems already have use cases for mounting the same super block from multiple user namespaces. For sysfs this happens when using criu for snapshotting a container, where sysfs is mounted in the containers network ns but the hosts user ns. The cgroup filesystem shares the same

[dm-devel] [PATCH v3 10/21] fs: Check for invalid i_uid in may_follow_link()

Filesystem uids which don't map into a user namespace may result in inode->i_uid being INVALID_UID. A symlink and its parent could have different owners in the filesystem can both get mapped to INVALID_UID, which may result in following a symlink when this would not have otherwise been permitted

[dm-devel] [PATCH 06/41] Documentation: device-mapper: fix spelling mistakes

Signed-off-by: Eric Engestrom --- Documentation/device-mapper/cache-policies.txt | 4 ++-- Documentation/device-mapper/statistics.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/device-mapper/cache-policies.txt

[dm-devel] [PATCH v3 09/21] Smack: Handle labels consistently in untrusted mounts

The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled differently in untrusted mounts. This is confusing and potentically problematic. Change this to handle them all the same way that SMACK64 is currently handled; that is, read the label from disk and check it at use time. For SMACK64

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On 25.4.2016 12:52, Peter Volkov wrote: Hi, guys. There is a problem: udev does not create partitions for multipath devices in case I use kpartx.rules provided with multipath sources. I found that udev always go to kpartx_end after following line of rules: ENV{DM_TABLE_STATE}!="LIVE",

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On 04/25/2016 07:38 PM, Benjamin Marzinski wrote: > On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote: >>Hi, >>Those example udev rules are indeed unmaintained and should be removed not >>to confuse distributors. >>Distributors can't be asked to agree on a common

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote: > On 04/25/2016 02:56 PM, Christophe Varoqui wrote: > >> Those example udev rules are indeed unmaintained and should be >> removed not to confuse distributors. >> >> Distributors can't be asked to agree on a common udev ruleset. >> Ben, Hannes,

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On Mon, Apr 25, 2016 at 3:32 PM, Zdenek Kabelac wrote: > On 25.4.2016 14:10, Peter Volkov wrote: > >> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac > > wrote: >> >> On 25.4.2016 12:52, Peter Volkov wrote: >> >>

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

Hi, Those example udev rules are indeed unmaintained and should be removed not to confuse distributors. Distributors can't be asked to agree on a common udev ruleset. Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ? Best regards, On Mon, Apr 25, 2016 at 2:32 PM,

Re: [dm-devel] multipath-0.5.0 still provides broken udev rules

On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac wrote: > On 25.4.2016 12:52, Peter Volkov wrote: >> >> There is a problem: udev does not create partitions for multipath devices >> in >> case I use kpartx.rules provided with multipath sources. I found that udev >> always go