Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

[Jordan Glover]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, October 4, 2018 6:18 PM, Kees Cook  wrote:

>
> I don't want to overload "security=", but we can if we want. It would
> be as above, but a trailing comma would be needed to trigger the
> "ordering" behavior. e.g. "security=selinux" would disable all other
> majors (retaining the current behavior), but "security=selinux," would
> disable all other LSMs.
>
> -Kees
>
>

I don't think giving such big impact to trailing comma is good idea :)

Jordan

Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter

[Jordan Glover]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, October 4, 2018 6:18 PM, Kees Cook  wrote:

>
> I don't want to overload "security=", but we can if we want. It would
> be as above, but a trailing comma would be needed to trigger the
> "ordering" behavior. e.g. "security=selinux" would disable all other
> majors (retaining the current behavior), but "security=selinux," would
> disable all other LSMs.
>
> -Kees
>
>

I don't think giving such big impact to trailing comma is good idea :)

Jordan

Re: [PATCH v3 1/3] acpi: arm64: add iort support for PMCG

[Robin Murphy]

On 04/10/18 17:43, Lorenzo Pieralisi wrote:

On Fri, Sep 21, 2018 at 04:08:01PM +0100, Shameer Kolothum wrote:

From: Neil Leeder 

Add support for the SMMU Performance Monitor Counter Group
information from ACPI. This is in preparation for its use
in the SMMUv3 PMU driver.

Signed-off-by: Neil Leeder 
Signed-off-by: Hanjun Guo 
Signed-off-by: Shameer Kolothum 
---
  drivers/acpi/arm64/iort.c | 78 +++
  1 file changed, 66 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 08f26db..b979c86 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -356,7 +356,8 @@ static struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
-   node->type == ACPI_IORT_NODE_SMMU_V3) {
+   node->type == ACPI_IORT_NODE_SMMU_V3 ||
+   node->type == ACPI_IORT_NODE_PMCG) {
*id_out = map->output_base;
return parent;
}
@@ -394,6 +395,8 @@ static int iort_get_id_mapping_index(struct acpi_iort_node 
*node)
}
  
  		return smmu->id_mapping_index;

+   case ACPI_IORT_NODE_PMCG:
+   return 0;
default:
return -EINVAL;
}
@@ -1309,6 +1312,50 @@ static bool __init arm_smmu_is_coherent(struct 
acpi_iort_node *node)
return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK;
  }
  
+static void __init arm_smmu_common_dma_configure(struct device *dev,

+   enum dev_dma_attr attr)
+{
+   /* We expect the dma masks to be equivalent for all SMMUs set-ups */
+   dev->dma_mask = >coherent_dma_mask;
+
+   /* Configure DMA for the page table walker */
+   acpi_dma_configure(dev, attr);
+}


It looks like we can't get rid of this acpi_dma_configure() call
given that the platform device we create has no ACPI companion
(and I am not looking forward to fabricating one to make the
code homogeneous :)).


Yeah, given that this is essentially only for SMMUs, the alternatives 
all end up looking like too much bother to be worthwhile.



Still, having two methods per IORT node type (dev_is_coherent() and
dev_dma_configure()) does not make much sense, we can merge it into one
I think.


Good point - looks the attr from dev_is_coherent is only ever passed 
through dev_dma_configure, so we may as well just have per-SMMU-type 
dev_dma_configure methods which retrieve their own relevant coherency 
directly. FWIW, on v2 I was tempted to suggest just wrapping the DMA 
setup in "if (node->type != ACPI_IORT_NODE_PMCG)..." rather than messing 
with more callbacks, but that clearly wouldn't fit well with the local 
style here.


Robin.



Thanks,
Lorenzo


+static int __init arm_smmu_v3_pmcg_count_resources(struct acpi_iort_node *node)
+{
+   struct acpi_iort_pmcg *pmcg;
+
+   /* Retrieve PMCG specific data */
+   pmcg = (struct acpi_iort_pmcg *)node->node_data;
+
+   /*
+* There are always 2 memory resources.
+* If the overflow_gsiv is present then add that for a total of 3.
+*/
+   return pmcg->overflow_gsiv ? 3 : 2;
+}
+
+static void __init arm_smmu_v3_pmcg_init_resources(struct resource *res,
+  struct acpi_iort_node *node)
+{
+   struct acpi_iort_pmcg *pmcg;
+
+   /* Retrieve PMCG specific data */
+   pmcg = (struct acpi_iort_pmcg *)node->node_data;
+
+   res[0].start = pmcg->page0_base_address;
+   res[0].end = pmcg->page0_base_address + SZ_4K - 1;
+   res[0].flags = IORESOURCE_MEM;
+   res[1].start = pmcg->page1_base_address;
+   res[1].end = pmcg->page1_base_address + SZ_4K - 1;
+   res[1].flags = IORESOURCE_MEM;
+
+   if (pmcg->overflow_gsiv)
+   acpi_iort_register_irq(pmcg->overflow_gsiv, "overflow",
+  ACPI_EDGE_SENSITIVE, [2]);
+}
+
  struct iort_dev_config {
const char *name;
int (*dev_init)(struct acpi_iort_node *node);
@@ -1318,6 +1365,8 @@ struct iort_dev_config {
 struct acpi_iort_node *node);
void (*dev_set_proximity)(struct device *dev,
struct acpi_iort_node *node);
+   void (*dev_dma_configure)(struct device *dev,
+   enum dev_dma_attr attr);
  };
  
  static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {

@@ -1326,23 +1375,34 @@ static const struct iort_dev_config 
iort_arm_smmu_v3_cfg __initconst = {
.dev_count_resources = arm_smmu_v3_count_resources,
.dev_init_resources = arm_smmu_v3_init_resources,
.dev_set_proximity = arm_smmu_v3_set_proximity,
+

Re: [PATCH v3 1/3] acpi: arm64: add iort support for PMCG

[Robin Murphy]

On 04/10/18 17:43, Lorenzo Pieralisi wrote:

On Fri, Sep 21, 2018 at 04:08:01PM +0100, Shameer Kolothum wrote:

From: Neil Leeder 

Add support for the SMMU Performance Monitor Counter Group
information from ACPI. This is in preparation for its use
in the SMMUv3 PMU driver.

Signed-off-by: Neil Leeder 
Signed-off-by: Hanjun Guo 
Signed-off-by: Shameer Kolothum 
---
  drivers/acpi/arm64/iort.c | 78 +++
  1 file changed, 66 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 08f26db..b979c86 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -356,7 +356,8 @@ static struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
-   node->type == ACPI_IORT_NODE_SMMU_V3) {
+   node->type == ACPI_IORT_NODE_SMMU_V3 ||
+   node->type == ACPI_IORT_NODE_PMCG) {
*id_out = map->output_base;
return parent;
}
@@ -394,6 +395,8 @@ static int iort_get_id_mapping_index(struct acpi_iort_node 
*node)
}
  
  		return smmu->id_mapping_index;

+   case ACPI_IORT_NODE_PMCG:
+   return 0;
default:
return -EINVAL;
}
@@ -1309,6 +1312,50 @@ static bool __init arm_smmu_is_coherent(struct 
acpi_iort_node *node)
return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK;
  }
  
+static void __init arm_smmu_common_dma_configure(struct device *dev,

+   enum dev_dma_attr attr)
+{
+   /* We expect the dma masks to be equivalent for all SMMUs set-ups */
+   dev->dma_mask = >coherent_dma_mask;
+
+   /* Configure DMA for the page table walker */
+   acpi_dma_configure(dev, attr);
+}


It looks like we can't get rid of this acpi_dma_configure() call
given that the platform device we create has no ACPI companion
(and I am not looking forward to fabricating one to make the
code homogeneous :)).


Yeah, given that this is essentially only for SMMUs, the alternatives 
all end up looking like too much bother to be worthwhile.



Still, having two methods per IORT node type (dev_is_coherent() and
dev_dma_configure()) does not make much sense, we can merge it into one
I think.


Good point - looks the attr from dev_is_coherent is only ever passed 
through dev_dma_configure, so we may as well just have per-SMMU-type 
dev_dma_configure methods which retrieve their own relevant coherency 
directly. FWIW, on v2 I was tempted to suggest just wrapping the DMA 
setup in "if (node->type != ACPI_IORT_NODE_PMCG)..." rather than messing 
with more callbacks, but that clearly wouldn't fit well with the local 
style here.


Robin.



Thanks,
Lorenzo


+static int __init arm_smmu_v3_pmcg_count_resources(struct acpi_iort_node *node)
+{
+   struct acpi_iort_pmcg *pmcg;
+
+   /* Retrieve PMCG specific data */
+   pmcg = (struct acpi_iort_pmcg *)node->node_data;
+
+   /*
+* There are always 2 memory resources.
+* If the overflow_gsiv is present then add that for a total of 3.
+*/
+   return pmcg->overflow_gsiv ? 3 : 2;
+}
+
+static void __init arm_smmu_v3_pmcg_init_resources(struct resource *res,
+  struct acpi_iort_node *node)
+{
+   struct acpi_iort_pmcg *pmcg;
+
+   /* Retrieve PMCG specific data */
+   pmcg = (struct acpi_iort_pmcg *)node->node_data;
+
+   res[0].start = pmcg->page0_base_address;
+   res[0].end = pmcg->page0_base_address + SZ_4K - 1;
+   res[0].flags = IORESOURCE_MEM;
+   res[1].start = pmcg->page1_base_address;
+   res[1].end = pmcg->page1_base_address + SZ_4K - 1;
+   res[1].flags = IORESOURCE_MEM;
+
+   if (pmcg->overflow_gsiv)
+   acpi_iort_register_irq(pmcg->overflow_gsiv, "overflow",
+  ACPI_EDGE_SENSITIVE, [2]);
+}
+
  struct iort_dev_config {
const char *name;
int (*dev_init)(struct acpi_iort_node *node);
@@ -1318,6 +1365,8 @@ struct iort_dev_config {
 struct acpi_iort_node *node);
void (*dev_set_proximity)(struct device *dev,
struct acpi_iort_node *node);
+   void (*dev_dma_configure)(struct device *dev,
+   enum dev_dma_attr attr);
  };
  
  static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {

@@ -1326,23 +1375,34 @@ static const struct iort_dev_config 
iort_arm_smmu_v3_cfg __initconst = {
.dev_count_resources = arm_smmu_v3_count_resources,
.dev_init_resources = arm_smmu_v3_init_resources,
.dev_set_proximity = arm_smmu_v3_set_proximity,
+

Hello Good Day,

[Mr. Richards Francisco]

Dear Respectfully,

I write to seek for your indulgence on a US$9.7 Million deal, I am an Insurance 
agent by profession, this funds was supposed be paid to my late client as Life 
Assurance policy, he died interstate without any next of kin in case of 
eventuality and now the paying institution has mandated me as the agent that I 
present the next of kin to this funds from now till second week of November 
after which the government will confiscate it.

Due to the fact you have a similar name with him and With the papers in my 
possession, I will make you the sole beneficiary to this payment by submitting 
your credentials to the bank as the next of kin after which you and I will 
share it equally among ourselves than leaving this opportunity for other 
insurance agents to benefit or allowing it paid into the government coffers as 
unclaimed policy.

Best Regards

Mr Richards P.Francisco

Hello Good Day,

[Mr. Richards Francisco]

Dear Respectfully,

I write to seek for your indulgence on a US$9.7 Million deal, I am an Insurance 
agent by profession, this funds was supposed be paid to my late client as Life 
Assurance policy, he died interstate without any next of kin in case of 
eventuality and now the paying institution has mandated me as the agent that I 
present the next of kin to this funds from now till second week of November 
after which the government will confiscate it.

Due to the fact you have a similar name with him and With the papers in my 
possession, I will make you the sole beneficiary to this payment by submitting 
your credentials to the bank as the next of kin after which you and I will 
share it equally among ourselves than leaving this opportunity for other 
insurance agents to benefit or allowing it paid into the government coffers as 
unclaimed policy.

Best Regards

Mr Richards P.Francisco

Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd_address()

[Matthias Kaehlcke]

On Thu, Sep 27, 2018 at 10:13:05AM -0700, Matthias Kaehlcke wrote:
> On Thu, Sep 27, 2018 at 12:47:06PM -0400, Sinan Kaya wrote:
> > On 9/27/2018 12:41 PM, Balakrishna Godavarthi wrote:
> > >   void bt_sock_reclassify_lock(struct sock *sk, int proto);
> > > 
> > > +int device_get_bd_address(struct device *dev, bdaddr_t *bd_addr);
> > 
> > Maybe change the API name to start with bt_ and get rid of device_?
> 
> device_ indicates that we get the BD_ADDR for a 'struct device' and
> not for e.g. a 'struct fwnode_handle'.
> 
> Anyway with this version of the patch fwnode_get_bd_address() has been
> scrapped and it might never be introduced again, so I'm open to change
> the name to bt_ if there is a general preference for it.

Marcel, can you live with this being added to the Bluetooth code base
instead of property? Also if you'd prefer the function to be named
bt_get_bd_address() let me know.

Cheers

Matthias

Re: [PATCH 1/2] Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()

[Pali Rohár]

On Friday 05 October 2018 01:21:00 chenchacha wrote:
> Signed-off-by: chenchacha 
> ---
>  fs/fat/file.c | 22 ++
>  include/uapi/linux/msdos_fs.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 4724cc9ad650..56db0b5a8df1 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -121,10 +121,30 @@ static int fat_ioctl_get_volume_id(struct inode *inode, 
> u32 __user *user_attr)
>   return put_user(sbi->vol_id, user_attr);
>  }
>  
> +static int fat_ioctl_get_volume_label(struct inode *inode, u8 __user *label)
> +{
> + struct super_block *sb = inode->i_sb;
> + struct inode *root_inode = d_inode(sb->s_root);
> + struct buffer_head *bh = NULL;
> + struct msdos_dir_entry *de;
> + int err;
> +
> + inode_lock_shared(root_inode);
> + err = fat_get_root_entry(root_inode, , );
> + if (err == 0) {
> + if (copy_to_user(label, de->name, MSDOS_NAME))

You need to convert entry name from 8.3 format to label in correct
encoding specified by codepage mount option. Plus needs to handle
leading 0x03 byte.

> + err = -EFAULT;
> + }
> + inode_unlock_shared(root_inode);
> +
> + return err;
> +}
> +
>  long fat_generic_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> arg)
>  {
>   struct inode *inode = file_inode(filp);
>   u32 __user *user_attr = (u32 __user *)arg;
> + u8 __user *user_vol_label = (u8 __user *)arg;
>  
>   switch (cmd) {
>   case FAT_IOCTL_GET_ATTRIBUTES:
> @@ -133,6 +153,8 @@ long fat_generic_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   return fat_ioctl_set_attributes(filp, user_attr);
>   case FAT_IOCTL_GET_VOLUME_ID:
>   return fat_ioctl_get_volume_id(inode, user_attr);
> + case FAT_IOCTL_GET_VOLUME_LABEL:
> + return fat_ioctl_get_volume_label(inode, user_vol_label);
>   default:
>   return -ENOTTY; /* Inappropriate ioctl for device */
>   }
> diff --git a/include/uapi/linux/msdos_fs.h b/include/uapi/linux/msdos_fs.h
> index fde753735aba..8ba8e2d7bafe 100644
> --- a/include/uapi/linux/msdos_fs.h
> +++ b/include/uapi/linux/msdos_fs.h
> @@ -109,6 +109,7 @@ struct __fat_dirent {
>  #define FAT_IOCTL_SET_ATTRIBUTES _IOW('r', 0x11, __u32)
>  /*Android kernel has used 0x12, so we use 0x13*/
>  #define FAT_IOCTL_GET_VOLUME_ID  _IOR('r', 0x13, __u32)
> +#define FAT_IOCTL_GET_VOLUME_LABEL   _IOR('r', 0x14, __u8[MSDOS_NAME])
>  
>  struct fat_boot_sector {
>   __u8ignored[3]; /* Boot strap short or near jump */

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd_address()

[Matthias Kaehlcke]

On Thu, Sep 27, 2018 at 10:13:05AM -0700, Matthias Kaehlcke wrote:
> On Thu, Sep 27, 2018 at 12:47:06PM -0400, Sinan Kaya wrote:
> > On 9/27/2018 12:41 PM, Balakrishna Godavarthi wrote:
> > >   void bt_sock_reclassify_lock(struct sock *sk, int proto);
> > > 
> > > +int device_get_bd_address(struct device *dev, bdaddr_t *bd_addr);
> > 
> > Maybe change the API name to start with bt_ and get rid of device_?
> 
> device_ indicates that we get the BD_ADDR for a 'struct device' and
> not for e.g. a 'struct fwnode_handle'.
> 
> Anyway with this version of the patch fwnode_get_bd_address() has been
> scrapped and it might never be introduced again, so I'm open to change
> the name to bt_ if there is a general preference for it.

Marcel, can you live with this being added to the Bluetooth code base
instead of property? Also if you'd prefer the function to be named
bt_get_bd_address() let me know.

Cheers

Matthias

Re: [PATCH 1/2] Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()

[Pali Rohár]

On Friday 05 October 2018 01:21:00 chenchacha wrote:
> Signed-off-by: chenchacha 
> ---
>  fs/fat/file.c | 22 ++
>  include/uapi/linux/msdos_fs.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 4724cc9ad650..56db0b5a8df1 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -121,10 +121,30 @@ static int fat_ioctl_get_volume_id(struct inode *inode, 
> u32 __user *user_attr)
>   return put_user(sbi->vol_id, user_attr);
>  }
>  
> +static int fat_ioctl_get_volume_label(struct inode *inode, u8 __user *label)
> +{
> + struct super_block *sb = inode->i_sb;
> + struct inode *root_inode = d_inode(sb->s_root);
> + struct buffer_head *bh = NULL;
> + struct msdos_dir_entry *de;
> + int err;
> +
> + inode_lock_shared(root_inode);
> + err = fat_get_root_entry(root_inode, , );
> + if (err == 0) {
> + if (copy_to_user(label, de->name, MSDOS_NAME))

You need to convert entry name from 8.3 format to label in correct
encoding specified by codepage mount option. Plus needs to handle
leading 0x03 byte.

> + err = -EFAULT;
> + }
> + inode_unlock_shared(root_inode);
> +
> + return err;
> +}
> +
>  long fat_generic_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> arg)
>  {
>   struct inode *inode = file_inode(filp);
>   u32 __user *user_attr = (u32 __user *)arg;
> + u8 __user *user_vol_label = (u8 __user *)arg;
>  
>   switch (cmd) {
>   case FAT_IOCTL_GET_ATTRIBUTES:
> @@ -133,6 +153,8 @@ long fat_generic_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   return fat_ioctl_set_attributes(filp, user_attr);
>   case FAT_IOCTL_GET_VOLUME_ID:
>   return fat_ioctl_get_volume_id(inode, user_attr);
> + case FAT_IOCTL_GET_VOLUME_LABEL:
> + return fat_ioctl_get_volume_label(inode, user_vol_label);
>   default:
>   return -ENOTTY; /* Inappropriate ioctl for device */
>   }
> diff --git a/include/uapi/linux/msdos_fs.h b/include/uapi/linux/msdos_fs.h
> index fde753735aba..8ba8e2d7bafe 100644
> --- a/include/uapi/linux/msdos_fs.h
> +++ b/include/uapi/linux/msdos_fs.h
> @@ -109,6 +109,7 @@ struct __fat_dirent {
>  #define FAT_IOCTL_SET_ATTRIBUTES _IOW('r', 0x11, __u32)
>  /*Android kernel has used 0x12, so we use 0x13*/
>  #define FAT_IOCTL_GET_VOLUME_ID  _IOR('r', 0x13, __u32)
> +#define FAT_IOCTL_GET_VOLUME_LABEL   _IOR('r', 0x14, __u8[MSDOS_NAME])
>  
>  struct fat_boot_sector {
>   __u8ignored[3]; /* Boot strap short or near jump */

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Christian Brauner]

On Fri, Oct 05, 2018 at 02:26:11AM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn  wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> 
> I've been playing with this and I have the following patch, which
> according to my testing protects against attacks where ".." skips over
> nd->root. It abuses __d_path to figure out if nd->path can be resolved
> from nd->root (obviously a proper version of this patch would refactor
> __d_path so it could be used like this -- and would not return
> -EMULTIHOP).
> 
> I've also attached my reproducer. With it, I was seeing fairly constant
> breakouts before this patch and after it I didn't see a single breakout
> after running it overnight. Obviously this is not conclusive, but I'm
> hoping that it can show what my idea for protecting against ".." was.
> 
> Does this patch make sense? Or is there something wrong with it that I'm
> not seeing?

Interesting.
Apart from the abuse of __d_path() :) the question I'd have is whether
this just minimizes the race window or if you can provide a sound
argument that this actually can't happen anymore with this patch.

> 
> --8<---
> 
> There is a fairly easy-to-exploit race condition with chroot(2) (and
> thus by extension AT_THIS_ROOT and AT_BENEATH) where a rename(2) of a
> path can be used to "skip over" nd->root and thus escape to the
> filesystem above nd->root.
> 
>   thread1 [attacker]:
> for (;;)
>   renameat2(AT_FDCWD, "/a/b/c", AT_FDCWD, "/a/d", RENAME_EXCHANGE);
>   thread2 [victim]:
> for (;;)
>   openat(dirb, "b/c/../../etc/shadow", O_THISROOT);
> 
> With fairly significant regularity, thread2 will resolve to
> "/etc/shadow" rather than "/a/b/etc/shadow". With this patch, such cases
> will be detected during ".." resolution (which is the weak point of
> chroot(2) -- since walking *into* a subdirectory tautologically cannot
> result in you walking *outside* nd->root).
> 
> The use of __d_path here might seem suspect, however we don't mind if a
> path is moved from within the chroot to outside the chroot and we
> incorrectly decide it is safe (because at that point we are still within
> the set of files which were accessible at the beginning of resolution).
> However, we can fail resolution on the next path component if it remains
> outside of the root. A path which has always been outside nd->root
> during resolution will never be resolveable from nd->root and thus will
> always be blocked.
> 
> DO NOT MERGE: Currently this code returns -EMULTIHOP in this case,
> purely as a debugging measure (so that you can see that
> the protection actually does something). Obviously in the
> proper patch this will return -EXDEV.
> 
> Signed-off-by: Aleksa Sarai 
> ---
>  fs/namei.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 6f995e6de6b1..c8349693d47b 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -53,8 +53,8 @@
>   * The new code replaces the old recursive symlink resolution with
>   * an iterative one (in case of non-nested symlink chains).  It does
>   * this with calls to _follow_link().
> - * As a side effect, dir_namei(), _namei() and follow_link() are now 
> - * replaced with a single function lookup_dentry() that can handle all 
> + * As a side effect, dir_namei(), _namei() and follow_link() are now
> + * replaced with a single function lookup_dentry() that can handle all
>   * the special cases of the former code.
>   *
>   * With the new dcache, the pathname is stored at each inode, at least as
> @@ -1375,6 +1375,20 @@ static int follow_dotdot_rcu(struct nameidata *nd)
>   return -EXDEV;
>   break;
>   }
> + if (unlikely(nd->flags & (LOOKUP_BENEATH | LOOKUP_CHROOT))) {
> + char *pathbuf, *pathptr;
> +
> + pathbuf = kmalloc(PATH_MAX, GFP_ATOMIC);
> + if (!pathbuf)
> + return -ECHILD;
> + pathptr = __d_path(>path, >root, pathbuf, 
> PATH_MAX);
> + kfree(pathbuf);
> + if (IS_ERR_OR_NULL(pathptr)) {
> +   

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Christian Brauner]

On Fri, Oct 05, 2018 at 02:26:11AM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn  wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> 
> I've been playing with this and I have the following patch, which
> according to my testing protects against attacks where ".." skips over
> nd->root. It abuses __d_path to figure out if nd->path can be resolved
> from nd->root (obviously a proper version of this patch would refactor
> __d_path so it could be used like this -- and would not return
> -EMULTIHOP).
> 
> I've also attached my reproducer. With it, I was seeing fairly constant
> breakouts before this patch and after it I didn't see a single breakout
> after running it overnight. Obviously this is not conclusive, but I'm
> hoping that it can show what my idea for protecting against ".." was.
> 
> Does this patch make sense? Or is there something wrong with it that I'm
> not seeing?

Interesting.
Apart from the abuse of __d_path() :) the question I'd have is whether
this just minimizes the race window or if you can provide a sound
argument that this actually can't happen anymore with this patch.

> 
> --8<---
> 
> There is a fairly easy-to-exploit race condition with chroot(2) (and
> thus by extension AT_THIS_ROOT and AT_BENEATH) where a rename(2) of a
> path can be used to "skip over" nd->root and thus escape to the
> filesystem above nd->root.
> 
>   thread1 [attacker]:
> for (;;)
>   renameat2(AT_FDCWD, "/a/b/c", AT_FDCWD, "/a/d", RENAME_EXCHANGE);
>   thread2 [victim]:
> for (;;)
>   openat(dirb, "b/c/../../etc/shadow", O_THISROOT);
> 
> With fairly significant regularity, thread2 will resolve to
> "/etc/shadow" rather than "/a/b/etc/shadow". With this patch, such cases
> will be detected during ".." resolution (which is the weak point of
> chroot(2) -- since walking *into* a subdirectory tautologically cannot
> result in you walking *outside* nd->root).
> 
> The use of __d_path here might seem suspect, however we don't mind if a
> path is moved from within the chroot to outside the chroot and we
> incorrectly decide it is safe (because at that point we are still within
> the set of files which were accessible at the beginning of resolution).
> However, we can fail resolution on the next path component if it remains
> outside of the root. A path which has always been outside nd->root
> during resolution will never be resolveable from nd->root and thus will
> always be blocked.
> 
> DO NOT MERGE: Currently this code returns -EMULTIHOP in this case,
> purely as a debugging measure (so that you can see that
> the protection actually does something). Obviously in the
> proper patch this will return -EXDEV.
> 
> Signed-off-by: Aleksa Sarai 
> ---
>  fs/namei.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 6f995e6de6b1..c8349693d47b 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -53,8 +53,8 @@
>   * The new code replaces the old recursive symlink resolution with
>   * an iterative one (in case of non-nested symlink chains).  It does
>   * this with calls to _follow_link().
> - * As a side effect, dir_namei(), _namei() and follow_link() are now 
> - * replaced with a single function lookup_dentry() that can handle all 
> + * As a side effect, dir_namei(), _namei() and follow_link() are now
> + * replaced with a single function lookup_dentry() that can handle all
>   * the special cases of the former code.
>   *
>   * With the new dcache, the pathname is stored at each inode, at least as
> @@ -1375,6 +1375,20 @@ static int follow_dotdot_rcu(struct nameidata *nd)
>   return -EXDEV;
>   break;
>   }
> + if (unlikely(nd->flags & (LOOKUP_BENEATH | LOOKUP_CHROOT))) {
> + char *pathbuf, *pathptr;
> +
> + pathbuf = kmalloc(PATH_MAX, GFP_ATOMIC);
> + if (!pathbuf)
> + return -ECHILD;
> + pathptr = __d_path(>path, >root, pathbuf, 
> PATH_MAX);
> + kfree(pathbuf);
> + if (IS_ERR_OR_NULL(pathptr)) {
> +   

[PATCH 0/2] fs: fat: add ioctl method to read voluem label in fat filesystem driver

[chenchacha]

This patch add fat ioctl command FAT_IOCTL_GET_VOLUME_LABEL.

We can get the volume label with this command:

ioctl(fd, FAT_IOCTL_GET_VOLUME_LABEL, _label);

FAT volume label (volume name) is exactly same stored in boot sector and root
directory. And this patch read label only from the root directory. If label in
root directory is missing then disk would be treated as without label. Label
from boot sector would not be read.

The volume label format reference from Pali Rohár testing results
(https://www.spinics.net/lists/kernel/msg2645732.html) in the previous mail.

chenchacha (2):
  Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()
  Add a new function to get root directory with ATTR_VOLUME

 fs/fat/dir.c  | 13 +
 fs/fat/fat.h  |  2 ++
 fs/fat/file.c | 22 ++
 include/uapi/linux/msdos_fs.h |  1 +
 4 files changed, 38 insertions(+)

-- 
2.19.0

Re: [PATCH 2/2] Add a new function to get root directory with ATTR_VOLUME

[Pali Rohár]

On Friday 05 October 2018 01:21:01 chenchacha wrote:
> Signed-off-by: chenchacha 
> ---
>  fs/fat/dir.c | 13 +
>  fs/fat/fat.h |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
> index 7f5f3699fc6c..4fdcc1200f2b 100644
> --- a/fs/fat/dir.c
> +++ b/fs/fat/dir.c
> @@ -881,6 +881,19 @@ static int fat_get_short_entry(struct inode *dir, loff_t 
> *pos,
>   return -ENOENT;
>  }
>  
> +int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
> +struct msdos_dir_entry **de)

fat_get_root_volume_entry would be better name. It does not return root
entry, but volume label entry.

> +{
> + loff_t offset = 0;
> +
> + *de = NULL;
> + while (fat_get_entry(dir, , bh, de) >= 0) {
> + if (!IS_FREE((*de)->name) && (*de)->attr & ATTR_VOLUME)

You should check that cluster number is zero. As e.g. first entry with
ATTR_VOLUME can be also LFN entry and not real volume label. So you
should properly check mask and filter out also LFN entries which have
ATTR_VOLUME flag set too.

> + return 0;
> + }
> + return -ENOENT;
> +}
> +
>  /*
>   * The ".." entry can not provide the "struct fat_slot_info" information
>   * for inode, nor a usable i_pos. So, this function provides some information
> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
> index be012de96f65..4195cb1e891a 100644
> --- a/fs/fat/fat.h
> +++ b/fs/fat/fat.h
> @@ -302,6 +302,8 @@ extern int fat_scan(struct inode *dir, const unsigned 
> char *name,
>   struct fat_slot_info *sinfo);
>  extern int fat_scan_logstart(struct inode *dir, int i_logstart,
>struct fat_slot_info *sinfo);
> +extern int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
> +   struct msdos_dir_entry **de);
>  extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
>   struct msdos_dir_entry **de);
>  extern int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts);
> -- 
> 2.19.0
> 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

[PATCH 0/2] fs: fat: add ioctl method to read voluem label in fat filesystem driver

[chenchacha]

This patch add fat ioctl command FAT_IOCTL_GET_VOLUME_LABEL.

We can get the volume label with this command:

ioctl(fd, FAT_IOCTL_GET_VOLUME_LABEL, _label);

FAT volume label (volume name) is exactly same stored in boot sector and root
directory. And this patch read label only from the root directory. If label in
root directory is missing then disk would be treated as without label. Label
from boot sector would not be read.

The volume label format reference from Pali Rohár testing results
(https://www.spinics.net/lists/kernel/msg2645732.html) in the previous mail.

chenchacha (2):
  Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()
  Add a new function to get root directory with ATTR_VOLUME

 fs/fat/dir.c  | 13 +
 fs/fat/fat.h  |  2 ++
 fs/fat/file.c | 22 ++
 include/uapi/linux/msdos_fs.h |  1 +
 4 files changed, 38 insertions(+)

-- 
2.19.0

Re: [PATCH 2/2] Add a new function to get root directory with ATTR_VOLUME

[Pali Rohár]

On Friday 05 October 2018 01:21:01 chenchacha wrote:
> Signed-off-by: chenchacha 
> ---
>  fs/fat/dir.c | 13 +
>  fs/fat/fat.h |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
> index 7f5f3699fc6c..4fdcc1200f2b 100644
> --- a/fs/fat/dir.c
> +++ b/fs/fat/dir.c
> @@ -881,6 +881,19 @@ static int fat_get_short_entry(struct inode *dir, loff_t 
> *pos,
>   return -ENOENT;
>  }
>  
> +int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
> +struct msdos_dir_entry **de)

fat_get_root_volume_entry would be better name. It does not return root
entry, but volume label entry.

> +{
> + loff_t offset = 0;
> +
> + *de = NULL;
> + while (fat_get_entry(dir, , bh, de) >= 0) {
> + if (!IS_FREE((*de)->name) && (*de)->attr & ATTR_VOLUME)

You should check that cluster number is zero. As e.g. first entry with
ATTR_VOLUME can be also LFN entry and not real volume label. So you
should properly check mask and filter out also LFN entries which have
ATTR_VOLUME flag set too.

> + return 0;
> + }
> + return -ENOENT;
> +}
> +
>  /*
>   * The ".." entry can not provide the "struct fat_slot_info" information
>   * for inode, nor a usable i_pos. So, this function provides some information
> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
> index be012de96f65..4195cb1e891a 100644
> --- a/fs/fat/fat.h
> +++ b/fs/fat/fat.h
> @@ -302,6 +302,8 @@ extern int fat_scan(struct inode *dir, const unsigned 
> char *name,
>   struct fat_slot_info *sinfo);
>  extern int fat_scan_logstart(struct inode *dir, int i_logstart,
>struct fat_slot_info *sinfo);
> +extern int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
> +   struct msdos_dir_entry **de);
>  extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
>   struct msdos_dir_entry **de);
>  extern int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts);
> -- 
> 2.19.0
> 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

[PATCH 2/2] Add a new function to get root directory with ATTR_VOLUME

[chenchacha]

Signed-off-by: chenchacha 
---
 fs/fat/dir.c | 13 +
 fs/fat/fat.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 7f5f3699fc6c..4fdcc1200f2b 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -881,6 +881,19 @@ static int fat_get_short_entry(struct inode *dir, loff_t 
*pos,
return -ENOENT;
 }
 
+int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
+  struct msdos_dir_entry **de)
+{
+   loff_t offset = 0;
+
+   *de = NULL;
+   while (fat_get_entry(dir, , bh, de) >= 0) {
+   if (!IS_FREE((*de)->name) && (*de)->attr & ATTR_VOLUME)
+   return 0;
+   }
+   return -ENOENT;
+}
+
 /*
  * The ".." entry can not provide the "struct fat_slot_info" information
  * for inode, nor a usable i_pos. So, this function provides some information
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index be012de96f65..4195cb1e891a 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -302,6 +302,8 @@ extern int fat_scan(struct inode *dir, const unsigned char 
*name,
struct fat_slot_info *sinfo);
 extern int fat_scan_logstart(struct inode *dir, int i_logstart,
 struct fat_slot_info *sinfo);
+extern int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
+ struct msdos_dir_entry **de);
 extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
struct msdos_dir_entry **de);
 extern int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts);
-- 
2.19.0

[PATCH 2/2] Add a new function to get root directory with ATTR_VOLUME

[chenchacha]

Signed-off-by: chenchacha 
---
 fs/fat/dir.c | 13 +
 fs/fat/fat.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 7f5f3699fc6c..4fdcc1200f2b 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -881,6 +881,19 @@ static int fat_get_short_entry(struct inode *dir, loff_t 
*pos,
return -ENOENT;
 }
 
+int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
+  struct msdos_dir_entry **de)
+{
+   loff_t offset = 0;
+
+   *de = NULL;
+   while (fat_get_entry(dir, , bh, de) >= 0) {
+   if (!IS_FREE((*de)->name) && (*de)->attr & ATTR_VOLUME)
+   return 0;
+   }
+   return -ENOENT;
+}
+
 /*
  * The ".." entry can not provide the "struct fat_slot_info" information
  * for inode, nor a usable i_pos. So, this function provides some information
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index be012de96f65..4195cb1e891a 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -302,6 +302,8 @@ extern int fat_scan(struct inode *dir, const unsigned char 
*name,
struct fat_slot_info *sinfo);
 extern int fat_scan_logstart(struct inode *dir, int i_logstart,
 struct fat_slot_info *sinfo);
+extern int fat_get_root_entry(struct inode *dir, struct buffer_head **bh,
+ struct msdos_dir_entry **de);
 extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
struct msdos_dir_entry **de);
 extern int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts);
-- 
2.19.0

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Christian Brauner]

On Tue, Oct 02, 2018 at 02:18:33AM +1000, Aleksa Sarai wrote:
> On 2018-10-01, Jann Horn  wrote:
> > > If this is an issue for AT_THIS_ROOT, I believe this might also be an
> > > issue for AT_BENEATH since they are effectively both using the same
> > > nd->root trick (so you could similarly trick AT_BENEATH to not error
> > > out). So we'd need to figure out how to solve this problem in order for
> > > AT_BENEATH to be safe.
> > 
> > Oh, wait, what? I think I didn't notice that the semantics of
> > AT_BENEATH changed like that since the original posting of David
> > Drysdale's O_BENEATH_ONLY patch
> > (https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysd...@google.com/).
> > David's patch had nice, straightforward semantics, blocking any form
> > of upwards traversal. Why was that changed? Does anyone actually want
> > to use paths that contain ".." with AT_BENEATH? I would strongly
> > prefer something that blocks any use of "..".
> > 
> > @Al: It looks like this already changed back when you posted
> > https://lore.kernel.org/lkml/20170429220414.gt29...@zeniv.linux.org.uk/
> > ?
> 
> Yes, I copied the semantics from Al's patchset. I don't know why he felt
> strongly that this was the best idea, but in my opinion allowing paths
> like "a/../b/../c" seems like it's quite useful because otherwise you
> wouldn't be able to operate on most distribution root filesystems (many
> have symlinks that have ".." components). Looking at my own (openSUSE)
> machine there are something like 100k such symlinks (~37% of symlinks on
> my machine).
> 
> While I do understand that the easiest way of solving this problem is to
> disallow ".." entirely with AT_BENEATH, given that support ".." has
> utility, I would like to know whether it's actually not possible to have
> this work safely.
> 
> > > Speaking naively, doesn't it make sense to invalidate the walk if a path
> > > component was modified? Or is this something that would be far too
> > > costly with little benefit? What if we do more aggressive nd->root
> > > checks when resolving with AT_BENEATH or AT_THIS_ROOT (or if nd->root !=
> > > current->mnt_ns->root)?
> > 
> > It seems to me like doing that would basically require looking at each
> > node in the path walk twice? And it'd be difficult to guarantee
> > forward progress unless you're willing to do some fairly heavy
> > locking.
> 
> I had another idea since I wrote my previous mail -- since the issue (at
> least the way I understand it) is that ".." can "skip" over nd->root
> because of the rename, what if we had some sort of is_descendant() check
> within follow_dotdot()? (FWIW, ".." already has some pretty interesting
> "hand-over-hand" locking semantics.) This should be effectively similar
> to how prepend_path() deals with a path that is not reachable from @root
> (I'm not sure if the locking is acceptable for the namei path though).
> 
> Since ".." with AT_THIS_ROOT (or AT_BENEATH) is not going to be the most
> common component type (and we only need to do these checks for those
> flags), I would think that the extra cost would not be _that_ awful.
> 
> Would this work?
> 
> > > You're right about this -- for C runtimes. In Go we cannot do a raw
> > > clone() or fork() (if you do it manually with RawSyscall you'll end with
> > > broken runtime state). So you're forced to do fork+exec (which then
> > > means that you can't use CLONE_FILES and must use SCM_RIGHTS). Same goes
> > > for CLONE_VFORK.
> > 
> > If you insist on implementing every last bit of your code in Go, I guess.
> 
> Fair enough, though I believe this would affect most multi-threaded
> programs as well (regardless of the language they're written in).

(Depends on whether you do any explicit locking and have atfork handlers
for your locks and so on. If you do a clone syscall directly to avoid
having libc running any additional atfork handlers (flushing streams
etc.) it's doable though not ideal.)

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Christian Brauner]

On Tue, Oct 02, 2018 at 02:18:33AM +1000, Aleksa Sarai wrote:
> On 2018-10-01, Jann Horn  wrote:
> > > If this is an issue for AT_THIS_ROOT, I believe this might also be an
> > > issue for AT_BENEATH since they are effectively both using the same
> > > nd->root trick (so you could similarly trick AT_BENEATH to not error
> > > out). So we'd need to figure out how to solve this problem in order for
> > > AT_BENEATH to be safe.
> > 
> > Oh, wait, what? I think I didn't notice that the semantics of
> > AT_BENEATH changed like that since the original posting of David
> > Drysdale's O_BENEATH_ONLY patch
> > (https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysd...@google.com/).
> > David's patch had nice, straightforward semantics, blocking any form
> > of upwards traversal. Why was that changed? Does anyone actually want
> > to use paths that contain ".." with AT_BENEATH? I would strongly
> > prefer something that blocks any use of "..".
> > 
> > @Al: It looks like this already changed back when you posted
> > https://lore.kernel.org/lkml/20170429220414.gt29...@zeniv.linux.org.uk/
> > ?
> 
> Yes, I copied the semantics from Al's patchset. I don't know why he felt
> strongly that this was the best idea, but in my opinion allowing paths
> like "a/../b/../c" seems like it's quite useful because otherwise you
> wouldn't be able to operate on most distribution root filesystems (many
> have symlinks that have ".." components). Looking at my own (openSUSE)
> machine there are something like 100k such symlinks (~37% of symlinks on
> my machine).
> 
> While I do understand that the easiest way of solving this problem is to
> disallow ".." entirely with AT_BENEATH, given that support ".." has
> utility, I would like to know whether it's actually not possible to have
> this work safely.
> 
> > > Speaking naively, doesn't it make sense to invalidate the walk if a path
> > > component was modified? Or is this something that would be far too
> > > costly with little benefit? What if we do more aggressive nd->root
> > > checks when resolving with AT_BENEATH or AT_THIS_ROOT (or if nd->root !=
> > > current->mnt_ns->root)?
> > 
> > It seems to me like doing that would basically require looking at each
> > node in the path walk twice? And it'd be difficult to guarantee
> > forward progress unless you're willing to do some fairly heavy
> > locking.
> 
> I had another idea since I wrote my previous mail -- since the issue (at
> least the way I understand it) is that ".." can "skip" over nd->root
> because of the rename, what if we had some sort of is_descendant() check
> within follow_dotdot()? (FWIW, ".." already has some pretty interesting
> "hand-over-hand" locking semantics.) This should be effectively similar
> to how prepend_path() deals with a path that is not reachable from @root
> (I'm not sure if the locking is acceptable for the namei path though).
> 
> Since ".." with AT_THIS_ROOT (or AT_BENEATH) is not going to be the most
> common component type (and we only need to do these checks for those
> flags), I would think that the extra cost would not be _that_ awful.
> 
> Would this work?
> 
> > > You're right about this -- for C runtimes. In Go we cannot do a raw
> > > clone() or fork() (if you do it manually with RawSyscall you'll end with
> > > broken runtime state). So you're forced to do fork+exec (which then
> > > means that you can't use CLONE_FILES and must use SCM_RIGHTS). Same goes
> > > for CLONE_VFORK.
> > 
> > If you insist on implementing every last bit of your code in Go, I guess.
> 
> Fair enough, though I believe this would affect most multi-threaded
> programs as well (regardless of the language they're written in).

(Depends on whether you do any explicit locking and have atfork handlers
for your locks and so on. If you do a clone syscall directly to avoid
having libc running any additional atfork handlers (flushing streams
etc.) it's doable though not ideal.)

Re: [PATCH 0/2] fs: fat: add ioctl method to read voluem label in fat filesystem driver

[Pali Rohár]

On Friday 05 October 2018 01:20:59 chenchacha wrote:
> This patch add fat ioctl command FAT_IOCTL_GET_VOLUME_LABEL.
> 
> We can get the volume label with this command:
> 
>   ioctl(fd, FAT_IOCTL_GET_VOLUME_LABEL, _label);

Hi! What is purpose of having such functionality in kernel? Userspace
can read it without any kernel support. (e.g. mlabel or fatlabel)

> FAT volume label (volume name) is exactly same stored in boot sector and root
> directory. And this patch read label only from the root directory. If label in
> root directory is missing then disk would be treated as without label. Label
> from boot sector would not be read.
> 
> The volume label format reference from Pali Rohár testing results
> (https://www.spinics.net/lists/kernel/msg2645732.html) in the previous mail.
> 
> chenchacha (2):
>   Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()
>   Add a new function to get root directory with ATTR_VOLUME
> 
>  fs/fat/dir.c  | 13 +
>  fs/fat/fat.h  |  2 ++
>  fs/fat/file.c | 22 ++
>  include/uapi/linux/msdos_fs.h |  1 +
>  4 files changed, 38 insertions(+)
> 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: [PATCH 0/2] fs: fat: add ioctl method to read voluem label in fat filesystem driver

[Pali Rohár]

On Friday 05 October 2018 01:20:59 chenchacha wrote:
> This patch add fat ioctl command FAT_IOCTL_GET_VOLUME_LABEL.
> 
> We can get the volume label with this command:
> 
>   ioctl(fd, FAT_IOCTL_GET_VOLUME_LABEL, _label);

Hi! What is purpose of having such functionality in kernel? Userspace
can read it without any kernel support. (e.g. mlabel or fatlabel)

> FAT volume label (volume name) is exactly same stored in boot sector and root
> directory. And this patch read label only from the root directory. If label in
> root directory is missing then disk would be treated as without label. Label
> from boot sector would not be read.
> 
> The volume label format reference from Pali Rohár testing results
> (https://www.spinics.net/lists/kernel/msg2645732.html) in the previous mail.
> 
> chenchacha (2):
>   Add FAT_IOCTL_GET_VOLUME_LABEL in fat_generic_ioctl()
>   Add a new function to get root directory with ATTR_VOLUME
> 
>  fs/fat/dir.c  | 13 +
>  fs/fat/fat.h  |  2 ++
>  fs/fat/file.c | 22 ++
>  include/uapi/linux/msdos_fs.h |  1 +
>  4 files changed, 38 insertions(+)
> 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

[PATCH V10 3/8] irqchip: add C-SKY APB bus interrupt controller

[Guo Ren]

 - irq-csky-apb-intc is a simple SOC interrupt controller which is
   used in a lot of C-SKY CPU SOC products.

Changelog:
 - pass checkpatch.pl.
 - use "bool ret" instead of "int ret"
 - add support-pulse-signal in irq-csky-apb-intc.c
 - change name with upstream feed-back
 - add INTC_IFR to clear irq-pending
 - remove CSKY_VECIRQ_LEGENCY
 - change to generic irq chip framework
 - add License and Copyright
 - use irq_domain_add_linear instead of leagcy

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig |   8 ++
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-csky-apb-intc.c | 274 
 3 files changed, 283 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-apb-intc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 8103f6f..41cdca0 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -380,6 +380,14 @@ config CSKY_MPINTC
  In fact it's not mmio map in hw and it use ld/st to visit the
  controller's register inside CPU.
 
+config CSKY_APB_INTC
+   bool "C-SKY APB Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY APB interrupt controller driver used
+ by C-SKY single core SOC system. It use mmio map apb-bus to visit
+ the controller's register.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 6b739ea..72eaf53 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -88,4 +88,5 @@ obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
 obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
+obj-$(CONFIG_CSKY_APB_INTC)+= irq-csky-apb-intc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-apb-intc.c 
b/drivers/irqchip/irq-csky-apb-intc.c
new file mode 100644
index 000..2543bab
--- /dev/null
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INTC_IRQS  64
+
+#define CK_INTC_ICR0x00
+#define CK_INTC_PEN31_00   0x14
+#define CK_INTC_PEN63_32   0x2c
+#define CK_INTC_NEN31_00   0x10
+#define CK_INTC_NEN63_32   0x28
+#define CK_INTC_SOURCE 0x40
+#define CK_INTC_DUAL_BASE  0x100
+
+#define GX_INTC_PEN31_00   0x00
+#define GX_INTC_PEN63_32   0x04
+#define GX_INTC_NEN31_00   0x40
+#define GX_INTC_NEN63_32   0x44
+#define GX_INTC_NMASK31_00 0x50
+#define GX_INTC_NMASK63_32 0x54
+#define GX_INTC_SOURCE 0x60
+
+static void __iomem *reg_base;
+static struct irq_domain *root_domain;
+
+static int nr_irq = INTC_IRQS;
+
+/*
+ * When controller support pulse signal, the PEN_reg will hold on signal
+ * without software trigger.
+ *
+ * So, to support pulse signal we need to clear IFR_reg and the address of
+ * IFR_offset is NEN_offset - 8.
+ */
+static void irq_ck_mask_set_bit(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   unsigned long ifr = ct->regs.mask - 8;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   *ct->mask_cache |= mask;
+   irq_reg_writel(gc, *ct->mask_cache, ct->regs.mask);
+   irq_reg_writel(gc, irq_reg_readl(gc, ifr) & ~mask, ifr);
+   irq_gc_unlock(gc);
+}
+
+static void __init ck_set_gc(struct device_node *node, void __iomem *reg_base,
+u32 mask_reg, u32 irq_base)
+{
+   struct irq_chip_generic *gc;
+
+   gc = irq_get_domain_generic_chip(root_domain, irq_base);
+   gc->reg_base = reg_base;
+   gc->chip_types[0].regs.mask = mask_reg;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+   if (of_find_property(node, "csky,support-pulse-signal", NULL))
+   gc->chip_types[0].chip.irq_unmask = irq_ck_mask_set_bit;
+}
+
+static inline u32 build_channel_val(u32 idx, u32 magic)
+{
+   u32 res;
+
+   /*
+* Set the same index for each channel
+*/
+   res = idx | (idx << 8) | (idx << 16) | (idx << 24);
+
+   /*
+* Set the channel magic number in descending order.
+* The magic is 0x00010203 for ck-intc
+* The magic is 0x03020100 for gx6605s-intc
+*/
+   return res | magic;
+}
+
+static inline void setup_irq_channel(u32 magic, void __iomem *reg_addr)
+{
+   u32 i;
+
+   /* Setup 64 channel slots */
+   for (i = 0; i < INTC_IRQS; i += 4)
+   writel_relaxed(build_channel_val(i, magic), reg_addr + 

[PATCH V10 4/8] dt-bindings: interrupt-controller: C-SKY APB intc

[Guo Ren]

 - Dt-bindings doc about C-SKY apb bus interrupt controller.

Signed-off-by: Guo Ren 
Reviewed-by: Rob Herring 
---
 .../interrupt-controller/csky,apb-intc.txt | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
new file mode 100644
index 000..44286dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
@@ -0,0 +1,62 @@
+==
+C-SKY APB Interrupt Controller
+==
+
+C-SKY APB Interrupt Controller is a simple soc interrupt controller
+on the apb bus and we only use it as root irq controller.
+
+ - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq 
nums.
+ - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
+ - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq 
nums.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes APB interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,apb-intc"
+   "csky,dual-apb-intc"
+   "csky,gx6605s-intc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - interrupt-controller:
+   Usage: required
+   - csky,support-pulse-signal:
+   Usage: select
+   Description: to support pulse signal flag
+
+Examples:
+-
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,dual-apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,gx6605s-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
-- 
2.7.4

[PATCH V10 2/8] dt-bindings: interrupt-controller: C-SKY SMP intc

[Guo Ren]

Dt-bindings doc about C-SKY Multi-processors interrupt controller.

Changelog:
 - Should be: '#interrupt-cells' not 'interrupt-cells'

Signed-off-by: Guo Ren 
---
 .../bindings/interrupt-controller/csky,mpintc.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
new file mode 100644
index 000..ab921f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
@@ -0,0 +1,40 @@
+===
+C-SKY Multi-processors Interrupt Controller
+===
+
+C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860
+SMP soc, and it also could be used in non-SMP system.
+
+Interrupt number definition:
+
+  0-15  : software irq, and we use 15 as our IPI_IRQ.
+ 16-31  : private  irq, and we use 16 as the co-processor timer.
+ 31-1024: common irq for soc ip.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes SMP interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mpintc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - interrupt-controller:
+   Usage: required
+
+Examples:
+-
+
+   intc: interrupt-controller {
+   compatible = "csky,mpintc";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   };
-- 
2.7.4

Re: [PATCH 9/9] ARM: bcm63138: Enable SATA AHCI and PHY

[Florian Fainelli]

On 09/20/2018 12:16 PM, Florian Fainelli wrote:
> The Broadcom BCM963138DVT board has an eSATA port which is fully
> functional, turn on the AHCI controller and the companion SATA PHY.
> 
> Signed-off-by: Florian Fainelli 

Applied to devicetree/next
-- 
Florian

[PATCH V10 3/8] irqchip: add C-SKY APB bus interrupt controller

[Guo Ren]

 - irq-csky-apb-intc is a simple SOC interrupt controller which is
   used in a lot of C-SKY CPU SOC products.

Changelog:
 - pass checkpatch.pl.
 - use "bool ret" instead of "int ret"
 - add support-pulse-signal in irq-csky-apb-intc.c
 - change name with upstream feed-back
 - add INTC_IFR to clear irq-pending
 - remove CSKY_VECIRQ_LEGENCY
 - change to generic irq chip framework
 - add License and Copyright
 - use irq_domain_add_linear instead of leagcy

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig |   8 ++
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-csky-apb-intc.c | 274 
 3 files changed, 283 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-apb-intc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 8103f6f..41cdca0 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -380,6 +380,14 @@ config CSKY_MPINTC
  In fact it's not mmio map in hw and it use ld/st to visit the
  controller's register inside CPU.
 
+config CSKY_APB_INTC
+   bool "C-SKY APB Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY APB interrupt controller driver used
+ by C-SKY single core SOC system. It use mmio map apb-bus to visit
+ the controller's register.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 6b739ea..72eaf53 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -88,4 +88,5 @@ obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
 obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
+obj-$(CONFIG_CSKY_APB_INTC)+= irq-csky-apb-intc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-apb-intc.c 
b/drivers/irqchip/irq-csky-apb-intc.c
new file mode 100644
index 000..2543bab
--- /dev/null
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INTC_IRQS  64
+
+#define CK_INTC_ICR0x00
+#define CK_INTC_PEN31_00   0x14
+#define CK_INTC_PEN63_32   0x2c
+#define CK_INTC_NEN31_00   0x10
+#define CK_INTC_NEN63_32   0x28
+#define CK_INTC_SOURCE 0x40
+#define CK_INTC_DUAL_BASE  0x100
+
+#define GX_INTC_PEN31_00   0x00
+#define GX_INTC_PEN63_32   0x04
+#define GX_INTC_NEN31_00   0x40
+#define GX_INTC_NEN63_32   0x44
+#define GX_INTC_NMASK31_00 0x50
+#define GX_INTC_NMASK63_32 0x54
+#define GX_INTC_SOURCE 0x60
+
+static void __iomem *reg_base;
+static struct irq_domain *root_domain;
+
+static int nr_irq = INTC_IRQS;
+
+/*
+ * When controller support pulse signal, the PEN_reg will hold on signal
+ * without software trigger.
+ *
+ * So, to support pulse signal we need to clear IFR_reg and the address of
+ * IFR_offset is NEN_offset - 8.
+ */
+static void irq_ck_mask_set_bit(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   unsigned long ifr = ct->regs.mask - 8;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   *ct->mask_cache |= mask;
+   irq_reg_writel(gc, *ct->mask_cache, ct->regs.mask);
+   irq_reg_writel(gc, irq_reg_readl(gc, ifr) & ~mask, ifr);
+   irq_gc_unlock(gc);
+}
+
+static void __init ck_set_gc(struct device_node *node, void __iomem *reg_base,
+u32 mask_reg, u32 irq_base)
+{
+   struct irq_chip_generic *gc;
+
+   gc = irq_get_domain_generic_chip(root_domain, irq_base);
+   gc->reg_base = reg_base;
+   gc->chip_types[0].regs.mask = mask_reg;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+   if (of_find_property(node, "csky,support-pulse-signal", NULL))
+   gc->chip_types[0].chip.irq_unmask = irq_ck_mask_set_bit;
+}
+
+static inline u32 build_channel_val(u32 idx, u32 magic)
+{
+   u32 res;
+
+   /*
+* Set the same index for each channel
+*/
+   res = idx | (idx << 8) | (idx << 16) | (idx << 24);
+
+   /*
+* Set the channel magic number in descending order.
+* The magic is 0x00010203 for ck-intc
+* The magic is 0x03020100 for gx6605s-intc
+*/
+   return res | magic;
+}
+
+static inline void setup_irq_channel(u32 magic, void __iomem *reg_addr)
+{
+   u32 i;
+
+   /* Setup 64 channel slots */
+   for (i = 0; i < INTC_IRQS; i += 4)
+   writel_relaxed(build_channel_val(i, magic), reg_addr + 

[PATCH V10 4/8] dt-bindings: interrupt-controller: C-SKY APB intc

[Guo Ren]

 - Dt-bindings doc about C-SKY apb bus interrupt controller.

Signed-off-by: Guo Ren 
Reviewed-by: Rob Herring 
---
 .../interrupt-controller/csky,apb-intc.txt | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
new file mode 100644
index 000..44286dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
@@ -0,0 +1,62 @@
+==
+C-SKY APB Interrupt Controller
+==
+
+C-SKY APB Interrupt Controller is a simple soc interrupt controller
+on the apb bus and we only use it as root irq controller.
+
+ - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq 
nums.
+ - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
+ - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq 
nums.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes APB interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,apb-intc"
+   "csky,dual-apb-intc"
+   "csky,gx6605s-intc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - interrupt-controller:
+   Usage: required
+   - csky,support-pulse-signal:
+   Usage: select
+   Description: to support pulse signal flag
+
+Examples:
+-
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,dual-apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,gx6605s-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
-- 
2.7.4

[PATCH V10 2/8] dt-bindings: interrupt-controller: C-SKY SMP intc

[Guo Ren]

Dt-bindings doc about C-SKY Multi-processors interrupt controller.

Changelog:
 - Should be: '#interrupt-cells' not 'interrupt-cells'

Signed-off-by: Guo Ren 
---
 .../bindings/interrupt-controller/csky,mpintc.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
new file mode 100644
index 000..ab921f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
@@ -0,0 +1,40 @@
+===
+C-SKY Multi-processors Interrupt Controller
+===
+
+C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860
+SMP soc, and it also could be used in non-SMP system.
+
+Interrupt number definition:
+
+  0-15  : software irq, and we use 15 as our IPI_IRQ.
+ 16-31  : private  irq, and we use 16 as the co-processor timer.
+ 31-1024: common irq for soc ip.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes SMP interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mpintc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - interrupt-controller:
+   Usage: required
+
+Examples:
+-
+
+   intc: interrupt-controller {
+   compatible = "csky,mpintc";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   };
-- 
2.7.4

Re: [PATCH 9/9] ARM: bcm63138: Enable SATA AHCI and PHY

[Florian Fainelli]

On 09/20/2018 12:16 PM, Florian Fainelli wrote:
> The Broadcom BCM963138DVT board has an eSATA port which is fully
> functional, turn on the AHCI controller and the companion SATA PHY.
> 
> Signed-off-by: Florian Fainelli 

Applied to devicetree/next
-- 
Florian

[PATCH V10 6/8] dt-bindings: timer: C-SKY Multi-processor timer

[Guo Ren]

Dt-bingdings doc for C-SKY SMP system setting.

Changelog:
 - Drop the interrupt-parent.

Signed-off-by: Guo Ren 
---
 .../devicetree/bindings/timer/csky,mptimer.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.txt 
b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
new file mode 100644
index 000..15cfec0
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
@@ -0,0 +1,42 @@
+
+C-SKY Multi-processors Timer
+
+
+C-SKY multi-processors timer is designed for C-SKY SMP system and the
+regs is accessed by cpu co-processor 4 registers with mtcr/mfcr.
+
+ - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
+ - PTIM_TSR  "cr<1, 14>" Interrupt cleanup status reg.
+ - PTIM_CCVR "cr<3, 14>" Current counter value reg.
+ - PTIM_LVR  "cr<6, 14>" Window value reg to triger next event.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes SMP timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mptimer"
+   - clocks
+   Usage: required
+   Value type: 
+   Definition: must be input clk node
+   - interrupts
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer: timer {
+   compatible = "csky,mptimer";
+   clocks = <_apb_clk>;
+   interrupts = <16>;
+   interrupt-parent = <>;
+   };
-- 
2.7.4

[PATCH V10 6/8] dt-bindings: timer: C-SKY Multi-processor timer

[Guo Ren]

Dt-bingdings doc for C-SKY SMP system setting.

Changelog:
 - Drop the interrupt-parent.

Signed-off-by: Guo Ren 
---
 .../devicetree/bindings/timer/csky,mptimer.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.txt 
b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
new file mode 100644
index 000..15cfec0
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
@@ -0,0 +1,42 @@
+
+C-SKY Multi-processors Timer
+
+
+C-SKY multi-processors timer is designed for C-SKY SMP system and the
+regs is accessed by cpu co-processor 4 registers with mtcr/mfcr.
+
+ - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
+ - PTIM_TSR  "cr<1, 14>" Interrupt cleanup status reg.
+ - PTIM_CCVR "cr<3, 14>" Current counter value reg.
+ - PTIM_LVR  "cr<6, 14>" Window value reg to triger next event.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes SMP timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mptimer"
+   - clocks
+   Usage: required
+   Value type: 
+   Definition: must be input clk node
+   - interrupts
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer: timer {
+   compatible = "csky,mptimer";
+   clocks = <_apb_clk>;
+   interrupts = <16>;
+   interrupt-parent = <>;
+   };
-- 
2.7.4

[PATCH V10 8/8] dt-bindings: timer: gx6605s SOC timer

[Guo Ren]

Dt-bindings doc for gx6605s SOC's system timer.

Signed-off-by: Guo Ren 
---
 .../bindings/timer/csky,gx6605s-timer.txt  | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt 
b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
new file mode 100644
index 000..6b04344
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
@@ -0,0 +1,42 @@
+=
+gx6605s SOC Timer
+=
+
+The timer is used in gx6605s soc as system timer and the driver
+contain clk event and clk source.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes gx6605s SOC timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,gx6605s-timer"
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - clocks
+   Usage: required
+   Value type: phandle + clock specifier cells
+   Definition: must be input clk node
+   - interrupt
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer0: timer@20a000 {
+   compatible = "csky,gx6605s-timer";
+   reg = <0x0020a000 0x400>;
+   clocks = <_apb_clk>;
+   interrupts = <10>;
+   interrupt-parent = <>;
+   };
-- 
2.7.4

[PATCH V10 0/8] C-SKY(csky) Linux Kernel Driver

[Guo Ren]

This is about 10th patchset for C-SKY linux drivers. All patches have
been checked by checkpatch.pl.

Any feedback is welcome, thx for all people review my patchset.

If you finish the review for the patchset, please give a Reviewed-By
/ Acked-By and I'll record it in the commit-msg.

Guo Ren (8):
  irqchip: add C-SKY SMP interrupt controller
  dt-bindings: interrupt-controller: C-SKY SMP intc
  irqchip: add C-SKY APB bus interrupt controller
  dt-bindings: interrupt-controller: C-SKY APB intc
  clocksource: add C-SKY SMP timer
  dt-bindings: timer: C-SKY Multi-processor timer
  clocksource: add gx6605s SOC system timer
  dt-bindings: timer: gx6605s SOC timer

 .../interrupt-controller/csky,apb-intc.txt |  62 +
 .../bindings/interrupt-controller/csky,mpintc.txt  |  40 +++
 .../bindings/timer/csky,gx6605s-timer.txt  |  42 
 .../devicetree/bindings/timer/csky,mptimer.txt |  42 
 drivers/clocksource/Kconfig|  18 ++
 drivers/clocksource/Makefile   |   2 +
 drivers/clocksource/timer-gx6605s.c| 154 
 drivers/clocksource/timer-mp-csky.c| 173 +
 drivers/irqchip/Kconfig|  17 ++
 drivers/irqchip/Makefile   |   2 +
 drivers/irqchip/irq-csky-apb-intc.c| 274 +
 drivers/irqchip/irq-csky-mpintc.c  | 197 +++
 include/linux/cpuhotplug.h |   1 +
 13 files changed, 1024 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
 create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt
 create mode 100644 drivers/clocksource/timer-gx6605s.c
 create mode 100644 drivers/clocksource/timer-mp-csky.c
 create mode 100644 drivers/irqchip/irq-csky-apb-intc.c
 create mode 100644 drivers/irqchip/irq-csky-mpintc.c

-- 
2.7.4

[PATCH V10 5/8] clocksource: add C-SKY SMP timer

[Guo Ren]

This timer is used by SMP system and use mfcr/mtcr instruction
to access the regs.

Changelog:
 - Add rollback for timer_of_cleanup.
 - Use request_percpu_irq separate from time_of.
 - Remove #define CPUHP_AP_CSKY_TIMER_STARTING.
 - Add CPUHP_AP_CSKY_TIMER_STARTING in cpuhotplug.h.
 - Support csky mp timer alpha version.
 - Just use low-counter with 32bit width as clocksource.
 - Coding convention with upstream feed-back.

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig |  10 +++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-mp-csky.c | 173 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 185 insertions(+)
 create mode 100644 drivers/clocksource/timer-mp-csky.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a11f4ba..826a2e8 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -620,4 +620,14 @@ config RISCV_TIMER
  is accessed via both the SBI and the rdcycle instruction.  This is
  required for all RISC-V systems.
 
+config CSKY_MP_TIMER
+   bool "SMP Timer for the C-SKY platform"
+   depends on CSKY
+   select TIMER_OF
+   help
+ Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
+ system.
+ csky,mptimer is not only used in SMP system, it also could be used
+ single core system. It's not a mmio reg and it use mtcr/mfcr 
instruction.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index db51b24..5ce82d3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -79,3 +79,4 @@ obj-$(CONFIG_CLKSRC_ST_LPC)   += clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
+obj-$(CONFIG_CSKY_MP_TIMER)+= timer-mp-csky.o
diff --git a/drivers/clocksource/timer-mp-csky.c 
b/drivers/clocksource/timer-mp-csky.c
new file mode 100644
index 000..3e8de73
--- /dev/null
+++ b/drivers/clocksource/timer-mp-csky.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define PTIM_CCVR  "cr<3, 14>"
+#define PTIM_CTLR  "cr<0, 14>"
+#define PTIM_LVR   "cr<6, 14>"
+#define PTIM_TSR   "cr<1, 14>"
+
+static int csky_mptimer_irq;
+
+static int csky_mptimer_set_next_event(unsigned long delta,
+  struct clock_event_device *ce)
+{
+   mtcr(PTIM_LVR, delta);
+
+   return 0;
+}
+
+static int csky_mptimer_shutdown(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 1);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot_stopped(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static DEFINE_PER_CPU(struct timer_of, csky_to) = {
+   .flags  = TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_PERCPU |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = csky_mptimer_shutdown,
+   .set_state_oneshot  = csky_mptimer_oneshot,
+   .set_state_oneshot_stopped  = csky_mptimer_oneshot_stopped,
+   .set_next_event = csky_mptimer_set_next_event,
+   },
+};
+
+static irqreturn_t csky_timer_interrupt(int irq, void *dev)
+{
+   struct timer_of *to = this_cpu_ptr(_to);
+
+   mtcr(PTIM_TSR, 0);
+
+   to->clkevt.event_handler(>clkevt);
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * clock event for percpu
+ */
+static int csky_mptimer_starting_cpu(unsigned int cpu)
+{
+   struct timer_of *to = per_cpu_ptr(_to, cpu);
+
+   to->clkevt.cpumask = cpumask_of(cpu);
+
+   clockevents_config_and_register(>clkevt, timer_of_rate(to),
+   2, ULONG_MAX);
+
+   enable_percpu_irq(csky_mptimer_irq, 0);
+
+   return 0;
+}
+
+static int csky_mptimer_dying_cpu(unsigned int cpu)
+{
+   disable_percpu_irq(csky_mptimer_irq);
+
+   return 0;
+}
+
+/*
+ * clock source
+ */
+static u64 sched_clock_read(void)
+{
+   return (u64)mfcr(PTIM_CCVR);
+}
+
+static u64 clksrc_read(struct clocksource *c)
+{
+   return (u64)mfcr(PTIM_CCVR);
+}
+
+struct clocksource csky_clocksource = {
+   .name   = "csky",
+   .rating = 400,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+   .read   = clksrc_read,
+};
+
+static int __init csky_mptimer_init(struct device_node *np)
+{
+   

[PATCH V10 8/8] dt-bindings: timer: gx6605s SOC timer

[Guo Ren]

Dt-bindings doc for gx6605s SOC's system timer.

Signed-off-by: Guo Ren 
---
 .../bindings/timer/csky,gx6605s-timer.txt  | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt 
b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
new file mode 100644
index 000..6b04344
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
@@ -0,0 +1,42 @@
+=
+gx6605s SOC Timer
+=
+
+The timer is used in gx6605s soc as system timer and the driver
+contain clk event and clk source.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes gx6605s SOC timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,gx6605s-timer"
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - clocks
+   Usage: required
+   Value type: phandle + clock specifier cells
+   Definition: must be input clk node
+   - interrupt
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer0: timer@20a000 {
+   compatible = "csky,gx6605s-timer";
+   reg = <0x0020a000 0x400>;
+   clocks = <_apb_clk>;
+   interrupts = <10>;
+   interrupt-parent = <>;
+   };
-- 
2.7.4

[PATCH V10 0/8] C-SKY(csky) Linux Kernel Driver

[Guo Ren]

This is about 10th patchset for C-SKY linux drivers. All patches have
been checked by checkpatch.pl.

Any feedback is welcome, thx for all people review my patchset.

If you finish the review for the patchset, please give a Reviewed-By
/ Acked-By and I'll record it in the commit-msg.

Guo Ren (8):
  irqchip: add C-SKY SMP interrupt controller
  dt-bindings: interrupt-controller: C-SKY SMP intc
  irqchip: add C-SKY APB bus interrupt controller
  dt-bindings: interrupt-controller: C-SKY APB intc
  clocksource: add C-SKY SMP timer
  dt-bindings: timer: C-SKY Multi-processor timer
  clocksource: add gx6605s SOC system timer
  dt-bindings: timer: gx6605s SOC timer

 .../interrupt-controller/csky,apb-intc.txt |  62 +
 .../bindings/interrupt-controller/csky,mpintc.txt  |  40 +++
 .../bindings/timer/csky,gx6605s-timer.txt  |  42 
 .../devicetree/bindings/timer/csky,mptimer.txt |  42 
 drivers/clocksource/Kconfig|  18 ++
 drivers/clocksource/Makefile   |   2 +
 drivers/clocksource/timer-gx6605s.c| 154 
 drivers/clocksource/timer-mp-csky.c| 173 +
 drivers/irqchip/Kconfig|  17 ++
 drivers/irqchip/Makefile   |   2 +
 drivers/irqchip/irq-csky-apb-intc.c| 274 +
 drivers/irqchip/irq-csky-mpintc.c  | 197 +++
 include/linux/cpuhotplug.h |   1 +
 13 files changed, 1024 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
 create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt
 create mode 100644 drivers/clocksource/timer-gx6605s.c
 create mode 100644 drivers/clocksource/timer-mp-csky.c
 create mode 100644 drivers/irqchip/irq-csky-apb-intc.c
 create mode 100644 drivers/irqchip/irq-csky-mpintc.c

-- 
2.7.4

[PATCH V10 5/8] clocksource: add C-SKY SMP timer

[Guo Ren]

This timer is used by SMP system and use mfcr/mtcr instruction
to access the regs.

Changelog:
 - Add rollback for timer_of_cleanup.
 - Use request_percpu_irq separate from time_of.
 - Remove #define CPUHP_AP_CSKY_TIMER_STARTING.
 - Add CPUHP_AP_CSKY_TIMER_STARTING in cpuhotplug.h.
 - Support csky mp timer alpha version.
 - Just use low-counter with 32bit width as clocksource.
 - Coding convention with upstream feed-back.

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig |  10 +++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-mp-csky.c | 173 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 185 insertions(+)
 create mode 100644 drivers/clocksource/timer-mp-csky.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a11f4ba..826a2e8 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -620,4 +620,14 @@ config RISCV_TIMER
  is accessed via both the SBI and the rdcycle instruction.  This is
  required for all RISC-V systems.
 
+config CSKY_MP_TIMER
+   bool "SMP Timer for the C-SKY platform"
+   depends on CSKY
+   select TIMER_OF
+   help
+ Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
+ system.
+ csky,mptimer is not only used in SMP system, it also could be used
+ single core system. It's not a mmio reg and it use mtcr/mfcr 
instruction.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index db51b24..5ce82d3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -79,3 +79,4 @@ obj-$(CONFIG_CLKSRC_ST_LPC)   += clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
+obj-$(CONFIG_CSKY_MP_TIMER)+= timer-mp-csky.o
diff --git a/drivers/clocksource/timer-mp-csky.c 
b/drivers/clocksource/timer-mp-csky.c
new file mode 100644
index 000..3e8de73
--- /dev/null
+++ b/drivers/clocksource/timer-mp-csky.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define PTIM_CCVR  "cr<3, 14>"
+#define PTIM_CTLR  "cr<0, 14>"
+#define PTIM_LVR   "cr<6, 14>"
+#define PTIM_TSR   "cr<1, 14>"
+
+static int csky_mptimer_irq;
+
+static int csky_mptimer_set_next_event(unsigned long delta,
+  struct clock_event_device *ce)
+{
+   mtcr(PTIM_LVR, delta);
+
+   return 0;
+}
+
+static int csky_mptimer_shutdown(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 1);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot_stopped(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static DEFINE_PER_CPU(struct timer_of, csky_to) = {
+   .flags  = TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_PERCPU |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = csky_mptimer_shutdown,
+   .set_state_oneshot  = csky_mptimer_oneshot,
+   .set_state_oneshot_stopped  = csky_mptimer_oneshot_stopped,
+   .set_next_event = csky_mptimer_set_next_event,
+   },
+};
+
+static irqreturn_t csky_timer_interrupt(int irq, void *dev)
+{
+   struct timer_of *to = this_cpu_ptr(_to);
+
+   mtcr(PTIM_TSR, 0);
+
+   to->clkevt.event_handler(>clkevt);
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * clock event for percpu
+ */
+static int csky_mptimer_starting_cpu(unsigned int cpu)
+{
+   struct timer_of *to = per_cpu_ptr(_to, cpu);
+
+   to->clkevt.cpumask = cpumask_of(cpu);
+
+   clockevents_config_and_register(>clkevt, timer_of_rate(to),
+   2, ULONG_MAX);
+
+   enable_percpu_irq(csky_mptimer_irq, 0);
+
+   return 0;
+}
+
+static int csky_mptimer_dying_cpu(unsigned int cpu)
+{
+   disable_percpu_irq(csky_mptimer_irq);
+
+   return 0;
+}
+
+/*
+ * clock source
+ */
+static u64 sched_clock_read(void)
+{
+   return (u64)mfcr(PTIM_CCVR);
+}
+
+static u64 clksrc_read(struct clocksource *c)
+{
+   return (u64)mfcr(PTIM_CCVR);
+}
+
+struct clocksource csky_clocksource = {
+   .name   = "csky",
+   .rating = 400,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+   .read   = clksrc_read,
+};
+
+static int __init csky_mptimer_init(struct device_node *np)
+{
+   

[PATCH V10 7/8] clocksource: add gx6605s SOC system timer

[Guo Ren]

Changelog:
 - pass checkpatch.pl
 - Add COMIPLE_TEST in Kconfig
 - no cast is needed for "struct clock_event_device *ce = dev"
 - remove: extra space after (u64)
 - Add License and Copyright
 - Use timer-of framework
 - Change name with upstream feedback
 - Use clksource_mmio framework

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-gx6605s.c | 154 
 3 files changed, 163 insertions(+)
 create mode 100644 drivers/clocksource/timer-gx6605s.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 826a2e8..4dc15d2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -630,4 +630,12 @@ config CSKY_MP_TIMER
  csky,mptimer is not only used in SMP system, it also could be used
  single core system. It's not a mmio reg and it use mtcr/mfcr 
instruction.
 
+config GX6605S_TIMER
+   bool "Gx6605s SOC system timer driver" if COMPILE_TEST
+   depends on CSKY
+   select CLKSRC_MMIO
+   select TIMER_OF
+   help
+ This option enables support for gx6605s SOC's timer.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5ce82d3..9196331 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86_NUMACHIP)+= numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
 obj-$(CONFIG_CSKY_MP_TIMER)+= timer-mp-csky.o
+obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
diff --git a/drivers/clocksource/timer-gx6605s.c 
b/drivers/clocksource/timer-gx6605s.c
new file mode 100644
index 000..80d0939
--- /dev/null
+++ b/drivers/clocksource/timer-gx6605s.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define CLKSRC_OFFSET  0x40
+
+#define TIMER_STATUS   0x00
+#define TIMER_VALUE0x04
+#define TIMER_CONTRL   0x10
+#define TIMER_CONFIG   0x20
+#define TIMER_DIV  0x24
+#define TIMER_INI  0x28
+
+#define GX6605S_STATUS_CLR BIT(0)
+#define GX6605S_CONTRL_RST BIT(0)
+#define GX6605S_CONTRL_START   BIT(1)
+#define GX6605S_CONFIG_EN  BIT(0)
+#define GX6605S_CONFIG_IRQ_EN  BIT(1)
+
+static irqreturn_t gx6605s_timer_interrupt(int irq, void *dev)
+{
+   struct clock_event_device *ce = dev;
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(GX6605S_STATUS_CLR, base + TIMER_STATUS);
+
+   ce->event_handler(ce);
+
+   return IRQ_HANDLED;
+}
+
+static int gx6605s_timer_set_oneshot(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* reset and stop counter */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* enable with irq and start */
+   writel_relaxed(GX6605S_CONFIG_EN | GX6605S_CONFIG_IRQ_EN,
+  base + TIMER_CONFIG);
+
+   return 0;
+}
+
+static int gx6605s_timer_set_next_event(unsigned long delta,
+   struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* use reset to pause timer */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* config next timeout value */
+   writel_relaxed(ULONG_MAX - delta, base + TIMER_INI);
+   writel_relaxed(GX6605S_CONTRL_START, base + TIMER_CONTRL);
+
+   return 0;
+}
+
+static int gx6605s_timer_shutdown(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(0, base + TIMER_CONTRL);
+   writel_relaxed(0, base + TIMER_CONFIG);
+
+   return 0;
+}
+
+static struct timer_of to = {
+   .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_DYNIRQ |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = gx6605s_timer_shutdown,
+   .set_state_oneshot  = gx6605s_timer_set_oneshot,
+   .set_next_event = gx6605s_timer_set_next_event,
+   .cpumask= cpu_possible_mask,
+   },
+   .of_irq = {
+   .handler= gx6605s_timer_interrupt,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
+   },
+};
+
+static u64 notrace gx6605s_sched_clock_read(void)
+{
+   void __iomem *base;
+
+   base = timer_of_base() + CLKSRC_OFFSET;
+
+   return (u64)readl_relaxed(base + TIMER_VALUE);
+}
+
+static void gx6605s_clkevt_init(void __iomem *base)
+{
+   writel_relaxed(0, base + TIMER_DIV);
+   writel_relaxed(0, base + 

[PATCH V10 1/8] irqchip: add C-SKY SMP interrupt controller

[Guo Ren]

 - Irq-csky-mpintc is C-SKY smp system interrupt controller and it
   could support 16 soft irqs, 16 private irqs, and 992 max common
   irqs.

Changelog:
 - pass checkpatch.pl
 - Move IPI_IRQ into the driver
 - Remove irq_set_default_host() and use set_ipi_irq_mapping()
 - Change name with upstream feed-back
 - Change irq map, reserve soft_irq & private_irq space
 - Add License and Copyright
 - Support set_affinity for irq balance in SMP

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig   |   9 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-csky-mpintc.c | 197 ++
 3 files changed, 207 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-mpintc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 383e7b7..8103f6f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,6 +371,15 @@ config QCOM_PDC
  Power Domain Controller driver to manage and configure wakeup
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
+config CSKY_MPINTC
+   bool "C-SKY Multi Processor Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY SMP interrupt controller driver used
+ for C-SKY SMP system.
+ In fact it's not mmio map in hw and it use ld/st to visit the
+ controller's register inside CPU.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index fbd1ec8..6b739ea 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,4 +87,5 @@ obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
 obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-mpintc.c 
b/drivers/irqchip/irq-csky-mpintc.c
new file mode 100644
index 000..a008f8e
--- /dev/null
+++ b/drivers/irqchip/irq-csky-mpintc.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct irq_domain *root_domain;
+static void __iomem *INTCG_base;
+static void __iomem *INTCL_base;
+
+#define IPI_IRQ15
+#define INTC_IRQS  256
+#define COMM_IRQ_BASE  32
+
+#define INTCG_SIZE 0x8000
+#define INTCL_SIZE 0x1000
+
+#define INTCG_ICTLR0x0
+#define INTCG_CICFGR   0x100
+#define INTCG_CIDSTR   0x1000
+
+#define INTCL_PICTLR   0x0
+#define INTCL_SIGR 0x60
+#define INTCL_HPPIR0x68
+#define INTCL_RDYIR0x6c
+#define INTCL_SENR 0xa0
+#define INTCL_CENR 0xa4
+#define INTCL_CACR 0xb4
+
+static DEFINE_PER_CPU(void __iomem *, intcl_reg);
+
+static void csky_mpintc_handler(struct pt_regs *regs)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   do {
+   handle_domain_irq(root_domain,
+ readl_relaxed(reg_base + INTCL_RDYIR),
+ regs);
+   } while (readl_relaxed(reg_base + INTCL_HPPIR) & BIT(31));
+}
+
+static void csky_mpintc_enable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_SENR);
+}
+
+static void csky_mpintc_disable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CENR);
+}
+
+static void csky_mpintc_eoi(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CACR);
+}
+
+#ifdef CONFIG_SMP
+static int csky_irq_set_affinity(struct irq_data *d,
+const struct cpumask *mask_val,
+bool force)
+{
+   unsigned int cpu;
+   unsigned int offset = 4 * (d->hwirq - COMM_IRQ_BASE);
+
+   if (!force)
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   else
+   cpu = cpumask_first(mask_val);
+
+   if (cpu >= nr_cpu_ids)
+   return -EINVAL;
+
+   /* Enable interrupt destination */
+   cpu |= BIT(31);
+
+   writel_relaxed(cpu, INTCG_base + INTCG_CIDSTR + offset);
+
+   irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+   return IRQ_SET_MASK_OK_DONE;
+}
+#endif
+
+static struct irq_chip csky_irq_chip = {
+   .name   = "C-SKY SMP Intc",
+   .irq_eoi= csky_mpintc_eoi,
+   .irq_enable = csky_mpintc_enable,
+   .irq_disable= csky_mpintc_disable,
+#ifdef CONFIG_SMP
+   .irq_set_affinity = csky_irq_set_affinity,
+#endif
+};
+
+static int 

[PATCH V10 1/8] irqchip: add C-SKY SMP interrupt controller

[Guo Ren]

 - Irq-csky-mpintc is C-SKY smp system interrupt controller and it
   could support 16 soft irqs, 16 private irqs, and 992 max common
   irqs.

Changelog:
 - pass checkpatch.pl
 - Move IPI_IRQ into the driver
 - Remove irq_set_default_host() and use set_ipi_irq_mapping()
 - Change name with upstream feed-back
 - Change irq map, reserve soft_irq & private_irq space
 - Add License and Copyright
 - Support set_affinity for irq balance in SMP

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig   |   9 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-csky-mpintc.c | 197 ++
 3 files changed, 207 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-mpintc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 383e7b7..8103f6f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,6 +371,15 @@ config QCOM_PDC
  Power Domain Controller driver to manage and configure wakeup
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
+config CSKY_MPINTC
+   bool "C-SKY Multi Processor Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY SMP interrupt controller driver used
+ for C-SKY SMP system.
+ In fact it's not mmio map in hw and it use ld/st to visit the
+ controller's register inside CPU.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index fbd1ec8..6b739ea 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,4 +87,5 @@ obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
 obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-mpintc.c 
b/drivers/irqchip/irq-csky-mpintc.c
new file mode 100644
index 000..a008f8e
--- /dev/null
+++ b/drivers/irqchip/irq-csky-mpintc.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct irq_domain *root_domain;
+static void __iomem *INTCG_base;
+static void __iomem *INTCL_base;
+
+#define IPI_IRQ15
+#define INTC_IRQS  256
+#define COMM_IRQ_BASE  32
+
+#define INTCG_SIZE 0x8000
+#define INTCL_SIZE 0x1000
+
+#define INTCG_ICTLR0x0
+#define INTCG_CICFGR   0x100
+#define INTCG_CIDSTR   0x1000
+
+#define INTCL_PICTLR   0x0
+#define INTCL_SIGR 0x60
+#define INTCL_HPPIR0x68
+#define INTCL_RDYIR0x6c
+#define INTCL_SENR 0xa0
+#define INTCL_CENR 0xa4
+#define INTCL_CACR 0xb4
+
+static DEFINE_PER_CPU(void __iomem *, intcl_reg);
+
+static void csky_mpintc_handler(struct pt_regs *regs)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   do {
+   handle_domain_irq(root_domain,
+ readl_relaxed(reg_base + INTCL_RDYIR),
+ regs);
+   } while (readl_relaxed(reg_base + INTCL_HPPIR) & BIT(31));
+}
+
+static void csky_mpintc_enable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_SENR);
+}
+
+static void csky_mpintc_disable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CENR);
+}
+
+static void csky_mpintc_eoi(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CACR);
+}
+
+#ifdef CONFIG_SMP
+static int csky_irq_set_affinity(struct irq_data *d,
+const struct cpumask *mask_val,
+bool force)
+{
+   unsigned int cpu;
+   unsigned int offset = 4 * (d->hwirq - COMM_IRQ_BASE);
+
+   if (!force)
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   else
+   cpu = cpumask_first(mask_val);
+
+   if (cpu >= nr_cpu_ids)
+   return -EINVAL;
+
+   /* Enable interrupt destination */
+   cpu |= BIT(31);
+
+   writel_relaxed(cpu, INTCG_base + INTCG_CIDSTR + offset);
+
+   irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+   return IRQ_SET_MASK_OK_DONE;
+}
+#endif
+
+static struct irq_chip csky_irq_chip = {
+   .name   = "C-SKY SMP Intc",
+   .irq_eoi= csky_mpintc_eoi,
+   .irq_enable = csky_mpintc_enable,
+   .irq_disable= csky_mpintc_disable,
+#ifdef CONFIG_SMP
+   .irq_set_affinity = csky_irq_set_affinity,
+#endif
+};
+
+static int 

[PATCH V10 7/8] clocksource: add gx6605s SOC system timer

[Guo Ren]

Changelog:
 - pass checkpatch.pl
 - Add COMIPLE_TEST in Kconfig
 - no cast is needed for "struct clock_event_device *ce = dev"
 - remove: extra space after (u64)
 - Add License and Copyright
 - Use timer-of framework
 - Change name with upstream feedback
 - Use clksource_mmio framework

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-gx6605s.c | 154 
 3 files changed, 163 insertions(+)
 create mode 100644 drivers/clocksource/timer-gx6605s.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 826a2e8..4dc15d2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -630,4 +630,12 @@ config CSKY_MP_TIMER
  csky,mptimer is not only used in SMP system, it also could be used
  single core system. It's not a mmio reg and it use mtcr/mfcr 
instruction.
 
+config GX6605S_TIMER
+   bool "Gx6605s SOC system timer driver" if COMPILE_TEST
+   depends on CSKY
+   select CLKSRC_MMIO
+   select TIMER_OF
+   help
+ This option enables support for gx6605s SOC's timer.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5ce82d3..9196331 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86_NUMACHIP)+= numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
 obj-$(CONFIG_CSKY_MP_TIMER)+= timer-mp-csky.o
+obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
diff --git a/drivers/clocksource/timer-gx6605s.c 
b/drivers/clocksource/timer-gx6605s.c
new file mode 100644
index 000..80d0939
--- /dev/null
+++ b/drivers/clocksource/timer-gx6605s.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define CLKSRC_OFFSET  0x40
+
+#define TIMER_STATUS   0x00
+#define TIMER_VALUE0x04
+#define TIMER_CONTRL   0x10
+#define TIMER_CONFIG   0x20
+#define TIMER_DIV  0x24
+#define TIMER_INI  0x28
+
+#define GX6605S_STATUS_CLR BIT(0)
+#define GX6605S_CONTRL_RST BIT(0)
+#define GX6605S_CONTRL_START   BIT(1)
+#define GX6605S_CONFIG_EN  BIT(0)
+#define GX6605S_CONFIG_IRQ_EN  BIT(1)
+
+static irqreturn_t gx6605s_timer_interrupt(int irq, void *dev)
+{
+   struct clock_event_device *ce = dev;
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(GX6605S_STATUS_CLR, base + TIMER_STATUS);
+
+   ce->event_handler(ce);
+
+   return IRQ_HANDLED;
+}
+
+static int gx6605s_timer_set_oneshot(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* reset and stop counter */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* enable with irq and start */
+   writel_relaxed(GX6605S_CONFIG_EN | GX6605S_CONFIG_IRQ_EN,
+  base + TIMER_CONFIG);
+
+   return 0;
+}
+
+static int gx6605s_timer_set_next_event(unsigned long delta,
+   struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* use reset to pause timer */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* config next timeout value */
+   writel_relaxed(ULONG_MAX - delta, base + TIMER_INI);
+   writel_relaxed(GX6605S_CONTRL_START, base + TIMER_CONTRL);
+
+   return 0;
+}
+
+static int gx6605s_timer_shutdown(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(0, base + TIMER_CONTRL);
+   writel_relaxed(0, base + TIMER_CONFIG);
+
+   return 0;
+}
+
+static struct timer_of to = {
+   .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_DYNIRQ |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = gx6605s_timer_shutdown,
+   .set_state_oneshot  = gx6605s_timer_set_oneshot,
+   .set_next_event = gx6605s_timer_set_next_event,
+   .cpumask= cpu_possible_mask,
+   },
+   .of_irq = {
+   .handler= gx6605s_timer_interrupt,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
+   },
+};
+
+static u64 notrace gx6605s_sched_clock_read(void)
+{
+   void __iomem *base;
+
+   base = timer_of_base() + CLKSRC_OFFSET;
+
+   return (u64)readl_relaxed(base + TIMER_VALUE);
+}
+
+static void gx6605s_clkevt_init(void __iomem *base)
+{
+   writel_relaxed(0, base + TIMER_DIV);
+   writel_relaxed(0, base + 

Re: [PATCH 8/9] ARM: dts: BCM63xx: enable SATA PHY and AHCI controller

[Florian Fainelli]

On 09/20/2018 12:16 PM, Florian Fainelli wrote:
> Add Device Tree entries for the Broadcom AHCI and SATA PHY controller
> found on BCM63138 SoCs
> 
> Signed-off-by: Florian Fainelli 

Applied to devicetree/next.
-- 
Florian

Re: [PATCH 8/9] ARM: dts: BCM63xx: enable SATA PHY and AHCI controller

[Florian Fainelli]

On 09/20/2018 12:16 PM, Florian Fainelli wrote:
> Add Device Tree entries for the Broadcom AHCI and SATA PHY controller
> found on BCM63138 SoCs
> 
> Signed-off-by: Florian Fainelli 

Applied to devicetree/next.
-- 
Florian

[PATCH] SMT: State SMT is disabled even with nosmt and without "=force"

[Borislav Petkov]

From: Borislav Petkov 

When booting with "nosmt=force" a message is issued into dmesg to
confirm that SMT has been force-disabled but such a message is not
issued when only "nosmt" is on the kernel command line.

Fix that.

Signed-off-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: x...@kernel.org
---
 kernel/cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 668c8553e171..3c7f3b4c453c 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -383,6 +383,7 @@ void __init cpu_smt_disable(bool force)
pr_info("SMT: Force disabled\n");
cpu_smt_control = CPU_SMT_FORCE_DISABLED;
} else {
+   pr_info("SMT: disabled\n");
cpu_smt_control = CPU_SMT_DISABLED;
}
 }
-- 
2.19.0.271.gfe8321ec057f

[PATCH] SMT: State SMT is disabled even with nosmt and without "=force"

[Borislav Petkov]

From: Borislav Petkov 

When booting with "nosmt=force" a message is issued into dmesg to
confirm that SMT has been force-disabled but such a message is not
issued when only "nosmt" is on the kernel command line.

Fix that.

Signed-off-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: x...@kernel.org
---
 kernel/cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 668c8553e171..3c7f3b4c453c 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -383,6 +383,7 @@ void __init cpu_smt_disable(bool force)
pr_info("SMT: Force disabled\n");
cpu_smt_control = CPU_SMT_FORCE_DISABLED;
} else {
+   pr_info("SMT: disabled\n");
cpu_smt_control = CPU_SMT_DISABLED;
}
 }
-- 
2.19.0.271.gfe8321ec057f

Re: [PATCH 1/3] namei: implement O_BENEATH-style AT_* flags

[Christian Brauner]

On Tue, Oct 02, 2018 at 02:04:31AM +1000, Aleksa Sarai wrote:
> On 2018-10-01, Christian Brauner  wrote:
> > On Mon, Oct 01, 2018 at 02:28:03PM +0200, Jann Horn wrote:
> > > On Sat, Sep 29, 2018 at 4:28 PM Aleksa Sarai  wrote:
> > > > * AT_BENEATH: Disallow ".." or absolute paths (either in the path or
> > > >   found during symlink resolution) to escape the starting point of name
> > > >   resolution, though ".." is permitted in cases like "foo/../bar".
> > > >   Relative symlinks are still allowed (as long as they don't escape the
> > > >   starting point).
> > > 
> > > As I said on the other thread, I would strongly prefer an API that
> > > behaves along the lines of David Drysdale's old patch
> > > https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysd...@google.com/
> > > : Forbid any use of "..". This would also be more straightforward to
> > > implement safely. If that doesn't work for you, I would like it if you
> > > could at least make that an option. I would like it if this API could
> > > mitigate straightforward directory traversal bugs such as
> > > https://bugs.chromium.org/p/project-zero/issues/detail?id=1583, where
> > > a confused deputy attempts to access a path like
> > > "/mnt/media_rw/../../data" while intending to access a directory under
> > > "/mnt/media_rw".
> > 
> > Oh, the semantics for this changed in this patchset, hah. I was still on
> > vacation so didn't get to look at it before it was sent out. From prior
> > discussion I remember that the original intention actual was what you
> > argue for. And the patchset should be as tight as possible. Having
> > special cases where ".." is allowed just sounds like an invitation for
> > userspace to get it wrong.
> > Aleksa, did you have a specific use-case in mind that made you change
> > this or was it already present in an earlier iteration of the patchset
> > by someone else?
> 
> Al's original patchset allowed "..". A quick survey of my machine shows
> that there are 100k symlinks that contain ".." (~37% of all symlinks on
> my machine). This indicates to me that you would be restricting a large
> amount of reasonable resolutions because of this restriction.
> 
> I posted a proposed way to protect against ".." shenanigans. If it's
> turns out this is not possible, I'm okay with disallowing ".." (assuming
> Al is also okay with that).

Sounds acceptable to me.

Re: [PATCH 1/3] namei: implement O_BENEATH-style AT_* flags

[Christian Brauner]

On Tue, Oct 02, 2018 at 02:04:31AM +1000, Aleksa Sarai wrote:
> On 2018-10-01, Christian Brauner  wrote:
> > On Mon, Oct 01, 2018 at 02:28:03PM +0200, Jann Horn wrote:
> > > On Sat, Sep 29, 2018 at 4:28 PM Aleksa Sarai  wrote:
> > > > * AT_BENEATH: Disallow ".." or absolute paths (either in the path or
> > > >   found during symlink resolution) to escape the starting point of name
> > > >   resolution, though ".." is permitted in cases like "foo/../bar".
> > > >   Relative symlinks are still allowed (as long as they don't escape the
> > > >   starting point).
> > > 
> > > As I said on the other thread, I would strongly prefer an API that
> > > behaves along the lines of David Drysdale's old patch
> > > https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysd...@google.com/
> > > : Forbid any use of "..". This would also be more straightforward to
> > > implement safely. If that doesn't work for you, I would like it if you
> > > could at least make that an option. I would like it if this API could
> > > mitigate straightforward directory traversal bugs such as
> > > https://bugs.chromium.org/p/project-zero/issues/detail?id=1583, where
> > > a confused deputy attempts to access a path like
> > > "/mnt/media_rw/../../data" while intending to access a directory under
> > > "/mnt/media_rw".
> > 
> > Oh, the semantics for this changed in this patchset, hah. I was still on
> > vacation so didn't get to look at it before it was sent out. From prior
> > discussion I remember that the original intention actual was what you
> > argue for. And the patchset should be as tight as possible. Having
> > special cases where ".." is allowed just sounds like an invitation for
> > userspace to get it wrong.
> > Aleksa, did you have a specific use-case in mind that made you change
> > this or was it already present in an earlier iteration of the patchset
> > by someone else?
> 
> Al's original patchset allowed "..". A quick survey of my machine shows
> that there are 100k symlinks that contain ".." (~37% of all symlinks on
> my machine). This indicates to me that you would be restricting a large
> amount of reasonable resolutions because of this restriction.
> 
> I posted a proposed way to protect against ".." shenanigans. If it's
> turns out this is not possible, I'm okay with disallowing ".." (assuming
> Al is also okay with that).

Sounds acceptable to me.

Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

[Lorenzo Pieralisi]

On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:

[...]

> > > I don't see any dependency there, so I'll queue up the 1-3 in
> > > pm-domains and the 4-6 in pm-cpuidle.
> >
> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
> > (DT bindings and related parsing code) with no user in the kernel; we
> > may still want to tweak them, in particular PSCI DT bindings.
> 
> My impression was that 4-6 have been agreed on due to the ACKs they
> carry.  I'll drop them if that's not the case.

I have not expressed myself correctly: they have been agreed (even
though as I said they may require some tweaking) but I see no urgency
of merging them in v4.20 since they have no user. They contain DT
bindings, that create ABI/legacy, I think it is better to have code
that uses them in the kernel before merging them and creating a
dependency that is not needed.

> > Likewise, it makes no sense to merge patches 7-8 without the rest of
> > the PSCI patches.
> 
> OK
> 
> I'll let the ARM camp sort out the PSCI material then.

We will do.

Thanks,
Lorenzo

Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

[Lorenzo Pieralisi]

On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:

[...]

> > > I don't see any dependency there, so I'll queue up the 1-3 in
> > > pm-domains and the 4-6 in pm-cpuidle.
> >
> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
> > (DT bindings and related parsing code) with no user in the kernel; we
> > may still want to tweak them, in particular PSCI DT bindings.
> 
> My impression was that 4-6 have been agreed on due to the ACKs they
> carry.  I'll drop them if that's not the case.

I have not expressed myself correctly: they have been agreed (even
though as I said they may require some tweaking) but I see no urgency
of merging them in v4.20 since they have no user. They contain DT
bindings, that create ABI/legacy, I think it is better to have code
that uses them in the kernel before merging them and creating a
dependency that is not needed.

> > Likewise, it makes no sense to merge patches 7-8 without the rest of
> > the PSCI patches.
> 
> OK
> 
> I'll let the ARM camp sort out the PSCI material then.

We will do.

Thanks,
Lorenzo

Re: [PATCH 3/6] cpuidle: menu: Get rid of first_idx from menu_select()

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 4:51 PM Daniel Lezcano  wrote:
>
> On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> >
> > Rearrange the code in menu_select() so that the loop over idle states
> > always starts from 0 and get rid of the first_idx variable.
> >
> > While at it, add two empty lines to separate conditional statements
> > one another.
> >
> > No intentional behavior changes.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
>
> This code is becoming a bit complex to follow :/
>
> May be I missed something, but it is not possible to enter the condition 
> without
> idx != 0, no ? (I meant the condition if ((drv->states[idx].flags &
> FLAG_POLLING))

Not sure what you mean.

We start with idx = -1, i = 0.  If state[0] is enabled, idx becomes 0.

If the target residency or exit latency of state[0] are already beyond
the limits, we just bail out and state[0] will be returned.

If not, we go to i = 1, but idx is still 0.  If the target residency
of state[1] is beyond predicted_us (which is the interesting case), we
check (drv->states[0].flags & FLAG_POLLING) and so on.

Currently, the polling state must be state[0] (if used at all) anyway.

> Reviewed-by: Daniel Lezcano 
>

Thanks!

Re: [PATCH 3/6] cpuidle: menu: Get rid of first_idx from menu_select()

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 4:51 PM Daniel Lezcano  wrote:
>
> On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> >
> > Rearrange the code in menu_select() so that the loop over idle states
> > always starts from 0 and get rid of the first_idx variable.
> >
> > While at it, add two empty lines to separate conditional statements
> > one another.
> >
> > No intentional behavior changes.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
>
> This code is becoming a bit complex to follow :/
>
> May be I missed something, but it is not possible to enter the condition 
> without
> idx != 0, no ? (I meant the condition if ((drv->states[idx].flags &
> FLAG_POLLING))

Not sure what you mean.

We start with idx = -1, i = 0.  If state[0] is enabled, idx becomes 0.

If the target residency or exit latency of state[0] are already beyond
the limits, we just bail out and state[0] will be returned.

If not, we go to i = 1, but idx is still 0.  If the target residency
of state[1] is beyond predicted_us (which is the interesting case), we
check (drv->states[0].flags & FLAG_POLLING) and so on.

Currently, the polling state must be state[0] (if used at all) anyway.

> Reviewed-by: Daniel Lezcano 
>

Thanks!

[PATCH 1/1] drivers/char/mem.c: Disable encryption bit in page tables for, MMIO access

[James Puthukattukaran]

Attempting to mmap to a memory mapped IO space returns -1s because the
memory encryption bit is set for these pages. According to the AMD spec,
this bit should not be set for non-DRAM space. The patch checks if this
is an memory IO region being accessed and decrypts accordingly.

Signed-off-by: James Puthukattukaran
---
 drivers/char/mem.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index ffeb60d..beaa374 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -355,10 +355,30 @@ static inline int private_mapping_ok(struct 
vm_area_struct *vma)
 #endif
 };
 
+static int check_flags(struct resource *res, void *arg)
+{
+   int *mmio = arg;
+   *mmio = (!((res->flags & IORESOURCE_SYSTEM_RAM) ==
+   IORESOURCE_SYSTEM_RAM) && (res->desc == IORES_DESC_NONE));
+   return *mmio;
+}
+
+static void check_iomem_region(phys_addr_t addr, size_t size,
+   int *mmio)
+{
+   u64 start, end;
+
+   start = (u64)addr;
+   end = start + size - 1;
+   *mmio = 0;
+   walk_mem_res(start, end, mmio, check_flags);
+}
+
 static int mmap_mem(struct file *file, struct vm_area_struct *vma)
 {
size_t size = vma->vm_end - vma->vm_start;
phys_addr_t offset = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
+   int mmio;
 
/* Does it even fit in phys_addr_t? */
if (offset >> PAGE_SHIFT != vma->vm_pgoff)
@@ -387,6 +407,13 @@ static int mmap_mem(struct file *file, struct 
vm_area_struct *vma)
 
vma->vm_ops = _mem_ops;
 
+   if (mem_encrypt_active()) {
+   check_iomem_region(vma->vm_pgoff, size, );
+   if (mmio)
+   vma->vm_page_prot  =
+   pgprot_decrypted(vma->vm_page_prot);
+   }
+
/* Remap-pfn-range will mark the range VM_IO */
if (remap_pfn_range(vma,
vma->vm_start,

[PATCH 1/1] drivers/char/mem.c: Disable encryption bit in page tables for, MMIO access

[James Puthukattukaran]

Attempting to mmap to a memory mapped IO space returns -1s because the
memory encryption bit is set for these pages. According to the AMD spec,
this bit should not be set for non-DRAM space. The patch checks if this
is an memory IO region being accessed and decrypts accordingly.

Signed-off-by: James Puthukattukaran
---
 drivers/char/mem.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index ffeb60d..beaa374 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -355,10 +355,30 @@ static inline int private_mapping_ok(struct 
vm_area_struct *vma)
 #endif
 };
 
+static int check_flags(struct resource *res, void *arg)
+{
+   int *mmio = arg;
+   *mmio = (!((res->flags & IORESOURCE_SYSTEM_RAM) ==
+   IORESOURCE_SYSTEM_RAM) && (res->desc == IORES_DESC_NONE));
+   return *mmio;
+}
+
+static void check_iomem_region(phys_addr_t addr, size_t size,
+   int *mmio)
+{
+   u64 start, end;
+
+   start = (u64)addr;
+   end = start + size - 1;
+   *mmio = 0;
+   walk_mem_res(start, end, mmio, check_flags);
+}
+
 static int mmap_mem(struct file *file, struct vm_area_struct *vma)
 {
size_t size = vma->vm_end - vma->vm_start;
phys_addr_t offset = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
+   int mmio;
 
/* Does it even fit in phys_addr_t? */
if (offset >> PAGE_SHIFT != vma->vm_pgoff)
@@ -387,6 +407,13 @@ static int mmap_mem(struct file *file, struct 
vm_area_struct *vma)
 
vma->vm_ops = _mem_ops;
 
+   if (mem_encrypt_active()) {
+   check_iomem_region(vma->vm_pgoff, size, );
+   if (mmio)
+   vma->vm_page_prot  =
+   pgprot_decrypted(vma->vm_page_prot);
+   }
+
/* Remap-pfn-range will mark the range VM_IO */
if (remap_pfn_range(vma,
vma->vm_start,

[PATCH 0/1] drivers/char/mem.c: Disable encryption bit in page tables for MMIO access

[James Puthukattukaran]

On AMD based systems, mmap'ing a PCI MMIO region does not return proper
values. This is because the mmap_mem function does not consider the fact
that IO regions are not to be encrypted. 

In the failing kernel, here's the output  --

[root@foo]# ./memaccess 0xd000 -t pmem -l 32
0(0   ) : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
10   (16  ) : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 


I instrumented the kernel to print out the PTE value --

Jun 20 11:46:35 bur-e1-2l-303 kernel: pfn = 0xfff80f0866b2, vma->pgoff = 0xd
, flags = 0x5044471,  prot = 0x80008025
Jun 20 11:46:35 bur-e1-2l-303 kernel: pte = 0x80008000d235, pfn  = 0xd

Note that 0x80008025 -- bit 47 is set. It should not be set for a 
MMIO region. 

When I disable memory encryption (mem_encrypt=off command line), things work
as they should.



[root@foo]# ./memaccess 0xd000 -t pmem -l 32
0(0   ) : 20 00 00 01 40 08 00 04 f1 00 00 14 0a 00 ff 07 
10   (16  ) : 65 f6 70 02 c0 05 00 00 a0 04 00 00 0b 00 00 00 



James Puthukattukaran(1):
  drivers/char/mem.c: Disable encryption bit in page tables for MMIO
access

 drivers/char/mem.c | 27 +++
 1 file changed, 27 insertions(+)

[PATCH 0/1] drivers/char/mem.c: Disable encryption bit in page tables for MMIO access

[James Puthukattukaran]

On AMD based systems, mmap'ing a PCI MMIO region does not return proper
values. This is because the mmap_mem function does not consider the fact
that IO regions are not to be encrypted. 

In the failing kernel, here's the output  --

[root@foo]# ./memaccess 0xd000 -t pmem -l 32
0(0   ) : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
10   (16  ) : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 


I instrumented the kernel to print out the PTE value --

Jun 20 11:46:35 bur-e1-2l-303 kernel: pfn = 0xfff80f0866b2, vma->pgoff = 0xd
, flags = 0x5044471,  prot = 0x80008025
Jun 20 11:46:35 bur-e1-2l-303 kernel: pte = 0x80008000d235, pfn  = 0xd

Note that 0x80008025 -- bit 47 is set. It should not be set for a 
MMIO region. 

When I disable memory encryption (mem_encrypt=off command line), things work
as they should.



[root@foo]# ./memaccess 0xd000 -t pmem -l 32
0(0   ) : 20 00 00 01 40 08 00 04 f1 00 00 14 0a 00 ff 07 
10   (16  ) : 65 f6 70 02 c0 05 00 00 a0 04 00 00 0b 00 00 00 



James Puthukattukaran(1):
  drivers/char/mem.c: Disable encryption bit in page tables for MMIO
access

 drivers/char/mem.c | 27 +++
 1 file changed, 27 insertions(+)

Re: [PATCH v2 RESEND] trace_uprobe: support reference counter in fd-based uprobe

[Song Liu]

> On Oct 2, 2018, at 1:12 AM, Peter Zijlstra  wrote:
> 
> On Mon, Oct 01, 2018 at 10:36:36PM -0700, Song Liu wrote:
>> Changes v1 -> v2: Fix PMU_FORMAT_ATTR as Peter suggested
>> 
>> This patch enables uprobes with reference counter in fd-based uprobe.
>> Highest 32 bits of perf_event_attr.config is used to stored offset
>> of the reference count (semaphore).
>> 
>> Format information in /sys/bus/event_source/devices/uprobe/format/ is
>> updated to reflect this new feature.
>> 
>> Signed-off-by: Song Liu 
>> Reviewed-and-tested-by: Ravi Bangoria 
>> Cc: Oleg Nesterov 
>> Cc: Steven Rostedt (VMware) 
>> Cc: Peter Zijlstra 
> 
> Works for me,
> 
> Acked-by: Peter Zijlstra (Intel) 

Thanks Peter!

Steven, could you please test/apply this? 

Best,
Song

Re: [PATCH v2 RESEND] trace_uprobe: support reference counter in fd-based uprobe

[Song Liu]

> On Oct 2, 2018, at 1:12 AM, Peter Zijlstra  wrote:
> 
> On Mon, Oct 01, 2018 at 10:36:36PM -0700, Song Liu wrote:
>> Changes v1 -> v2: Fix PMU_FORMAT_ATTR as Peter suggested
>> 
>> This patch enables uprobes with reference counter in fd-based uprobe.
>> Highest 32 bits of perf_event_attr.config is used to stored offset
>> of the reference count (semaphore).
>> 
>> Format information in /sys/bus/event_source/devices/uprobe/format/ is
>> updated to reflect this new feature.
>> 
>> Signed-off-by: Song Liu 
>> Reviewed-and-tested-by: Ravi Bangoria 
>> Cc: Oleg Nesterov 
>> Cc: Steven Rostedt (VMware) 
>> Cc: Peter Zijlstra 
> 
> Works for me,
> 
> Acked-by: Peter Zijlstra (Intel) 

Thanks Peter!

Steven, could you please test/apply this? 

Best,
Song

Re: [PATCH 2/2] cpuidle/drivers/menu: Remove get_loadavg in the performance multiplier

[Joe Perches]

On Thu, 2018-10-04 at 10:40 +0200, Daniel Lezcano wrote:
> On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano  
> > wrote:
> > > The function get_loadavg() returns almost always zero. To be more
> > > precise, statistically speaking for a total of 1023379 times passing
> > > in the function, the load is equal to zero 1020728 times, greater than
> > > 100, 610 times, the remaining is between 0 and 5.
[]
> > > diff --git a/drivers/cpuidle/governors/menu.c 
> > > b/drivers/cpuidle/governors/menu.c
[]
> > > @@ -359,7 +346,8 @@ static int menu_select(struct cpuidle_driver *drv, 
> > > struct cpuidle_device *dev,
> > >  * Use the performance multiplier and the 
> > > user-configurable
> > >  * latency_req to determine the maximum exit latency.
> > >  */
> > > -   interactivity_req = data->predicted_us / 
> > > performance_multiplier(nr_iowaiters, cpu_load);
> > > +   interactivity_req = data->predicted_us /
> > > +   performance_multiplier(nr_iowaiters);
> > 
> > I wouldn't break this line.
> 
> Ok, mind if I break the line in a separate patch before ? (my git
> pre-commit hook runs checkpatch and it complains and prevent to commit
> the patch because of the line length (94)).

A lot of this file uses > 80 column lines.
As well, the identifiers here are relatively long.

Long identifier lengths and 80 column lines are generally
incompatible.

I suggest you change your script to allow > 80 column lines
using the checkpatch command-line option --ignore==long_line
or perhaps add --max-line-length= or at
least allow some other senstible interactivity when the silly
script bleats some mindless warning or another.

Re: [PATCH 2/2] cpuidle/drivers/menu: Remove get_loadavg in the performance multiplier

[Joe Perches]

On Thu, 2018-10-04 at 10:40 +0200, Daniel Lezcano wrote:
> On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano  
> > wrote:
> > > The function get_loadavg() returns almost always zero. To be more
> > > precise, statistically speaking for a total of 1023379 times passing
> > > in the function, the load is equal to zero 1020728 times, greater than
> > > 100, 610 times, the remaining is between 0 and 5.
[]
> > > diff --git a/drivers/cpuidle/governors/menu.c 
> > > b/drivers/cpuidle/governors/menu.c
[]
> > > @@ -359,7 +346,8 @@ static int menu_select(struct cpuidle_driver *drv, 
> > > struct cpuidle_device *dev,
> > >  * Use the performance multiplier and the 
> > > user-configurable
> > >  * latency_req to determine the maximum exit latency.
> > >  */
> > > -   interactivity_req = data->predicted_us / 
> > > performance_multiplier(nr_iowaiters, cpu_load);
> > > +   interactivity_req = data->predicted_us /
> > > +   performance_multiplier(nr_iowaiters);
> > 
> > I wouldn't break this line.
> 
> Ok, mind if I break the line in a separate patch before ? (my git
> pre-commit hook runs checkpatch and it complains and prevent to commit
> the patch because of the line length (94)).

A lot of this file uses > 80 column lines.
As well, the identifiers here are relatively long.

Long identifier lengths and 80 column lines are generally
incompatible.

I suggest you change your script to allow > 80 column lines
using the checkpatch command-line option --ignore==long_line
or perhaps add --max-line-length= or at
least allow some other senstible interactivity when the silly
script bleats some mindless warning or another.

Re: [PATCH v2 1/3] mm: Shuffle initial free memory

[Dan Williams]

On Thu, Oct 4, 2018 at 12:48 AM Michal Hocko  wrote:
>
> On Wed 03-10-18 19:15:24, Dan Williams wrote:
> > Some data exfiltration and return-oriented-programming attacks rely on
> > the ability to infer the location of sensitive data objects. The kernel
> > page allocator, especially early in system boot, has predictable
> > first-in-first out behavior for physical pages. Pages are freed in
> > physical address order when first onlined.
> >
> > Introduce shuffle_free_memory(), and its helper shuffle_zone(), to
> > perform a Fisher-Yates shuffle of the page allocator 'free_area' lists
> > when they are initially populated with free memory at boot and at
> > hotplug time.
> >
> > Quoting Kees:
> > "While we already have a base-address randomization
> >  (CONFIG_RANDOMIZE_MEMORY), attacks against the same hardware and
> >  memory layouts would certainly be using the predictability of
> >  allocation ordering (i.e. for attacks where the base address isn't
> >  important: only the relative positions between allocated memory).
> >  This is common in lots of heap-style attacks. They try to gain
> >  control over ordering by spraying allocations, etc.
> >
> >  I'd really like to see this because it gives us something similar
> >  to CONFIG_SLAB_FREELIST_RANDOM but for the page allocator."
> >
> > Another motivation for this change is performance in the presence of a
> > memory-side cache. In the future, memory-side-cache technology will be
> > available on generally available server platforms. The proposed
> > randomization approach has been measured to improve the cache conflict
> > rate by a factor of 2.5X on a well-known Java benchmark. It avoids
> > performance peaks and valleys to provide more predictable performance.
> >
> > While SLAB_FREELIST_RANDOM reduces the predictability of some local slab
> > caches it leaves vast bulk of memory to be predictably in order
> > allocated. That ordering can be detected by a memory side-cache.
> >
> > The shuffling is done in terms of 'shuffle_page_order' sized free pages
> > where the default shuffle_page_order is MAX_ORDER-1 i.e. 10, 4MB this
> > trades off randomization granularity for time spent shuffling.
> > MAX_ORDER-1 was chosen to be minimally invasive to the page allocator
> > while still showing memory-side cache behavior improvements.
> >
> > The performance impact of the shuffling appears to be in the noise
> > compared to other memory initialization work. Also the bulk of the work
> > is done in the background as a part of deferred_init_memmap().
>
> This is the biggest portion of the series and I am wondering why do we
> need it at all. Why it isn't sufficient to rely on the patch 3 here?

In fact we started with only patch3 and it had no measurable impact on
the cache conflict rate.

> Pages freed from the bootmem allocator go via the same path so they
> might be shuffled at that time. Or is there any problem with that?
> Not enough entropy at the time when this is called or the final result
> is not randomized enough (some numbers would be helpful).

So the reason front-back randomization is not enough is due to the
in-order initial freeing of pages. At the start of that process
putting page1 in front or behind page0 still keeps them close
together, page2 is still near page1 and has a high chance of being
adjacent. As more pages are added ordering diversity improves, but
there is still high page locality for the low address pages and this
leads to no significant impact to the cache conflict rate. Patch3 is
enough to keep the entropy sustained over time, but it's not enough
initially.

Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

[Alexey Budankov]

Hi,

On 03.10.2018 20:01, Jann Horn wrote:
> On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
>  wrote:

>> 3. Every time an event for ${PMU} is created over perf_event_open():
>>a) the calling thread's euid is checked to belong to ${PMU}_users group
>>   and if it does then the event's fd is allocated;
>>b) then traditional checks against perf_event_pranoid content are applied;
>>c) if the file doesn't exist the access is governed by global setting
>>   at /proc/sys/kernel/perf_even_paranoid;
> 
> You'll also have to make sure that this thing in kernel/events/core.c
> doesn't have any bad effect:
> 
> /*
> * Special case software events and allow them to be part of
> * any hardware group.
> */
> 
> As in, make sure that you can't smuggle in arbitrary software events
> by attaching them to a whitelisted hardware event.

Yes, makes sense. Please see and comment below.

> 

>> Security analysis for uncore IMC, QPI/UPI, PCIe PMUs is still required
>> to be enabled for fine grain control.
> 
> And you can't whitelist anything that permits using sampling events
> with arbitrary sample_type.
> 

It appears that there is a dependency on the significance of data that PMUs 
captures 
for later analysis. Currently there are following options for data being 
captured 
(please correct or extend if something is missing from the list below):

1) Monitored process details:
   - system information on a process as a container (of threads, memory data 
and 
 IDs (e.g. open fds) from process specific namespaces and etc.);
   - system information on threads as containers (of execution context details);
2) Execution context details:
   - memory addresses;
   - memory data;
   - calculation results;
   - calculation state in HW;
3) Monitored process and execution context telemetry data, used for building 
   various performance metrics and can come from:
   - user mode code and OS kernel;
   - various parts of HW e.g. core, uncore, peripheral and etc.

Group 2) is the potential leakage source of sensitive process data so if a PMU, 
at some mode, samples execution context details then the PMU, working in that 
mode, 
is the subject for *access* and *scope* control.

On the other hand if captured data contain only the monitored process details 
and/or associated execution telemetry, there is probably no sensitive data 
leakage 
thru that captured data.

For example, if cpu PMU samples PC addresses overtime, e.g. for providing 
hotspots-by-function profile, then this requires to be controlled as from 
access as 
from scope perspective, because PC addresses is execution context details that 
can contain sensitive data.

However, if cpu PMU does counting of some metric value, or if software PMU 
reads 
value of thread active time from the OS, possibly overtime, for later building 
some 
rating profile, or reading of some HW counter value without attribution to any 
execution context details, that is probably not that risky as in the case of 
PC address sampling.

Uncore PMUs e.g. memory controller (IMC), interconnect (QPI/UPI) and peripheral 
(PCIe) 
currently only read counters values that are captured system wide by HW, and 
provide 
no attribution to any specific execution context details, thus, sensitive 
process data.

Based on that,

A) paranoid knob is required for a PMU if it can capture data from group 2)
B) paranoid knob limits scope of capturing sensitive data:
   -3 - *scope* is defined by some high level setting
   -2 - disabled - no allowed *scope*
   -1 - no restrictions - max *scope*
0 - system wide
1 - process user and kernel space
2 - process user space only
C) paranoid knob has to be checked every time the PMU is going to start 
   capturing sensitive data to avoid capturing beyond the allowed scope.

PMU *access* semantics is derived from fs ACLs and could look like this:

r - read PMU architectural and configuration details, read PMU *access* settings
w - modify PMU *access* settings
x - modify PMU configuration and collect data

So levels of *access* to PMU could look like this:

root=rwx, ${PMU}_users=r-x, other=r--.

Possible examples of *scope* control settings could look like this:

1) system wide user+kernel mode CPU sampling with context switches 
   and uncore counting:

/proc/sys/kernel/perf_event_paranoid (-2, 2): 0
SW.paranoid  (-3, 2):(root=rwx, SW_users=r-x,other=r--): -3
CPU.paranoid (-3, 2):(root=rwx,CPU_users=r-x,other=r--): -3
IMC.paranoid (-3,-1):(root=rwx,IMC_users=r-x,other=r--): -3
UPI.paranoid (-3,-1):(root=rwx,UPI_users=r-x,other=r--): -3
PCI.paranoid (-3,-1):(root=rwx,PCI_users=r-x,other=r--): -3

2) per-process CPU sampling with context switches and uncore counting:

/proc/sys/kernel/perf_event_paranoid (-2, 2): 1|2
SW.paranoid  (-3, 2):(root=rwx, SW_users=r-x,other=r--): -3
CPU.paranoid (-3, 2):(root=rwx,CPU_users=r-x,other=r--): -3
IMC.paranoid 

Re: [PATCH v2 1/3] mm: Shuffle initial free memory

[Dan Williams]

On Thu, Oct 4, 2018 at 12:48 AM Michal Hocko  wrote:
>
> On Wed 03-10-18 19:15:24, Dan Williams wrote:
> > Some data exfiltration and return-oriented-programming attacks rely on
> > the ability to infer the location of sensitive data objects. The kernel
> > page allocator, especially early in system boot, has predictable
> > first-in-first out behavior for physical pages. Pages are freed in
> > physical address order when first onlined.
> >
> > Introduce shuffle_free_memory(), and its helper shuffle_zone(), to
> > perform a Fisher-Yates shuffle of the page allocator 'free_area' lists
> > when they are initially populated with free memory at boot and at
> > hotplug time.
> >
> > Quoting Kees:
> > "While we already have a base-address randomization
> >  (CONFIG_RANDOMIZE_MEMORY), attacks against the same hardware and
> >  memory layouts would certainly be using the predictability of
> >  allocation ordering (i.e. for attacks where the base address isn't
> >  important: only the relative positions between allocated memory).
> >  This is common in lots of heap-style attacks. They try to gain
> >  control over ordering by spraying allocations, etc.
> >
> >  I'd really like to see this because it gives us something similar
> >  to CONFIG_SLAB_FREELIST_RANDOM but for the page allocator."
> >
> > Another motivation for this change is performance in the presence of a
> > memory-side cache. In the future, memory-side-cache technology will be
> > available on generally available server platforms. The proposed
> > randomization approach has been measured to improve the cache conflict
> > rate by a factor of 2.5X on a well-known Java benchmark. It avoids
> > performance peaks and valleys to provide more predictable performance.
> >
> > While SLAB_FREELIST_RANDOM reduces the predictability of some local slab
> > caches it leaves vast bulk of memory to be predictably in order
> > allocated. That ordering can be detected by a memory side-cache.
> >
> > The shuffling is done in terms of 'shuffle_page_order' sized free pages
> > where the default shuffle_page_order is MAX_ORDER-1 i.e. 10, 4MB this
> > trades off randomization granularity for time spent shuffling.
> > MAX_ORDER-1 was chosen to be minimally invasive to the page allocator
> > while still showing memory-side cache behavior improvements.
> >
> > The performance impact of the shuffling appears to be in the noise
> > compared to other memory initialization work. Also the bulk of the work
> > is done in the background as a part of deferred_init_memmap().
>
> This is the biggest portion of the series and I am wondering why do we
> need it at all. Why it isn't sufficient to rely on the patch 3 here?

In fact we started with only patch3 and it had no measurable impact on
the cache conflict rate.

> Pages freed from the bootmem allocator go via the same path so they
> might be shuffled at that time. Or is there any problem with that?
> Not enough entropy at the time when this is called or the final result
> is not randomized enough (some numbers would be helpful).

So the reason front-back randomization is not enough is due to the
in-order initial freeing of pages. At the start of that process
putting page1 in front or behind page0 still keeps them close
together, page2 is still near page1 and has a high chance of being
adjacent. As more pages are added ordering diversity improves, but
there is still high page locality for the low address pages and this
leads to no significant impact to the cache conflict rate. Patch3 is
enough to keep the entropy sustained over time, but it's not enough
initially.

Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

[Alexey Budankov]

Hi,

On 03.10.2018 20:01, Jann Horn wrote:
> On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
>  wrote:

>> 3. Every time an event for ${PMU} is created over perf_event_open():
>>a) the calling thread's euid is checked to belong to ${PMU}_users group
>>   and if it does then the event's fd is allocated;
>>b) then traditional checks against perf_event_pranoid content are applied;
>>c) if the file doesn't exist the access is governed by global setting
>>   at /proc/sys/kernel/perf_even_paranoid;
> 
> You'll also have to make sure that this thing in kernel/events/core.c
> doesn't have any bad effect:
> 
> /*
> * Special case software events and allow them to be part of
> * any hardware group.
> */
> 
> As in, make sure that you can't smuggle in arbitrary software events
> by attaching them to a whitelisted hardware event.

Yes, makes sense. Please see and comment below.

> 

>> Security analysis for uncore IMC, QPI/UPI, PCIe PMUs is still required
>> to be enabled for fine grain control.
> 
> And you can't whitelist anything that permits using sampling events
> with arbitrary sample_type.
> 

It appears that there is a dependency on the significance of data that PMUs 
captures 
for later analysis. Currently there are following options for data being 
captured 
(please correct or extend if something is missing from the list below):

1) Monitored process details:
   - system information on a process as a container (of threads, memory data 
and 
 IDs (e.g. open fds) from process specific namespaces and etc.);
   - system information on threads as containers (of execution context details);
2) Execution context details:
   - memory addresses;
   - memory data;
   - calculation results;
   - calculation state in HW;
3) Monitored process and execution context telemetry data, used for building 
   various performance metrics and can come from:
   - user mode code and OS kernel;
   - various parts of HW e.g. core, uncore, peripheral and etc.

Group 2) is the potential leakage source of sensitive process data so if a PMU, 
at some mode, samples execution context details then the PMU, working in that 
mode, 
is the subject for *access* and *scope* control.

On the other hand if captured data contain only the monitored process details 
and/or associated execution telemetry, there is probably no sensitive data 
leakage 
thru that captured data.

For example, if cpu PMU samples PC addresses overtime, e.g. for providing 
hotspots-by-function profile, then this requires to be controlled as from 
access as 
from scope perspective, because PC addresses is execution context details that 
can contain sensitive data.

However, if cpu PMU does counting of some metric value, or if software PMU 
reads 
value of thread active time from the OS, possibly overtime, for later building 
some 
rating profile, or reading of some HW counter value without attribution to any 
execution context details, that is probably not that risky as in the case of 
PC address sampling.

Uncore PMUs e.g. memory controller (IMC), interconnect (QPI/UPI) and peripheral 
(PCIe) 
currently only read counters values that are captured system wide by HW, and 
provide 
no attribution to any specific execution context details, thus, sensitive 
process data.

Based on that,

A) paranoid knob is required for a PMU if it can capture data from group 2)
B) paranoid knob limits scope of capturing sensitive data:
   -3 - *scope* is defined by some high level setting
   -2 - disabled - no allowed *scope*
   -1 - no restrictions - max *scope*
0 - system wide
1 - process user and kernel space
2 - process user space only
C) paranoid knob has to be checked every time the PMU is going to start 
   capturing sensitive data to avoid capturing beyond the allowed scope.

PMU *access* semantics is derived from fs ACLs and could look like this:

r - read PMU architectural and configuration details, read PMU *access* settings
w - modify PMU *access* settings
x - modify PMU configuration and collect data

So levels of *access* to PMU could look like this:

root=rwx, ${PMU}_users=r-x, other=r--.

Possible examples of *scope* control settings could look like this:

1) system wide user+kernel mode CPU sampling with context switches 
   and uncore counting:

/proc/sys/kernel/perf_event_paranoid (-2, 2): 0
SW.paranoid  (-3, 2):(root=rwx, SW_users=r-x,other=r--): -3
CPU.paranoid (-3, 2):(root=rwx,CPU_users=r-x,other=r--): -3
IMC.paranoid (-3,-1):(root=rwx,IMC_users=r-x,other=r--): -3
UPI.paranoid (-3,-1):(root=rwx,UPI_users=r-x,other=r--): -3
PCI.paranoid (-3,-1):(root=rwx,PCI_users=r-x,other=r--): -3

2) per-process CPU sampling with context switches and uncore counting:

/proc/sys/kernel/perf_event_paranoid (-2, 2): 1|2
SW.paranoid  (-3, 2):(root=rwx, SW_users=r-x,other=r--): -3
CPU.paranoid (-3, 2):(root=rwx,CPU_users=r-x,other=r--): -3
IMC.paranoid 

Re: linux-next: build failure after merge of the tty tree

[Steve Sakoman]

On Thu, Oct 4, 2018 at 7:00 AM Greg Kroah-Hartman  wrote:

> We should just get rid of the "unused" fields entirely.  They aren't
> needed here as this is not a structure that anyone really cares about.
> We can move things around a bit if the padding is an issue.
>
> I've reverted this patch first for now.  I suggest a patch to the uart
> core to drop the unused fields and fix up the samsung driver and then
> your patch can go on top of that.  Can you work on this?

Yes I can. Stay tuned . . .

Steve

Re: linux-next: build failure after merge of the tty tree

[Steve Sakoman]

On Thu, Oct 4, 2018 at 7:00 AM Greg Kroah-Hartman  wrote:

> We should just get rid of the "unused" fields entirely.  They aren't
> needed here as this is not a structure that anyone really cares about.
> We can move things around a bit if the padding is an issue.
>
> I've reverted this patch first for now.  I suggest a patch to the uart
> core to drop the unused fields and fix up the samsung driver and then
> your patch can go on top of that.  Can you work on this?

Yes I can. Stay tuned . . .

Steve

Re: [PATCH 5/6] cpuidle: menu: Avoid computations for very close timers

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 5:50 PM Daniel Lezcano  wrote:
>
> On Tue, Oct 02, 2018 at 11:46:28PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> >
> > If the next timer event (with the tick excluded) is closer than the
> > target residency of the second state or the PM QoS latency constraint
> > is below its exit latency, state[0] will be used regardless of any
> > other factors, so skip the computations in menu_select() then and
> > return 0 straight away from it.
> >
> > Still, do that after the bucket has been determined to avoid
> > disturbing the wakeup statistics in general.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/cpuidle/governors/menu.c |   12 
> >  1 file changed, 12 insertions(+)
> >
> > Index: linux-pm/drivers/cpuidle/governors/menu.c
> > ===
> > --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> > +++ linux-pm/drivers/cpuidle/governors/menu.c
> > @@ -309,6 +309,18 @@ static int menu_select(struct cpuidle_dr
> >   get_iowait_load(_iowaiters, _load);
> >   data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
> >
> > + if (unlikely(drv->state_count <= 1) ||
>
> I'm not sure this test is necessary.

Yes, it is IMO.

Strictly speaking it prevents state[1] from being accessed if the
count is not 2 at least.

> If state_count == 0, we don't have to select anything as the cpuidle can't 
> register because of:
>
> static int __cpuidle_register_driver(struct cpuidle_driver *drv)
> {
> int ret;
>
> if (!drv || !drv->state_count)
> return -EINVAL;
>
> [ ... ]
> }
>
> If state_count == 1, then there is nothing to select, it is always the state 
> 0.

Which is why it is better to simply return 0 right away in this case. :-)

I guess I could compare state_count just to 1, but <= 1 works too.

Re: [PATCH 5/6] cpuidle: menu: Avoid computations for very close timers

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 5:50 PM Daniel Lezcano  wrote:
>
> On Tue, Oct 02, 2018 at 11:46:28PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> >
> > If the next timer event (with the tick excluded) is closer than the
> > target residency of the second state or the PM QoS latency constraint
> > is below its exit latency, state[0] will be used regardless of any
> > other factors, so skip the computations in menu_select() then and
> > return 0 straight away from it.
> >
> > Still, do that after the bucket has been determined to avoid
> > disturbing the wakeup statistics in general.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/cpuidle/governors/menu.c |   12 
> >  1 file changed, 12 insertions(+)
> >
> > Index: linux-pm/drivers/cpuidle/governors/menu.c
> > ===
> > --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> > +++ linux-pm/drivers/cpuidle/governors/menu.c
> > @@ -309,6 +309,18 @@ static int menu_select(struct cpuidle_dr
> >   get_iowait_load(_iowaiters, _load);
> >   data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
> >
> > + if (unlikely(drv->state_count <= 1) ||
>
> I'm not sure this test is necessary.

Yes, it is IMO.

Strictly speaking it prevents state[1] from being accessed if the
count is not 2 at least.

> If state_count == 0, we don't have to select anything as the cpuidle can't 
> register because of:
>
> static int __cpuidle_register_driver(struct cpuidle_driver *drv)
> {
> int ret;
>
> if (!drv || !drv->state_count)
> return -EINVAL;
>
> [ ... ]
> }
>
> If state_count == 1, then there is nothing to select, it is always the state 
> 0.

Which is why it is better to simply return 0 right away in this case. :-)

I guess I could compare state_count just to 1, but <= 1 works too.

Re: [PATCH v2 1/4] reset: imx7: Add PCIE_CTRL_APPS_TURNOFF

[Lorenzo Pieralisi]

On Thu, Oct 04, 2018 at 06:47:01PM +0200, Philipp Zabel wrote:
> Hi Leonard,
> 
> On Thu, 2018-10-04 at 16:34 +, Leonard Crestez wrote:
> > This is required for the imx pci driver to send the PME_Turn_Off TLP.
> > 
> > Signed-off-by: Leonard Crestez 
> > Acked-by: Rob Herring 
> > ---
> >  drivers/reset/reset-imx7.c | 1 +
> >  include/dt-bindings/reset/imx7-reset.h | 4 +++-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> > index 97d9f08271c5..77911fa8f31d 100644
> > --- a/drivers/reset/reset-imx7.c
> > +++ b/drivers/reset/reset-imx7.c
> > @@ -65,10 +65,11 @@ static const struct imx7_src_signal 
> > imx7_src_signals[IMX7_RESET_NUM] = {
> > [IMX7_RESET_MIPI_PHY_MRST]  = { SRC_MIPIPHY_RCR, BIT(1) },
> > [IMX7_RESET_MIPI_PHY_SRST]  = { SRC_MIPIPHY_RCR, BIT(2) },
> > [IMX7_RESET_PCIEPHY]= { SRC_PCIEPHY_RCR, BIT(2) | BIT(1) },
> > [IMX7_RESET_PCIEPHY_PERST]  = { SRC_PCIEPHY_RCR, BIT(3) },
> > [IMX7_RESET_PCIE_CTRL_APPS_EN]  = { SRC_PCIEPHY_RCR, BIT(6) },
> > +   [IMX7_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) },
> > [IMX7_RESET_DDRC_PRST]  = { SRC_DDRC_RCR, BIT(0) },
> > [IMX7_RESET_DDRC_CORE_RST]  = { SRC_DDRC_RCR, BIT(1) },
> >  };
> >  
> >  static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
> > diff --git a/include/dt-bindings/reset/imx7-reset.h 
> > b/include/dt-bindings/reset/imx7-reset.h
> > index 63948170c7b2..31b3f87dde9a 100644
> > --- a/include/dt-bindings/reset/imx7-reset.h
> > +++ b/include/dt-bindings/reset/imx7-reset.h
> > @@ -54,9 +54,11 @@
> >   */
> >  #define IMX7_RESET_PCIE_CTRL_APPS_EN   22
> >  #define IMX7_RESET_DDRC_PRST   23
> >  #define IMX7_RESET_DDRC_CORE_RST   24
> >  
> > -#define IMX7_RESET_NUM 25
> > +#define IMX7_RESET_PCIE_CTRL_APPS_TURNOFF 25
> > +
> > +#define IMX7_RESET_NUM 26
> >  
> >  #endif
> 
> This is contained enough to be merged with the rest of the series,
> patches 1 and 2:
> 
> Acked-by: Philipp Zabel 
> 
> Let me know if I should pick them up instead.

I can take the whole series but I would like to have it rebased against
v4.19-rc4 please since it does not apply as it is, thanks.

Lorenzo

Re: [PATCH v2 1/4] reset: imx7: Add PCIE_CTRL_APPS_TURNOFF

[Lorenzo Pieralisi]

On Thu, Oct 04, 2018 at 06:47:01PM +0200, Philipp Zabel wrote:
> Hi Leonard,
> 
> On Thu, 2018-10-04 at 16:34 +, Leonard Crestez wrote:
> > This is required for the imx pci driver to send the PME_Turn_Off TLP.
> > 
> > Signed-off-by: Leonard Crestez 
> > Acked-by: Rob Herring 
> > ---
> >  drivers/reset/reset-imx7.c | 1 +
> >  include/dt-bindings/reset/imx7-reset.h | 4 +++-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> > index 97d9f08271c5..77911fa8f31d 100644
> > --- a/drivers/reset/reset-imx7.c
> > +++ b/drivers/reset/reset-imx7.c
> > @@ -65,10 +65,11 @@ static const struct imx7_src_signal 
> > imx7_src_signals[IMX7_RESET_NUM] = {
> > [IMX7_RESET_MIPI_PHY_MRST]  = { SRC_MIPIPHY_RCR, BIT(1) },
> > [IMX7_RESET_MIPI_PHY_SRST]  = { SRC_MIPIPHY_RCR, BIT(2) },
> > [IMX7_RESET_PCIEPHY]= { SRC_PCIEPHY_RCR, BIT(2) | BIT(1) },
> > [IMX7_RESET_PCIEPHY_PERST]  = { SRC_PCIEPHY_RCR, BIT(3) },
> > [IMX7_RESET_PCIE_CTRL_APPS_EN]  = { SRC_PCIEPHY_RCR, BIT(6) },
> > +   [IMX7_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) },
> > [IMX7_RESET_DDRC_PRST]  = { SRC_DDRC_RCR, BIT(0) },
> > [IMX7_RESET_DDRC_CORE_RST]  = { SRC_DDRC_RCR, BIT(1) },
> >  };
> >  
> >  static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
> > diff --git a/include/dt-bindings/reset/imx7-reset.h 
> > b/include/dt-bindings/reset/imx7-reset.h
> > index 63948170c7b2..31b3f87dde9a 100644
> > --- a/include/dt-bindings/reset/imx7-reset.h
> > +++ b/include/dt-bindings/reset/imx7-reset.h
> > @@ -54,9 +54,11 @@
> >   */
> >  #define IMX7_RESET_PCIE_CTRL_APPS_EN   22
> >  #define IMX7_RESET_DDRC_PRST   23
> >  #define IMX7_RESET_DDRC_CORE_RST   24
> >  
> > -#define IMX7_RESET_NUM 25
> > +#define IMX7_RESET_PCIE_CTRL_APPS_TURNOFF 25
> > +
> > +#define IMX7_RESET_NUM 26
> >  
> >  #endif
> 
> This is contained enough to be merged with the rest of the series,
> patches 1 and 2:
> 
> Acked-by: Philipp Zabel 
> 
> Let me know if I should pick them up instead.

I can take the whole series but I would like to have it rebased against
v4.19-rc4 please since it does not apply as it is, thanks.

Lorenzo

Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 5:58 PM Lorenzo Pieralisi
 wrote:
>
> On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki  
> > wrote:
> > >
> > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> > > > On 4 October 2018 at 10:39, Rafael J. Wysocki  wrote:
> > > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson  
> > > > > wrote:
> > > > >>
> > > > >> I have digested the review comments so far, including a recent 
> > > > >> offlist chat
> > > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More 
> > > > >> or less I
> > > > >> have a plan for how to move forward.
> > > > >>
> > > > >> However, to avoid re-posting non-changed patches over and over 
> > > > >> again, I decided
> > > > >> to withhold the more debatable part from this v9, hence this is not 
> > > > >> the complete
> > > > >> series to make things play. In v9, I have just included the trivial 
> > > > >> changes,
> > > > >> which are either already acked/reviewed or hopefully can be rather 
> > > > >> soon/easily.
> > > > >>
> > > > >> My hope is to get this queued for v4.20, to move things forward. I 
> > > > >> know it's
> > > > >> late, but there are more or less nothing new here since v8.
> > > > >
> > > > > I have no problems with the first three patches in this series, so I
> > > > > can apply them right away.  Do you want me to do that?
> > > >
> > > > Yes, please.
> > > >
> > > > >
> > > > > As for the rest, the cpuidle driver patch looks OK to me, but the
> > > > > PSCI-related ones need ACKs.
> > > >
> > > > For some yes, but I think you can go ahead with a few more.
> > > >
> > > > Patch 4, 5 is already acked/reviewed.
> > > >
> > > > Patch 6 should be fine (if you are okay with it else wait for an ack
> > > > from Daniel)
> > >
> > > OK, thanks.
> > >
> > > Do the 4-6 depend on the 1-3?
> >
> > I don't see any dependency there, so I'll queue up the 1-3 in
> > pm-domains and the 4-6 in pm-cpuidle.
>
> I do not see why we should merge patches 4-6 for v4.20; they add legacy
> (DT bindings and related parsing code) with no user in the kernel; we
> may still want to tweak them, in particular PSCI DT bindings.

My impression was that 4-6 have been agreed on due to the ACKs they
carry.  I'll drop them if that's not the case.

> Likewise, it makes no sense to merge patches 7-8 without the rest of
> the PSCI patches.

OK

I'll let the ARM camp sort out the PSCI material then.

Thanks,
Rafael

Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

[Rafael J. Wysocki]

On Thu, Oct 4, 2018 at 5:58 PM Lorenzo Pieralisi
 wrote:
>
> On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki  
> > wrote:
> > >
> > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> > > > On 4 October 2018 at 10:39, Rafael J. Wysocki  wrote:
> > > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson  
> > > > > wrote:
> > > > >>
> > > > >> I have digested the review comments so far, including a recent 
> > > > >> offlist chat
> > > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More 
> > > > >> or less I
> > > > >> have a plan for how to move forward.
> > > > >>
> > > > >> However, to avoid re-posting non-changed patches over and over 
> > > > >> again, I decided
> > > > >> to withhold the more debatable part from this v9, hence this is not 
> > > > >> the complete
> > > > >> series to make things play. In v9, I have just included the trivial 
> > > > >> changes,
> > > > >> which are either already acked/reviewed or hopefully can be rather 
> > > > >> soon/easily.
> > > > >>
> > > > >> My hope is to get this queued for v4.20, to move things forward. I 
> > > > >> know it's
> > > > >> late, but there are more or less nothing new here since v8.
> > > > >
> > > > > I have no problems with the first three patches in this series, so I
> > > > > can apply them right away.  Do you want me to do that?
> > > >
> > > > Yes, please.
> > > >
> > > > >
> > > > > As for the rest, the cpuidle driver patch looks OK to me, but the
> > > > > PSCI-related ones need ACKs.
> > > >
> > > > For some yes, but I think you can go ahead with a few more.
> > > >
> > > > Patch 4, 5 is already acked/reviewed.
> > > >
> > > > Patch 6 should be fine (if you are okay with it else wait for an ack
> > > > from Daniel)
> > >
> > > OK, thanks.
> > >
> > > Do the 4-6 depend on the 1-3?
> >
> > I don't see any dependency there, so I'll queue up the 1-3 in
> > pm-domains and the 4-6 in pm-cpuidle.
>
> I do not see why we should merge patches 4-6 for v4.20; they add legacy
> (DT bindings and related parsing code) with no user in the kernel; we
> may still want to tweak them, in particular PSCI DT bindings.

My impression was that 4-6 have been agreed on due to the ACKs they
carry.  I'll drop them if that's not the case.

> Likewise, it makes no sense to merge patches 7-8 without the rest of
> the PSCI patches.

OK

I'll let the ARM camp sort out the PSCI material then.

Thanks,
Rafael

Re: linux-next: build failure after merge of the tty tree

[Greg Kroah-Hartman]

On Thu, Oct 04, 2018 at 06:34:31AM -1000, Steve Sakoman wrote:
> Interesting indeed. Who would have thought someone would be using the
> "unused" padding variable!

Ugh :(

> How would folks prefer we fix this, in the referenced patch or by
> eliminating the use of "unused" in samsung.c?

We should just get rid of the "unused" fields entirely.  They aren't
needed here as this is not a structure that anyone really cares about.
We can move things around a bit if the padding is an issue.

I've reverted this patch first for now.  I suggest a patch to the uart
core to drop the unused fields and fix up the samsung driver and then
your patch can go on top of that.  Can you work on this?

thanks,

greg k-h

Re: linux-next: build failure after merge of the tty tree

[Greg Kroah-Hartman]

On Thu, Oct 04, 2018 at 06:34:31AM -1000, Steve Sakoman wrote:
> Interesting indeed. Who would have thought someone would be using the
> "unused" padding variable!

Ugh :(

> How would folks prefer we fix this, in the referenced patch or by
> eliminating the use of "unused" in samsung.c?

We should just get rid of the "unused" fields entirely.  They aren't
needed here as this is not a structure that anyone really cares about.
We can move things around a bit if the padding is an issue.

I've reverted this patch first for now.  I suggest a patch to the uart
core to drop the unused fields and fix up the samsung driver and then
your patch can go on top of that.  Can you work on this?

thanks,

greg k-h

Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap

[Andy Lutomirski]

On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit  wrote:
>
> at 7:11 AM, Andy Lutomirski  wrote:
>
> >
> >
> > On Oct 3, 2018, at 9:59 PM, Nadav Amit  wrote:
> >
> >> This RFC proposes to return part of the entry-area back to the fixmap to
> >> improve system-call performance. Currently, since the entry-area is
> >> mapped far (more than 2GB) away from the kernel text, an indirect branch
> >> is needed to jump from the trampoline into the kernel. Due to Spectre
> >> v2, vulnerable CPUs need to use a retpoline, which introduces an
> >> overhead of >20 cycles.
> >
> > That retpoline is gone in -tip. Can you see how your code stacks up against 
> > -tip?  If it’s enough of a win to justify the added complexity, we can try 
> > it.
> >
> > You can see some pros and cons in the changelog:
> >
> > https://git.kernel.org/tip/bf904d2762ee6fc1e4acfcb0772bbfb4a27ad8a6
>
> Err.. That’s what I get for not following lkml. Very nice discussion.
> Based on it, I may be able to do an additional micro-optimizations or
> two. Let me give it a try.
>

I think you should at least try to benchmark your code against mine,
since you more or less implemented the alternative I suggested. :)

Hello Dear

[Tracy William]

Hello Dear, 

how are you today,I hope you are doing great. 

It is my great pleasure to contact you,I want to make a new and special 
friend,I hope you don't mind. My name is Tracy William from the United States, 
Am a french and English nationality. I will give you pictures and more details 
about my self as soon as i hear from you. 

Thanks 
Tracy

Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap

[Andy Lutomirski]

On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit  wrote:
>
> at 7:11 AM, Andy Lutomirski  wrote:
>
> >
> >
> > On Oct 3, 2018, at 9:59 PM, Nadav Amit  wrote:
> >
> >> This RFC proposes to return part of the entry-area back to the fixmap to
> >> improve system-call performance. Currently, since the entry-area is
> >> mapped far (more than 2GB) away from the kernel text, an indirect branch
> >> is needed to jump from the trampoline into the kernel. Due to Spectre
> >> v2, vulnerable CPUs need to use a retpoline, which introduces an
> >> overhead of >20 cycles.
> >
> > That retpoline is gone in -tip. Can you see how your code stacks up against 
> > -tip?  If it’s enough of a win to justify the added complexity, we can try 
> > it.
> >
> > You can see some pros and cons in the changelog:
> >
> > https://git.kernel.org/tip/bf904d2762ee6fc1e4acfcb0772bbfb4a27ad8a6
>
> Err.. That’s what I get for not following lkml. Very nice discussion.
> Based on it, I may be able to do an additional micro-optimizations or
> two. Let me give it a try.
>

I think you should at least try to benchmark your code against mine,
since you more or less implemented the alternative I suggested. :)

Hello Dear

[Tracy William]

Hello Dear, 

how are you today,I hope you are doing great. 

It is my great pleasure to contact you,I want to make a new and special 
friend,I hope you don't mind. My name is Tracy William from the United States, 
Am a french and English nationality. I will give you pictures and more details 
about my self as soon as i hear from you. 

Thanks 
Tracy

Re: [PATCH 00/11 v3] x86: load FPU registers on return to userland

[Andy Lutomirski]

> On Oct 4, 2018, at 9:45 AM, Rik van Riel  wrote:
> 
> On Thu, 2018-10-04 at 16:05 +0200, Sebastian Andrzej Siewior wrote:
> 
> 
>> In v3 I dropped that decouple idea. I also learned that the wrpkru
>> instruction is not privileged and so caching it in kernel does not
>> work.
> 
> Wait, so any thread can bypass its memory protection
> keys, even if there is a seccomp filter preventing
> it from calling the PKRU syscalls?
> 
> Is that intended?
> 
> Is that simply a hardware limitation, or something
> where we can set a flag somewhere to force tasks to
> go through the kernel?
> 
> 

Hardware limitation.

Re: [PATCH 00/11 v3] x86: load FPU registers on return to userland

[Andy Lutomirski]

> On Oct 4, 2018, at 9:45 AM, Rik van Riel  wrote:
> 
> On Thu, 2018-10-04 at 16:05 +0200, Sebastian Andrzej Siewior wrote:
> 
> 
>> In v3 I dropped that decouple idea. I also learned that the wrpkru
>> instruction is not privileged and so caching it in kernel does not
>> work.
> 
> Wait, so any thread can bypass its memory protection
> keys, even if there is a seccomp filter preventing
> it from calling the PKRU syscalls?
> 
> Is that intended?
> 
> Is that simply a hardware limitation, or something
> where we can set a flag somewhere to force tasks to
> go through the kernel?
> 
> 

Hardware limitation.

Re: [RFC 1/2] reboot: Make restart_handler_list a blocking notifier chain.

[Russell King - ARM Linux]

On Thu, Oct 04, 2018 at 06:23:38PM +0200, Nicolas Cavallari wrote:
> Many users of restart_handlers are sleeping in their callbacks.  Some
> are doing infinite loops or calling driver code that may sleep or
> perform operation on slow busses, like i2c.
> 
> This is not allowed in an atomic notifier chain, which is what
> restart_handler_list currently is, so use a blocking notifier chain
> instead.

This isn't going to work.

For example, sysrq processing (which can happen in IRQ context) calls
emergency_restart() for the reboot sysrq.  That calls through to
machine_restart(), which then calls do_kernel_restart().

If do_kernel_restart() sleeps, then we're trying to sleep in IRQ
context, and that's a no no.  I'm afraid you can't just add an irq
enable and change the notifier list to be atomic - and, as you're
making the change in generic code, this affects everyone, not just the
architecture that happens to be in front of you (so if it were merged,
you're likely to get a lot of bug reports!)

It gets worse, because (eg) a panic() or IRQ can happen with any locks
held - and if the I2C device's locks are held when one of those events
happen, you have a deadlock situation (hence you won't reboot!)

I suppose a good first step would be for us to have our own
machine_emergency_restart() on ARM, to separate the atomic paths
from the non-atomic paths, so that those who need to talk to an I2C,
that can happen from the non-atomic path (which means things like
/sbin/reboot will work) but other stuff (eg, restart on panic, sysrq,
soft-watchdog) will fail.

This issue as come up recently surrounding PMIC issues, but the
discussions there appear to have completely dried up...

However, my conclusion is that having an I2C driver deal with reboot
is possible for the process-induced reboot cases, but it's never going
to work reliably for the emergency case.

If you want the emergency case to work, then you need to work out some
way to talk on the I2C bus without involving any locks and with the I2C
bus possibly mid-transfer - which is not an easy problem to solve.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [RFC 1/2] reboot: Make restart_handler_list a blocking notifier chain.

[Russell King - ARM Linux]

On Thu, Oct 04, 2018 at 06:23:38PM +0200, Nicolas Cavallari wrote:
> Many users of restart_handlers are sleeping in their callbacks.  Some
> are doing infinite loops or calling driver code that may sleep or
> perform operation on slow busses, like i2c.
> 
> This is not allowed in an atomic notifier chain, which is what
> restart_handler_list currently is, so use a blocking notifier chain
> instead.

This isn't going to work.

For example, sysrq processing (which can happen in IRQ context) calls
emergency_restart() for the reboot sysrq.  That calls through to
machine_restart(), which then calls do_kernel_restart().

If do_kernel_restart() sleeps, then we're trying to sleep in IRQ
context, and that's a no no.  I'm afraid you can't just add an irq
enable and change the notifier list to be atomic - and, as you're
making the change in generic code, this affects everyone, not just the
architecture that happens to be in front of you (so if it were merged,
you're likely to get a lot of bug reports!)

It gets worse, because (eg) a panic() or IRQ can happen with any locks
held - and if the I2C device's locks are held when one of those events
happen, you have a deadlock situation (hence you won't reboot!)

I suppose a good first step would be for us to have our own
machine_emergency_restart() on ARM, to separate the atomic paths
from the non-atomic paths, so that those who need to talk to an I2C,
that can happen from the non-atomic path (which means things like
/sbin/reboot will work) but other stuff (eg, restart on panic, sysrq,
soft-watchdog) will fail.

This issue as come up recently surrounding PMIC issues, but the
discussions there appear to have completely dried up...

However, my conclusion is that having an I2C driver deal with reboot
is possible for the process-induced reboot cases, but it's never going
to work reliably for the emergency case.

If you want the emergency case to work, then you need to work out some
way to talk on the I2C bus without involving any locks and with the I2C
bus possibly mid-transfer - which is not an easy problem to solve.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [GIT PULL] xfs: fixes for 4.19-rc6

[Greg KH]

On Thu, Oct 04, 2018 at 11:03:12AM +1000, Dave Chinner wrote:
> Hi Greg,
> 
> Can you please pull the XFS from the tag listed below. It's a bit
> bigger than that I'd like this late in the cycle, but we've had a
> few challenges getting ourselves sorted out this cycle. Details
> of the contents are in the pull-req output below. This has been be
> run through xfstests over the past week, and merges against 4.19-rc6
> cleanly.
> 
> FYI, there is likely to be one more XFS fix for this cycle - we've
> just tracked down the source of a clone_file_range() data corruption
> so I'll send that as a separate pullreq once Darrick's fix is
> reviewed and tested.

Now merged, and thanks for the heads-up on a future patch.

greg k-h

Re: [GIT PULL] xfs: fixes for 4.19-rc6

[Greg KH]

On Thu, Oct 04, 2018 at 11:03:12AM +1000, Dave Chinner wrote:
> Hi Greg,
> 
> Can you please pull the XFS from the tag listed below. It's a bit
> bigger than that I'd like this late in the cycle, but we've had a
> few challenges getting ourselves sorted out this cycle. Details
> of the contents are in the pull-req output below. This has been be
> run through xfstests over the past week, and merges against 4.19-rc6
> cleanly.
> 
> FYI, there is likely to be one more XFS fix for this cycle - we've
> just tracked down the source of a clone_file_range() data corruption
> so I'll send that as a separate pullreq once Darrick's fix is
> reviewed and tested.

Now merged, and thanks for the heads-up on a future patch.

greg k-h

Re: [git pull] drm fixes for 4.19-rc7

[Greg Kroah-Hartman]

On Thu, Oct 04, 2018 at 02:55:42PM +1000, Dave Airlie wrote:
> Hi Greg,
> 
> Nothing too much happening at this point,
> 
> 3 i915 fixes:
> compressed error handling zlib fix
> compiler warning cleanup
> and a minor code cleanup
> 
> 2 tda9950:
> Two fixes for the HDMI CEC
> 
> 1 exynos:
> A fix required for IOMMU interaction.
> 
> Thanks,
> Dave.
> 
> drm-fixes-2018-10-04:
> drm exynos, tda9950 and intel fixes
> The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
> 
>   Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-10-04

Now merged, thanks.

greg k-h

Re: [git pull] drm fixes for 4.19-rc7

[Greg Kroah-Hartman]

On Thu, Oct 04, 2018 at 02:55:42PM +1000, Dave Airlie wrote:
> Hi Greg,
> 
> Nothing too much happening at this point,
> 
> 3 i915 fixes:
> compressed error handling zlib fix
> compiler warning cleanup
> and a minor code cleanup
> 
> 2 tda9950:
> Two fixes for the HDMI CEC
> 
> 1 exynos:
> A fix required for IOMMU interaction.
> 
> Thanks,
> Dave.
> 
> drm-fixes-2018-10-04:
> drm exynos, tda9950 and intel fixes
> The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
> 
>   Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-10-04

Now merged, thanks.

greg k-h

Re: [PATCH v2 1/4] reset: imx7: Add PCIE_CTRL_APPS_TURNOFF

[Philipp Zabel]

Hi Leonard,

On Thu, 2018-10-04 at 16:34 +, Leonard Crestez wrote:
> This is required for the imx pci driver to send the PME_Turn_Off TLP.
> 
> Signed-off-by: Leonard Crestez 
> Acked-by: Rob Herring 
> ---
>  drivers/reset/reset-imx7.c | 1 +
>  include/dt-bindings/reset/imx7-reset.h | 4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> index 97d9f08271c5..77911fa8f31d 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -65,10 +65,11 @@ static const struct imx7_src_signal 
> imx7_src_signals[IMX7_RESET_NUM] = {
>   [IMX7_RESET_MIPI_PHY_MRST]  = { SRC_MIPIPHY_RCR, BIT(1) },
>   [IMX7_RESET_MIPI_PHY_SRST]  = { SRC_MIPIPHY_RCR, BIT(2) },
>   [IMX7_RESET_PCIEPHY]= { SRC_PCIEPHY_RCR, BIT(2) | BIT(1) },
>   [IMX7_RESET_PCIEPHY_PERST]  = { SRC_PCIEPHY_RCR, BIT(3) },
>   [IMX7_RESET_PCIE_CTRL_APPS_EN]  = { SRC_PCIEPHY_RCR, BIT(6) },
> + [IMX7_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) },
>   [IMX7_RESET_DDRC_PRST]  = { SRC_DDRC_RCR, BIT(0) },
>   [IMX7_RESET_DDRC_CORE_RST]  = { SRC_DDRC_RCR, BIT(1) },
>  };
>  
>  static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
> diff --git a/include/dt-bindings/reset/imx7-reset.h 
> b/include/dt-bindings/reset/imx7-reset.h
> index 63948170c7b2..31b3f87dde9a 100644
> --- a/include/dt-bindings/reset/imx7-reset.h
> +++ b/include/dt-bindings/reset/imx7-reset.h
> @@ -54,9 +54,11 @@
>   */
>  #define IMX7_RESET_PCIE_CTRL_APPS_EN 22
>  #define IMX7_RESET_DDRC_PRST 23
>  #define IMX7_RESET_DDRC_CORE_RST 24
>  
> -#define IMX7_RESET_NUM   25
> +#define IMX7_RESET_PCIE_CTRL_APPS_TURNOFF 25
> +
> +#define IMX7_RESET_NUM   26
>  
>  #endif

This is contained enough to be merged with the rest of the series,
patches 1 and 2:

Acked-by: Philipp Zabel 

Let me know if I should pick them up instead.

regards
Philipp

[GIT PULL] for-next updates for soc/fsl drivers for v4.20 take 2

[Li Yang]

Hi arm-soc maintainers,

Please merge the following updates for next.

PS.  One of the patches is depending on the last pull request for fixes to build
https://patchwork.kernel.org/patch/10622883/
I didn't include the fix patches directly in this pull request to prevent a
complicated merge.  Please let me know if there is a more preferred approach
to deal with dependencies between pull requests.

Regards,
Leo

The following changes since commit afa86d264a7ce62ba214bc7c6012e2129141421e:

  soc: fsl: dpio: remove redundant pointer 'priv' (2018-08-30 12:19:02 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
tags/soc-fsl-next-v4.20-2

for you to fetch changes up to aeaf982954849e9d2bccffab138703be28edd2ae:

  soc: fsl: qbman: add interrupt coalesce changing APIs (2018-10-02 15:04:19 
-0500)


NXP/FSL SoC drivers updates for v4.20 take 2

- Update qbman driver to better work with CPU hotplug
- Add Kconfig dependency of 64-bit DMA addressing for qbman driver
- Use last reponse to determine valid bit for qbman driver
- Defer bman_portals probe if bman is not probed
- Add interrupt coalescing APIs to qbman driver


Laurentiu Tudor (1):
  soc: fsl: bman_portals: defer probe after bman's probe

Madalin Bucur (2):
  soc: fsl: qbman: replace CPU 0 with any online CPU in hotplug handlers
  soc: fsl: qbman: add interrupt coalesce changing APIs

Roy Pledge (3):
  soc: fsl: qbman: Check if CPU is offline when initializing portals
  soc: fsl: qbman: Add 64 bit DMA addressing requirement to QBMan
  soc: fsl: qbman: Use last response to determine valid bit

 drivers/soc/fsl/qbman/Kconfig   |  2 +-
 drivers/soc/fsl/qbman/bman.c|  6 ++---
 drivers/soc/fsl/qbman/bman_portal.c | 14 --
 drivers/soc/fsl/qbman/dpaa_sys.h| 20 ++
 drivers/soc/fsl/qbman/qman.c| 53 -
 drivers/soc/fsl/qbman/qman_portal.c |  6 +++--
 include/soc/fsl/qman.h  | 27 +++
 7 files changed, 113 insertions(+), 15 deletions(-)

Re: [PATCH v2 1/4] reset: imx7: Add PCIE_CTRL_APPS_TURNOFF

[Philipp Zabel]

Hi Leonard,

On Thu, 2018-10-04 at 16:34 +, Leonard Crestez wrote:
> This is required for the imx pci driver to send the PME_Turn_Off TLP.
> 
> Signed-off-by: Leonard Crestez 
> Acked-by: Rob Herring 
> ---
>  drivers/reset/reset-imx7.c | 1 +
>  include/dt-bindings/reset/imx7-reset.h | 4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> index 97d9f08271c5..77911fa8f31d 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -65,10 +65,11 @@ static const struct imx7_src_signal 
> imx7_src_signals[IMX7_RESET_NUM] = {
>   [IMX7_RESET_MIPI_PHY_MRST]  = { SRC_MIPIPHY_RCR, BIT(1) },
>   [IMX7_RESET_MIPI_PHY_SRST]  = { SRC_MIPIPHY_RCR, BIT(2) },
>   [IMX7_RESET_PCIEPHY]= { SRC_PCIEPHY_RCR, BIT(2) | BIT(1) },
>   [IMX7_RESET_PCIEPHY_PERST]  = { SRC_PCIEPHY_RCR, BIT(3) },
>   [IMX7_RESET_PCIE_CTRL_APPS_EN]  = { SRC_PCIEPHY_RCR, BIT(6) },
> + [IMX7_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) },
>   [IMX7_RESET_DDRC_PRST]  = { SRC_DDRC_RCR, BIT(0) },
>   [IMX7_RESET_DDRC_CORE_RST]  = { SRC_DDRC_RCR, BIT(1) },
>  };
>  
>  static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
> diff --git a/include/dt-bindings/reset/imx7-reset.h 
> b/include/dt-bindings/reset/imx7-reset.h
> index 63948170c7b2..31b3f87dde9a 100644
> --- a/include/dt-bindings/reset/imx7-reset.h
> +++ b/include/dt-bindings/reset/imx7-reset.h
> @@ -54,9 +54,11 @@
>   */
>  #define IMX7_RESET_PCIE_CTRL_APPS_EN 22
>  #define IMX7_RESET_DDRC_PRST 23
>  #define IMX7_RESET_DDRC_CORE_RST 24
>  
> -#define IMX7_RESET_NUM   25
> +#define IMX7_RESET_PCIE_CTRL_APPS_TURNOFF 25
> +
> +#define IMX7_RESET_NUM   26
>  
>  #endif

This is contained enough to be merged with the rest of the series,
patches 1 and 2:

Acked-by: Philipp Zabel 

Let me know if I should pick them up instead.

regards
Philipp

[GIT PULL] for-next updates for soc/fsl drivers for v4.20 take 2

[Li Yang]

Hi arm-soc maintainers,

Please merge the following updates for next.

PS.  One of the patches is depending on the last pull request for fixes to build
https://patchwork.kernel.org/patch/10622883/
I didn't include the fix patches directly in this pull request to prevent a
complicated merge.  Please let me know if there is a more preferred approach
to deal with dependencies between pull requests.

Regards,
Leo

The following changes since commit afa86d264a7ce62ba214bc7c6012e2129141421e:

  soc: fsl: dpio: remove redundant pointer 'priv' (2018-08-30 12:19:02 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
tags/soc-fsl-next-v4.20-2

for you to fetch changes up to aeaf982954849e9d2bccffab138703be28edd2ae:

  soc: fsl: qbman: add interrupt coalesce changing APIs (2018-10-02 15:04:19 
-0500)


NXP/FSL SoC drivers updates for v4.20 take 2

- Update qbman driver to better work with CPU hotplug
- Add Kconfig dependency of 64-bit DMA addressing for qbman driver
- Use last reponse to determine valid bit for qbman driver
- Defer bman_portals probe if bman is not probed
- Add interrupt coalescing APIs to qbman driver


Laurentiu Tudor (1):
  soc: fsl: bman_portals: defer probe after bman's probe

Madalin Bucur (2):
  soc: fsl: qbman: replace CPU 0 with any online CPU in hotplug handlers
  soc: fsl: qbman: add interrupt coalesce changing APIs

Roy Pledge (3):
  soc: fsl: qbman: Check if CPU is offline when initializing portals
  soc: fsl: qbman: Add 64 bit DMA addressing requirement to QBMan
  soc: fsl: qbman: Use last response to determine valid bit

 drivers/soc/fsl/qbman/Kconfig   |  2 +-
 drivers/soc/fsl/qbman/bman.c|  6 ++---
 drivers/soc/fsl/qbman/bman_portal.c | 14 --
 drivers/soc/fsl/qbman/dpaa_sys.h| 20 ++
 drivers/soc/fsl/qbman/qman.c| 53 -
 drivers/soc/fsl/qbman/qman_portal.c |  6 +++--
 include/soc/fsl/qman.h  | 27 +++
 7 files changed, 113 insertions(+), 15 deletions(-)

Re: [PATCH v5 2/2] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC

[Doug Anderson]

Hi,
On Wed, Oct 3, 2018 at 5:14 PM Matthias Kaehlcke  wrote:
>
> Add a channel node for the die temperature to the ADC.
>
> Signed-off-by: Matthias Kaehlcke 
> Reviewed-by: Douglas Anderson 
> ---
> Changes in v4:
> - added unit address to 'die-temp' node

This probably should have been "changes in v5"

> ---
>  arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi 
> b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> index 048f19fa0150..32b141637d13 100644
> --- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> @@ -75,6 +75,11 @@
> #address-cells = <1>;
> #size-cells = <0>;
> #io-channel-cells = <1>;
> +
> +   die-temp@ADC5_DIE_TEMP {
> +   reg = ;

Thanks for adding the unit address.  Note to Andy that this ought to
go into the queue for 4.20 since you'll have the ADC5_DIE_TEMP then.


-Doug

RE: [PATCH v2] qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers

[Tayar, Tomer]

From: Nathan Chancellor 
Sent: Thursday, October 04, 2018 7:39 PM

> Clang warns when one enumerated type is implicitly converted to another.
> 
> drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
> conversion from enumeration type 'enum core_tx_dest' to different
> enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> tx_pkt.tx_dest = p_ll2_conn->tx_dest;
>~ ^~~
> 1 warning generated.
> 
> Fix this by using a switch statement to convert between the enumerated
> values since they are not 1 to 1, which matches how the rest of the
> driver handles this conversion.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Suggested-by: Tomer Tayar 
> Signed-off-by: Nathan Chancellor 
> ---
> 
> v1 -> v2:
> 
> * Use an explicit switch statement to convert between the enumerated
>   types like the rest of the driver, as suggested by Tomer.

Thanks
Acked-by: Tomer Tayar 

Re: [PATCH v5 2/2] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC

[Doug Anderson]

Hi,
On Wed, Oct 3, 2018 at 5:14 PM Matthias Kaehlcke  wrote:
>
> Add a channel node for the die temperature to the ADC.
>
> Signed-off-by: Matthias Kaehlcke 
> Reviewed-by: Douglas Anderson 
> ---
> Changes in v4:
> - added unit address to 'die-temp' node

This probably should have been "changes in v5"

> ---
>  arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi 
> b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> index 048f19fa0150..32b141637d13 100644
> --- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> @@ -75,6 +75,11 @@
> #address-cells = <1>;
> #size-cells = <0>;
> #io-channel-cells = <1>;
> +
> +   die-temp@ADC5_DIE_TEMP {
> +   reg = ;

Thanks for adding the unit address.  Note to Andy that this ought to
go into the queue for 4.20 since you'll have the ADC5_DIE_TEMP then.


-Doug

RE: [PATCH v2] qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers

[Tayar, Tomer]

From: Nathan Chancellor 
Sent: Thursday, October 04, 2018 7:39 PM

> Clang warns when one enumerated type is implicitly converted to another.
> 
> drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
> conversion from enumeration type 'enum core_tx_dest' to different
> enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> tx_pkt.tx_dest = p_ll2_conn->tx_dest;
>~ ^~~
> 1 warning generated.
> 
> Fix this by using a switch statement to convert between the enumerated
> values since they are not 1 to 1, which matches how the rest of the
> driver handles this conversion.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Suggested-by: Tomer Tayar 
> Signed-off-by: Nathan Chancellor 
> ---
> 
> v1 -> v2:
> 
> * Use an explicit switch statement to convert between the enumerated
>   types like the rest of the driver, as suggested by Tomer.

Thanks
Acked-by: Tomer Tayar 

Re: [PATCH 00/11 v3] x86: load FPU registers on return to userland

[Rik van Riel]

On Thu, 2018-10-04 at 16:05 +0200, Sebastian Andrzej Siewior wrote:


> In v3 I dropped that decouple idea. I also learned that the wrpkru
> instruction is not privileged and so caching it in kernel does not
> work.

Wait, so any thread can bypass its memory protection
keys, even if there is a seccomp filter preventing
it from calling the PKRU syscalls?

Is that intended?

Is that simply a hardware limitation, or something
where we can set a flag somewhere to force tasks to
go through the kernel?

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 00/11 v3] x86: load FPU registers on return to userland

[Rik van Riel]

On Thu, 2018-10-04 at 16:05 +0200, Sebastian Andrzej Siewior wrote:


> In v3 I dropped that decouple idea. I also learned that the wrpkru
> instruction is not privileged and so caching it in kernel does not
> work.

Wait, so any thread can bypass its memory protection
keys, even if there is a seccomp filter preventing
it from calling the PKRU syscalls?

Is that intended?

Is that simply a hardware limitation, or something
where we can set a flag somewhere to force tasks to
go through the kernel?

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH net-next 0/9] rxrpc: Development

[David Miller]

From: David Howells 
Date: Thu, 04 Oct 2018 14:50:31 +0100

> Here are some development patches for AF_RXRPC.  The most significant points
> are:
 ...
> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-next-20181004

Pulled, thanks David.

Re: [PATCH net-next 0/9] rxrpc: Development

[David Miller]

From: David Howells 
Date: Thu, 04 Oct 2018 14:50:31 +0100

> Here are some development patches for AF_RXRPC.  The most significant points
> are:
 ...
> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-next-20181004

Pulled, thanks David.

Re: [PATCH v2 0/3] Randomize free memory

[Dan Williams]

Hi Michal,

On Thu, Oct 4, 2018 at 12:53 AM Michal Hocko  wrote:
>
> On Wed 03-10-18 19:15:18, Dan Williams wrote:
> > Changes since v1:
> > * Add support for shuffling hot-added memory (Andrew)
> > * Update cover letter and commit message to clarify the performance impact
> >   and relevance to future platforms
>
> I believe this hasn't addressed my questions in
> http://lkml.kernel.org/r/20181002143015.gx18...@dhcp22.suse.cz. Namely
> "
> It is the more general idea that I am not really sure about. First of
> all. Does it make _any_ sense to randomize 4MB blocks by default? Why
> cannot we simply have it disabled?

I'm not aware of any CVE that this would directly preclude, but that
said the entropy injected at 4MB boundaries raises the bar on heap
attacks. Environments that want more can adjust that with the boot
parameter. Given the potential benefits I think it would only make
sense to default disable it if there was a significant runtime impact,
from what I have seen there isn't.

> Then and more concerning question is,
> does it even make sense to have this randomization applied to higher
> orders than 0? Attacker might fragment the memory and keep recycling the
> lowest order and get the predictable behavior that we have right now.

Certainly I expect there are attacks that can operate within a 4MB
window, as I expect there are attacks that could operate within a 4K
window that would need sub-page randomization to deter. In fact I
believe that is the motivation for CONFIG_SLAB_FREELIST_RANDOM.
Combining that with page allocator randomization makes the kernel less
predictable.

Is that enough justification for this patch on its own? It's
debatable. Combine that though with the wider availability of
platforms with memory-side-cache and I think it's a reasonable default
behavior for the kernel to deploy.

Re: [GIT PULL] fixes for soc/fsl drivers for v4.19 take 2

[Li Yang]

On Thu, Oct 4, 2018 at 4:40 AM Laurentiu Tudor  wrote:
>
> Hi Leo,
>
> On 02.10.2018 01:58, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > Please merge the updated fix for the following issue.
> >
> > Regards,
> > Leo
> >
> > The following changes since commit 96fc74333f84cfdf8d434c6c07254e215e2aad00:
> >
> >soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift() (2018-09-25 
> > 13:57:26 -0700)
> >
> > are available in the Git repository at:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
> > soc-fsl-fix-v4.19-2
> >
> > for you to fetch changes up to 5a1eb8b9542884592a018829bb1ff20c9695d925:
> >
> >soc: fsl: qman_portals: defer probe after qman's probe (2018-10-01 
> > 17:47:43 -0500)
> >
> > 
> > NXP/FSL SoC driver fixes for v4.19 round 2
> >
> > - Fix crash of qman_portal by deferring its probe if qman is not probed
> >
> > 
> > Laurentiu Tudor (2):
> >soc: fsl: qbman: add APIs to retrieve the probing status
> >soc: fsl: qman_portals: defer probe after qman's probe
>
> There's a similar fix for bman portals [1]. I was under the impression
> that you plan to pick that up too.
>
> [1] "soc/fsl/bman_portals: defer probe after bman's probe", found here:
> https://lore.kernel.org/patchwork/patch/992009/

As mentioned in the patch description, it doesn't trigger a crash
right now.  It might not be qualified as a fix, so on a second
thought, I move it to the for-next pull request.

Regards,
Leo