Re: [PATCH 3/6] docs: Document BCM23550 bindings

On Mon, May 9, 2016 at 12:41 PM, Rob Herring wrote: > On Thu, May 05, 2016 at 01:48:51PM -0700, Chris Brand wrote: >> Add binding document for Broadcom BCM23550 SoC. [...] >> +The enable method is specified by defining the following required >> +properties in the "cpu" device

Re: [PATCH 3/6] docs: Document BCM23550 bindings

On Mon, May 9, 2016 at 12:41 PM, Rob Herring wrote: > On Thu, May 05, 2016 at 01:48:51PM -0700, Chris Brand wrote: >> Add binding document for Broadcom BCM23550 SoC. [...] >> +The enable method is specified by defining the following required >> +properties in the "cpu" device tree node: >> + -

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:23 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: >> Still should be assigned once, and should be done in >> prepare_level4(). --- by may need different name for that ? >> >> The exact reason to have

Re: [PATCH 1/3] mm: thp: calculate the mapcount correctly for THP pages during WP faults

On Fri, 6 May 2016 17:03:58 +0200 Andrea Arcangeli wrote: > This will provide fully accuracy to the mapcount calculation in the > write protect faults, so page pinning will not get broken by false > positive copy-on-writes. > > total_mapcount() isn't the right calculation

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:23 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: >> Still should be assigned once, and should be done in >> prepare_level4(). --- by may need different name for that ? >> >> The exact reason to have assigning in functions. >> >> pgt_data

Re: [PATCH 1/3] mm: thp: calculate the mapcount correctly for THP pages during WP faults

On Fri, 6 May 2016 17:03:58 +0200 Andrea Arcangeli wrote: > This will provide fully accuracy to the mapcount calculation in the > write protect faults, so page pinning will not get broken by false > positive copy-on-writes. > > total_mapcount() isn't the right calculation needed in >

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: >> As it turns out, mapping_info DOES need to be initialized every >> time. Without this, page tables were not being corrected updated, which >> could

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: >> As it turns out, mapping_info DOES need to be initialized every >> time. Without this, page tables were not being corrected updated, which >> could

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: >> As it turns out, mapping_info DOES need to be initialized every >> time. Without this, page tables were not being corrected updated, which >> could cause reboots when a physical address beyond

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 3:01 PM, Yinghai Lu wrote: > On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: >> As it turns out, mapping_info DOES need to be initialized every >> time. Without this, page tables were not being corrected updated, which >> could cause reboots when a physical address beyond

[PATCH] staging: speakup: ensure we do not overrun synths array

From: Colin Ian King synth_add allows one to add MAXSYNTHS synths to the synths array; however it always NULLifies the next synth in the array which means that on the MAXSYNTHS synth we get an out-of-bounds write of the NULL to the synths array. Make the synths array

[PATCH] staging: speakup: ensure we do not overrun synths array

From: Colin Ian King synth_add allows one to add MAXSYNTHS synths to the synths array; however it always NULLifies the next synth in the array which means that on the MAXSYNTHS synth we get an out-of-bounds write of the NULL to the synths array. Make the synths array MAXSYNTHS + 1 elements in

Re: [PATCH V4 0/4] Code refine for Intel IOMMU

On Mon, May 09, 2016 at 01:24:02PM +0200, Joerg Roedel wrote: >On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote: >> >Wei Yang (4): >> > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct >> >dmar_{drhd/atsr}_unit >> > iommu/vt-d: use zero-sized array in DMAR related ACPI

Re: [PATCH V4 0/4] Code refine for Intel IOMMU

On Mon, May 09, 2016 at 01:24:02PM +0200, Joerg Roedel wrote: >On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote: >> >Wei Yang (4): >> > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct >> >dmar_{drhd/atsr}_unit >> > iommu/vt-d: use zero-sized array in DMAR related ACPI

[PATCH v3 2/3] net: ethernet: fec: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH v3 1/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

Ethtool callbacks {get|set}_link_ksettings are often the same, so we add two generics functions phy_ethtool_{get|set}_link_ksettings to avoid writing severals times the same function. Signed-off-by: Philippe Reynes --- drivers/net/phy/phy.c | 24

[PATCH v3 2/3] net: ethernet: fec: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH v3 1/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

Ethtool callbacks {get|set}_link_ksettings are often the same, so we add two generics functions phy_ethtool_{get|set}_link_ksettings to avoid writing severals times the same function. Signed-off-by: Philippe Reynes --- drivers/net/phy/phy.c | 24 include/linux/phy.h

[PATCH v3 3/3] net: ethernet: fec: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/freescale/fec_main.c | 26 ++ 1 files changed, 2

[PATCH v3 0/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

Ethtool callbacks {get|set}_link_ksettings may be the same for many drivers. So we add two generics callbacks phy_ethtool_{get|set}_link_ksettings. To use those generics callbacks, the ethernet driver must use the pointer phydev contained in struct net_device, and not use a private structure to

[PATCH v3 3/3] net: ethernet: fec: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/freescale/fec_main.c | 26 ++ 1 files changed, 2 insertions(+), 24

[PATCH v3 0/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

Ethtool callbacks {get|set}_link_ksettings may be the same for many drivers. So we add two generics callbacks phy_ethtool_{get|set}_link_ksettings. To use those generics callbacks, the ethernet driver must use the pointer phydev contained in struct net_device, and not use a private structure to

Re: [PATCH v2] uapi glibc compat: fix compile errors when glibc net/if.h included before linux/if.h

On Mon, May 09, 2016 at 11:35:35PM +0200, Pablo Neira Ayuso wrote: > It seems linux-netdev was not Cc'ed. I cannot find this in David's > patchwork [1]. > > @Mikko: Could you resubmit including net...@vger.kernel.org? Thanks. Done: http://patchwork.ozlabs.org/patch/620262/ -Mikko

Re: [PATCH V6 01/13] pci, acpi, x86, ia64: Move ACPI host bridge device companion assignment to core code.

On Wednesday, May 04, 2016 10:10:58 AM Tomasz Nowicki wrote: > On 27.04.2016 04:45, Bjorn Helgaas wrote: > > [question for Rafael below] > > > > On Fri, Apr 15, 2016 at 07:06:36PM +0200, Tomasz Nowicki wrote: > >> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host > >> bridge

Re: [PATCH v2] uapi glibc compat: fix compile errors when glibc net/if.h included before linux/if.h

On Mon, May 09, 2016 at 11:35:35PM +0200, Pablo Neira Ayuso wrote: > It seems linux-netdev was not Cc'ed. I cannot find this in David's > patchwork [1]. > > @Mikko: Could you resubmit including net...@vger.kernel.org? Thanks. Done: http://patchwork.ozlabs.org/patch/620262/ -Mikko

Re: [PATCH V6 01/13] pci, acpi, x86, ia64: Move ACPI host bridge device companion assignment to core code.

On Wednesday, May 04, 2016 10:10:58 AM Tomasz Nowicki wrote: > On 27.04.2016 04:45, Bjorn Helgaas wrote: > > [question for Rafael below] > > > > On Fri, Apr 15, 2016 at 07:06:36PM +0200, Tomasz Nowicki wrote: > >> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host > >> bridge

Re: [PATCH v7 8/9] clk: mediatek: Add config options for MT2701 subsystem clocks

On 05/09, James Liao wrote: > HI Stephen, > > On Fri, 2016-05-06 at 16:02 -0700, Stephen Boyd wrote: > > On 04/14, James Liao wrote: > > > MT2701 subsystem clocks are optional and should be enabled only if > > > their subsystem drivers are ready to control these clocks. > > > > > >

Re: [PATCH] workqueue: fix rebind bound workers warning

Cc Peterz, Frederic, 2016-05-10 5:50 GMT+08:00 Wanpeng Li : > Cc Thomas, the new state machine author, > 2016-05-10 1:00 GMT+08:00 Tejun Heo : >> Hello, >> >> On Thu, May 05, 2016 at 09:41:31AM +0800, Wanpeng Li wrote: >>> The boot CPU handles housekeeping

Re: [PATCH v7 8/9] clk: mediatek: Add config options for MT2701 subsystem clocks

On 05/09, James Liao wrote: > HI Stephen, > > On Fri, 2016-05-06 at 16:02 -0700, Stephen Boyd wrote: > > On 04/14, James Liao wrote: > > > MT2701 subsystem clocks are optional and should be enabled only if > > > their subsystem drivers are ready to control these clocks. > > > > > >

Re: [PATCH] workqueue: fix rebind bound workers warning

Cc Peterz, Frederic, 2016-05-10 5:50 GMT+08:00 Wanpeng Li : > Cc Thomas, the new state machine author, > 2016-05-10 1:00 GMT+08:00 Tejun Heo : >> Hello, >> >> On Thu, May 05, 2016 at 09:41:31AM +0800, Wanpeng Li wrote: >>> The boot CPU handles housekeeping duty(unbound timers, workqueues, >>>

Re: [PATCH v7 7/9] clk: mediatek: Enable critical clocks for MT2701

On 05/09, James Liao wrote: > Hi Stephen, > > On Fri, 2016-05-06 at 16:12 -0700, Stephen Boyd wrote: > > On 04/14, James Liao wrote: > > > Some system clocks should be turned on by default on MT2701. > > > This patch enable these clocks when related clocks have > > > been registered. > > > > > >

Re: [PATCH v7 7/9] clk: mediatek: Enable critical clocks for MT2701

On 05/09, James Liao wrote: > Hi Stephen, > > On Fri, 2016-05-06 at 16:12 -0700, Stephen Boyd wrote: > > On 04/14, James Liao wrote: > > > Some system clocks should be turned on by default on MT2701. > > > This patch enable these clocks when related clocks have > > > been registered. > > > > > >

[PATCH v21 01/22] vfs: Add IS_ACL() and IS_RICHACL() tests

The vfs does not apply the umask for file systems that support acls. The test used for this used to be called IS_POSIXACL(). Switch to a new IS_ACL() test to check for either posix acls or richacls instead. Add a new MS_RICHACL flag and IS_RICHACL() test for richacls alone. The IS_POSIXACL() test

[PATCH v21 01/22] vfs: Add IS_ACL() and IS_RICHACL() tests

The vfs does not apply the umask for file systems that support acls. The test used for this used to be called IS_POSIXACL(). Switch to a new IS_ACL() test to check for either posix acls or richacls instead. Add a new MS_RICHACL flag and IS_RICHACL() test for richacls alone. The IS_POSIXACL() test

Re: [PATCH v5 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 05/09/2016 01:46 PM, Yu-cheng Yu wrote: > XSAVES is a kernel instruction and uses a compacted format. When working > with user space, the kernel should provide standard-format, non-supervisor > state data. We cannot do __copy_to_user() from a compacted- format kernel > xstate area to a signal

[PATCH v21 10/22] posix_acl: Improve xattr fixup code

Both XATTR_NAME_POSIX_ACL_ACCESS and XATTR_NAME_POSIX_ACL_DEFAULT have the same XATTR_SYSTEM_PREFIX prefix; don't check for the same prefix repeatedly. Signed-off-by: Andreas Gruenbacher Reviewed-by: Steve French --- fs/xattr.c | 29

Re: [PATCH v5 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 05/09/2016 01:46 PM, Yu-cheng Yu wrote: > XSAVES is a kernel instruction and uses a compacted format. When working > with user space, the kernel should provide standard-format, non-supervisor > state data. We cannot do __copy_to_user() from a compacted- format kernel > xstate area to a signal

[PATCH v21 10/22] posix_acl: Improve xattr fixup code

Both XATTR_NAME_POSIX_ACL_ACCESS and XATTR_NAME_POSIX_ACL_DEFAULT have the same XATTR_SYSTEM_PREFIX prefix; don't check for the same prefix repeatedly. Signed-off-by: Andreas Gruenbacher Reviewed-by: Steve French --- fs/xattr.c | 29 +++-- 1 file changed, 23

[PATCH v21 19/22] richacl: Add richacl xattr handler

Add richacl xattr handler implementing the xattr operations based on the get_richacl and set_richacl inode operations. Signed-off-by: Andreas Gruenbacher --- fs/richacl_xattr.c| 74 +++ include/linux/richacl_xattr.h | 2

[PATCH v21 19/22] richacl: Add richacl xattr handler

Add richacl xattr handler implementing the xattr operations based on the get_richacl and set_richacl inode operations. Signed-off-by: Andreas Gruenbacher --- fs/richacl_xattr.c| 74 +++ include/linux/richacl_xattr.h | 2 ++ 2 files changed,

[PATCH v21 15/22] richacl: Check if an acl is equivalent to a file mode

ACLs are considered equivalent to file modes if they only consist of owner@, group@, and everyone@ entries, the owner@ permissions do not depend on whether the owner is a member in the owning group, and no inheritance flags are set. This test is used to avoid storing richacls if the acl can be

[PATCH v21 17/22] richacl: Automatic Inheritance

Automatic Inheritance (AI) allows changes to the acl of a directory to propagate down to children. This is mostly implemented in user space: when a process changes the permissions of a directory and Automatic Inheritance is enabled for that directory, the process must propagate those changes to

[PATCH v21 21/22] ext4: Add richacl support

From: "Aneesh Kumar K.V" Support the richacl permission model in ext4. The richacls are stored in "system.richacl" xattrs. Richacls need to be enabled by tune2fs or at file system create time. Signed-off-by: Aneesh Kumar K.V

[PATCH v21 22/22] ext4: Add richacl feature flag

From: "Aneesh Kumar K.V" This feature flag selects richacl instead of POSIX ACL support on the filesystem. When this feature is off, the "acl" and "noacl" mount options control whether POSIX ACLs are enabled. When it is on, richacls are automatically enabled

[PATCH v21 16/22] richacl: Create-time inheritance

When a new file is created, it can inherit an acl from its parent directory; this is similar to how default acls work in POSIX ACLs. As with POSIX ACLs, if a file inherits an acl from its parent directory, the intersection between the create mode and the permissions granted by the inherited acl

[PATCH v21 15/22] richacl: Check if an acl is equivalent to a file mode

ACLs are considered equivalent to file modes if they only consist of owner@, group@, and everyone@ entries, the owner@ permissions do not depend on whether the owner is a member in the owning group, and no inheritance flags are set. This test is used to avoid storing richacls if the acl can be

[PATCH v21 17/22] richacl: Automatic Inheritance

Automatic Inheritance (AI) allows changes to the acl of a directory to propagate down to children. This is mostly implemented in user space: when a process changes the permissions of a directory and Automatic Inheritance is enabled for that directory, the process must propagate those changes to

[PATCH v21 21/22] ext4: Add richacl support

From: "Aneesh Kumar K.V" Support the richacl permission model in ext4. The richacls are stored in "system.richacl" xattrs. Richacls need to be enabled by tune2fs or at file system create time. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andreas Gruenbacher Reviewed-by: Andreas Dilger

[PATCH v21 22/22] ext4: Add richacl feature flag

From: "Aneesh Kumar K.V" This feature flag selects richacl instead of POSIX ACL support on the filesystem. When this feature is off, the "acl" and "noacl" mount options control whether POSIX ACLs are enabled. When it is on, richacls are automatically enabled and using the "noacl" mount option

[PATCH v21 16/22] richacl: Create-time inheritance

When a new file is created, it can inherit an acl from its parent directory; this is similar to how default acls work in POSIX ACLs. As with POSIX ACLs, if a file inherits an acl from its parent directory, the intersection between the create mode and the permissions granted by the inherited acl

Re: [PATCH v2 00/22] ARM: dts: exynos: Add initial support for Odroid XU

Hello Krzysztof, On 05/08/2016 03:05 PM, Krzysztof Kozlowski wrote: > > Hi, > > Patchset adds necessary clocks, reorganizes existing stuff and finally > adds Odroid XU support. > Do you have a branch available so I can pull these patches and test in the Exynos5 boards I've access to? Thanks

[PATCH v21 13/22] vfs: Cache richacl in struct inode

Cache richacls in struct inode so that this doesn't have to be done individually in each filesystem. This is similar to POSIX ACLs. Signed-off-by: Andreas Gruenbacher --- fs/inode.c | 13 +--- fs/richacl.c| 81

[PATCH v21 18/22] richacl: xattr mapping functions

Map between "system.richacl" xattrs and the in-kernel representation. Signed-off-by: Andreas Gruenbacher --- fs/Makefile| 2 +- fs/richacl_xattr.c | 161 + include/linux/richacl_xattr.h | 29

[PATCH v21 12/22] vfs: Add get_richacl and set_richacl inode operations

These operations are similar to the get_acl and set_acl operations for POSIX ACLs. The distinction between access and default ACLs doesn't exist for richacls. Signed-off-by: Andreas Gruenbacher Reviewed-by: Steve French --- include/linux/fs.h

Re: [PATCH v2 00/22] ARM: dts: exynos: Add initial support for Odroid XU

Hello Krzysztof, On 05/08/2016 03:05 PM, Krzysztof Kozlowski wrote: > > Hi, > > Patchset adds necessary clocks, reorganizes existing stuff and finally > adds Odroid XU support. > Do you have a branch available so I can pull these patches and test in the Exynos5 boards I've access to? Thanks

[PATCH v21 13/22] vfs: Cache richacl in struct inode

Cache richacls in struct inode so that this doesn't have to be done individually in each filesystem. This is similar to POSIX ACLs. Signed-off-by: Andreas Gruenbacher --- fs/inode.c | 13 +--- fs/richacl.c| 81 +

[PATCH v21 18/22] richacl: xattr mapping functions

Map between "system.richacl" xattrs and the in-kernel representation. Signed-off-by: Andreas Gruenbacher --- fs/Makefile| 2 +- fs/richacl_xattr.c | 161 + include/linux/richacl_xattr.h | 29 +++

[PATCH v21 12/22] vfs: Add get_richacl and set_richacl inode operations

These operations are similar to the get_acl and set_acl operations for POSIX ACLs. The distinction between access and default ACLs doesn't exist for richacls. Signed-off-by: Andreas Gruenbacher Reviewed-by: Steve French --- include/linux/fs.h | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH v21 20/22] vfs: Add richacl permission checking

Hook the richacl permission checking function into the vfs. Signed-off-by: Andreas Gruenbacher --- fs/namei.c | 54 -- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index

Re: [PATCH 4/7] [media] ir-rx51: add DT support to driver

On 10.05.2016 00:07, Rob Herring wrote: On Mon, May 9, 2016 at 3:53 PM, Ivaylo Dimitrov wrote: Hi, On 9.05.2016 23:06, Rob Herring wrote: On Sat, May 07, 2016 at 06:21:45PM +0300, Ivaylo Dimitrov wrote: With the upcoming removal of legacy boot, lets add

[PATCH v21 14/22] richacl: Update the file masks in chmod()

Doing a chmod() sets the file mode, which includes the file permission bits. When a file has a richacl, the permissions that the richacl grants need to be limited to what the new file permission bits allow. This is done by setting the file masks in the richacl to what the file permission bits

[PATCH v21 20/22] vfs: Add richacl permission checking

Hook the richacl permission checking function into the vfs. Signed-off-by: Andreas Gruenbacher --- fs/namei.c | 54 -- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index 2b1bf71..5fbe60a 100644 ---

Re: [PATCH 4/7] [media] ir-rx51: add DT support to driver

On 10.05.2016 00:07, Rob Herring wrote: On Mon, May 9, 2016 at 3:53 PM, Ivaylo Dimitrov wrote: Hi, On 9.05.2016 23:06, Rob Herring wrote: On Sat, May 07, 2016 at 06:21:45PM +0300, Ivaylo Dimitrov wrote: With the upcoming removal of legacy boot, lets add support to one of the last N900

[PATCH v21 14/22] richacl: Update the file masks in chmod()

Doing a chmod() sets the file mode, which includes the file permission bits. When a file has a richacl, the permissions that the richacl grants need to be limited to what the new file permission bits allow. This is done by setting the file masks in the richacl to what the file permission bits

[PATCH v21 02/22] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags

Richacls distinguish between creating non-directories and directories. To support that, add an isdir parameter to may_create(). When checking inode_permission() for create permission, pass in an additional MAY_CREATE_FILE or MAY_CREATE_DIR mask flag. Add may_replace() to allow checking for delete

[PATCH v21 05/22] vfs: Add permission flags for setting file attributes

Richacls support permissions that allow to take ownership of a file, change the file permissions, and set the file timestamps. Support that by introducing new permission mask flags and by checking for those mask flags in inode_change_ok(). Signed-off-by: Andreas Gruenbacher

[PATCH v21 03/22] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

Normally, deleting a file requires MAY_WRITE access to the parent directory. With richacls, a file may be deleted with MAY_DELETE_CHILD access to the parent directory or with MAY_DELETE_SELF access to the file. To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() when

[PATCH v21 09/22] richacl: Permission check algorithm

A richacl roughly grants a requested access if the NFSv4 acl in the richacl grants the requested permissions according to the NFSv4 permission check algorithm and the file mask that applies to the process includes the requested permissions. Signed-off-by: Andreas Gruenbacher

[PATCH v21 04/22] vfs: Make the inode passed to inode_change_ok non-const

We will need to call iop->permission and iop->get_acl from inode_change_ok() for additional permission checks, and both take a non-const inode. Signed-off-by: Andreas Gruenbacher Reviewed-by: J. Bruce Fields Reviewed-by: Andreas Dilger

Re: [PATCH v2 22/22] ARM: dts: exynos: Add initial support for Odroid XU board

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > The Hardkernel's Odroid XU board was first design with big.LITTLE SoC > from Samsung: the Exynos5410. Comparing now to more popular Odroid XU3 > the differences are: > 1. Exynos5410 instead of 5422, > 2. DisplayPort, > 3. Main

[PATCH v21 06/22] richacl: In-memory representation and helper functions

A richacl consists of an NFSv4 acl and an owner, group, and other mask. These three masks correspond to the owner, group, and other file permission bits, but they contain NFSv4 permissions instead of POSIX permissions. Each entry in the NFSv4 acl applies to the file owner (OWNER@), the owning

[PATCH v21 02/22] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags

Richacls distinguish between creating non-directories and directories. To support that, add an isdir parameter to may_create(). When checking inode_permission() for create permission, pass in an additional MAY_CREATE_FILE or MAY_CREATE_DIR mask flag. Add may_replace() to allow checking for delete

[PATCH v21 05/22] vfs: Add permission flags for setting file attributes

Richacls support permissions that allow to take ownership of a file, change the file permissions, and set the file timestamps. Support that by introducing new permission mask flags and by checking for those mask flags in inode_change_ok(). Signed-off-by: Andreas Gruenbacher Reviewed-by: J.

[PATCH v21 03/22] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

Normally, deleting a file requires MAY_WRITE access to the parent directory. With richacls, a file may be deleted with MAY_DELETE_CHILD access to the parent directory or with MAY_DELETE_SELF access to the file. To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() when

[PATCH v21 09/22] richacl: Permission check algorithm

A richacl roughly grants a requested access if the NFSv4 acl in the richacl grants the requested permissions according to the NFSv4 permission check algorithm and the file mask that applies to the process includes the requested permissions. Signed-off-by: Andreas Gruenbacher Reviewed-by: "J.

[PATCH v21 04/22] vfs: Make the inode passed to inode_change_ok non-const

We will need to call iop->permission and iop->get_acl from inode_change_ok() for additional permission checks, and both take a non-const inode. Signed-off-by: Andreas Gruenbacher Reviewed-by: J. Bruce Fields Reviewed-by: Andreas Dilger Reviewed-by: Steve French --- fs/attr.c | 2 +-

Re: [PATCH v2 22/22] ARM: dts: exynos: Add initial support for Odroid XU board

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > The Hardkernel's Odroid XU board was first design with big.LITTLE SoC > from Samsung: the Exynos5410. Comparing now to more popular Odroid XU3 > the differences are: > 1. Exynos5410 instead of 5422, > 2. DisplayPort, > 3. Main

[PATCH v21 06/22] richacl: In-memory representation and helper functions

A richacl consists of an NFSv4 acl and an owner, group, and other mask. These three masks correspond to the owner, group, and other file permission bits, but they contain NFSv4 permissions instead of POSIX permissions. Each entry in the NFSv4 acl applies to the file owner (OWNER@), the owning

[PATCH v21 08/22] richacl: Compute maximum file masks from an acl

Compute upper bound owner, group, and other file masks with as few permissions as possible without denying any permissions that the NFSv4 acl in a richacl grants. This algorithm is used when a file inherits an acl at create time and when an acl is set via a mechanism that does not provide file

[PATCH v21 07/22] richacl: Permission mapping functions

We need to map from POSIX permissions to NFSv4 permissions when a chmod() is done, from NFSv4 permissions to POSIX permissions when an acl is set (which implicitly sets the file permission bits), and from the MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when doing an access

[PATCH v21 11/22] vfs: Cache base_acl objects in inodes

POSIX ACLs and richacls are both objects allocated by kmalloc() with a reference count which are freed by kfree_rcu(). An inode can either cache an access and a default POSIX ACL, or a richacl (richacls do not have default acls). To allow an inode to cache either of the two kinds of acls,

[PATCH v21 08/22] richacl: Compute maximum file masks from an acl

Compute upper bound owner, group, and other file masks with as few permissions as possible without denying any permissions that the NFSv4 acl in a richacl grants. This algorithm is used when a file inherits an acl at create time and when an acl is set via a mechanism that does not provide file

[PATCH v21 07/22] richacl: Permission mapping functions

We need to map from POSIX permissions to NFSv4 permissions when a chmod() is done, from NFSv4 permissions to POSIX permissions when an acl is set (which implicitly sets the file permission bits), and from the MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when doing an access

[PATCH v21 11/22] vfs: Cache base_acl objects in inodes

POSIX ACLs and richacls are both objects allocated by kmalloc() with a reference count which are freed by kfree_rcu(). An inode can either cache an access and a default POSIX ACL, or a richacl (richacls do not have default acls). To allow an inode to cache either of the two kinds of acls,

[PATCH v21 00/22] Richacls

Al, here is an update to the richacl patches. Changes since the last posting (https://lwn.net/Articles/680388/): * Rebase on top of work.acl [*]. Minor restructuring of the functions accessing the cached ACLs in inodes. [*]

[PATCH v21 00/22] Richacls

Al, here is an update to the richacl patches. Changes since the last posting (https://lwn.net/Articles/680388/): * Rebase on top of work.acl [*]. Minor restructuring of the functions accessing the cached ACLs in inodes. [*]

Re: [PATCH v2 00/22] ARM: dts: exynos: Add initial support for Odroid XU

On 05/08, Krzysztof Kozlowski wrote: > > Hi, > > Patchset adds necessary clocks, reorganizes existing stuff and finally > adds Odroid XU support. > > Merging strategy > > Complicated! The clock dt-bindings and driver changes can go to clock > tree. However there are three DTS

Re: [PATCH v2 00/22] ARM: dts: exynos: Add initial support for Odroid XU

On 05/08, Krzysztof Kozlowski wrote: > > Hi, > > Patchset adds necessary clocks, reorganizes existing stuff and finally > adds Odroid XU support. > > Merging strategy > > Complicated! The clock dt-bindings and driver changes can go to clock > tree. However there are three DTS

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: > As it turns out, mapping_info DOES need to be initialized every > time. Without this, page tables were not being corrected updated, which > could cause reboots when a physical address beyond 2G was chosen. > >

Re: [PATCH v7 1/9] x86/KASLR: Initialize mapping_info every time

On Mon, May 9, 2016 at 1:22 PM, Kees Cook wrote: > As it turns out, mapping_info DOES need to be initialized every > time. Without this, page tables were not being corrected updated, which > could cause reboots when a physical address beyond 2G was chosen. > > Signed-off-by: Kees Cook > --- >

Re: [PATCH 3/6] doc: dt: Document the indirect overlay method.

On Mon, May 9, 2016 at 1:05 PM, Pantelis Antoniou wrote: > Add a description of the indirect overlay method to the overlay > documention file. Why? Please write some decent commit messages. > Signed-off-by: Pantelis Antoniou > ---

Re: [PATCH 3/6] doc: dt: Document the indirect overlay method.

On Mon, May 9, 2016 at 1:05 PM, Pantelis Antoniou wrote: > Add a description of the indirect overlay method to the overlay > documention file. Why? Please write some decent commit messages. > Signed-off-by: Pantelis Antoniou > --- > Documentation/devicetree/overlay-notes.txt | 13

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > If you think we're violating EFI rules by accessing these registers from > both sides of the fence, please let me know. I'd like to make sure that > we get everything behaving the way it should be! Oh no, I don't think this is violating

Re: [PATCH v2 21/22] ARM: dts: exynos: Add USB to Exynos5410

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > Move USB 3.0 DWC and 2.0 EHCI/OHCI nodes from exynos5420.dtsi to > exynos54xx.dtsi common for entire family. For Exynos542x/5800 this > should not have functional impact but for Exynos5410 this effectively > adds USB support. >

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > If you think we're violating EFI rules by accessing these registers from > both sides of the fence, please let me know. I'd like to make sure that > we get everything behaving the way it should be! Oh no, I don't think this is violating

Re: [PATCH v2 21/22] ARM: dts: exynos: Add USB to Exynos5410

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > Move USB 3.0 DWC and 2.0 EHCI/OHCI nodes from exynos5420.dtsi to > exynos54xx.dtsi common for entire family. For Exynos542x/5800 this > should not have functional impact but for Exynos5410 this effectively > adds USB support. >

Re: [PATCH v2 20/22] ARM: dts: exynos: Move common Exynos5410/542x/5800 nodes to new DTSI

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > The Exynos5410/542x/5800 are very similar designs. Create new new s/new new/a new > DTSI with common nodes to remove DTS duplication. Although currently > only MCT and SysRAM are shared but in future more nodes will be added

[PATCH 2/2] drm/sti: include linux/seq_file.h where needed

The sti drm driver has a lot of debugfs interface that cause build errors in some configurations when seq_file.h is not included implicitly: drm/sti/sti_mixer.c: In function 'mixer_dbg_ctl': drm/sti/sti_mixer.c:88:2: error: implicit declaration of function 'seq_puts'

Re: [PATCH v2 20/22] ARM: dts: exynos: Move common Exynos5410/542x/5800 nodes to new DTSI

Hello Krzysztof, On 05/08/2016 03:06 PM, Krzysztof Kozlowski wrote: > The Exynos5410/542x/5800 are very similar designs. Create new new s/new new/a new > DTSI with common nodes to remove DTS duplication. Although currently > only MCT and SysRAM are shared but in future more nodes will be added

[PATCH 2/2] drm/sti: include linux/seq_file.h where needed

The sti drm driver has a lot of debugfs interface that cause build errors in some configurations when seq_file.h is not included implicitly: drm/sti/sti_mixer.c: In function 'mixer_dbg_ctl': drm/sti/sti_mixer.c:88:2: error: implicit declaration of function 'seq_puts'

<    1   2   3   4   5   6   7   8   9   10   >