Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

2018-05-12 Thread Joel Fernandes
On Tue, May 08, 2018 at 10:42:37AM +0100, Quentin Perret wrote:
> On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote:
> > On 05/08/2018 10:22 AM, Viresh Kumar wrote:
> > > On 08-05-18, 08:33, Dietmar Eggemann wrote:
> > > > This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.
> > > > 
> > > > Lifting the restriction that the sugov kthread is bound to the
> > > > policy->related_cpus for a system with a slow switching cpufreq driver,
> > > > which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not
> > > > only not beneficial it also harms Enery-Aware Scheduling (EAS) on
> > > > systems with asymmetric cpu capacities (e.g. Arm big.LITTLE).
> > > > 
> > > > The sugov kthread which does the update for the little cpus could
> > > > potentially run on a big cpu. It could prevent that the big cluster goes
> > > > into deeper idle states although all the tasks are running on the little
> > > > cluster.
> > > 
> > > I think the original patch did the right thing, but that doesn't suit
> > > everybody as you explained.
> > > 
> > > I wouldn't really revert the patch but fix my platform's cpufreq
> > > driver to set dvfs_possible_from_any_cpu = false, so that other
> > > platforms can still benefit from the original commit.
> > 
> > This would make sure that the kthreads are bound to the correct set of cpus
> > for platforms with those cpufreq drivers (cpufreq-dt (h960), scmi-cpufreq,
> > scpi-cpufreq) but it will also change the logic (e.g.
> > sugov_should_update_freq() -> cpufreq_can_do_remote_dvfs()).
> > 
> > I'm still struggling to understand when a driver/platform should set
> > dvfs_possible_from_any_cpu to true and what the actual benefit would be.
> 
> I assume it might be beneficial to have the kthread moving around freely
> in some cases, but since it is a SCHED_DEADLINE task now it can't really
> migrate anywhere anyway. So I'm not sure either if this commits still makes
> sense now. Or is there another use case for this ?

The usecase I guess is, as Dietmar was saying, that it makes sense for
kthread to update its own cluster and not disturb other clusters or random
CPUs. I agree with this point.

- Joel




Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

2018-05-12 Thread Joel Fernandes
On Tue, May 08, 2018 at 10:42:37AM +0100, Quentin Perret wrote:
> On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote:
> > On 05/08/2018 10:22 AM, Viresh Kumar wrote:
> > > On 08-05-18, 08:33, Dietmar Eggemann wrote:
> > > > This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.
> > > > 
> > > > Lifting the restriction that the sugov kthread is bound to the
> > > > policy->related_cpus for a system with a slow switching cpufreq driver,
> > > > which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not
> > > > only not beneficial it also harms Enery-Aware Scheduling (EAS) on
> > > > systems with asymmetric cpu capacities (e.g. Arm big.LITTLE).
> > > > 
> > > > The sugov kthread which does the update for the little cpus could
> > > > potentially run on a big cpu. It could prevent that the big cluster goes
> > > > into deeper idle states although all the tasks are running on the little
> > > > cluster.
> > > 
> > > I think the original patch did the right thing, but that doesn't suit
> > > everybody as you explained.
> > > 
> > > I wouldn't really revert the patch but fix my platform's cpufreq
> > > driver to set dvfs_possible_from_any_cpu = false, so that other
> > > platforms can still benefit from the original commit.
> > 
> > This would make sure that the kthreads are bound to the correct set of cpus
> > for platforms with those cpufreq drivers (cpufreq-dt (h960), scmi-cpufreq,
> > scpi-cpufreq) but it will also change the logic (e.g.
> > sugov_should_update_freq() -> cpufreq_can_do_remote_dvfs()).
> > 
> > I'm still struggling to understand when a driver/platform should set
> > dvfs_possible_from_any_cpu to true and what the actual benefit would be.
> 
> I assume it might be beneficial to have the kthread moving around freely
> in some cases, but since it is a SCHED_DEADLINE task now it can't really
> migrate anywhere anyway. So I'm not sure either if this commits still makes
> sense now. Or is there another use case for this ?

The usecase I guess is, as Dietmar was saying, that it makes sense for
kthread to update its own cluster and not disturb other clusters or random
CPUs. I agree with this point.

- Joel




Re: [PATCH v5 01/13] mm: Assign id to every memcg-aware shrinker

2018-05-12 Thread Vladimir Davydov
On Thu, May 10, 2018 at 12:52:18PM +0300, Kirill Tkhai wrote:
> The patch introduces shrinker::id number, which is used to enumerate
> memcg-aware shrinkers. The number start from 0, and the code tries
> to maintain it as small as possible.
> 
> This will be used as to represent a memcg-aware shrinkers in memcg
> shrinkers map.
> 
> Since all memcg-aware shrinkers are based on list_lru, which is per-memcg
> in case of !SLOB only, the new functionality will be under MEMCG && !SLOB
> ifdef (symlinked to CONFIG_MEMCG_SHRINKER).

Using MEMCG && !SLOB instead of introducing a new config option was done
deliberately, see:

  http://lkml.kernel.org/r/20151210202244.ga4...@cmpxchg.org

I guess, this doesn't work well any more, as there are more and more
parts depending on kmem accounting, like shrinkers. If you really want
to introduce a new option, I think you should call it CONFIG_MEMCG_KMEM
and use it consistently throughout the code instead of MEMCG && !SLOB.
And this should be done in a separate patch.

> diff --git a/fs/super.c b/fs/super.c
> index 122c402049a2..16c153d2f4f1 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -248,6 +248,9 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags,
>   s->s_time_gran = 10;
>   s->cleancache_poolid = CLEANCACHE_NO_POOL;
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> + s->s_shrink.id = -1;
> +#endif

No point doing that - you are going to overwrite the id anyway in
prealloc_shrinker().

>   s->s_shrink.seeks = DEFAULT_SEEKS;
>   s->s_shrink.scan_objects = super_cache_scan;
>   s->s_shrink.count_objects = super_cache_count;

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 10c8a38c5eef..d691beac1048 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -169,6 +169,47 @@ unsigned long vm_total_pages;
>  static LIST_HEAD(shrinker_list);
>  static DECLARE_RWSEM(shrinker_rwsem);
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> +static DEFINE_IDR(shrinker_idr);
> +
> +static int prealloc_memcg_shrinker(struct shrinker *shrinker)
> +{
> + int id, ret;
> +
> + down_write(_rwsem);
> + ret = id = idr_alloc(_idr, shrinker, 0, 0, GFP_KERNEL);
> + if (ret < 0)
> + goto unlock;
> + shrinker->id = id;
> + ret = 0;
> +unlock:
> + up_write(_rwsem);
> + return ret;
> +}
> +
> +static void del_memcg_shrinker(struct shrinker *shrinker)

Nit: IMO unregister_memcg_shrinker() would be a better name as it
matches unregister_shrinker(), just like prealloc_memcg_shrinker()
matches prealloc_shrinker().

> +{
> + int id = shrinker->id;
> +

> + if (id < 0)
> + return;

Nit: I think this should be BUG_ON(id >= 0) as this function is only
called for memcg-aware shrinkers AFAICS.

> +
> + down_write(_rwsem);
> + idr_remove(_idr, id);
> + up_write(_rwsem);
> + shrinker->id = -1;
> +}


Re: [PATCH v5 01/13] mm: Assign id to every memcg-aware shrinker

2018-05-12 Thread Vladimir Davydov
On Thu, May 10, 2018 at 12:52:18PM +0300, Kirill Tkhai wrote:
> The patch introduces shrinker::id number, which is used to enumerate
> memcg-aware shrinkers. The number start from 0, and the code tries
> to maintain it as small as possible.
> 
> This will be used as to represent a memcg-aware shrinkers in memcg
> shrinkers map.
> 
> Since all memcg-aware shrinkers are based on list_lru, which is per-memcg
> in case of !SLOB only, the new functionality will be under MEMCG && !SLOB
> ifdef (symlinked to CONFIG_MEMCG_SHRINKER).

Using MEMCG && !SLOB instead of introducing a new config option was done
deliberately, see:

  http://lkml.kernel.org/r/20151210202244.ga4...@cmpxchg.org

I guess, this doesn't work well any more, as there are more and more
parts depending on kmem accounting, like shrinkers. If you really want
to introduce a new option, I think you should call it CONFIG_MEMCG_KMEM
and use it consistently throughout the code instead of MEMCG && !SLOB.
And this should be done in a separate patch.

> diff --git a/fs/super.c b/fs/super.c
> index 122c402049a2..16c153d2f4f1 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -248,6 +248,9 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags,
>   s->s_time_gran = 10;
>   s->cleancache_poolid = CLEANCACHE_NO_POOL;
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> + s->s_shrink.id = -1;
> +#endif

No point doing that - you are going to overwrite the id anyway in
prealloc_shrinker().

>   s->s_shrink.seeks = DEFAULT_SEEKS;
>   s->s_shrink.scan_objects = super_cache_scan;
>   s->s_shrink.count_objects = super_cache_count;

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 10c8a38c5eef..d691beac1048 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -169,6 +169,47 @@ unsigned long vm_total_pages;
>  static LIST_HEAD(shrinker_list);
>  static DECLARE_RWSEM(shrinker_rwsem);
>  
> +#ifdef CONFIG_MEMCG_SHRINKER
> +static DEFINE_IDR(shrinker_idr);
> +
> +static int prealloc_memcg_shrinker(struct shrinker *shrinker)
> +{
> + int id, ret;
> +
> + down_write(_rwsem);
> + ret = id = idr_alloc(_idr, shrinker, 0, 0, GFP_KERNEL);
> + if (ret < 0)
> + goto unlock;
> + shrinker->id = id;
> + ret = 0;
> +unlock:
> + up_write(_rwsem);
> + return ret;
> +}
> +
> +static void del_memcg_shrinker(struct shrinker *shrinker)

Nit: IMO unregister_memcg_shrinker() would be a better name as it
matches unregister_shrinker(), just like prealloc_memcg_shrinker()
matches prealloc_shrinker().

> +{
> + int id = shrinker->id;
> +

> + if (id < 0)
> + return;

Nit: I think this should be BUG_ON(id >= 0) as this function is only
called for memcg-aware shrinkers AFAICS.

> +
> + down_write(_rwsem);
> + idr_remove(_idr, id);
> + up_write(_rwsem);
> + shrinker->id = -1;
> +}


Re: [PATCH] pstore: Convert internal records to timespec64

2018-05-12 Thread Kees Cook
On Sat, May 12, 2018 at 10:45 AM, Deepa Dinamani  wrote:
>  Acked-by: Deepa Dinamani 

Thanks for checking this over!

> I will rebase the vfs series on top of this.
> I'm a little worried about merge strategy.
> Whoever is taking that series should pull in this patch as well?
> I could include it as one of the patches in the series if you prefer.

I'll send a v2, I found some problems in my testing. I'll see if Linus
will take it for v4.17, so it'll be out of your way for v4.18.

-Kees

>
> -Deepa
>
> On Fri, May 11, 2018 at 11:57 PM, Kees Cook  wrote:
>> This prepares pstore for converting the VFS layer to timespec64.
>>
>> Cc: Deepa Dinamani 
>> Signed-off-by: Kees Cook 
>> ---
>>  fs/pstore/inode.c  | 3 ++-
>>  fs/pstore/platform.c   | 2 +-
>>  include/linux/pstore.h | 2 +-
>>  3 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index 5fcb845b9fec..75afe5eb0574 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -392,7 +392,8 @@ int pstore_mkfile(struct dentry *root, struct 
>> pstore_record *record)
>> inode->i_private = private;
>>
>> if (record->time.tv_sec)
>> -   inode->i_mtime = inode->i_ctime = record->time;
>> +   inode->i_mtime = inode->i_ctime =
>> +   timespec64_to_timespec(record->time);
>>
>> d_add(dentry, inode);
>>
>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>> index dc720573fd53..c238ab8ba31d 100644
>> --- a/fs/pstore/platform.c
>> +++ b/fs/pstore/platform.c
>> @@ -328,7 +328,7 @@ void pstore_record_init(struct pstore_record *record,
>> record->psi = psinfo;
>>
>> /* Report zeroed timestamp if called before timekeeping has resumed. 
>> */
>> -   record->time = ns_to_timespec(ktime_get_real_fast_ns());
>> +   record->time = ns_to_timespec64(ktime_get_real_fast_ns());
>>  }
>>
>>  /*
>> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
>> index 61f806a7fe29..a15bc4d48752 100644
>> --- a/include/linux/pstore.h
>> +++ b/include/linux/pstore.h
>> @@ -71,7 +71,7 @@ struct pstore_record {
>> struct pstore_info  *psi;
>> enum pstore_type_id type;
>> u64 id;
>> -   struct timespec time;
>> +   struct timespec64   time;
>> char*buf;
>> ssize_t size;
>> ssize_t ecc_notice_size;
>> --
>> 2.17.0
>>
>>
>> --
>> Kees Cook
>> Pixel Security



-- 
Kees Cook
Pixel Security


Re: [PATCH] pstore: Convert internal records to timespec64

2018-05-12 Thread Kees Cook
On Sat, May 12, 2018 at 10:45 AM, Deepa Dinamani  wrote:
>  Acked-by: Deepa Dinamani 

Thanks for checking this over!

> I will rebase the vfs series on top of this.
> I'm a little worried about merge strategy.
> Whoever is taking that series should pull in this patch as well?
> I could include it as one of the patches in the series if you prefer.

I'll send a v2, I found some problems in my testing. I'll see if Linus
will take it for v4.17, so it'll be out of your way for v4.18.

-Kees

>
> -Deepa
>
> On Fri, May 11, 2018 at 11:57 PM, Kees Cook  wrote:
>> This prepares pstore for converting the VFS layer to timespec64.
>>
>> Cc: Deepa Dinamani 
>> Signed-off-by: Kees Cook 
>> ---
>>  fs/pstore/inode.c  | 3 ++-
>>  fs/pstore/platform.c   | 2 +-
>>  include/linux/pstore.h | 2 +-
>>  3 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index 5fcb845b9fec..75afe5eb0574 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -392,7 +392,8 @@ int pstore_mkfile(struct dentry *root, struct 
>> pstore_record *record)
>> inode->i_private = private;
>>
>> if (record->time.tv_sec)
>> -   inode->i_mtime = inode->i_ctime = record->time;
>> +   inode->i_mtime = inode->i_ctime =
>> +   timespec64_to_timespec(record->time);
>>
>> d_add(dentry, inode);
>>
>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>> index dc720573fd53..c238ab8ba31d 100644
>> --- a/fs/pstore/platform.c
>> +++ b/fs/pstore/platform.c
>> @@ -328,7 +328,7 @@ void pstore_record_init(struct pstore_record *record,
>> record->psi = psinfo;
>>
>> /* Report zeroed timestamp if called before timekeeping has resumed. 
>> */
>> -   record->time = ns_to_timespec(ktime_get_real_fast_ns());
>> +   record->time = ns_to_timespec64(ktime_get_real_fast_ns());
>>  }
>>
>>  /*
>> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
>> index 61f806a7fe29..a15bc4d48752 100644
>> --- a/include/linux/pstore.h
>> +++ b/include/linux/pstore.h
>> @@ -71,7 +71,7 @@ struct pstore_record {
>> struct pstore_info  *psi;
>> enum pstore_type_id type;
>> u64 id;
>> -   struct timespec time;
>> +   struct timespec64   time;
>> char*buf;
>> ssize_t size;
>> ssize_t ecc_notice_size;
>> --
>> 2.17.0
>>
>>
>> --
>> Kees Cook
>> Pixel Security



-- 
Kees Cook
Pixel Security


RE: [PATCH v6] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

2018-05-12 Thread Wan, Jane (Nokia - US/Sunnyvale)
Hi Boris,

I've sent v7 of the patch.

Thanks.
Jane

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Saturday, May 12, 2018 1:21 AM
> To: Wan, Jane (Nokia - US/Sunnyvale) 
> Cc: miquel.ray...@bootlin.com; dw...@infradead.org;
> computersforpe...@gmail.com; rich...@nod.at; marek.va...@gmail.com;
> yamada.masah...@socionext.com; prabhakar.kushw...@nxp.com;
> shawn...@kernel.org; jagdish.ged...@nxp.com;
> shreeya.patel23...@gmail.com; linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Bos, Ties (Nokia - US/Sunnyvale) 
> Subject: Re: [PATCH v6] mtd: rawnand: use bit-wise majority to recover the
> contents of ONFI parameter
> 
> On Thu, 10 May 2018 14:28:37 -0700
> Jane Wan  wrote:
> 
> > Per ONFI specification (Rev. 4.0), if all parameter pages have invalid
> > CRC values, the bit-wise majority may be used to recover the contents
> > of the parameter pages from the parameter page copies present.
> >
> > Signed-off-by: Jane Wan 
> > ---
> > v6: support the cases that srcbufs are not contiguous
> > v5: make the bit-wise majority functon generic
> > v4: move the bit-wise majority code in a separate function
> > v3: fix warning message detected by kbuild test robot
> > v2: rebase the changes on top of v4.17-rc1
> >
> >  drivers/mtd/nand/raw/nand_base.c |   52
> ++
> >  1 file changed, 47 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/nand_base.c
> > b/drivers/mtd/nand/raw/nand_base.c
> > index 72f3a89..acf905c 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -5087,6 +5087,35 @@ static int
> > nand_flash_detect_ext_param_page(struct nand_chip *chip,  }
> >
> >  /*
> > + * Recover data with bit-wise majority  */ static void
> > +nand_bit_wise_majority(const void **srcbufs,
> > +  unsigned int nsrcbufs,
> > +  void *dstbuf,
> > +  unsigned int bufsize)
> > +{
> > +   int i, j, k;
> > +
> > +   for (i = 0; i < bufsize; i++) {
> > +   u8 cnt, val;
> > +
> > +   val = 0;
> > +   for (j = 0; j < 8; j++) {
> > +   cnt = 0;
> > +   for (k = 0; k < nsrcbufs; k++) {
> > +   const u8 *srcbuf = srcbufs[k];
> > +
> > +   if (srcbuf[i] & BIT(j))
> > +   cnt++;
> > +   }
> > +   if (cnt > nsrcbufs / 2)
> > +   val |= BIT(j);
> > +   }
> > +   ((u8 *)dstbuf)[i] = val;
> > +   }
> > +}
> > +
> > +/*
> >   * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 
> > otherwise.
> >   */
> >  static int nand_flash_detect_onfi(struct nand_chip *chip) @@ -5102,7
> > +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
> > return 0;
> >
> > /* ONFI chip: allocate a buffer to hold its parameter page */
> > -   p = kzalloc(sizeof(*p), GFP_KERNEL);
> > +   p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
> > if (!p)
> > return -ENOMEM;
> >
> > @@ -5113,21 +5142,34 @@ static int nand_flash_detect_onfi(struct
> nand_chip *chip)
> > }
> >
> > for (i = 0; i < 3; i++) {
> > -   ret = nand_read_data_op(chip, p, sizeof(*p), true);
> > +   ret = nand_read_data_op(chip, [i], sizeof(*p), true);
> > if (ret) {
> > ret = 0;
> > goto free_onfi_param_page;
> > }
> >
> > -   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
> > +   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)[i], 254) ==
> > le16_to_cpu(p->crc)) {
> > +   if (i)
> > +   memcpy(p, [i], sizeof(*p));
> > break;
> > }
> > }
> >
> > if (i == 3) {
> > -   pr_err("Could not find valid ONFI parameter page; aborting\n");
> > -   goto free_onfi_param_page;
> > +   const void *srcbufs[3] = {p, p + 1, p + 2};
> > +
> > +   pr_err("Could not find valid ONFI parameter page\n");
> 
> Maybe pr_warn() here
> 
> > +   pr_info("Recover ONFI params with bit-wise majority\n");
> 
> and maybe you can pack the 2 messages:
> 
>   pr_warn("Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it");

[Jane] Changed as suggested.

> 
> > +
> > +   nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
> > +  sizeof(*p));
> > +
> > +   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
> > +   le16_to_cpu(p->crc)) {
> > +   pr_err("ONFI parameter recovery failed, aborting\n");
> > +   goto free_onfi_param_page;
> > +   }
> > }
> >
> >   

RE: [PATCH v6] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

2018-05-12 Thread Wan, Jane (Nokia - US/Sunnyvale)
Hi Boris,

I've sent v7 of the patch.

Thanks.
Jane

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Saturday, May 12, 2018 1:21 AM
> To: Wan, Jane (Nokia - US/Sunnyvale) 
> Cc: miquel.ray...@bootlin.com; dw...@infradead.org;
> computersforpe...@gmail.com; rich...@nod.at; marek.va...@gmail.com;
> yamada.masah...@socionext.com; prabhakar.kushw...@nxp.com;
> shawn...@kernel.org; jagdish.ged...@nxp.com;
> shreeya.patel23...@gmail.com; linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Bos, Ties (Nokia - US/Sunnyvale) 
> Subject: Re: [PATCH v6] mtd: rawnand: use bit-wise majority to recover the
> contents of ONFI parameter
> 
> On Thu, 10 May 2018 14:28:37 -0700
> Jane Wan  wrote:
> 
> > Per ONFI specification (Rev. 4.0), if all parameter pages have invalid
> > CRC values, the bit-wise majority may be used to recover the contents
> > of the parameter pages from the parameter page copies present.
> >
> > Signed-off-by: Jane Wan 
> > ---
> > v6: support the cases that srcbufs are not contiguous
> > v5: make the bit-wise majority functon generic
> > v4: move the bit-wise majority code in a separate function
> > v3: fix warning message detected by kbuild test robot
> > v2: rebase the changes on top of v4.17-rc1
> >
> >  drivers/mtd/nand/raw/nand_base.c |   52
> ++
> >  1 file changed, 47 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/nand_base.c
> > b/drivers/mtd/nand/raw/nand_base.c
> > index 72f3a89..acf905c 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -5087,6 +5087,35 @@ static int
> > nand_flash_detect_ext_param_page(struct nand_chip *chip,  }
> >
> >  /*
> > + * Recover data with bit-wise majority  */ static void
> > +nand_bit_wise_majority(const void **srcbufs,
> > +  unsigned int nsrcbufs,
> > +  void *dstbuf,
> > +  unsigned int bufsize)
> > +{
> > +   int i, j, k;
> > +
> > +   for (i = 0; i < bufsize; i++) {
> > +   u8 cnt, val;
> > +
> > +   val = 0;
> > +   for (j = 0; j < 8; j++) {
> > +   cnt = 0;
> > +   for (k = 0; k < nsrcbufs; k++) {
> > +   const u8 *srcbuf = srcbufs[k];
> > +
> > +   if (srcbuf[i] & BIT(j))
> > +   cnt++;
> > +   }
> > +   if (cnt > nsrcbufs / 2)
> > +   val |= BIT(j);
> > +   }
> > +   ((u8 *)dstbuf)[i] = val;
> > +   }
> > +}
> > +
> > +/*
> >   * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 
> > otherwise.
> >   */
> >  static int nand_flash_detect_onfi(struct nand_chip *chip) @@ -5102,7
> > +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
> > return 0;
> >
> > /* ONFI chip: allocate a buffer to hold its parameter page */
> > -   p = kzalloc(sizeof(*p), GFP_KERNEL);
> > +   p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
> > if (!p)
> > return -ENOMEM;
> >
> > @@ -5113,21 +5142,34 @@ static int nand_flash_detect_onfi(struct
> nand_chip *chip)
> > }
> >
> > for (i = 0; i < 3; i++) {
> > -   ret = nand_read_data_op(chip, p, sizeof(*p), true);
> > +   ret = nand_read_data_op(chip, [i], sizeof(*p), true);
> > if (ret) {
> > ret = 0;
> > goto free_onfi_param_page;
> > }
> >
> > -   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
> > +   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)[i], 254) ==
> > le16_to_cpu(p->crc)) {
> > +   if (i)
> > +   memcpy(p, [i], sizeof(*p));
> > break;
> > }
> > }
> >
> > if (i == 3) {
> > -   pr_err("Could not find valid ONFI parameter page; aborting\n");
> > -   goto free_onfi_param_page;
> > +   const void *srcbufs[3] = {p, p + 1, p + 2};
> > +
> > +   pr_err("Could not find valid ONFI parameter page\n");
> 
> Maybe pr_warn() here
> 
> > +   pr_info("Recover ONFI params with bit-wise majority\n");
> 
> and maybe you can pack the 2 messages:
> 
>   pr_warn("Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it");

[Jane] Changed as suggested.

> 
> > +
> > +   nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
> > +  sizeof(*p));
> > +
> > +   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
> > +   le16_to_cpu(p->crc)) {
> > +   pr_err("ONFI parameter recovery failed, aborting\n");
> > +   goto free_onfi_param_page;
> > +   }
> > }
> >
> > /* Check version */



[PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

2018-05-12 Thread Wan, Jane (Nokia - US/Sunnyvale)
Per ONFI specification (Rev. 4.0), if all parameter pages have invalid CRC 
values, the bit-wise majority may be used to recover the contents of the 
parameter pages from the parameter page copies present.

Signed-off-by: Jane Wan 
---
v7: change debug print messages
v6: support the cases that srcbufs are not contiguous
v5: make the bit-wise majority functon generic
v4: move the bit-wise majority code in a separate function
v3: fix warning message detected by kbuild test robot
v2: rebase the changes on top of v4.17-rc1
 
drivers/mtd/nand/raw/nand_base.c |   50 ++
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..b43b784 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5087,6 +5087,35 @@ static int nand_flash_detect_ext_param_page(struct 
nand_chip *chip,
 }
 
 /*
+ * Recover data with bit-wise majority
+ */
+static void nand_bit_wise_majority(const void **srcbufs,
+  unsigned int nsrcbufs,
+  void *dstbuf,
+  unsigned int bufsize)
+{
+   int i, j, k;
+
+   for (i = 0; i < bufsize; i++) {
+   u8 cnt, val;
+
+   val = 0;
+   for (j = 0; j < 8; j++) {
+   cnt = 0;
+   for (k = 0; k < nsrcbufs; k++) {
+   const u8 *srcbuf = srcbufs[k];
+
+   if (srcbuf[i] & BIT(j))
+   cnt++;
+   }
+   if (cnt > nsrcbufs / 2)
+   val |= BIT(j);
+   }
+   ((u8 *)dstbuf)[i] = val;
+   }
+}
+
+/*
  * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
  */
 static int nand_flash_detect_onfi(struct nand_chip *chip)
@@ -5102,7 +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
return 0;
 
/* ONFI chip: allocate a buffer to hold its parameter page */
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
+   p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
if (!p)
return -ENOMEM;
 
@@ -5113,21 +5142,32 @@ static int nand_flash_detect_onfi(struct nand_chip 
*chip)
}
 
for (i = 0; i < 3; i++) {
-   ret = nand_read_data_op(chip, p, sizeof(*p), true);
+   ret = nand_read_data_op(chip, [i], sizeof(*p), true);
if (ret) {
ret = 0;
goto free_onfi_param_page;
}
 
-   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)[i], 254) ==
le16_to_cpu(p->crc)) {
+   if (i)
+   memcpy(p, [i], sizeof(*p));
break;
}
}
 
if (i == 3) {
-   pr_err("Could not find valid ONFI parameter page; aborting\n");
-   goto free_onfi_param_page;
+   const void *srcbufs[3] = {p, p + 1, p + 2};
+
+   pr_warn("Could not find a valid ONFI parameter page, trying 
bit-wise majority to recover it\n");
+   nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
+  sizeof(*p));
+
+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
+   le16_to_cpu(p->crc)) {
+   pr_err("ONFI parameter recovery failed, aborting\n");
+   goto free_onfi_param_page;
+   }
}
 
/* Check version */
-- 
1.7.9.5


[PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

2018-05-12 Thread Wan, Jane (Nokia - US/Sunnyvale)
Per ONFI specification (Rev. 4.0), if all parameter pages have invalid CRC 
values, the bit-wise majority may be used to recover the contents of the 
parameter pages from the parameter page copies present.

Signed-off-by: Jane Wan 
---
v7: change debug print messages
v6: support the cases that srcbufs are not contiguous
v5: make the bit-wise majority functon generic
v4: move the bit-wise majority code in a separate function
v3: fix warning message detected by kbuild test robot
v2: rebase the changes on top of v4.17-rc1
 
drivers/mtd/nand/raw/nand_base.c |   50 ++
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..b43b784 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5087,6 +5087,35 @@ static int nand_flash_detect_ext_param_page(struct 
nand_chip *chip,
 }
 
 /*
+ * Recover data with bit-wise majority
+ */
+static void nand_bit_wise_majority(const void **srcbufs,
+  unsigned int nsrcbufs,
+  void *dstbuf,
+  unsigned int bufsize)
+{
+   int i, j, k;
+
+   for (i = 0; i < bufsize; i++) {
+   u8 cnt, val;
+
+   val = 0;
+   for (j = 0; j < 8; j++) {
+   cnt = 0;
+   for (k = 0; k < nsrcbufs; k++) {
+   const u8 *srcbuf = srcbufs[k];
+
+   if (srcbuf[i] & BIT(j))
+   cnt++;
+   }
+   if (cnt > nsrcbufs / 2)
+   val |= BIT(j);
+   }
+   ((u8 *)dstbuf)[i] = val;
+   }
+}
+
+/*
  * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
  */
 static int nand_flash_detect_onfi(struct nand_chip *chip)
@@ -5102,7 +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
return 0;
 
/* ONFI chip: allocate a buffer to hold its parameter page */
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
+   p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
if (!p)
return -ENOMEM;
 
@@ -5113,21 +5142,32 @@ static int nand_flash_detect_onfi(struct nand_chip 
*chip)
}
 
for (i = 0; i < 3; i++) {
-   ret = nand_read_data_op(chip, p, sizeof(*p), true);
+   ret = nand_read_data_op(chip, [i], sizeof(*p), true);
if (ret) {
ret = 0;
goto free_onfi_param_page;
}
 
-   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)[i], 254) ==
le16_to_cpu(p->crc)) {
+   if (i)
+   memcpy(p, [i], sizeof(*p));
break;
}
}
 
if (i == 3) {
-   pr_err("Could not find valid ONFI parameter page; aborting\n");
-   goto free_onfi_param_page;
+   const void *srcbufs[3] = {p, p + 1, p + 2};
+
+   pr_warn("Could not find a valid ONFI parameter page, trying 
bit-wise majority to recover it\n");
+   nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
+  sizeof(*p));
+
+   if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
+   le16_to_cpu(p->crc)) {
+   pr_err("ONFI parameter recovery failed, aborting\n");
+   goto free_onfi_param_page;
+   }
}
 
/* Check version */
-- 
1.7.9.5


Re: BUG: workqueue lockup (2)

2018-05-12 Thread Eric Biggers
Hi Tetsuo,

On Sun, May 13, 2018 at 11:06:17AM +0900, Tetsuo Handa wrote:
> Eric Biggers wrote:
> > The bug that this reproducer reproduces was fixed a while ago by commit
> > 966031f340185e, so I'm marking this bug report fixed by it:
> > 
> > #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka 
> > FIONREAD)
> 
> Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs ICANON interaction with
> TIOCINQ (aka FIONREAD)") is "Wed Dec 20 17:57:06 2017 -0800" but the last
> occurrence on linux.git (commit 008464a9360e31b1 ("Merge branch 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid")) is only a few days 
> ago
> ("Wed May 9 10:49:52 2018 -1000").
> 
> > 
> > Note that the error message was not always "BUG: workqueue lockup"; it was 
> > also
> > sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".
> > 
> > syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it 
> > must
> > be for other reasons.  None has a reproducer currently.
> 
> The last occurrence on linux.git is considered as a duplicate of
> 
>   [upstream] INFO: rcu detected stall in n_tty_receive_char_special
>   
> https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
> 
> which we already have a reproducer at
> https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/YCVPocx3AgAJ
> and debug output is available at
> https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/TxQ7WS5ZAwAJ .
> 
> We are currently waiting for comments from Peter Hurley who added that code.
> 

Actually I did verify that the C reproducer is fixed by the commit I said, and I
also simplified the reproducer and turned it into an LTP test
(http://lists.linux.it/pipermail/ltp/2018-May/008071.html).  Like I said, syzbot
is still occasionally hitting the same "BUG: workqueue lockup" error, but
apparently for other reasons.  The one on 008464a9360e31b even looks like it's
in the TTY layer too, and it very well could be a very similar bug, but based on
what I observed it's not the same bug that syzbot reproduced on f3b5ad89de16f5d.
Generally it's best to close syzbot bug reports once the original cause is
fixed, so that syzbot can continue to report other bugs with the same signature.
Otherwise they sit on the syzbot dashboard where few people are looking at them.
Though of course, if you are up to it, you're certainly free to look into any of
the crashes already there even before a new bug report gets created.

Note also that a "workqueue lockup" can be caused by almost anything in the
kernel, I think.  This one for example is probably in the sound subsystem:
https://syzkaller.appspot.com/text?tag=CrashReport=1767232b80

Thanks!

Eric


Re: BUG: workqueue lockup (2)

2018-05-12 Thread Eric Biggers
Hi Tetsuo,

On Sun, May 13, 2018 at 11:06:17AM +0900, Tetsuo Handa wrote:
> Eric Biggers wrote:
> > The bug that this reproducer reproduces was fixed a while ago by commit
> > 966031f340185e, so I'm marking this bug report fixed by it:
> > 
> > #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka 
> > FIONREAD)
> 
> Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs ICANON interaction with
> TIOCINQ (aka FIONREAD)") is "Wed Dec 20 17:57:06 2017 -0800" but the last
> occurrence on linux.git (commit 008464a9360e31b1 ("Merge branch 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid")) is only a few days 
> ago
> ("Wed May 9 10:49:52 2018 -1000").
> 
> > 
> > Note that the error message was not always "BUG: workqueue lockup"; it was 
> > also
> > sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".
> > 
> > syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it 
> > must
> > be for other reasons.  None has a reproducer currently.
> 
> The last occurrence on linux.git is considered as a duplicate of
> 
>   [upstream] INFO: rcu detected stall in n_tty_receive_char_special
>   
> https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
> 
> which we already have a reproducer at
> https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/YCVPocx3AgAJ
> and debug output is available at
> https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/TxQ7WS5ZAwAJ .
> 
> We are currently waiting for comments from Peter Hurley who added that code.
> 

Actually I did verify that the C reproducer is fixed by the commit I said, and I
also simplified the reproducer and turned it into an LTP test
(http://lists.linux.it/pipermail/ltp/2018-May/008071.html).  Like I said, syzbot
is still occasionally hitting the same "BUG: workqueue lockup" error, but
apparently for other reasons.  The one on 008464a9360e31b even looks like it's
in the TTY layer too, and it very well could be a very similar bug, but based on
what I observed it's not the same bug that syzbot reproduced on f3b5ad89de16f5d.
Generally it's best to close syzbot bug reports once the original cause is
fixed, so that syzbot can continue to report other bugs with the same signature.
Otherwise they sit on the syzbot dashboard where few people are looking at them.
Though of course, if you are up to it, you're certainly free to look into any of
the crashes already there even before a new bug report gets created.

Note also that a "workqueue lockup" can be caused by almost anything in the
kernel, I think.  This one for example is probably in the sound subsystem:
https://syzkaller.appspot.com/text?tag=CrashReport=1767232b80

Thanks!

Eric


[PATCH 2/2] KVM: X86: Fix loss of CR3_PCID_INVD bit when guest writes CR3

2018-05-12 Thread Wanpeng Li
From: Wanpeng Li 

SDM volume 3, section 4.10.4:

* MOV to CR3. The behavior of the instruction depends on the value of CR4.PCIDE:
— If CR4.PCIDE = 1 and bit 63 of the instruction’s source operand is 1, the 
  instruction is not required to invalidate any TLB entries or entries in 
  paging-structure caches.

The CR3_PCID_INVD bit should not be removed if CR4.PCIDE = 1 when guest writes 
CR3, this patch fixes it.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Junaid Shahid 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9a90668..438f140 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -849,11 +849,13 @@ EXPORT_SYMBOL_GPL(kvm_set_cr4);
 
 int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
 {
+   unsigned long cr3_check = cr3;
+
 #ifdef CONFIG_X86_64
bool pcid_enabled = kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE);
 
if (pcid_enabled)
-   cr3 &= ~CR3_PCID_INVD;
+   cr3_check &= ~CR3_PCID_INVD;
 #endif
 
if (cr3 == kvm_read_cr3(vcpu) && !pdptrs_changed(vcpu)) {
@@ -863,7 +865,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
}
 
if (is_long_mode(vcpu) &&
-   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
+   (cr3_check & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
return 1;
else if (is_pae(vcpu) && is_paging(vcpu) &&
   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
-- 
2.7.4



[PATCH 2/2] KVM: X86: Fix loss of CR3_PCID_INVD bit when guest writes CR3

2018-05-12 Thread Wanpeng Li
From: Wanpeng Li 

SDM volume 3, section 4.10.4:

* MOV to CR3. The behavior of the instruction depends on the value of CR4.PCIDE:
— If CR4.PCIDE = 1 and bit 63 of the instruction’s source operand is 1, the 
  instruction is not required to invalidate any TLB entries or entries in 
  paging-structure caches.

The CR3_PCID_INVD bit should not be removed if CR4.PCIDE = 1 when guest writes 
CR3, this patch fixes it.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Junaid Shahid 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9a90668..438f140 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -849,11 +849,13 @@ EXPORT_SYMBOL_GPL(kvm_set_cr4);
 
 int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
 {
+   unsigned long cr3_check = cr3;
+
 #ifdef CONFIG_X86_64
bool pcid_enabled = kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE);
 
if (pcid_enabled)
-   cr3 &= ~CR3_PCID_INVD;
+   cr3_check &= ~CR3_PCID_INVD;
 #endif
 
if (cr3 == kvm_read_cr3(vcpu) && !pdptrs_changed(vcpu)) {
@@ -863,7 +865,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
}
 
if (is_long_mode(vcpu) &&
-   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
+   (cr3_check & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
return 1;
else if (is_pae(vcpu) && is_paging(vcpu) &&
   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
-- 
2.7.4



[PATCH 1/2] KVM: X86: Fix CR3 reserve bits

2018-05-12 Thread Wanpeng Li
From: Wanpeng Li 

MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4. 
It should be checked when PCIDE bit is not set, however commit 
'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on 
its physical address width")' removes the bit 63 checking 
unconditionally. This patch fixes it by checking bit 63 of CR3 
when PCIDE bit is not set in CR4.

Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its 
physical address width)
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Junaid Shahid 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/emulate.c | 4 +++-
 arch/x86/kvm/x86.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index b3705ae..b21f427 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4189,7 +4189,9 @@ static int check_cr_write(struct x86_emulate_ctxt *ctxt)
maxphyaddr = eax & 0xff;
else
maxphyaddr = 36;
-   rsvd = rsvd_bits(maxphyaddr, 62);
+   if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
+   new_val &= ~CR3_PCID_INVD;
+   rsvd = rsvd_bits(maxphyaddr, 63);
}
 
if (new_val & rsvd)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 87e4805..9a90668 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -863,7 +863,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
}
 
if (is_long_mode(vcpu) &&
-   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 62)))
+   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
return 1;
else if (is_pae(vcpu) && is_paging(vcpu) &&
   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
-- 
2.7.4



[PATCH 1/2] KVM: X86: Fix CR3 reserve bits

2018-05-12 Thread Wanpeng Li
From: Wanpeng Li 

MSB of CR3 is a reserved bit if the PCIDE bit is not set in CR4. 
It should be checked when PCIDE bit is not set, however commit 
'd1cd3ce900441 ("KVM: MMU: check guest CR3 reserved bits based on 
its physical address width")' removes the bit 63 checking 
unconditionally. This patch fixes it by checking bit 63 of CR3 
when PCIDE bit is not set in CR4.

Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its 
physical address width)
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Junaid Shahid 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/emulate.c | 4 +++-
 arch/x86/kvm/x86.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index b3705ae..b21f427 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4189,7 +4189,9 @@ static int check_cr_write(struct x86_emulate_ctxt *ctxt)
maxphyaddr = eax & 0xff;
else
maxphyaddr = 36;
-   rsvd = rsvd_bits(maxphyaddr, 62);
+   if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PCIDE)
+   new_val &= ~CR3_PCID_INVD;
+   rsvd = rsvd_bits(maxphyaddr, 63);
}
 
if (new_val & rsvd)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 87e4805..9a90668 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -863,7 +863,7 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
}
 
if (is_long_mode(vcpu) &&
-   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 62)))
+   (cr3 & rsvd_bits(cpuid_maxphyaddr(vcpu), 63)))
return 1;
else if (is_pae(vcpu) && is_paging(vcpu) &&
   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
-- 
2.7.4



[PATCH] drivers: zorro: zorro.c: Added a blank line after declarations.

2018-05-12 Thread Jacob Enders
From: Jacob 

Fixed a coding style issue.

Signed-off-by: Jacob Enders 
---
 drivers/zorro/zorro.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/zorro/zorro.c b/drivers/zorro/zorro.c
index 47728477297e..67fa900572a9 100644
--- a/drivers/zorro/zorro.c
+++ b/drivers/zorro/zorro.c
@@ -101,6 +101,7 @@ static void __init mark_region(unsigned long start, 
unsigned long end,
end = end > Z2RAM_END ? Z2RAM_SIZE : end-Z2RAM_START;
while (start < end) {
u32 chunk = start>>Z2RAM_CHUNKSHIFT;
+
if (flag)
set_bit(chunk, zorro_unused_z2ram);
else
@@ -117,6 +118,7 @@ static struct resource __init *zorro_find_parent_resource(
 
for (i = 0; i < bridge->num_resources; i++) {
struct resource *r = >resource[i];
+
if (zorro_resource_start(z) >= r->start &&
zorro_resource_end(z) <= r->end)
return r;
@@ -168,6 +170,7 @@ static int __init amiga_zorro_probe(struct platform_device 
*pdev)
if (z->id == ZORRO_PROD_GVP_EPC_BASE) {
/* GVP quirk */
unsigned long magic = zi->boardaddr + 0x8000;
+
z->id |= *(u16 *)ZTWO_VADDR(magic) & GVP_PRODMASK;
}
z->slotaddr = zi->slotaddr;
-- 
2.11.0



[PATCH] drivers: zorro: zorro.c: Added a blank line after declarations.

2018-05-12 Thread Jacob Enders
From: Jacob 

Fixed a coding style issue.

Signed-off-by: Jacob Enders 
---
 drivers/zorro/zorro.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/zorro/zorro.c b/drivers/zorro/zorro.c
index 47728477297e..67fa900572a9 100644
--- a/drivers/zorro/zorro.c
+++ b/drivers/zorro/zorro.c
@@ -101,6 +101,7 @@ static void __init mark_region(unsigned long start, 
unsigned long end,
end = end > Z2RAM_END ? Z2RAM_SIZE : end-Z2RAM_START;
while (start < end) {
u32 chunk = start>>Z2RAM_CHUNKSHIFT;
+
if (flag)
set_bit(chunk, zorro_unused_z2ram);
else
@@ -117,6 +118,7 @@ static struct resource __init *zorro_find_parent_resource(
 
for (i = 0; i < bridge->num_resources; i++) {
struct resource *r = >resource[i];
+
if (zorro_resource_start(z) >= r->start &&
zorro_resource_end(z) <= r->end)
return r;
@@ -168,6 +170,7 @@ static int __init amiga_zorro_probe(struct platform_device 
*pdev)
if (z->id == ZORRO_PROD_GVP_EPC_BASE) {
/* GVP quirk */
unsigned long magic = zi->boardaddr + 0x8000;
+
z->id |= *(u16 *)ZTWO_VADDR(magic) & GVP_PRODMASK;
}
z->slotaddr = zi->slotaddr;
-- 
2.11.0



Re: [PATCH v3] mm: Change return type to vm_fault_t

2018-05-12 Thread Dan Williams
On Sat, May 12, 2018 at 12:14 PM, Souptick Joarder  wrote:
>>> It'd be nicer to realign the 2nd and 3rd arguments
>>> on the subsequent lines.
>
>>>
>>>   vm_fault_t (*fault)(const struct vm_special_mapping *sm,
>>>   struct vm_area_struct *vma,
>>>   struct vm_fault *vmf);
>>>
>>
>
>> It'd be nicer if people didn't try to line up arguments at all and
>> just indented by an extra two tabs when they had to break a logical
>> line due to the 80-column limit.
>
> Matthew, there are two different opinions. Which one to take ?

Unfortunately this is one of those "maintainer's choice" preferences
that drives new contributors crazy. Just go with the two tabs like
Matthew said and be done.



Re: [PATCH v3] mm: Change return type to vm_fault_t

2018-05-12 Thread Dan Williams
On Sat, May 12, 2018 at 12:14 PM, Souptick Joarder  wrote:
>>> It'd be nicer to realign the 2nd and 3rd arguments
>>> on the subsequent lines.
>
>>>
>>>   vm_fault_t (*fault)(const struct vm_special_mapping *sm,
>>>   struct vm_area_struct *vma,
>>>   struct vm_fault *vmf);
>>>
>>
>
>> It'd be nicer if people didn't try to line up arguments at all and
>> just indented by an extra two tabs when they had to break a logical
>> line due to the 80-column limit.
>
> Matthew, there are two different opinions. Which one to take ?

Unfortunately this is one of those "maintainer's choice" preferences
that drives new contributors crazy. Just go with the two tabs like
Matthew said and be done.



Re: [RFC] net: Add new LoRaWAN subsystem

2018-05-12 Thread Jian-Hong Pan
Hi Jiri and Marcel,

2018-05-11 23:39 GMT+08:00 Marcel Holtmann :
> Hi Jian-Hong,
>
>> A Low-Power Wide-Area Network (LPWAN) is a type of wireless
>> telecommunication wide area network designed to allow long range
>> communications at a low bit rate among things (connected objects), such
>> as sensors operated on a battery.  It can be used widely in IoT area.
>> LoRaWAN, which is one kind of implementation of LPWAN, is a medium
>> access control (MAC) layer protocol for managing communication between
>> LPWAN gateways and end-node devices, maintained by the LoRa Alliance.
>> LoRaWAN™ Specification could be downloaded at:
>> https://lora-alliance.org/lorawan-for-developers
>>
>> However, LoRaWAN is not implemented in Linux kernel right now, so I am
>> trying to develop it.  Here is my repository:
>> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN
>>
>> Because it is a kind of network, the ideal usage in an user space
>> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with
>> other socket APIs.  Therefore, the definitions like AF_LORAWAN,
>> PF_LORAWAN ..., must be listed in the header files of glibc.
>> For the driver in kernel space, the definitions also must be listed in
>> the corresponding Linux socket header files.
>> Especially, both are for the testing programs.
>>
>> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now".
>> Could or should we add the definitions into corresponding kernel header
>> files now, if LoRaWAN will be accepted as a subsystem in Linux?
>
> when you submit your LoRaWAN subsystem to netdev for review, include a patch 
> that adds these new address family definitions. Just pick the next one 
> available. There will be no pre-allocation of numbers until your work has 
> been accepted upstream. Meaning, that the number might change if other 
> address families get merged before yours. So you have to keep updating. glibc 
> will eventually follow the number assigned by the kernel.

Thanks for your guidance.  I will follow the steps.

Thanks a lot,

Jian-Hong Pan

> Regards
>
> Marcel
>


Re: [RFC] net: Add new LoRaWAN subsystem

2018-05-12 Thread Jian-Hong Pan
Hi Jiri and Marcel,

2018-05-11 23:39 GMT+08:00 Marcel Holtmann :
> Hi Jian-Hong,
>
>> A Low-Power Wide-Area Network (LPWAN) is a type of wireless
>> telecommunication wide area network designed to allow long range
>> communications at a low bit rate among things (connected objects), such
>> as sensors operated on a battery.  It can be used widely in IoT area.
>> LoRaWAN, which is one kind of implementation of LPWAN, is a medium
>> access control (MAC) layer protocol for managing communication between
>> LPWAN gateways and end-node devices, maintained by the LoRa Alliance.
>> LoRaWAN™ Specification could be downloaded at:
>> https://lora-alliance.org/lorawan-for-developers
>>
>> However, LoRaWAN is not implemented in Linux kernel right now, so I am
>> trying to develop it.  Here is my repository:
>> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN
>>
>> Because it is a kind of network, the ideal usage in an user space
>> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with
>> other socket APIs.  Therefore, the definitions like AF_LORAWAN,
>> PF_LORAWAN ..., must be listed in the header files of glibc.
>> For the driver in kernel space, the definitions also must be listed in
>> the corresponding Linux socket header files.
>> Especially, both are for the testing programs.
>>
>> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now".
>> Could or should we add the definitions into corresponding kernel header
>> files now, if LoRaWAN will be accepted as a subsystem in Linux?
>
> when you submit your LoRaWAN subsystem to netdev for review, include a patch 
> that adds these new address family definitions. Just pick the next one 
> available. There will be no pre-allocation of numbers until your work has 
> been accepted upstream. Meaning, that the number might change if other 
> address families get merged before yours. So you have to keep updating. glibc 
> will eventually follow the number assigned by the kernel.

Thanks for your guidance.  I will follow the steps.

Thanks a lot,

Jian-Hong Pan

> Regards
>
> Marcel
>


Applied "ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"" to the asoc tree

2018-05-12 Thread Mark Brown
The patch

   ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 2b8eae795580ca13ce6f035cac599f6a85c81bbf Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 11 May 2018 14:28:18 +0100
Subject: [PATCH] ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"

Trivial fix to spelling mistake in dev_err message text

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/hisilicon/hi6210-i2s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/hisilicon/hi6210-i2s.c b/sound/soc/hisilicon/hi6210-i2s.c
index 07a57209e055..53344a3b7a60 100644
--- a/sound/soc/hisilicon/hi6210-i2s.c
+++ b/sound/soc/hisilicon/hi6210-i2s.c
@@ -498,7 +498,7 @@ static int hi6210_i2s_trigger(struct snd_pcm_substream 
*substream, int cmd,
hi6210_i2s_txctrl(cpu_dai, 0);
break;
default:
-   dev_err(cpu_dai->dev, "uknown cmd\n");
+   dev_err(cpu_dai->dev, "unknown cmd\n");
return -EINVAL;
}
return 0;
-- 
2.17.0



Applied "ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"" to the asoc tree

2018-05-12 Thread Mark Brown
The patch

   ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 2b8eae795580ca13ce6f035cac599f6a85c81bbf Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 11 May 2018 14:28:18 +0100
Subject: [PATCH] ASoC: hisilicon: fix spelling mistake: "uknown" -> "unknown"

Trivial fix to spelling mistake in dev_err message text

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/hisilicon/hi6210-i2s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/hisilicon/hi6210-i2s.c b/sound/soc/hisilicon/hi6210-i2s.c
index 07a57209e055..53344a3b7a60 100644
--- a/sound/soc/hisilicon/hi6210-i2s.c
+++ b/sound/soc/hisilicon/hi6210-i2s.c
@@ -498,7 +498,7 @@ static int hi6210_i2s_trigger(struct snd_pcm_substream 
*substream, int cmd,
hi6210_i2s_txctrl(cpu_dai, 0);
break;
default:
-   dev_err(cpu_dai->dev, "uknown cmd\n");
+   dev_err(cpu_dai->dev, "unknown cmd\n");
return -EINVAL;
}
return 0;
-- 
2.17.0



Re: [PATCH/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

2018-05-12 Thread Mark Brown
On Thu, Apr 19, 2018 at 10:13:56PM +0200, Pavel Machek wrote:
> On Wed 2018-04-18 15:00:41, Mark Brown wrote:

> > Please don't send content free pings and please allow a reasonable time
> > for review.  People get busy, go on holiday, attend conferences and so 

> If I follow the logs right, there was one month before ping. That
> seems pretty reasonable time.

Right, but the content free bit still applies (as does the bit about
resending which is the main actionable bit for people).  The two go hand
in hand so often that I just wrote the one thing for both.

> > Sending content free pings adds to the mail volume (if they are seen at
> > all) which is often the problem and since they can't be reviewed

> Yep, and sending content free complains about pings also adds to the
> main volume :-(.

They're not content free.  They're telling people that if it looks like
their patch has fallen through the cracks then they need to resend their
patch and why, without that people (especially newer contributors) might
not be clear about what to do.

> Anyway, last time I sent you a patch... you _had_ time to complain
> that I'm pinging too often, but you apparently did not have time to
> look at the patch. That patch would have been in time for v4.16-rc1
> IIRC.

If that's the tlv320dac33 patch you sent a followup in the middle of the
thread with what you said was a current version or something but never
actually sent that version as a regular patch submission.  You'd also
managed to not have the ASoC on the front of the patch which pushes it
to the bottom of the review queue, it won't turn up when I look in in my
inbox for ASoC patches.

Now, I for whatever reason didn't explicitly tell you I was expecting a
resend so you didn't explicitly know that this was what was going on
which is a good example of why letting people know what's going on is a
good idea.


signature.asc
Description: PGP signature


Re: [PATCH/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

2018-05-12 Thread Mark Brown
On Thu, Apr 19, 2018 at 10:13:56PM +0200, Pavel Machek wrote:
> On Wed 2018-04-18 15:00:41, Mark Brown wrote:

> > Please don't send content free pings and please allow a reasonable time
> > for review.  People get busy, go on holiday, attend conferences and so 

> If I follow the logs right, there was one month before ping. That
> seems pretty reasonable time.

Right, but the content free bit still applies (as does the bit about
resending which is the main actionable bit for people).  The two go hand
in hand so often that I just wrote the one thing for both.

> > Sending content free pings adds to the mail volume (if they are seen at
> > all) which is often the problem and since they can't be reviewed

> Yep, and sending content free complains about pings also adds to the
> main volume :-(.

They're not content free.  They're telling people that if it looks like
their patch has fallen through the cracks then they need to resend their
patch and why, without that people (especially newer contributors) might
not be clear about what to do.

> Anyway, last time I sent you a patch... you _had_ time to complain
> that I'm pinging too often, but you apparently did not have time to
> look at the patch. That patch would have been in time for v4.16-rc1
> IIRC.

If that's the tlv320dac33 patch you sent a followup in the middle of the
thread with what you said was a current version or something but never
actually sent that version as a regular patch submission.  You'd also
managed to not have the ASoC on the front of the patch which pushes it
to the bottom of the review queue, it won't turn up when I look in in my
inbox for ASoC patches.

Now, I for whatever reason didn't explicitly tell you I was expecting a
resend so you didn't explicitly know that this was what was going on
which is a good example of why letting people know what's going on is a
good idea.


signature.asc
Description: PGP signature


Re: [RFC] regmap: allow volatile register writes with cached only read maps

2018-05-12 Thread Mark Brown
On Fri, May 11, 2018 at 12:29:42PM +0200, Jorge Ramirez-Ortiz wrote:
> On 05/11/2018 04:00 AM, Mark Brown wrote:

> > We don't currently suppress writes except when regmap_update_bits()
> > notices that the modification was a noop.  You probably want to be using
> > regmap_write_bits() here instead of regmap_update_bits(), that will
> > always do the write.

> but isnt that interface at a different level?

It's at the level where we suppress writes - the write suppression isn't
a feature of the caching, it's something that regmap_update_bits() does
if it notices that it won't change anything.  It'll happen even if
there's no cache at all.

> I am not sure if you are asking me to review my patch or just discarding the
> RFC and highlighting that I have a configuration problem.

I don't understand your patch as-is.

> In my use case and what triggered this RFC (config below), an 'amixer set'
> might never reach the driver's .reg_write interface even though the register
> is configured as volatile (to me this is not consistent since volatile_reg
> is being silently ignored).

I'm not seeing any inconsistency there.  Volatility means the register
can't be cached as it might change underneath us, it doesn't have any
impact on writes and it's happening at a lower level.  Like I say if you
absolutely need a write to happen you should be explicitly doing a
write, though if you need a write to happen for a noop control change it
sounds like there's something weird with that control that's possibly a
problem anyway.

> So I dont see where/how your recommendation fits; maybe you could clarify a
> bit more please?

As I've been saying if you explicitly need a write to happen don't use
regmap_update_bits(), do something that guarantees you'll get a write
like regmap_write() or regmap_write_bits().


signature.asc
Description: PGP signature


Re: [RFC] regmap: allow volatile register writes with cached only read maps

2018-05-12 Thread Mark Brown
On Fri, May 11, 2018 at 12:29:42PM +0200, Jorge Ramirez-Ortiz wrote:
> On 05/11/2018 04:00 AM, Mark Brown wrote:

> > We don't currently suppress writes except when regmap_update_bits()
> > notices that the modification was a noop.  You probably want to be using
> > regmap_write_bits() here instead of regmap_update_bits(), that will
> > always do the write.

> but isnt that interface at a different level?

It's at the level where we suppress writes - the write suppression isn't
a feature of the caching, it's something that regmap_update_bits() does
if it notices that it won't change anything.  It'll happen even if
there's no cache at all.

> I am not sure if you are asking me to review my patch or just discarding the
> RFC and highlighting that I have a configuration problem.

I don't understand your patch as-is.

> In my use case and what triggered this RFC (config below), an 'amixer set'
> might never reach the driver's .reg_write interface even though the register
> is configured as volatile (to me this is not consistent since volatile_reg
> is being silently ignored).

I'm not seeing any inconsistency there.  Volatility means the register
can't be cached as it might change underneath us, it doesn't have any
impact on writes and it's happening at a lower level.  Like I say if you
absolutely need a write to happen you should be explicitly doing a
write, though if you need a write to happen for a noop control change it
sounds like there's something weird with that control that's possibly a
problem anyway.

> So I dont see where/how your recommendation fits; maybe you could clarify a
> bit more please?

As I've been saying if you explicitly need a write to happen don't use
regmap_update_bits(), do something that guarantees you'll get a write
like regmap_write() or regmap_write_bits().


signature.asc
Description: PGP signature


Re: general protection fault in kernfs_kill_sb (2)

2018-05-12 Thread Tetsuo Handa
On 2018/05/13 2:01, syzbot wrote:
> Call Trace:
>  __list_del_entry include/linux/list.h:117 [inline]
>  list_del include/linux/list.h:125 [inline]
>  kernfs_kill_sb+0xa0/0x350 fs/kernfs/mount.c:361
>  sysfs_kill_sb+0x22/0x40 fs/sysfs/mount.c:50
>  deactivate_locked_super+0x97/0x100 fs/super.c:316
>  kernfs_mount_ns+0x753/0x8e0 fs/kernfs/mount.c:335
>  sysfs_mount+0xdf/0x200 fs/sysfs/mount.c:36
>  mount_fs+0xae/0x328 fs/super.c:1267
>  vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:1027 [inline]
>  do_new_mount fs/namespace.c:2518 [inline]
>  do_mount+0x564/0x3070 fs/namespace.c:2848
>  ksys_mount+0x12d/0x140 fs/namespace.c:3064
>  __do_sys_mount fs/namespace.c:3078 [inline]
>  __se_sys_mount fs/namespace.c:3075 [inline]
>  __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4426a9
> RSP: 002b:7ffc558bd1b8 EFLAGS: 0246 ORIG_RAX: 00a5
> RAX: ffda RBX:  RCX: 004426a9
> RDX: 20c0 RSI: 2080 RDI: 2040
> RBP: 7ffc558bda60 R08:  R09: 0003
> R10:  R11: 0246 R12: 
> R13: 0004 R14: 1380 R15: 7ffc558bd2f8
> Code: c5 0f 84 cc 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f 84 a5 00 
> 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 5f 
> 49 8b 14 24 48 39 da 0f 85 ba 00 00 00 48 b8
> RIP: __list_del_entry_valid+0x84/0xf3 lib/list_debug.c:51 RSP: 
> 8801aca6f860
> ---[ end trace d148f307a34e229f ]---

This is what I reported at
https://groups.google.com/d/msg/syzkaller-bugs/ISOJlV2I2QM/qHslGMi3AwAJ .

We are currently waiting for comments from Al Viro.


Re: general protection fault in kernfs_kill_sb (2)

2018-05-12 Thread Tetsuo Handa
On 2018/05/13 2:01, syzbot wrote:
> Call Trace:
>  __list_del_entry include/linux/list.h:117 [inline]
>  list_del include/linux/list.h:125 [inline]
>  kernfs_kill_sb+0xa0/0x350 fs/kernfs/mount.c:361
>  sysfs_kill_sb+0x22/0x40 fs/sysfs/mount.c:50
>  deactivate_locked_super+0x97/0x100 fs/super.c:316
>  kernfs_mount_ns+0x753/0x8e0 fs/kernfs/mount.c:335
>  sysfs_mount+0xdf/0x200 fs/sysfs/mount.c:36
>  mount_fs+0xae/0x328 fs/super.c:1267
>  vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:1027 [inline]
>  do_new_mount fs/namespace.c:2518 [inline]
>  do_mount+0x564/0x3070 fs/namespace.c:2848
>  ksys_mount+0x12d/0x140 fs/namespace.c:3064
>  __do_sys_mount fs/namespace.c:3078 [inline]
>  __se_sys_mount fs/namespace.c:3075 [inline]
>  __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4426a9
> RSP: 002b:7ffc558bd1b8 EFLAGS: 0246 ORIG_RAX: 00a5
> RAX: ffda RBX:  RCX: 004426a9
> RDX: 20c0 RSI: 2080 RDI: 2040
> RBP: 7ffc558bda60 R08:  R09: 0003
> R10:  R11: 0246 R12: 
> R13: 0004 R14: 1380 R15: 7ffc558bd2f8
> Code: c5 0f 84 cc 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f 84 a5 00 
> 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 5f 
> 49 8b 14 24 48 39 da 0f 85 ba 00 00 00 48 b8
> RIP: __list_del_entry_valid+0x84/0xf3 lib/list_debug.c:51 RSP: 
> 8801aca6f860
> ---[ end trace d148f307a34e229f ]---

This is what I reported at
https://groups.google.com/d/msg/syzkaller-bugs/ISOJlV2I2QM/qHslGMi3AwAJ .

We are currently waiting for comments from Al Viro.


Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

2018-05-12 Thread Baolin Wang
Hi Jacek and Pavel,

On 13 May 2018 at 04:44, Jacek Anaszewski  wrote:
> Hi Pavel,
>
>
> On 05/12/2018 10:35 AM, Pavel Machek wrote:
>>
>> Hi!
>>
> I disagree here. We already had the same discussion at the occasion
> of the patch [0] and it turned out to be a dead-end [1]. Now we have
> neither the driver nor the generic pattern interface.
>
> We also already have some older LED class drivers that implement custom
> pattern interfaces (e.g. drivers/leds/leds-lm3533.c) and the same
> approach can be applied in this case.


 Please don't. It was mistake to implement custom pattern interfaces
 back then, it is still mistake now.
>>>
>>>
>>> It turned out to be really hard to cover all known pattern generator
>>> implementations with generic interface. Sure, it would be nice to have
>>> one, but the whole discussion around [0] only unveiled the diversity of
>>> parameters to cover. And still new devices appear on the market.
>>>
>>> We would have to propose a set of pattern schemes and allow to
>>> add new ones to it.
>>
>>
>> I believe that what I'm proposing below is close enough to universal.
>>
 If we really need solution now, I'd recommend "pattern" file with

 "   ".

 In this specific case, hardware only supports patterns in this format:

 low_time 0 rise_time 255 high_time 255 fall_time 0

 so driver would simply -EINVAL on anything else.
>>>
>>>
>>> I'm fine with the pattern file, but the pattern format would have
>>> to be defined in the per-driver ABI documentation. It wouldn't much
>>> differ from the custom pattern approach though, unless I'm missing some
>>> gain of having pattern setting in a uniformly named single sysfs file
>>> (with semantics differing from driver to driver).
>>
>>
>> I'm proposing "  ..." sysfs file. It certainly
>> covers this hardware, it would be enough to cover the Qualcomm Pulse
>> generator (IIRC), and it would cover most uses cases of Nokia N900's
>> LED.
>>
>> Yes, we would need to document limitations of each chip. But it should
>> be easily possible to run pattern designed for Spreadtrum on N900,
>> even if it would not work the other way around.
>>
>> (If someone really wants to run complex patterns on simple hardware,
>> we can provide software emulation using same file format. I believe I
>> still have that patch somewhere.)
>
>
> OK, I've revised the discussion under Qualcomm LPG patch set and
> it seems that we have almost ready solution in [0], except the
> pattern_repeat file you mention in [1]. So probably Baolin could
> address your remarks from [1] and add pattern_repeat file to the
> patch that begins thread [0].
>
> [0] https://lkml.org/lkml/2017/11/15/27
> [1] https://lkml.org/lkml/2017/12/8/470

Thanks for your suggestion. So I will remove the sysfs part from the
new driver, then send incremental patches when introducing some common
LED interfaces.

-- 
Baolin.wang
Best Regards


Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

2018-05-12 Thread Baolin Wang
Hi Jacek and Pavel,

On 13 May 2018 at 04:44, Jacek Anaszewski  wrote:
> Hi Pavel,
>
>
> On 05/12/2018 10:35 AM, Pavel Machek wrote:
>>
>> Hi!
>>
> I disagree here. We already had the same discussion at the occasion
> of the patch [0] and it turned out to be a dead-end [1]. Now we have
> neither the driver nor the generic pattern interface.
>
> We also already have some older LED class drivers that implement custom
> pattern interfaces (e.g. drivers/leds/leds-lm3533.c) and the same
> approach can be applied in this case.


 Please don't. It was mistake to implement custom pattern interfaces
 back then, it is still mistake now.
>>>
>>>
>>> It turned out to be really hard to cover all known pattern generator
>>> implementations with generic interface. Sure, it would be nice to have
>>> one, but the whole discussion around [0] only unveiled the diversity of
>>> parameters to cover. And still new devices appear on the market.
>>>
>>> We would have to propose a set of pattern schemes and allow to
>>> add new ones to it.
>>
>>
>> I believe that what I'm proposing below is close enough to universal.
>>
 If we really need solution now, I'd recommend "pattern" file with

 "   ".

 In this specific case, hardware only supports patterns in this format:

 low_time 0 rise_time 255 high_time 255 fall_time 0

 so driver would simply -EINVAL on anything else.
>>>
>>>
>>> I'm fine with the pattern file, but the pattern format would have
>>> to be defined in the per-driver ABI documentation. It wouldn't much
>>> differ from the custom pattern approach though, unless I'm missing some
>>> gain of having pattern setting in a uniformly named single sysfs file
>>> (with semantics differing from driver to driver).
>>
>>
>> I'm proposing "  ..." sysfs file. It certainly
>> covers this hardware, it would be enough to cover the Qualcomm Pulse
>> generator (IIRC), and it would cover most uses cases of Nokia N900's
>> LED.
>>
>> Yes, we would need to document limitations of each chip. But it should
>> be easily possible to run pattern designed for Spreadtrum on N900,
>> even if it would not work the other way around.
>>
>> (If someone really wants to run complex patterns on simple hardware,
>> we can provide software emulation using same file format. I believe I
>> still have that patch somewhere.)
>
>
> OK, I've revised the discussion under Qualcomm LPG patch set and
> it seems that we have almost ready solution in [0], except the
> pattern_repeat file you mention in [1]. So probably Baolin could
> address your remarks from [1] and add pattern_repeat file to the
> patch that begins thread [0].
>
> [0] https://lkml.org/lkml/2017/11/15/27
> [1] https://lkml.org/lkml/2017/12/8/470

Thanks for your suggestion. So I will remove the sysfs part from the
new driver, then send incremental patches when introducing some common
LED interfaces.

-- 
Baolin.wang
Best Regards


Re: BUG: workqueue lockup (2)

2018-05-12 Thread Tetsuo Handa
Eric Biggers wrote:
> The bug that this reproducer reproduces was fixed a while ago by commit
> 966031f340185e, so I'm marking this bug report fixed by it:
> 
> #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs ICANON interaction with
TIOCINQ (aka FIONREAD)") is "Wed Dec 20 17:57:06 2017 -0800" but the last
occurrence on linux.git (commit 008464a9360e31b1 ("Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid")) is only a few days 
ago
("Wed May 9 10:49:52 2018 -1000").

> 
> Note that the error message was not always "BUG: workqueue lockup"; it was 
> also
> sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".
> 
> syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it 
> must
> be for other reasons.  None has a reproducer currently.

The last occurrence on linux.git is considered as a duplicate of

  [upstream] INFO: rcu detected stall in n_tty_receive_char_special
  https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8

which we already have a reproducer at
https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/YCVPocx3AgAJ
and debug output is available at
https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/TxQ7WS5ZAwAJ .

We are currently waiting for comments from Peter Hurley who added that code.


Re: BUG: workqueue lockup (2)

2018-05-12 Thread Tetsuo Handa
Eric Biggers wrote:
> The bug that this reproducer reproduces was fixed a while ago by commit
> 966031f340185e, so I'm marking this bug report fixed by it:
> 
> #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs ICANON interaction with
TIOCINQ (aka FIONREAD)") is "Wed Dec 20 17:57:06 2017 -0800" but the last
occurrence on linux.git (commit 008464a9360e31b1 ("Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid")) is only a few days 
ago
("Wed May 9 10:49:52 2018 -1000").

> 
> Note that the error message was not always "BUG: workqueue lockup"; it was 
> also
> sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".
> 
> syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it 
> must
> be for other reasons.  None has a reproducer currently.

The last occurrence on linux.git is considered as a duplicate of

  [upstream] INFO: rcu detected stall in n_tty_receive_char_special
  https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8

which we already have a reproducer at
https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/YCVPocx3AgAJ
and debug output is available at
https://groups.google.com/d/msg/syzkaller-bugs/O4DbPiJZFBY/TxQ7WS5ZAwAJ .

We are currently waiting for comments from Peter Hurley who added that code.


[PATCH ghak81 RFC V2 0/5] audit: group task params

2018-05-12 Thread Richard Guy Briggs
Group the audit parameters for each task into one structure.
In particular, remove the loginuid and sessionid values and the audit
context pointer from the task structure, replacing them with an audit
task information structure to contain them.  Use access functions to
access audit values.

Note:  Use static allocation of the audit task information structure
initially.  Dynamic allocation was considered and attempted, but isn't
ready yet.  Static allocation has the limitation that future audit task
information structure changes would cause a visible change to the rest
of the kernel, whereas dynamic allocation would mostly hide any future
changes.

The first four access normalization patches could stand alone.

Passes audit-testsuite.

Changelog:
v2
- p2/5: add audit header to init/init_task.c to quiet kbuildbot
- audit_signal_info(): fetch loginuid once
- remove task_struct from audit_context() param list
- remove extra task_struct local vars
- do nothing on request to set audit context when audit is disabled

Richard Guy Briggs (5):
  audit: normalize loginuid read access
  audit: convert sessionid unset to a macro
  audit: use inline function to get audit context
  audit: use inline function to set audit context
  audit: collect audit task parameters

 MAINTAINERS  |  2 +-
 include/linux/audit.h| 28 ---
 include/linux/audit_task.h   | 31 
 include/linux/sched.h|  6 +--
 include/net/xfrm.h   |  4 +-
 include/uapi/linux/audit.h   |  1 +
 init/init_task.c |  8 ++-
 kernel/audit.c   |  6 +--
 kernel/audit_watch.c |  2 +-
 kernel/auditsc.c | 97 +---
 kernel/fork.c|  2 +-
 net/bridge/netfilter/ebtables.c  |  2 +-
 net/core/dev.c   |  2 +-
 net/netfilter/x_tables.c |  2 +-
 net/netlabel/netlabel_user.c |  2 +-
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/integrity_audit.c |  2 +-
 security/lsm_audit.c |  2 +-
 security/selinux/hooks.c |  4 +-
 security/selinux/selinuxfs.c |  6 +--
 security/selinux/ss/services.c   | 12 ++---
 21 files changed, 133 insertions(+), 90 deletions(-)
 create mode 100644 include/linux/audit_task.h

-- 
1.8.3.1



[PATCH ghak81 RFC V2 0/5] audit: group task params

2018-05-12 Thread Richard Guy Briggs
Group the audit parameters for each task into one structure.
In particular, remove the loginuid and sessionid values and the audit
context pointer from the task structure, replacing them with an audit
task information structure to contain them.  Use access functions to
access audit values.

Note:  Use static allocation of the audit task information structure
initially.  Dynamic allocation was considered and attempted, but isn't
ready yet.  Static allocation has the limitation that future audit task
information structure changes would cause a visible change to the rest
of the kernel, whereas dynamic allocation would mostly hide any future
changes.

The first four access normalization patches could stand alone.

Passes audit-testsuite.

Changelog:
v2
- p2/5: add audit header to init/init_task.c to quiet kbuildbot
- audit_signal_info(): fetch loginuid once
- remove task_struct from audit_context() param list
- remove extra task_struct local vars
- do nothing on request to set audit context when audit is disabled

Richard Guy Briggs (5):
  audit: normalize loginuid read access
  audit: convert sessionid unset to a macro
  audit: use inline function to get audit context
  audit: use inline function to set audit context
  audit: collect audit task parameters

 MAINTAINERS  |  2 +-
 include/linux/audit.h| 28 ---
 include/linux/audit_task.h   | 31 
 include/linux/sched.h|  6 +--
 include/net/xfrm.h   |  4 +-
 include/uapi/linux/audit.h   |  1 +
 init/init_task.c |  8 ++-
 kernel/audit.c   |  6 +--
 kernel/audit_watch.c |  2 +-
 kernel/auditsc.c | 97 +---
 kernel/fork.c|  2 +-
 net/bridge/netfilter/ebtables.c  |  2 +-
 net/core/dev.c   |  2 +-
 net/netfilter/x_tables.c |  2 +-
 net/netlabel/netlabel_user.c |  2 +-
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/integrity_audit.c |  2 +-
 security/lsm_audit.c |  2 +-
 security/selinux/hooks.c |  4 +-
 security/selinux/selinuxfs.c |  6 +--
 security/selinux/ss/services.c   | 12 ++---
 21 files changed, 133 insertions(+), 90 deletions(-)
 create mode 100644 include/linux/audit_task.h

-- 
1.8.3.1



[PATCH ghak81 RFC V2 1/5] audit: normalize loginuid read access

2018-05-12 Thread Richard Guy Briggs
Recognizing that the loginuid is an internal audit value, use an access
function to retrieve the audit loginuid value for the task rather than
reaching directly into the task struct to get it.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 479c031..0d4e269 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -374,7 +374,7 @@ static int audit_field_compare(struct task_struct *tsk,
case AUDIT_COMPARE_EGID_TO_OBJ_GID:
return audit_compare_gid(cred->egid, name, f, ctx);
case AUDIT_COMPARE_AUID_TO_OBJ_UID:
-   return audit_compare_uid(tsk->loginuid, name, f, ctx);
+   return audit_compare_uid(audit_get_loginuid(tsk), name, f, ctx);
case AUDIT_COMPARE_SUID_TO_OBJ_UID:
return audit_compare_uid(cred->suid, name, f, ctx);
case AUDIT_COMPARE_SGID_TO_OBJ_GID:
@@ -385,7 +385,7 @@ static int audit_field_compare(struct task_struct *tsk,
return audit_compare_gid(cred->fsgid, name, f, ctx);
/* uid comparisons */
case AUDIT_COMPARE_UID_TO_AUID:
-   return audit_uid_comparator(cred->uid, f->op, tsk->loginuid);
+   return audit_uid_comparator(cred->uid, f->op, 
audit_get_loginuid(tsk));
case AUDIT_COMPARE_UID_TO_EUID:
return audit_uid_comparator(cred->uid, f->op, cred->euid);
case AUDIT_COMPARE_UID_TO_SUID:
@@ -394,11 +394,11 @@ static int audit_field_compare(struct task_struct *tsk,
return audit_uid_comparator(cred->uid, f->op, cred->fsuid);
/* auid comparisons */
case AUDIT_COMPARE_AUID_TO_EUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->euid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->euid);
case AUDIT_COMPARE_AUID_TO_SUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->suid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->suid);
case AUDIT_COMPARE_AUID_TO_FSUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->fsuid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->fsuid);
/* euid comparisons */
case AUDIT_COMPARE_EUID_TO_SUID:
return audit_uid_comparator(cred->euid, f->op, cred->suid);
@@ -611,7 +611,7 @@ static int audit_filter_rules(struct task_struct *tsk,
result = match_tree_refs(ctx, rule->tree);
break;
case AUDIT_LOGINUID:
-   result = audit_uid_comparator(tsk->loginuid, f->op, 
f->uid);
+   result = audit_uid_comparator(audit_get_loginuid(tsk), 
f->op, f->uid);
break;
case AUDIT_LOGINUID_SET:
result = audit_comparator(audit_loginuid_set(tsk), 
f->op, f->val);
@@ -2281,14 +2281,14 @@ int audit_signal_info(int sig, struct task_struct *t)
struct audit_aux_data_pids *axp;
struct task_struct *tsk = current;
struct audit_context *ctx = tsk->audit_context;
-   kuid_t uid = current_uid(), t_uid = task_uid(t);
+   kuid_t uid = current_uid(), auid, t_uid = task_uid(t);
 
if (auditd_test_task(t) &&
(sig == SIGTERM || sig == SIGHUP ||
 sig == SIGUSR1 || sig == SIGUSR2)) {
audit_sig_pid = task_tgid_nr(tsk);
-   if (uid_valid(tsk->loginuid))
-   audit_sig_uid = tsk->loginuid;
+   if (uid_valid(auid = audit_get_loginuid(tsk)))
+   audit_sig_uid = auid;
else
audit_sig_uid = uid;
security_task_getsecid(tsk, _sig_sid);
-- 
1.8.3.1



[PATCH ghak81 RFC V2 1/5] audit: normalize loginuid read access

2018-05-12 Thread Richard Guy Briggs
Recognizing that the loginuid is an internal audit value, use an access
function to retrieve the audit loginuid value for the task rather than
reaching directly into the task struct to get it.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 479c031..0d4e269 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -374,7 +374,7 @@ static int audit_field_compare(struct task_struct *tsk,
case AUDIT_COMPARE_EGID_TO_OBJ_GID:
return audit_compare_gid(cred->egid, name, f, ctx);
case AUDIT_COMPARE_AUID_TO_OBJ_UID:
-   return audit_compare_uid(tsk->loginuid, name, f, ctx);
+   return audit_compare_uid(audit_get_loginuid(tsk), name, f, ctx);
case AUDIT_COMPARE_SUID_TO_OBJ_UID:
return audit_compare_uid(cred->suid, name, f, ctx);
case AUDIT_COMPARE_SGID_TO_OBJ_GID:
@@ -385,7 +385,7 @@ static int audit_field_compare(struct task_struct *tsk,
return audit_compare_gid(cred->fsgid, name, f, ctx);
/* uid comparisons */
case AUDIT_COMPARE_UID_TO_AUID:
-   return audit_uid_comparator(cred->uid, f->op, tsk->loginuid);
+   return audit_uid_comparator(cred->uid, f->op, 
audit_get_loginuid(tsk));
case AUDIT_COMPARE_UID_TO_EUID:
return audit_uid_comparator(cred->uid, f->op, cred->euid);
case AUDIT_COMPARE_UID_TO_SUID:
@@ -394,11 +394,11 @@ static int audit_field_compare(struct task_struct *tsk,
return audit_uid_comparator(cred->uid, f->op, cred->fsuid);
/* auid comparisons */
case AUDIT_COMPARE_AUID_TO_EUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->euid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->euid);
case AUDIT_COMPARE_AUID_TO_SUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->suid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->suid);
case AUDIT_COMPARE_AUID_TO_FSUID:
-   return audit_uid_comparator(tsk->loginuid, f->op, cred->fsuid);
+   return audit_uid_comparator(audit_get_loginuid(tsk), f->op, 
cred->fsuid);
/* euid comparisons */
case AUDIT_COMPARE_EUID_TO_SUID:
return audit_uid_comparator(cred->euid, f->op, cred->suid);
@@ -611,7 +611,7 @@ static int audit_filter_rules(struct task_struct *tsk,
result = match_tree_refs(ctx, rule->tree);
break;
case AUDIT_LOGINUID:
-   result = audit_uid_comparator(tsk->loginuid, f->op, 
f->uid);
+   result = audit_uid_comparator(audit_get_loginuid(tsk), 
f->op, f->uid);
break;
case AUDIT_LOGINUID_SET:
result = audit_comparator(audit_loginuid_set(tsk), 
f->op, f->val);
@@ -2281,14 +2281,14 @@ int audit_signal_info(int sig, struct task_struct *t)
struct audit_aux_data_pids *axp;
struct task_struct *tsk = current;
struct audit_context *ctx = tsk->audit_context;
-   kuid_t uid = current_uid(), t_uid = task_uid(t);
+   kuid_t uid = current_uid(), auid, t_uid = task_uid(t);
 
if (auditd_test_task(t) &&
(sig == SIGTERM || sig == SIGHUP ||
 sig == SIGUSR1 || sig == SIGUSR2)) {
audit_sig_pid = task_tgid_nr(tsk);
-   if (uid_valid(tsk->loginuid))
-   audit_sig_uid = tsk->loginuid;
+   if (uid_valid(auid = audit_get_loginuid(tsk)))
+   audit_sig_uid = auid;
else
audit_sig_uid = uid;
security_task_getsecid(tsk, _sig_sid);
-- 
1.8.3.1



[PATCH ghak81 RFC V2 3/5] audit: use inline function to get audit context

2018-05-12 Thread Richard Guy Briggs
Recognizing that the audit context is an internal audit value, use an
access function to retrieve the audit context pointer for the task
rather than reaching directly into the task struct to get it.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h| 14 ++--
 include/net/xfrm.h   |  2 +-
 kernel/audit.c   |  6 ++--
 kernel/audit_watch.c |  2 +-
 kernel/auditsc.c | 64 +---
 net/bridge/netfilter/ebtables.c  |  2 +-
 net/core/dev.c   |  2 +-
 net/netfilter/x_tables.c |  2 +-
 net/netlabel/netlabel_user.c |  2 +-
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/integrity_audit.c |  2 +-
 security/lsm_audit.c |  2 +-
 security/selinux/hooks.c |  4 +--
 security/selinux/selinuxfs.c |  6 ++--
 security/selinux/ss/services.c   | 12 +++
 15 files changed, 64 insertions(+), 60 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 5f86f7c..786aa8e 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -235,9 +235,13 @@ extern void __audit_inode_child(struct inode *parent,
 extern void __audit_seccomp(unsigned long syscall, long signr, int code);
 extern void __audit_ptrace(struct task_struct *t);
 
+static inline struct audit_context *audit_context(void)
+{
+   return current->audit_context;
+}
 static inline bool audit_dummy_context(void)
 {
-   void *p = current->audit_context;
+   void *p = audit_context();
return !p || *(int *)p;
 }
 static inline void audit_free(struct task_struct *task)
@@ -249,12 +253,12 @@ static inline void audit_syscall_entry(int major, 
unsigned long a0,
   unsigned long a1, unsigned long a2,
   unsigned long a3)
 {
-   if (unlikely(current->audit_context))
+   if (unlikely(audit_context()))
__audit_syscall_entry(major, a0, a1, a2, a3);
 }
 static inline void audit_syscall_exit(void *pt_regs)
 {
-   if (unlikely(current->audit_context)) {
+   if (unlikely(audit_context())) {
int success = is_syscall_success(pt_regs);
long return_code = regs_return_value(pt_regs);
 
@@ -468,6 +472,10 @@ static inline bool audit_dummy_context(void)
 {
return true;
 }
+static inline struct audit_context *audit_context(void)
+{
+   return NULL;
+}
 static inline struct filename *audit_reusename(const __user char *name)
 {
return NULL;
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index fcce8ee..7f2e31a 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -736,7 +736,7 @@ static inline struct audit_buffer *xfrm_audit_start(const 
char *op)
 
if (audit_enabled == 0)
return NULL;
-   audit_buf = audit_log_start(current->audit_context, GFP_ATOMIC,
+   audit_buf = audit_log_start(audit_context(), GFP_ATOMIC,
AUDIT_MAC_IPSEC_EVENT);
if (audit_buf == NULL)
return NULL;
diff --git a/kernel/audit.c b/kernel/audit.c
index e9f9a90..e7478cb 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1099,8 +1099,7 @@ static void audit_log_feature_change(int which, u32 
old_feature, u32 new_feature
 
if (audit_enabled == AUDIT_OFF)
return;
-   ab = audit_log_start(current->audit_context,
-GFP_KERNEL, AUDIT_FEATURE_CHANGE);
+   ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_FEATURE_CHANGE);
if (!ab)
return;
audit_log_task_info(ab, current);
@@ -2317,8 +2316,7 @@ void audit_log_link_denied(const char *operation)
return;
 
/* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
-   ab = audit_log_start(current->audit_context, GFP_KERNEL,
-AUDIT_ANOM_LINK);
+   ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_ANOM_LINK);
if (!ab)
return;
audit_log_format(ab, "op=%s", operation);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 9eb8b35..f1ba889 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -274,7 +274,7 @@ static void audit_update_watch(struct audit_parent *parent,
/* If the update involves invalidating rules, do the inode-based
 * filtering now, so we don't omit records. */
if (invalidating && !audit_dummy_context())
-   audit_filter_inodes(current, current->audit_context);
+   audit_filter_inodes(current, audit_context());
 
/* updating ino will likely change which audit_hash_list we
 * are on so we need a new watch for the new list */
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e157595..ecc0c23 100644

[PATCH ghak81 RFC V2 3/5] audit: use inline function to get audit context

2018-05-12 Thread Richard Guy Briggs
Recognizing that the audit context is an internal audit value, use an
access function to retrieve the audit context pointer for the task
rather than reaching directly into the task struct to get it.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h| 14 ++--
 include/net/xfrm.h   |  2 +-
 kernel/audit.c   |  6 ++--
 kernel/audit_watch.c |  2 +-
 kernel/auditsc.c | 64 +---
 net/bridge/netfilter/ebtables.c  |  2 +-
 net/core/dev.c   |  2 +-
 net/netfilter/x_tables.c |  2 +-
 net/netlabel/netlabel_user.c |  2 +-
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/integrity_audit.c |  2 +-
 security/lsm_audit.c |  2 +-
 security/selinux/hooks.c |  4 +--
 security/selinux/selinuxfs.c |  6 ++--
 security/selinux/ss/services.c   | 12 +++
 15 files changed, 64 insertions(+), 60 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 5f86f7c..786aa8e 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -235,9 +235,13 @@ extern void __audit_inode_child(struct inode *parent,
 extern void __audit_seccomp(unsigned long syscall, long signr, int code);
 extern void __audit_ptrace(struct task_struct *t);
 
+static inline struct audit_context *audit_context(void)
+{
+   return current->audit_context;
+}
 static inline bool audit_dummy_context(void)
 {
-   void *p = current->audit_context;
+   void *p = audit_context();
return !p || *(int *)p;
 }
 static inline void audit_free(struct task_struct *task)
@@ -249,12 +253,12 @@ static inline void audit_syscall_entry(int major, 
unsigned long a0,
   unsigned long a1, unsigned long a2,
   unsigned long a3)
 {
-   if (unlikely(current->audit_context))
+   if (unlikely(audit_context()))
__audit_syscall_entry(major, a0, a1, a2, a3);
 }
 static inline void audit_syscall_exit(void *pt_regs)
 {
-   if (unlikely(current->audit_context)) {
+   if (unlikely(audit_context())) {
int success = is_syscall_success(pt_regs);
long return_code = regs_return_value(pt_regs);
 
@@ -468,6 +472,10 @@ static inline bool audit_dummy_context(void)
 {
return true;
 }
+static inline struct audit_context *audit_context(void)
+{
+   return NULL;
+}
 static inline struct filename *audit_reusename(const __user char *name)
 {
return NULL;
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index fcce8ee..7f2e31a 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -736,7 +736,7 @@ static inline struct audit_buffer *xfrm_audit_start(const 
char *op)
 
if (audit_enabled == 0)
return NULL;
-   audit_buf = audit_log_start(current->audit_context, GFP_ATOMIC,
+   audit_buf = audit_log_start(audit_context(), GFP_ATOMIC,
AUDIT_MAC_IPSEC_EVENT);
if (audit_buf == NULL)
return NULL;
diff --git a/kernel/audit.c b/kernel/audit.c
index e9f9a90..e7478cb 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1099,8 +1099,7 @@ static void audit_log_feature_change(int which, u32 
old_feature, u32 new_feature
 
if (audit_enabled == AUDIT_OFF)
return;
-   ab = audit_log_start(current->audit_context,
-GFP_KERNEL, AUDIT_FEATURE_CHANGE);
+   ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_FEATURE_CHANGE);
if (!ab)
return;
audit_log_task_info(ab, current);
@@ -2317,8 +2316,7 @@ void audit_log_link_denied(const char *operation)
return;
 
/* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
-   ab = audit_log_start(current->audit_context, GFP_KERNEL,
-AUDIT_ANOM_LINK);
+   ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_ANOM_LINK);
if (!ab)
return;
audit_log_format(ab, "op=%s", operation);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 9eb8b35..f1ba889 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -274,7 +274,7 @@ static void audit_update_watch(struct audit_parent *parent,
/* If the update involves invalidating rules, do the inode-based
 * filtering now, so we don't omit records. */
if (invalidating && !audit_dummy_context())
-   audit_filter_inodes(current, current->audit_context);
+   audit_filter_inodes(current, audit_context());
 
/* updating ino will likely change which audit_hash_list we
 * are on so we need a new watch for the new list */
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e157595..ecc0c23 100644
--- 

[PATCH ghak81 RFC V2 5/5] audit: collect audit task parameters

2018-05-12 Thread Richard Guy Briggs
The audit-related parameters in struct task_struct should ideally be
collected together and accessed through a standard audit API.

Collect the existing loginuid, sessionid and audit_context together in a
new struct audit_task_info called "audit" in struct task_struct.

See: https://github.com/linux-audit/audit-kernel/issues/81

Signed-off-by: Richard Guy Briggs 
---
 MAINTAINERS|  2 +-
 include/linux/audit.h  | 10 +-
 include/linux/audit_task.h | 31 +++
 include/linux/sched.h  |  6 ++
 init/init_task.c   |  7 +--
 kernel/auditsc.c   |  6 +++---
 6 files changed, 47 insertions(+), 15 deletions(-)
 create mode 100644 include/linux/audit_task.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d..8c7992d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2510,7 +2510,7 @@ L:linux-au...@redhat.com (moderated for 
non-subscribers)
 W: https://github.com/linux-audit
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
 S: Supported
-F: include/linux/audit.h
+F: include/linux/audit*.h
 F: include/uapi/linux/audit.h
 F: kernel/audit*
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index f7973e4..6d599b6 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -237,11 +237,11 @@ extern void __audit_inode_child(struct inode *parent,
 
 static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
 {
-   task->audit_context = ctx;
+   task->audit.ctx = ctx;
 }
 static inline struct audit_context *audit_context(void)
 {
-   return current->audit_context;
+   return current->audit.ctx;
 }
 static inline bool audit_dummy_context(void)
 {
@@ -250,7 +250,7 @@ static inline bool audit_dummy_context(void)
 }
 static inline void audit_free(struct task_struct *task)
 {
-   if (unlikely(task->audit_context))
+   if (unlikely(task->audit.ctx))
__audit_free(task);
 }
 static inline void audit_syscall_entry(int major, unsigned long a0,
@@ -330,12 +330,12 @@ extern int auditsc_get_stamp(struct audit_context *ctx,
 
 static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
 {
-   return tsk->loginuid;
+   return tsk->audit.loginuid;
 }
 
 static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
 {
-   return tsk->sessionid;
+   return tsk->audit.sessionid;
 }
 
 extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
diff --git a/include/linux/audit_task.h b/include/linux/audit_task.h
new file mode 100644
index 000..d4b3a20
--- /dev/null
+++ b/include/linux/audit_task.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* audit_task.h -- definition of audit_task_info structure
+ *
+ * Copyright 2018 Red Hat Inc., Raleigh, North Carolina.
+ * All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Written by Richard Guy Briggs 
+ *
+ */
+
+#ifndef _LINUX_AUDIT_TASK_H_
+#define _LINUX_AUDIT_TASK_H_
+
+struct audit_context;
+struct audit_task_info {
+   kuid_t  loginuid;
+   unsigned intsessionid;
+   struct audit_context*ctx;
+};
+
+#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b3d697f..b58eca0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 /* task_struct member predeclarations (sorted alphabetically): */
-struct audit_context;
 struct backing_dev_info;
 struct bio_list;
 struct blk_plug;
@@ -832,10 +832,8 @@ struct task_struct {
 
struct callback_head*task_works;
 
-   struct audit_context*audit_context;
 #ifdef CONFIG_AUDITSYSCALL
-   kuid_t  loginuid;
-   unsigned intsessionid;
+   struct audit_task_info  audit;
 #endif
struct seccomp  seccomp;
 
diff --git a/init/init_task.c b/init/init_task.c
index 74f60ba..d33260d 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -119,8 +119,11 @@ struct task_struct init_task
.thread_group   = LIST_HEAD_INIT(init_task.thread_group),
.thread_node= LIST_HEAD_INIT(init_signals.thread_head),
 #ifdef CONFIG_AUDITSYSCALL
-   .loginuid   = INVALID_UID,
-   .sessionid  = AUDIT_SID_UNSET,
+   .audit  = {
+   .loginuid   = INVALID_UID,
+   .sessionid  = 

[PATCH ghak81 RFC V2 4/5] audit: use inline function to set audit context

2018-05-12 Thread Richard Guy Briggs
Recognizing that the audit context is an internal audit value, use an
access function to set the audit context pointer for the task
rather than reaching directly into the task struct to set it.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h | 6 ++
 kernel/auditsc.c  | 7 +++
 kernel/fork.c | 2 +-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 786aa8e..f7973e4 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -235,6 +235,10 @@ extern void __audit_inode_child(struct inode *parent,
 extern void __audit_seccomp(unsigned long syscall, long signr, int code);
 extern void __audit_ptrace(struct task_struct *t);
 
+static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
+{
+   task->audit_context = ctx;
+}
 static inline struct audit_context *audit_context(void)
 {
return current->audit_context;
@@ -472,6 +476,8 @@ static inline bool audit_dummy_context(void)
 {
return true;
 }
+static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
+{ }
 static inline struct audit_context *audit_context(void)
 {
return NULL;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ecc0c23..d441d68 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -865,7 +865,7 @@ static inline struct audit_context 
*audit_take_context(struct task_struct *tsk,
audit_filter_inodes(tsk, context);
}
 
-   tsk->audit_context = NULL;
+   audit_set_context(tsk, NULL);
return context;
 }
 
@@ -952,7 +952,7 @@ int audit_alloc(struct task_struct *tsk)
}
context->filterkey = key;
 
-   tsk->audit_context  = context;
+   audit_set_context(tsk, context);
set_tsk_thread_flag(tsk, TIF_SYSCALL_AUDIT);
return 0;
 }
@@ -1554,7 +1554,6 @@ void __audit_syscall_entry(int major, unsigned long a1, 
unsigned long a2,
  */
 void __audit_syscall_exit(int success, long return_code)
 {
-   struct task_struct *tsk = current;
struct audit_context *context;
 
if (success)
@@ -1589,7 +1588,7 @@ void __audit_syscall_exit(int success, long return_code)
kfree(context->filterkey);
context->filterkey = NULL;
}
-   tsk->audit_context = context;
+   audit_set_context(current, context);
 }
 
 static inline void handle_one(const struct inode *inode)
diff --git a/kernel/fork.c b/kernel/fork.c
index 242c8c9..cd18448 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1713,7 +1713,7 @@ static __latent_entropy struct task_struct *copy_process(
p->start_time = ktime_get_ns();
p->real_start_time = ktime_get_boot_ns();
p->io_context = NULL;
-   p->audit_context = NULL;
+   audit_set_context(p, NULL);
cgroup_fork(p);
 #ifdef CONFIG_NUMA
p->mempolicy = mpol_dup(p->mempolicy);
-- 
1.8.3.1



[PATCH ghak81 RFC V2 2/5] audit: convert sessionid unset to a macro

2018-05-12 Thread Richard Guy Briggs
Use a macro, "AUDIT_SID_UNSET", to replace each instance of
initialization and comparison to an audit session ID.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h  | 2 +-
 include/net/xfrm.h | 2 +-
 include/uapi/linux/audit.h | 1 +
 init/init_task.c   | 3 ++-
 kernel/auditsc.c   | 4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 75d5b03..5f86f7c 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -513,7 +513,7 @@ static inline kuid_t audit_get_loginuid(struct task_struct 
*tsk)
 }
 static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
 {
-   return -1;
+   return AUDIT_SID_UNSET;
 }
 static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
 { }
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index a872379..fcce8ee 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -751,7 +751,7 @@ static inline void xfrm_audit_helper_usrinfo(bool 
task_valid,
audit_get_loginuid(current) :
INVALID_UID);
const unsigned int ses = task_valid ? audit_get_sessionid(current) :
-   (unsigned int) -1;
+   AUDIT_SID_UNSET;
 
audit_log_format(audit_buf, " auid=%u ses=%u", auid, ses);
audit_log_task_context(audit_buf);
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 4e61a9e..04f9bd2 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -465,6 +465,7 @@ struct audit_tty_status {
 };
 
 #define AUDIT_UID_UNSET (unsigned int)-1
+#define AUDIT_SID_UNSET ((unsigned int)-1)
 
 /* audit_rule_data supports filter rules with both integer and string
  * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
diff --git a/init/init_task.c b/init/init_task.c
index 3ac6e75..74f60ba 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -119,7 +120,7 @@ struct task_struct init_task
.thread_node= LIST_HEAD_INIT(init_signals.thread_head),
 #ifdef CONFIG_AUDITSYSCALL
.loginuid   = INVALID_UID,
-   .sessionid  = (unsigned int)-1,
+   .sessionid  = AUDIT_SID_UNSET,
 #endif
 #ifdef CONFIG_PERF_EVENTS
.perf_event_mutex = __MUTEX_INITIALIZER(init_task.perf_event_mutex),
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 0d4e269..e157595 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2050,7 +2050,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, 
kuid_t kloginuid,
 int audit_set_loginuid(kuid_t loginuid)
 {
struct task_struct *task = current;
-   unsigned int oldsessionid, sessionid = (unsigned int)-1;
+   unsigned int oldsessionid, sessionid = AUDIT_SID_UNSET;
kuid_t oldloginuid;
int rc;
 
@@ -2064,7 +2064,7 @@ int audit_set_loginuid(kuid_t loginuid)
/* are we setting or clearing? */
if (uid_valid(loginuid)) {
sessionid = (unsigned int)atomic_inc_return(_id);
-   if (unlikely(sessionid == (unsigned int)-1))
+   if (unlikely(sessionid == AUDIT_SID_UNSET))
sessionid = (unsigned 
int)atomic_inc_return(_id);
}
 
-- 
1.8.3.1



[PATCH ghak81 RFC V2 5/5] audit: collect audit task parameters

2018-05-12 Thread Richard Guy Briggs
The audit-related parameters in struct task_struct should ideally be
collected together and accessed through a standard audit API.

Collect the existing loginuid, sessionid and audit_context together in a
new struct audit_task_info called "audit" in struct task_struct.

See: https://github.com/linux-audit/audit-kernel/issues/81

Signed-off-by: Richard Guy Briggs 
---
 MAINTAINERS|  2 +-
 include/linux/audit.h  | 10 +-
 include/linux/audit_task.h | 31 +++
 include/linux/sched.h  |  6 ++
 init/init_task.c   |  7 +--
 kernel/auditsc.c   |  6 +++---
 6 files changed, 47 insertions(+), 15 deletions(-)
 create mode 100644 include/linux/audit_task.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d..8c7992d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2510,7 +2510,7 @@ L:linux-au...@redhat.com (moderated for 
non-subscribers)
 W: https://github.com/linux-audit
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
 S: Supported
-F: include/linux/audit.h
+F: include/linux/audit*.h
 F: include/uapi/linux/audit.h
 F: kernel/audit*
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index f7973e4..6d599b6 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -237,11 +237,11 @@ extern void __audit_inode_child(struct inode *parent,
 
 static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
 {
-   task->audit_context = ctx;
+   task->audit.ctx = ctx;
 }
 static inline struct audit_context *audit_context(void)
 {
-   return current->audit_context;
+   return current->audit.ctx;
 }
 static inline bool audit_dummy_context(void)
 {
@@ -250,7 +250,7 @@ static inline bool audit_dummy_context(void)
 }
 static inline void audit_free(struct task_struct *task)
 {
-   if (unlikely(task->audit_context))
+   if (unlikely(task->audit.ctx))
__audit_free(task);
 }
 static inline void audit_syscall_entry(int major, unsigned long a0,
@@ -330,12 +330,12 @@ extern int auditsc_get_stamp(struct audit_context *ctx,
 
 static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
 {
-   return tsk->loginuid;
+   return tsk->audit.loginuid;
 }
 
 static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
 {
-   return tsk->sessionid;
+   return tsk->audit.sessionid;
 }
 
 extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
diff --git a/include/linux/audit_task.h b/include/linux/audit_task.h
new file mode 100644
index 000..d4b3a20
--- /dev/null
+++ b/include/linux/audit_task.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* audit_task.h -- definition of audit_task_info structure
+ *
+ * Copyright 2018 Red Hat Inc., Raleigh, North Carolina.
+ * All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Written by Richard Guy Briggs 
+ *
+ */
+
+#ifndef _LINUX_AUDIT_TASK_H_
+#define _LINUX_AUDIT_TASK_H_
+
+struct audit_context;
+struct audit_task_info {
+   kuid_t  loginuid;
+   unsigned intsessionid;
+   struct audit_context*ctx;
+};
+
+#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b3d697f..b58eca0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 /* task_struct member predeclarations (sorted alphabetically): */
-struct audit_context;
 struct backing_dev_info;
 struct bio_list;
 struct blk_plug;
@@ -832,10 +832,8 @@ struct task_struct {
 
struct callback_head*task_works;
 
-   struct audit_context*audit_context;
 #ifdef CONFIG_AUDITSYSCALL
-   kuid_t  loginuid;
-   unsigned intsessionid;
+   struct audit_task_info  audit;
 #endif
struct seccomp  seccomp;
 
diff --git a/init/init_task.c b/init/init_task.c
index 74f60ba..d33260d 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -119,8 +119,11 @@ struct task_struct init_task
.thread_group   = LIST_HEAD_INIT(init_task.thread_group),
.thread_node= LIST_HEAD_INIT(init_signals.thread_head),
 #ifdef CONFIG_AUDITSYSCALL
-   .loginuid   = INVALID_UID,
-   .sessionid  = AUDIT_SID_UNSET,
+   .audit  = {
+   .loginuid   = INVALID_UID,
+   .sessionid  = AUDIT_SID_UNSET,
+   .ctx   

[PATCH ghak81 RFC V2 4/5] audit: use inline function to set audit context

2018-05-12 Thread Richard Guy Briggs
Recognizing that the audit context is an internal audit value, use an
access function to set the audit context pointer for the task
rather than reaching directly into the task struct to set it.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h | 6 ++
 kernel/auditsc.c  | 7 +++
 kernel/fork.c | 2 +-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 786aa8e..f7973e4 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -235,6 +235,10 @@ extern void __audit_inode_child(struct inode *parent,
 extern void __audit_seccomp(unsigned long syscall, long signr, int code);
 extern void __audit_ptrace(struct task_struct *t);
 
+static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
+{
+   task->audit_context = ctx;
+}
 static inline struct audit_context *audit_context(void)
 {
return current->audit_context;
@@ -472,6 +476,8 @@ static inline bool audit_dummy_context(void)
 {
return true;
 }
+static inline void audit_set_context(struct task_struct *task, struct 
audit_context *ctx)
+{ }
 static inline struct audit_context *audit_context(void)
 {
return NULL;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ecc0c23..d441d68 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -865,7 +865,7 @@ static inline struct audit_context 
*audit_take_context(struct task_struct *tsk,
audit_filter_inodes(tsk, context);
}
 
-   tsk->audit_context = NULL;
+   audit_set_context(tsk, NULL);
return context;
 }
 
@@ -952,7 +952,7 @@ int audit_alloc(struct task_struct *tsk)
}
context->filterkey = key;
 
-   tsk->audit_context  = context;
+   audit_set_context(tsk, context);
set_tsk_thread_flag(tsk, TIF_SYSCALL_AUDIT);
return 0;
 }
@@ -1554,7 +1554,6 @@ void __audit_syscall_entry(int major, unsigned long a1, 
unsigned long a2,
  */
 void __audit_syscall_exit(int success, long return_code)
 {
-   struct task_struct *tsk = current;
struct audit_context *context;
 
if (success)
@@ -1589,7 +1588,7 @@ void __audit_syscall_exit(int success, long return_code)
kfree(context->filterkey);
context->filterkey = NULL;
}
-   tsk->audit_context = context;
+   audit_set_context(current, context);
 }
 
 static inline void handle_one(const struct inode *inode)
diff --git a/kernel/fork.c b/kernel/fork.c
index 242c8c9..cd18448 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1713,7 +1713,7 @@ static __latent_entropy struct task_struct *copy_process(
p->start_time = ktime_get_ns();
p->real_start_time = ktime_get_boot_ns();
p->io_context = NULL;
-   p->audit_context = NULL;
+   audit_set_context(p, NULL);
cgroup_fork(p);
 #ifdef CONFIG_NUMA
p->mempolicy = mpol_dup(p->mempolicy);
-- 
1.8.3.1



[PATCH ghak81 RFC V2 2/5] audit: convert sessionid unset to a macro

2018-05-12 Thread Richard Guy Briggs
Use a macro, "AUDIT_SID_UNSET", to replace each instance of
initialization and comparison to an audit session ID.

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h  | 2 +-
 include/net/xfrm.h | 2 +-
 include/uapi/linux/audit.h | 1 +
 init/init_task.c   | 3 ++-
 kernel/auditsc.c   | 4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 75d5b03..5f86f7c 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -513,7 +513,7 @@ static inline kuid_t audit_get_loginuid(struct task_struct 
*tsk)
 }
 static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
 {
-   return -1;
+   return AUDIT_SID_UNSET;
 }
 static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
 { }
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index a872379..fcce8ee 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -751,7 +751,7 @@ static inline void xfrm_audit_helper_usrinfo(bool 
task_valid,
audit_get_loginuid(current) :
INVALID_UID);
const unsigned int ses = task_valid ? audit_get_sessionid(current) :
-   (unsigned int) -1;
+   AUDIT_SID_UNSET;
 
audit_log_format(audit_buf, " auid=%u ses=%u", auid, ses);
audit_log_task_context(audit_buf);
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 4e61a9e..04f9bd2 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -465,6 +465,7 @@ struct audit_tty_status {
 };
 
 #define AUDIT_UID_UNSET (unsigned int)-1
+#define AUDIT_SID_UNSET ((unsigned int)-1)
 
 /* audit_rule_data supports filter rules with both integer and string
  * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
diff --git a/init/init_task.c b/init/init_task.c
index 3ac6e75..74f60ba 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -119,7 +120,7 @@ struct task_struct init_task
.thread_node= LIST_HEAD_INIT(init_signals.thread_head),
 #ifdef CONFIG_AUDITSYSCALL
.loginuid   = INVALID_UID,
-   .sessionid  = (unsigned int)-1,
+   .sessionid  = AUDIT_SID_UNSET,
 #endif
 #ifdef CONFIG_PERF_EVENTS
.perf_event_mutex = __MUTEX_INITIALIZER(init_task.perf_event_mutex),
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 0d4e269..e157595 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2050,7 +2050,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, 
kuid_t kloginuid,
 int audit_set_loginuid(kuid_t loginuid)
 {
struct task_struct *task = current;
-   unsigned int oldsessionid, sessionid = (unsigned int)-1;
+   unsigned int oldsessionid, sessionid = AUDIT_SID_UNSET;
kuid_t oldloginuid;
int rc;
 
@@ -2064,7 +2064,7 @@ int audit_set_loginuid(kuid_t loginuid)
/* are we setting or clearing? */
if (uid_valid(loginuid)) {
sessionid = (unsigned int)atomic_inc_return(_id);
-   if (unlikely(sessionid == (unsigned int)-1))
+   if (unlikely(sessionid == AUDIT_SID_UNSET))
sessionid = (unsigned 
int)atomic_inc_return(_id);
}
 
-- 
1.8.3.1



Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

2018-05-12 Thread Masami Hiramatsu
On Sat, 12 May 2018 10:29:57 -0700
Florian Fainelli  wrote:

> On May 12, 2018 4:31:37 AM PDT, Masami Hiramatsu  wrote:
> >Hi Russell,
> >
> >On Tue, 8 May 2018 12:25:03 +0100
> >Russell King - ARM Linux  wrote:
> >
> >> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> >> > Hi,
> >> > 
> >> > This is the 3rd version of bugfix series for kprobes on arm.
> >> > This series fixes 4 different issues which I found.
> >> > 
> >> >  - Fix to use smp_processor_id() after disabling preemption.
> >> >  - Prohibit probing on optimized_callback() for avoiding
> >> >recursive probe.
> >> >  - Prohibit kprobes on do_undefinstr() by same reason.
> >> >  - Prohibit kprobes on get_user() by same reason.
> >> > 
> >> > >From v2, I included another 2 bugfixes (1/4 and 2/4)
> >> > which are not merged yet, and added "Cc: sta...@vger.kernel.org",
> >> > since there are obvious bugs.
> >> 
> >> Please submit them to the patch system, thanks.
> >
> >Could you tell me what you mean the patch system?
> 
> This is in Russell's signature:
> 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/

Ah, Thanks!
OK, I'll submit via that system!


> 
> -- 
> Florian


-- 
Masami Hiramatsu 


Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

2018-05-12 Thread Masami Hiramatsu
On Sat, 12 May 2018 10:29:57 -0700
Florian Fainelli  wrote:

> On May 12, 2018 4:31:37 AM PDT, Masami Hiramatsu  wrote:
> >Hi Russell,
> >
> >On Tue, 8 May 2018 12:25:03 +0100
> >Russell King - ARM Linux  wrote:
> >
> >> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> >> > Hi,
> >> > 
> >> > This is the 3rd version of bugfix series for kprobes on arm.
> >> > This series fixes 4 different issues which I found.
> >> > 
> >> >  - Fix to use smp_processor_id() after disabling preemption.
> >> >  - Prohibit probing on optimized_callback() for avoiding
> >> >recursive probe.
> >> >  - Prohibit kprobes on do_undefinstr() by same reason.
> >> >  - Prohibit kprobes on get_user() by same reason.
> >> > 
> >> > >From v2, I included another 2 bugfixes (1/4 and 2/4)
> >> > which are not merged yet, and added "Cc: sta...@vger.kernel.org",
> >> > since there are obvious bugs.
> >> 
> >> Please submit them to the patch system, thanks.
> >
> >Could you tell me what you mean the patch system?
> 
> This is in Russell's signature:
> 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/

Ah, Thanks!
OK, I'll submit via that system!


> 
> -- 
> Florian


-- 
Masami Hiramatsu 


[PATCH] hexagon: fix printk format warning in setup.c

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

Fix printk format warning in hexagon/kernel/setup.c:

../arch/hexagon/kernel/setup.c: In function 'setup_arch':
../arch/hexagon/kernel/setup.c:69:2: warning: format '%x' expects argument of 
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]

where:
extern unsigned long__phys_offset;
#define PHYS_OFFSET __phys_offset

Signed-off-by: Randy Dunlap 
Cc: Richard Kuo 
Cc: linux-hexa...@vger.kernel.org
---
 arch/hexagon/kernel/setup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180510.orig/arch/hexagon/kernel/setup.c
+++ linux-next-20180510/arch/hexagon/kernel/setup.c
@@ -66,7 +66,7 @@ void __init setup_arch(char **cmdline_p)
 */
__vmsetvec(_K_VM_event_vector);
 
-   printk(KERN_INFO "PHYS_OFFSET=0x%08x\n", PHYS_OFFSET);
+   printk(KERN_INFO "PHYS_OFFSET=0x%08lx\n", PHYS_OFFSET);
 
/*
 * Simulator has a few differences from the hardware.




[PATCH] hexagon: fix printk format warning in setup.c

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

Fix printk format warning in hexagon/kernel/setup.c:

../arch/hexagon/kernel/setup.c: In function 'setup_arch':
../arch/hexagon/kernel/setup.c:69:2: warning: format '%x' expects argument of 
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]

where:
extern unsigned long__phys_offset;
#define PHYS_OFFSET __phys_offset

Signed-off-by: Randy Dunlap 
Cc: Richard Kuo 
Cc: linux-hexa...@vger.kernel.org
---
 arch/hexagon/kernel/setup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180510.orig/arch/hexagon/kernel/setup.c
+++ linux-next-20180510/arch/hexagon/kernel/setup.c
@@ -66,7 +66,7 @@ void __init setup_arch(char **cmdline_p)
 */
__vmsetvec(_K_VM_event_vector);
 
-   printk(KERN_INFO "PHYS_OFFSET=0x%08x\n", PHYS_OFFSET);
+   printk(KERN_INFO "PHYS_OFFSET=0x%08lx\n", PHYS_OFFSET);
 
/*
 * Simulator has a few differences from the hardware.




[PATCH -next] ASoC: omap: add sdma-pcm.c MODULE_LICENSE

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

ASoC: omap: add sdma-pcm.c MODULE_LICENSE

Fixes this build warning:

WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o

Signed-off-by: Randy Dunlap 
Cc: Peter Ujfalusi 
Cc: Jarkko Nikula 
Cc: Liam Girdwood 
Cc: Mark Brown 
---
 sound/soc/omap/sdma-pcm.c |3 +++
 1 file changed, 3 insertions(+)

--- linux-next-20180510.orig/sound/soc/omap/sdma-pcm.c
+++ linux-next-20180510/sound/soc/omap/sdma-pcm.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sdma-pcm.h"
@@ -66,3 +67,5 @@ int sdma_pcm_platform_register(struct de
return devm_snd_dmaengine_pcm_register(dev, config, flags);
 }
 EXPORT_SYMBOL_GPL(sdma_pcm_platform_register);
+
+MODULE_LICENSE("GPL v2");



[PATCH -next] ASoC: omap: add sdma-pcm.c MODULE_LICENSE

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

ASoC: omap: add sdma-pcm.c MODULE_LICENSE

Fixes this build warning:

WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o

Signed-off-by: Randy Dunlap 
Cc: Peter Ujfalusi 
Cc: Jarkko Nikula 
Cc: Liam Girdwood 
Cc: Mark Brown 
---
 sound/soc/omap/sdma-pcm.c |3 +++
 1 file changed, 3 insertions(+)

--- linux-next-20180510.orig/sound/soc/omap/sdma-pcm.c
+++ linux-next-20180510/sound/soc/omap/sdma-pcm.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sdma-pcm.h"
@@ -66,3 +67,5 @@ int sdma_pcm_platform_register(struct de
return devm_snd_dmaengine_pcm_register(dev, config, flags);
 }
 EXPORT_SYMBOL_GPL(sdma_pcm_platform_register);
+
+MODULE_LICENSE("GPL v2");



Re: [RFC PATCH v3 3/5] usb: typec: Bus type for alternate modes

2018-05-12 Thread Randy Dunlap
On 05/11/2018 06:18 AM, Heikki Krogerus wrote:
> Introducing a simple bus for the alternate modes. Bus allows
> binding drivers to the discovered alternate modes the
> partners support.
> 
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/obsolete/sysfs-class-typec |  48 +++
>  Documentation/ABI/testing/sysfs-bus-typec|  51 +++
>  Documentation/ABI/testing/sysfs-class-typec  |  62 +--
>  Documentation/driver-api/usb/typec_bus.rst   | 136 ++
>  drivers/usb/typec/Makefile   |   2 +-
>  drivers/usb/typec/bus.c  | 423 +++
>  drivers/usb/typec/bus.h  |  38 ++
>  drivers/usb/typec/class.c| 364 
>  include/linux/mod_devicetable.h  |  15 +
>  include/linux/usb/typec.h|  14 +-
>  include/linux/usb/typec_altmode.h| 142 +++
>  scripts/mod/devicetable-offsets.c|   4 +
>  scripts/mod/file2alias.c |  13 +
>  13 files changed, 1168 insertions(+), 144 deletions(-)
>  create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
>  create mode 100644 Documentation/driver-api/usb/typec_bus.rst
>  create mode 100644 drivers/usb/typec/bus.c
>  create mode 100644 drivers/usb/typec/bus.h
>  create mode 100644 include/linux/usb/typec_altmode.h

Hi,
I have a few doc corrections for you.

> diff --git a/Documentation/driver-api/usb/typec_bus.rst 
> b/Documentation/driver-api/usb/typec_bus.rst
> new file mode 100644
> index ..4184e0925567
> --- /dev/null
> +++ b/Documentation/driver-api/usb/typec_bus.rst
> @@ -0,0 +1,136 @@
> +
> +API for USB Type-C Alternate Mode drivers
> +=
> +
> +Introduction
> +
> +
> +Alternate modes require communication with the partner using Vendor Defined
> +Messages (VDM) as defined in USB Type-C and USB Power Delivery 
> Specifications.
> +The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
> +every alternate mode, so every alternate mode will need custom driver.

   a custom driver.

> +
> +USB Type-C bus allows binding a driver to the discovered partner alternate
> +modes by using the SVID and the mode number.
> +
> +USB Type-C Connector Class provides a device for every alternate mode a port
> +supports, and separate device for every alternate mode the partner supports.
> +The drivers for the alternate modes are bind to the partner alternate mode

   are bound
or just:   bind

> +devices, and the port alternate mode devices must be handled by the port
> +drivers.
> +
> +When a new partner alternate mode device is registered, it is linked to the
> +alternate mode device of the port that the partner is attached to, that has
> +matching SVID and mode. Communication between the port driver and alternate 
> mode
> +driver will happen using the same API.
> +
> +The port alternate mode devices are used as a proxy between the partner and 
> the
> +alternate mode drivers, so the port drivers are only expected to pass the 
> SVID
> +specific commands from the alternate mode drivers to the partner, and from 
> the
> +partners to the alternate mode drivers. No direct SVID specific 
> communication is
> +needed from the port drivers, but the port drivers need to provide the 
> operation
> +callbacks for the port alternate mode devices, just like the alternate mode
> +drivers need to provide them for the partner alternate mode devices.
> +
> +Usage:
> +--
> +
> +General
> +~~~
> +
> +By default, the alternate mode drivers are responsible for entering the mode.
> +It is also possible to leave the decision about entering the mode to the user
> +space (See Documentation/ABI/testing/sysfs-class-typec). Port drivers should 
> not
> +enter any modes on their own.
> +
> +``->vdm`` is the most important callback in the vector. It will be used to
> +deliver all the SVID specific commands from the partner to the alternate mode
> +driver, and vise versa in case of port drivers. The drivers send the SVID

   vice versa

> +specific commands to each other using :c:func:`typec_altmode_vmd()`.
> +
> +If the communication with the partner using the SVID specific commands 
> results
> +in need to re-configure the pins on the connector, the alternate mode driver

  reconfigure

> +needs to notify the bus using :c:func:`typec_altmode_notify()`. The driver
> +passes the negotiated SVID specific pin configuration value to the function 
> as
> +parameter. The bus driver will then configure the mux behind the connector 
> using
> +that value as the state value for the mux, and also call blocking 
> notification
> +chain to notify the external drivers about the state of the connector that 
> need
> 

Re: [RFC PATCH v3 3/5] usb: typec: Bus type for alternate modes

2018-05-12 Thread Randy Dunlap
On 05/11/2018 06:18 AM, Heikki Krogerus wrote:
> Introducing a simple bus for the alternate modes. Bus allows
> binding drivers to the discovered alternate modes the
> partners support.
> 
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/obsolete/sysfs-class-typec |  48 +++
>  Documentation/ABI/testing/sysfs-bus-typec|  51 +++
>  Documentation/ABI/testing/sysfs-class-typec  |  62 +--
>  Documentation/driver-api/usb/typec_bus.rst   | 136 ++
>  drivers/usb/typec/Makefile   |   2 +-
>  drivers/usb/typec/bus.c  | 423 +++
>  drivers/usb/typec/bus.h  |  38 ++
>  drivers/usb/typec/class.c| 364 
>  include/linux/mod_devicetable.h  |  15 +
>  include/linux/usb/typec.h|  14 +-
>  include/linux/usb/typec_altmode.h| 142 +++
>  scripts/mod/devicetable-offsets.c|   4 +
>  scripts/mod/file2alias.c |  13 +
>  13 files changed, 1168 insertions(+), 144 deletions(-)
>  create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
>  create mode 100644 Documentation/driver-api/usb/typec_bus.rst
>  create mode 100644 drivers/usb/typec/bus.c
>  create mode 100644 drivers/usb/typec/bus.h
>  create mode 100644 include/linux/usb/typec_altmode.h

Hi,
I have a few doc corrections for you.

> diff --git a/Documentation/driver-api/usb/typec_bus.rst 
> b/Documentation/driver-api/usb/typec_bus.rst
> new file mode 100644
> index ..4184e0925567
> --- /dev/null
> +++ b/Documentation/driver-api/usb/typec_bus.rst
> @@ -0,0 +1,136 @@
> +
> +API for USB Type-C Alternate Mode drivers
> +=
> +
> +Introduction
> +
> +
> +Alternate modes require communication with the partner using Vendor Defined
> +Messages (VDM) as defined in USB Type-C and USB Power Delivery 
> Specifications.
> +The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
> +every alternate mode, so every alternate mode will need custom driver.

   a custom driver.

> +
> +USB Type-C bus allows binding a driver to the discovered partner alternate
> +modes by using the SVID and the mode number.
> +
> +USB Type-C Connector Class provides a device for every alternate mode a port
> +supports, and separate device for every alternate mode the partner supports.
> +The drivers for the alternate modes are bind to the partner alternate mode

   are bound
or just:   bind

> +devices, and the port alternate mode devices must be handled by the port
> +drivers.
> +
> +When a new partner alternate mode device is registered, it is linked to the
> +alternate mode device of the port that the partner is attached to, that has
> +matching SVID and mode. Communication between the port driver and alternate 
> mode
> +driver will happen using the same API.
> +
> +The port alternate mode devices are used as a proxy between the partner and 
> the
> +alternate mode drivers, so the port drivers are only expected to pass the 
> SVID
> +specific commands from the alternate mode drivers to the partner, and from 
> the
> +partners to the alternate mode drivers. No direct SVID specific 
> communication is
> +needed from the port drivers, but the port drivers need to provide the 
> operation
> +callbacks for the port alternate mode devices, just like the alternate mode
> +drivers need to provide them for the partner alternate mode devices.
> +
> +Usage:
> +--
> +
> +General
> +~~~
> +
> +By default, the alternate mode drivers are responsible for entering the mode.
> +It is also possible to leave the decision about entering the mode to the user
> +space (See Documentation/ABI/testing/sysfs-class-typec). Port drivers should 
> not
> +enter any modes on their own.
> +
> +``->vdm`` is the most important callback in the vector. It will be used to
> +deliver all the SVID specific commands from the partner to the alternate mode
> +driver, and vise versa in case of port drivers. The drivers send the SVID

   vice versa

> +specific commands to each other using :c:func:`typec_altmode_vmd()`.
> +
> +If the communication with the partner using the SVID specific commands 
> results
> +in need to re-configure the pins on the connector, the alternate mode driver

  reconfigure

> +needs to notify the bus using :c:func:`typec_altmode_notify()`. The driver
> +passes the negotiated SVID specific pin configuration value to the function 
> as
> +parameter. The bus driver will then configure the mux behind the connector 
> using
> +that value as the state value for the mux, and also call blocking 
> notification
> +chain to notify the external drivers about the state of the connector that 
> need
> +to know it.
> +
> +NOTE: The 

[PATCH] edac: fix skx_edac build error when ACPI_NFIT=m

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

Prevent build error when CONFIG_ACPI_NFIT=m and CONFIG_EDAC_SKX=y
by limiting EDAC_SKX based on how ACPI_NFIT is set.

Fixes this build error:
drivers/edac/skx_edac.o: In function `get_nvdimm_info':
../drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

Fixes: 58ca9ac1463d ("EDAC, skx_edac: Detect non-volatile DIMMs")

Reported-by: kbuild test robot 
Signed-off-by: Randy Dunlap 
Cc: Tony Luck 
Cc: Borislav Petkov 
Cc: Mauro Carvalho Chehab 
Cc: sta...@vger.kernel.org
---
 drivers/edac/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-417-rc4.orig/drivers/edac/Kconfig
+++ lnx-417-rc4/drivers/edac/Kconfig
@@ -232,6 +232,7 @@ config EDAC_SBRIDGE
 config EDAC_SKX
tristate "Intel Skylake server Integrated MC"
depends on PCI && X86_64 && X86_MCE_INTEL && PCI_MMCONFIG
+   depends on ACPI_NFIT || !ACPI_NFIT
select DMI
help
  Support for error detection and correction the Intel




[PATCH] edac: fix skx_edac build error when ACPI_NFIT=m

2018-05-12 Thread Randy Dunlap
From: Randy Dunlap 

Prevent build error when CONFIG_ACPI_NFIT=m and CONFIG_EDAC_SKX=y
by limiting EDAC_SKX based on how ACPI_NFIT is set.

Fixes this build error:
drivers/edac/skx_edac.o: In function `get_nvdimm_info':
../drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

Fixes: 58ca9ac1463d ("EDAC, skx_edac: Detect non-volatile DIMMs")

Reported-by: kbuild test robot 
Signed-off-by: Randy Dunlap 
Cc: Tony Luck 
Cc: Borislav Petkov 
Cc: Mauro Carvalho Chehab 
Cc: sta...@vger.kernel.org
---
 drivers/edac/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-417-rc4.orig/drivers/edac/Kconfig
+++ lnx-417-rc4/drivers/edac/Kconfig
@@ -232,6 +232,7 @@ config EDAC_SBRIDGE
 config EDAC_SKX
tristate "Intel Skylake server Integrated MC"
depends on PCI && X86_64 && X86_MCE_INTEL && PCI_MMCONFIG
+   depends on ACPI_NFIT || !ACPI_NFIT
select DMI
help
  Support for error detection and correction the Intel




[RFC] m68k: Set up dma mask for platform devices

2018-05-12 Thread Finn Thain
This avoids a WARNING splat when loading the macsonic or macmace driver.
Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask").

This implementation of arch_setup_pdev_archdata() differs from the one
in arch/powerpc in that this one avoids clobbering an existing dma mask.
For example, this approach preserves the mask set by the initializer for
struct platform_device mcf_fec0.

Note that either approach would make that initializer redundant and
commit f61e64310b75 ("m68k: set dma and coherent masks for platform
FEC ethernets") could be reverted.
---
 arch/m68k/kernel/dma.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index c01b9b8f97bf..463572c4943f 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -165,3 +166,12 @@ const struct dma_map_ops m68k_dma_ops = {
.sync_sg_for_device = m68k_dma_sync_sg_for_device,
 };
 EXPORT_SYMBOL(m68k_dma_ops);
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+   if (pdev->dev.coherent_dma_mask == DMA_MASK_NONE &&
+   pdev->dev.dma_mask == NULL) {
+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   pdev->dev.dma_mask = >dev.coherent_dma_mask;
+   }
+}
-- 
2.16.1



[RFC] m68k: Set up dma mask for platform devices

2018-05-12 Thread Finn Thain
This avoids a WARNING splat when loading the macsonic or macmace driver.
Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask").

This implementation of arch_setup_pdev_archdata() differs from the one
in arch/powerpc in that this one avoids clobbering an existing dma mask.
For example, this approach preserves the mask set by the initializer for
struct platform_device mcf_fec0.

Note that either approach would make that initializer redundant and
commit f61e64310b75 ("m68k: set dma and coherent masks for platform
FEC ethernets") could be reverted.
---
 arch/m68k/kernel/dma.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index c01b9b8f97bf..463572c4943f 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -165,3 +166,12 @@ const struct dma_map_ops m68k_dma_ops = {
.sync_sg_for_device = m68k_dma_sync_sg_for_device,
 };
 EXPORT_SYMBOL(m68k_dma_ops);
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+   if (pdev->dev.coherent_dma_mask == DMA_MASK_NONE &&
+   pdev->dev.dma_mask == NULL) {
+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   pdev->dev.dma_mask = >dev.coherent_dma_mask;
+   }
+}
-- 
2.16.1



[PATCH] iio: tsl2583: correct values in integration_time_available

2018-05-12 Thread Brian Masney
The times reported by the in_illuminance_integration_time_available
sysfs attribute are actually in milliseconds, not microseconds. This
patch corrects the times with the correct unit.

Signed-off-by: Brian Masney 
---
 drivers/iio/light/tsl2583.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/tsl2583.c b/drivers/iio/light/tsl2583.c
index f2e50edaa242..4b5d9988f025 100644
--- a/drivers/iio/light/tsl2583.c
+++ b/drivers/iio/light/tsl2583.c
@@ -600,7 +600,7 @@ static ssize_t in_illuminance_lux_table_store(struct device 
*dev,
 
 static IIO_CONST_ATTR(in_illuminance_calibscale_available, "1 8 16 111");
 static IIO_CONST_ATTR(in_illuminance_integration_time_available,
- "0.50 0.000100 0.000150 0.000200 0.000250 0.000300 
0.000350 0.000400 0.000450 0.000500 0.000550 0.000600 0.000650");
+ "0.050 0.100 0.150 0.200 0.250 0.300 0.350 0.400 0.450 
0.500 0.550 0.600 0.650");
 static IIO_DEVICE_ATTR_RW(in_illuminance_input_target, 0);
 static IIO_DEVICE_ATTR_WO(in_illuminance_calibrate, 0);
 static IIO_DEVICE_ATTR_RW(in_illuminance_lux_table, 0);
-- 
2.14.3



[PATCH] iio: tsl2583: correct values in integration_time_available

2018-05-12 Thread Brian Masney
The times reported by the in_illuminance_integration_time_available
sysfs attribute are actually in milliseconds, not microseconds. This
patch corrects the times with the correct unit.

Signed-off-by: Brian Masney 
---
 drivers/iio/light/tsl2583.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/tsl2583.c b/drivers/iio/light/tsl2583.c
index f2e50edaa242..4b5d9988f025 100644
--- a/drivers/iio/light/tsl2583.c
+++ b/drivers/iio/light/tsl2583.c
@@ -600,7 +600,7 @@ static ssize_t in_illuminance_lux_table_store(struct device 
*dev,
 
 static IIO_CONST_ATTR(in_illuminance_calibscale_available, "1 8 16 111");
 static IIO_CONST_ATTR(in_illuminance_integration_time_available,
- "0.50 0.000100 0.000150 0.000200 0.000250 0.000300 
0.000350 0.000400 0.000450 0.000500 0.000550 0.000600 0.000650");
+ "0.050 0.100 0.150 0.200 0.250 0.300 0.350 0.400 0.450 
0.500 0.550 0.600 0.650");
 static IIO_DEVICE_ATTR_RW(in_illuminance_input_target, 0);
 static IIO_DEVICE_ATTR_WO(in_illuminance_calibrate, 0);
 static IIO_DEVICE_ATTR_RW(in_illuminance_lux_table, 0);
-- 
2.14.3



Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

2018-05-12 Thread Joel Fernandes
On Sat, May 12, 2018 at 07:41:19AM -0700, Paul E. McKenney wrote:
> On Fri, May 11, 2018 at 11:30:37PM -0700, Joel Fernandes wrote:
> > On Fri, May 11, 2018 at 10:08:24PM -0700, Paul E. McKenney wrote:
> > > On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> > > > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > > > > Hello folks,
> > > > > > 
> > > > > > I think I wrote the title in a misleading way.
> > > > > > 
> > > > > > Please change the title to something else such as,
> > > > > > "rcu: Report a quiescent state when it's in the state" or,
> > > > > > "rcu: Add points reporting quiescent states where proper" or so on.
> > > > > > 
> > > > > > On 2018-05-11 오후 5:30, Byungchul Park wrote:
> > > > > > >We expect a quiescent state of TASKS_RCU when 
> > > > > > >cond_resched_tasks_rcu_qs()
> > > > > > >is called, no matter whether it actually be scheduled or not. 
> > > > > > >However,
> > > > > > >it currently doesn't report the quiescent state when the task 
> > > > > > >enters
> > > > > > >into __schedule() as it's called with preempt = true. So make it 
> > > > > > >report
> > > > > > >the quiescent state unconditionally when 
> > > > > > >cond_resched_tasks_rcu_qs() is
> > > > > > >called.
> > > > > > >
> > > > > > >And in TINY_RCU, even though the quiescent state of rcu_bh also 
> > > > > > >should
> > > > > > >be reported when the tick interrupt comes from user, it doesn't. 
> > > > > > >So make
> > > > > > >it reported.
> > > > > > >
> > > > > > >Lastly in TREE_RCU, rcu_note_voluntary_context_switch() should be
> > > > > > >reported when the tick interrupt comes from not only user but also 
> > > > > > >idle,
> > > > > > >as an extended quiescent state.
> > > > > > >
> > > > > > >Signed-off-by: Byungchul Park 
> > > > > > >---
> > > > > > >  include/linux/rcupdate.h | 4 ++--
> > > > > > >  kernel/rcu/tiny.c| 6 +++---
> > > > > > >  kernel/rcu/tree.c| 4 ++--
> > > > > > >  3 files changed, 7 insertions(+), 7 deletions(-)
> > > > > > >
> > > > > > >diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > > > >index ee8cf5fc..7432261 100644
> > > > > > >--- a/include/linux/rcupdate.h
> > > > > > >+++ b/include/linux/rcupdate.h
> > > > > > >@@ -195,8 +195,8 @@ static inline void exit_tasks_rcu_finish(void) 
> > > > > > >{ }
> > > > > > >   */
> > > > > > >  #define cond_resched_tasks_rcu_qs() \
> > > > > > >  do { \
> > > > > > >-  if (!cond_resched()) \
> > > > > > >-  rcu_note_voluntary_context_switch_lite(current); \
> > > > > > >+  rcu_note_voluntary_context_switch_lite(current); \
> > > > > > >+  cond_resched(); \
> > > > > 
> > > > > Ah, good point.
> > > > > 
> > > > > Peter, I have to ask...  Why is "cond_resched()" considered a 
> > > > > preemption
> > > > > while "schedule()" is not?
> > > > 
> > > > Infact something interesting I inferred from the __schedule loop 
> > > > related to
> > > > your question:
> > > > 
> > > > switch_count can either be set to prev->invcsw or prev->nvcsw. If we can
> > > > assume that switch_count reflects whether the context switch is 
> > > > involuntary
> > > > or voluntary,
> > > >   
> > > > task-running-state  preempt switch_count
> > > > 0 (running) 1   involuntary
> > > > 0   0   involuntary
> > > > 1   0   voluntary
> > > > 1   1   involuntary
> > > > 
> > > > According to the above table, both the task's running state and the 
> > > > preempt
> > > > parameter to __schedule should be used together to determine if the 
> > > > switch is
> > > > a voluntary one or not.
> > > > 
> > > > So this code in rcu_note_context_switch should really be:
> > > > if (!preempt && !(current->state & TASK_RUNNING))
> > 
> > I should have writte here- !preempt && current->state
> > 
> > > > rcu_note_voluntary_context_switch_lite(current);
> > > > 
> > > > According to the above table, cond_resched always classifies as an
> > > > involuntary switch which makes sense to me. Even though cond_resched is
> > > > explicitly called, its still sort of involuntary in the sense its not 
> > > > called
> > > > into the scheduler for sleeping, but rather for seeing if something 
> > > > else can
> > > > run instead (a preemption point). Infact none of the task deactivation 
> > > > in the
> > > > __schedule loop will run if cond_resched is used.
> > > > 
> > > > I agree that if schedule was called directly but with TASK_RUNNING=1, 
> > > > then
> > > > that could probably be classified an involuntary switch too...
> > > > 
> > > > Also since we're deciding to call rcu_note_voluntary_context_switch_lite
> > > > unconditionally, then IMO this comment on that macro:
> > > > 
> > > > /*
> > > >  * Note a voluntary context switch for RCU-tasks benefit.  

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

2018-05-12 Thread Joel Fernandes
On Sat, May 12, 2018 at 07:41:19AM -0700, Paul E. McKenney wrote:
> On Fri, May 11, 2018 at 11:30:37PM -0700, Joel Fernandes wrote:
> > On Fri, May 11, 2018 at 10:08:24PM -0700, Paul E. McKenney wrote:
> > > On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> > > > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > > > > Hello folks,
> > > > > > 
> > > > > > I think I wrote the title in a misleading way.
> > > > > > 
> > > > > > Please change the title to something else such as,
> > > > > > "rcu: Report a quiescent state when it's in the state" or,
> > > > > > "rcu: Add points reporting quiescent states where proper" or so on.
> > > > > > 
> > > > > > On 2018-05-11 오후 5:30, Byungchul Park wrote:
> > > > > > >We expect a quiescent state of TASKS_RCU when 
> > > > > > >cond_resched_tasks_rcu_qs()
> > > > > > >is called, no matter whether it actually be scheduled or not. 
> > > > > > >However,
> > > > > > >it currently doesn't report the quiescent state when the task 
> > > > > > >enters
> > > > > > >into __schedule() as it's called with preempt = true. So make it 
> > > > > > >report
> > > > > > >the quiescent state unconditionally when 
> > > > > > >cond_resched_tasks_rcu_qs() is
> > > > > > >called.
> > > > > > >
> > > > > > >And in TINY_RCU, even though the quiescent state of rcu_bh also 
> > > > > > >should
> > > > > > >be reported when the tick interrupt comes from user, it doesn't. 
> > > > > > >So make
> > > > > > >it reported.
> > > > > > >
> > > > > > >Lastly in TREE_RCU, rcu_note_voluntary_context_switch() should be
> > > > > > >reported when the tick interrupt comes from not only user but also 
> > > > > > >idle,
> > > > > > >as an extended quiescent state.
> > > > > > >
> > > > > > >Signed-off-by: Byungchul Park 
> > > > > > >---
> > > > > > >  include/linux/rcupdate.h | 4 ++--
> > > > > > >  kernel/rcu/tiny.c| 6 +++---
> > > > > > >  kernel/rcu/tree.c| 4 ++--
> > > > > > >  3 files changed, 7 insertions(+), 7 deletions(-)
> > > > > > >
> > > > > > >diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > > > >index ee8cf5fc..7432261 100644
> > > > > > >--- a/include/linux/rcupdate.h
> > > > > > >+++ b/include/linux/rcupdate.h
> > > > > > >@@ -195,8 +195,8 @@ static inline void exit_tasks_rcu_finish(void) 
> > > > > > >{ }
> > > > > > >   */
> > > > > > >  #define cond_resched_tasks_rcu_qs() \
> > > > > > >  do { \
> > > > > > >-  if (!cond_resched()) \
> > > > > > >-  rcu_note_voluntary_context_switch_lite(current); \
> > > > > > >+  rcu_note_voluntary_context_switch_lite(current); \
> > > > > > >+  cond_resched(); \
> > > > > 
> > > > > Ah, good point.
> > > > > 
> > > > > Peter, I have to ask...  Why is "cond_resched()" considered a 
> > > > > preemption
> > > > > while "schedule()" is not?
> > > > 
> > > > Infact something interesting I inferred from the __schedule loop 
> > > > related to
> > > > your question:
> > > > 
> > > > switch_count can either be set to prev->invcsw or prev->nvcsw. If we can
> > > > assume that switch_count reflects whether the context switch is 
> > > > involuntary
> > > > or voluntary,
> > > >   
> > > > task-running-state  preempt switch_count
> > > > 0 (running) 1   involuntary
> > > > 0   0   involuntary
> > > > 1   0   voluntary
> > > > 1   1   involuntary
> > > > 
> > > > According to the above table, both the task's running state and the 
> > > > preempt
> > > > parameter to __schedule should be used together to determine if the 
> > > > switch is
> > > > a voluntary one or not.
> > > > 
> > > > So this code in rcu_note_context_switch should really be:
> > > > if (!preempt && !(current->state & TASK_RUNNING))
> > 
> > I should have writte here- !preempt && current->state
> > 
> > > > rcu_note_voluntary_context_switch_lite(current);
> > > > 
> > > > According to the above table, cond_resched always classifies as an
> > > > involuntary switch which makes sense to me. Even though cond_resched is
> > > > explicitly called, its still sort of involuntary in the sense its not 
> > > > called
> > > > into the scheduler for sleeping, but rather for seeing if something 
> > > > else can
> > > > run instead (a preemption point). Infact none of the task deactivation 
> > > > in the
> > > > __schedule loop will run if cond_resched is used.
> > > > 
> > > > I agree that if schedule was called directly but with TASK_RUNNING=1, 
> > > > then
> > > > that could probably be classified an involuntary switch too...
> > > > 
> > > > Also since we're deciding to call rcu_note_voluntary_context_switch_lite
> > > > unconditionally, then IMO this comment on that macro:
> > > > 
> > > > /*
> > > >  * Note a voluntary context switch for RCU-tasks benefit.  This is a
> > > >  * 

Re: [tip/core/rcu,16/21] rcu: Add funnel locking to rcu_start_this_gp()

2018-05-12 Thread Joel Fernandes
On Sat, May 12, 2018 at 07:44:38AM -0700, Paul E. McKenney wrote:
> On Sat, May 12, 2018 at 07:40:02AM -0700, Paul E. McKenney wrote:
> > On Fri, May 11, 2018 at 11:03:25PM -0700, Joel Fernandes wrote:
> > > On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> > > > The rcu_start_this_gp() function had a simple form of funnel locking 
> > > > that
> > > > used only the leaves and root of the rcu_node tree, which is fine for
> > > > systems with only a few hundred CPUs, but sub-optimal for systems having
> > > > thousands of CPUs.  This commit therefore adds full-tree funnel locking.
> > > > 
> > > > This variant of funnel locking is unusual in the following ways:
> > > > 
> > > > 1.  The leaf-level rcu_node structure's ->lock is held throughout.
> > > > Other funnel-locking implementations drop the leaf-level lock
> > > > before progressing to the next level of the tree.
> > > > 
> > > > 2.  Funnel locking can be started at the root, which is convenient
> > > > for code that already holds the root rcu_node structure's 
> > > > ->lock.
> > > > Other funnel-locking implementations start at the leaves.
> > > > 
> > > > 3.  If an rcu_node structure other than the initial one believes
> > > > that a grace period is in progress, it is not necessary to
> > > > go further up the tree.  This is because grace-period cleanup
> > > > scans the full tree, so that marking the need for a subsequent
> > > > grace period anywhere in the tree suffices -- but only if
> > > > a grace period is currently in progress.
> > > > 
> > > > 4.  It is possible that the RCU grace-period kthread has not yet
> > > > started, and this case must be handled appropriately.
> > > > 
> > > > However, the general approach of using a tree to control lock contention
> > > > is still in place.
> > > > 
> > > > Signed-off-by: Paul E. McKenney 
> > > > ---
> > > >  kernel/rcu/tree.c | 92 
> > > > +--
> > > >  1 file changed, 35 insertions(+), 57 deletions(-)
> > > > 
> > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > index 94519c7d552f..d3c769502929 100644
> > > > --- a/kernel/rcu/tree.c
> > > > +++ b/kernel/rcu/tree.c
> > > > @@ -1682,74 +1682,52 @@ static bool rcu_start_this_gp(struct rcu_node 
> > > > *rnp, struct rcu_data *rdp,
> > > >  {
> > > > bool ret = false;
> > > > struct rcu_state *rsp = rdp->rsp;
> > > > -   struct rcu_node *rnp_root = rcu_get_root(rsp);
> > > > -
> > > > -   raw_lockdep_assert_held_rcu_node(rnp);
> > > > -
> > > > -   /* If the specified GP is already known needed, return to 
> > > > caller. */
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > -   if (need_future_gp_element(rnp, c)) {
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Prestartleaf"));
> > > > -   goto out;
> > > > -   }
> > > > +   struct rcu_node *rnp_root;
> > > >  
> > > > /*
> > > > -* If this rcu_node structure believes that a grace period is in
> > > > -* progress, then we must wait for the one following, which is 
> > > > in
> > > > -* "c".  Because our request will be noticed at the end of the
> > > > -* current grace period, we don't need to explicitly start one.
> > > > +* Use funnel locking to either acquire the root rcu_node
> > > > +* structure's lock or bail out if the need for this grace 
> > > > period
> > > > +* has already been recorded -- or has already started.  If 
> > > > there
> > > > +* is already a grace period in progress in a non-leaf node, no
> > > > +* recording is needed because the end of the grace period will
> > > > +* scan the leaf rcu_node structures.  Note that rnp->lock must
> > > > +* not be released.
> > > >  */
> > > > -   if (rnp->gpnum != rnp->completed) {
> > > > -   need_future_gp_element(rnp, c) = true;
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Startedleaf"));
> > > > -   goto out;
> > > 
> > > Referring to the above negative diff as [1] (which I wanted to refer to 
> > > later
> > > in this message..)
> > > 
> > > > +   raw_lockdep_assert_held_rcu_node(rnp);
> > > > +   trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > +   for (rnp_root = rnp; 1; rnp_root = rnp_root->parent) {
> > > > +   if (rnp_root != rnp)
> > > > +   raw_spin_lock_rcu_node(rnp_root);
> > > > +   if (need_future_gp_element(rnp_root, c) ||
> > > > +   ULONG_CMP_GE(rnp_root->gpnum, c) ||
> > > > +   (rnp != rnp_root &&
> > > > +rnp_root->gpnum != rnp_root->completed)) {
> > > > +   trace_rcu_this_gp(rnp_root, rdp, c, 
> > > > TPS("Prestarted"));
> > > > +  

Re: [tip/core/rcu,16/21] rcu: Add funnel locking to rcu_start_this_gp()

2018-05-12 Thread Joel Fernandes
On Sat, May 12, 2018 at 07:44:38AM -0700, Paul E. McKenney wrote:
> On Sat, May 12, 2018 at 07:40:02AM -0700, Paul E. McKenney wrote:
> > On Fri, May 11, 2018 at 11:03:25PM -0700, Joel Fernandes wrote:
> > > On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> > > > The rcu_start_this_gp() function had a simple form of funnel locking 
> > > > that
> > > > used only the leaves and root of the rcu_node tree, which is fine for
> > > > systems with only a few hundred CPUs, but sub-optimal for systems having
> > > > thousands of CPUs.  This commit therefore adds full-tree funnel locking.
> > > > 
> > > > This variant of funnel locking is unusual in the following ways:
> > > > 
> > > > 1.  The leaf-level rcu_node structure's ->lock is held throughout.
> > > > Other funnel-locking implementations drop the leaf-level lock
> > > > before progressing to the next level of the tree.
> > > > 
> > > > 2.  Funnel locking can be started at the root, which is convenient
> > > > for code that already holds the root rcu_node structure's 
> > > > ->lock.
> > > > Other funnel-locking implementations start at the leaves.
> > > > 
> > > > 3.  If an rcu_node structure other than the initial one believes
> > > > that a grace period is in progress, it is not necessary to
> > > > go further up the tree.  This is because grace-period cleanup
> > > > scans the full tree, so that marking the need for a subsequent
> > > > grace period anywhere in the tree suffices -- but only if
> > > > a grace period is currently in progress.
> > > > 
> > > > 4.  It is possible that the RCU grace-period kthread has not yet
> > > > started, and this case must be handled appropriately.
> > > > 
> > > > However, the general approach of using a tree to control lock contention
> > > > is still in place.
> > > > 
> > > > Signed-off-by: Paul E. McKenney 
> > > > ---
> > > >  kernel/rcu/tree.c | 92 
> > > > +--
> > > >  1 file changed, 35 insertions(+), 57 deletions(-)
> > > > 
> > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > index 94519c7d552f..d3c769502929 100644
> > > > --- a/kernel/rcu/tree.c
> > > > +++ b/kernel/rcu/tree.c
> > > > @@ -1682,74 +1682,52 @@ static bool rcu_start_this_gp(struct rcu_node 
> > > > *rnp, struct rcu_data *rdp,
> > > >  {
> > > > bool ret = false;
> > > > struct rcu_state *rsp = rdp->rsp;
> > > > -   struct rcu_node *rnp_root = rcu_get_root(rsp);
> > > > -
> > > > -   raw_lockdep_assert_held_rcu_node(rnp);
> > > > -
> > > > -   /* If the specified GP is already known needed, return to 
> > > > caller. */
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > -   if (need_future_gp_element(rnp, c)) {
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Prestartleaf"));
> > > > -   goto out;
> > > > -   }
> > > > +   struct rcu_node *rnp_root;
> > > >  
> > > > /*
> > > > -* If this rcu_node structure believes that a grace period is in
> > > > -* progress, then we must wait for the one following, which is 
> > > > in
> > > > -* "c".  Because our request will be noticed at the end of the
> > > > -* current grace period, we don't need to explicitly start one.
> > > > +* Use funnel locking to either acquire the root rcu_node
> > > > +* structure's lock or bail out if the need for this grace 
> > > > period
> > > > +* has already been recorded -- or has already started.  If 
> > > > there
> > > > +* is already a grace period in progress in a non-leaf node, no
> > > > +* recording is needed because the end of the grace period will
> > > > +* scan the leaf rcu_node structures.  Note that rnp->lock must
> > > > +* not be released.
> > > >  */
> > > > -   if (rnp->gpnum != rnp->completed) {
> > > > -   need_future_gp_element(rnp, c) = true;
> > > > -   trace_rcu_this_gp(rnp, rdp, c, TPS("Startedleaf"));
> > > > -   goto out;
> > > 
> > > Referring to the above negative diff as [1] (which I wanted to refer to 
> > > later
> > > in this message..)
> > > 
> > > > +   raw_lockdep_assert_held_rcu_node(rnp);
> > > > +   trace_rcu_this_gp(rnp, rdp, c, TPS("Startleaf"));
> > > > +   for (rnp_root = rnp; 1; rnp_root = rnp_root->parent) {
> > > > +   if (rnp_root != rnp)
> > > > +   raw_spin_lock_rcu_node(rnp_root);
> > > > +   if (need_future_gp_element(rnp_root, c) ||
> > > > +   ULONG_CMP_GE(rnp_root->gpnum, c) ||
> > > > +   (rnp != rnp_root &&
> > > > +rnp_root->gpnum != rnp_root->completed)) {
> > > > +   trace_rcu_this_gp(rnp_root, rdp, c, 
> > > > TPS("Prestarted"));
> > > > +   goto unlock_out;
> > > 

[PATCH] MAINTAINERS: add entry for LEGO MINDSTORMS EV3

2018-05-12 Thread David Lechner
This adds an entry to MAINTAINERS for LEGO MINDSTORMS EV3 (an ARM-based
robotics platform). The files listed are exclusive to this device. Add
me as reviewer so that I will be cc'ed for any changes to these files.

Signed-off-by: David Lechner 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index df6e9bb2559a..2e057e0138b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7960,6 +7960,13 @@ S:   Maintained
 F: Documentation/misc-devices/eeprom
 F: drivers/misc/eeprom/eeprom.c
 
+LEGO MINDSTORMS EV3
+R: David Lechner 
+S: Maintained
+F: arch/arm/boot/dts/da850-lego-ev3.dts
+F: Documentation/devicetree/bindings/power/supply/lego_ev3_battery.txt
+F: drivers/power/supply/lego_ev3_battery.c
+
 LEGO USB Tower driver
 M: Juergen Stuber 
 L: legousb-de...@lists.sourceforge.net
-- 
2.17.0



[PATCH] MAINTAINERS: add entry for LEGO MINDSTORMS EV3

2018-05-12 Thread David Lechner
This adds an entry to MAINTAINERS for LEGO MINDSTORMS EV3 (an ARM-based
robotics platform). The files listed are exclusive to this device. Add
me as reviewer so that I will be cc'ed for any changes to these files.

Signed-off-by: David Lechner 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index df6e9bb2559a..2e057e0138b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7960,6 +7960,13 @@ S:   Maintained
 F: Documentation/misc-devices/eeprom
 F: drivers/misc/eeprom/eeprom.c
 
+LEGO MINDSTORMS EV3
+R: David Lechner 
+S: Maintained
+F: arch/arm/boot/dts/da850-lego-ev3.dts
+F: Documentation/devicetree/bindings/power/supply/lego_ev3_battery.txt
+F: drivers/power/supply/lego_ev3_battery.c
+
 LEGO USB Tower driver
 M: Juergen Stuber 
 L: legousb-de...@lists.sourceforge.net
-- 
2.17.0



Re: BUG: workqueue lockup (2)

2018-05-12 Thread Eric Biggers
On Tue, Dec 19, 2017 at 04:25:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 37s!
> BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=-20 stuck for 32s!
> Showing busy workqueues and worker pools:
> workqueue events: flags=0x0
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> pending: cache_reap
> workqueue events_power_efficient: flags=0x80
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> pending: neigh_periodic_work, do_cache_clean
> workqueue mm_percpu_wq: flags=0x8
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> pending: vmstat_update
> workqueue kblockd: flags=0x18
>   pwq 3: cpus=1 node=0 flags=0x0 nice=-20 active=1/256
> pending: blk_timeout_work
> 

The bug that this reproducer reproduces was fixed a while ago by commit
966031f340185e, so I'm marking this bug report fixed by it:

#syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

Note that the error message was not always "BUG: workqueue lockup"; it was also
sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".

syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it must
be for other reasons.  None has a reproducer currently.

- Eric


Re: BUG: workqueue lockup (2)

2018-05-12 Thread Eric Biggers
On Tue, Dec 19, 2017 at 04:25:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 37s!
> BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=-20 stuck for 32s!
> Showing busy workqueues and worker pools:
> workqueue events: flags=0x0
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> pending: cache_reap
> workqueue events_power_efficient: flags=0x80
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
> pending: neigh_periodic_work, do_cache_clean
> workqueue mm_percpu_wq: flags=0x8
>   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> pending: vmstat_update
> workqueue kblockd: flags=0x18
>   pwq 3: cpus=1 node=0 flags=0x0 nice=-20 active=1/256
> pending: blk_timeout_work
> 

The bug that this reproducer reproduces was fixed a while ago by commit
966031f340185e, so I'm marking this bug report fixed by it:

#syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

Note that the error message was not always "BUG: workqueue lockup"; it was also
sometimes like "watchdog: BUG: soft lockup - CPU#5 stuck for 22s!".

syzbot still is hitting the "BUG: workqueue lockup" error sometimes, but it must
be for other reasons.  None has a reproducer currently.

- Eric


Re: [RFC PATCH v3 0/5] usb: typec: Support for Alternate Modes

2018-05-12 Thread Guenter Roeck

On 05/11/2018 06:18 AM, Heikki Krogerus wrote:

Hi,

This is the third version of my proposal for more complete alternate
mode support. In this version I'm including a proposal for the mux
handling. Basically, I'm proposing that every supported alternate will
have its own mux handle. That should allow us to support multiple
alternate modes at the same time. There is also a small change to how
I handled enter/exit mode commands. Now the alternate mode drivers
will need to check if Enter Mode command ACK/NAK. The ->enter callback
is not called in those cases separately. The typec_altmode_enter/exit
functions are used only when the command is initiated. Other than
that, only minor tuning.



I like the both the idea and the approach. I browsed through the code,
but I don't see anything obviously wrong with it. Too bad I wont have
the time for an actual alternate mode implementation. Are you working
on one, by any chance ? I would like to see this move forward, and an
actual implementation would help to get there.

Thanks,
Guenter



v2 commit message:

This is second version of my proposal for more complete USB Type-C
Alternate Mode support. The original proposal can be read from here:
https://www.spinics.net/lists/linux-usb/msg161098.html

These patches now depend on series from Hans where he is introducing
mux handling support for USB Type-C and USB in general:
https://lkml.org/lkml/2018/3/2/340

The major difference compared to v1 is that I'm proposing change to
the sysfs ABI we have for the alternate mode devices. The files are
not changed, but they are moved to the parent directory from the
mode folder. Since the alternate mode devices are not yet used
and in practice not supported in mainline, I felt brave enough to
propose that.

The reason for removing the mode folder is because as in patch
1/3 I now create a device for every mode of every SVID, there will
never be more then one mode folder. I.e. the folder serves no purpose.
The mode is still kept for now, but it's just deprecated.

There are no alternate mode drivers included yet in this version.


Original commit message (subject was "usb: typec: alternate mode
bus"):

The bus allows SVID specific communication with the partners to be
handled in separate drivers for each alternate mode.

Alternate mode handling happens with two separate logical devices:
1. Partner alternate mode devices which represent the alternate modes
on the partner. The driver for them will handle the alternate mode
specific communication with the partner using VDMs.
2. Port alternate mode devices which represent connections from the
USB Type-C port to devices on the platform.

The drivers will be bind to the partner alternate modes. The alternate
mode drivers will need to deliver the result of the negotiated pin
configurations to the rest of the platform (towards the port alternate
mode devices). This series includes API for that, however, not the
final implementation yet.

The connections to the other devices on the platform the ports have
can be described by using the remote endpoint concept [1][2] on ACPI
and DT platforms, but I have no solution for the "platform data" case
where we have neither DT nor ACPI to describe the connections for us.

[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/acpi/dsd/graph.txt


Heikki Krogerus (5):
   usb: typec: mux: Get the mux identifier from function parameter
   usb: typec: Register a device for every mode
   usb: typec: Bus type for alternate modes
   usb: typec: pi3usb30532: Start using generic state values
   usb: typec: tcpm: Support for Alternate Modes

  Documentation/ABI/obsolete/sysfs-class-typec |  48 ++
  Documentation/ABI/testing/sysfs-bus-typec|  51 ++
  Documentation/ABI/testing/sysfs-class-typec  |  62 +--
  Documentation/driver-api/usb/typec_bus.rst   | 136 ++
  drivers/usb/typec/Makefile   |   2 +-
  drivers/usb/typec/bus.c  | 423 +
  drivers/usb/typec/bus.h  |  38 ++
  drivers/usb/typec/class.c| 472 ---
  drivers/usb/typec/mux.c  |   6 +-
  drivers/usb/typec/mux/pi3usb30532.c  |  11 +-
  drivers/usb/typec/tcpm.c | 179 +--
  include/linux/mod_devicetable.h  |  15 +
  include/linux/usb/tcpm.h |   9 -
  include/linux/usb/typec.h|  51 +-
  include/linux/usb/typec_altmode.h| 142 ++
  include/linux/usb/typec_mux.h|   2 +-
  scripts/mod/devicetable-offsets.c|   4 +
  scripts/mod/file2alias.c |  13 +
  18 files changed, 1347 insertions(+), 317 deletions(-)
  create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
  create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
  create mode 100644 Documentation/driver-api/usb/typec_bus.rst
  create mode 100644 drivers/usb/typec/bus.c
  create mode 100644 

[PATCH] ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties

2018-05-12 Thread David Lechner
This removes the #address-cells and #size-cells properties from the
gpio-keys node in the da850-lego-ev3 device tree. These properties are
not needed since the child nodes don't have a reg property.

Signed-off-by: David Lechner 
---
 arch/arm/boot/dts/da850-lego-ev3.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
index d4a131b6a46e..3fe8db69f50c 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -33,8 +33,6 @@
 */
gpio_keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
label = "EV3 Brick Buttons";
pinctrl-names = "default";
pinctrl-0 = <_bias>;
-- 
2.17.0



Re: [RFC PATCH v3 0/5] usb: typec: Support for Alternate Modes

2018-05-12 Thread Guenter Roeck

On 05/11/2018 06:18 AM, Heikki Krogerus wrote:

Hi,

This is the third version of my proposal for more complete alternate
mode support. In this version I'm including a proposal for the mux
handling. Basically, I'm proposing that every supported alternate will
have its own mux handle. That should allow us to support multiple
alternate modes at the same time. There is also a small change to how
I handled enter/exit mode commands. Now the alternate mode drivers
will need to check if Enter Mode command ACK/NAK. The ->enter callback
is not called in those cases separately. The typec_altmode_enter/exit
functions are used only when the command is initiated. Other than
that, only minor tuning.



I like the both the idea and the approach. I browsed through the code,
but I don't see anything obviously wrong with it. Too bad I wont have
the time for an actual alternate mode implementation. Are you working
on one, by any chance ? I would like to see this move forward, and an
actual implementation would help to get there.

Thanks,
Guenter



v2 commit message:

This is second version of my proposal for more complete USB Type-C
Alternate Mode support. The original proposal can be read from here:
https://www.spinics.net/lists/linux-usb/msg161098.html

These patches now depend on series from Hans where he is introducing
mux handling support for USB Type-C and USB in general:
https://lkml.org/lkml/2018/3/2/340

The major difference compared to v1 is that I'm proposing change to
the sysfs ABI we have for the alternate mode devices. The files are
not changed, but they are moved to the parent directory from the
mode folder. Since the alternate mode devices are not yet used
and in practice not supported in mainline, I felt brave enough to
propose that.

The reason for removing the mode folder is because as in patch
1/3 I now create a device for every mode of every SVID, there will
never be more then one mode folder. I.e. the folder serves no purpose.
The mode is still kept for now, but it's just deprecated.

There are no alternate mode drivers included yet in this version.


Original commit message (subject was "usb: typec: alternate mode
bus"):

The bus allows SVID specific communication with the partners to be
handled in separate drivers for each alternate mode.

Alternate mode handling happens with two separate logical devices:
1. Partner alternate mode devices which represent the alternate modes
on the partner. The driver for them will handle the alternate mode
specific communication with the partner using VDMs.
2. Port alternate mode devices which represent connections from the
USB Type-C port to devices on the platform.

The drivers will be bind to the partner alternate modes. The alternate
mode drivers will need to deliver the result of the negotiated pin
configurations to the rest of the platform (towards the port alternate
mode devices). This series includes API for that, however, not the
final implementation yet.

The connections to the other devices on the platform the ports have
can be described by using the remote endpoint concept [1][2] on ACPI
and DT platforms, but I have no solution for the "platform data" case
where we have neither DT nor ACPI to describe the connections for us.

[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/acpi/dsd/graph.txt


Heikki Krogerus (5):
   usb: typec: mux: Get the mux identifier from function parameter
   usb: typec: Register a device for every mode
   usb: typec: Bus type for alternate modes
   usb: typec: pi3usb30532: Start using generic state values
   usb: typec: tcpm: Support for Alternate Modes

  Documentation/ABI/obsolete/sysfs-class-typec |  48 ++
  Documentation/ABI/testing/sysfs-bus-typec|  51 ++
  Documentation/ABI/testing/sysfs-class-typec  |  62 +--
  Documentation/driver-api/usb/typec_bus.rst   | 136 ++
  drivers/usb/typec/Makefile   |   2 +-
  drivers/usb/typec/bus.c  | 423 +
  drivers/usb/typec/bus.h  |  38 ++
  drivers/usb/typec/class.c| 472 ---
  drivers/usb/typec/mux.c  |   6 +-
  drivers/usb/typec/mux/pi3usb30532.c  |  11 +-
  drivers/usb/typec/tcpm.c | 179 +--
  include/linux/mod_devicetable.h  |  15 +
  include/linux/usb/tcpm.h |   9 -
  include/linux/usb/typec.h|  51 +-
  include/linux/usb/typec_altmode.h| 142 ++
  include/linux/usb/typec_mux.h|   2 +-
  scripts/mod/devicetable-offsets.c|   4 +
  scripts/mod/file2alias.c |  13 +
  18 files changed, 1347 insertions(+), 317 deletions(-)
  create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
  create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
  create mode 100644 Documentation/driver-api/usb/typec_bus.rst
  create mode 100644 drivers/usb/typec/bus.c
  create mode 100644 

[PATCH] ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties

2018-05-12 Thread David Lechner
This removes the #address-cells and #size-cells properties from the
gpio-keys node in the da850-lego-ev3 device tree. These properties are
not needed since the child nodes don't have a reg property.

Signed-off-by: David Lechner 
---
 arch/arm/boot/dts/da850-lego-ev3.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
index d4a131b6a46e..3fe8db69f50c 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -33,8 +33,6 @@
 */
gpio_keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
label = "EV3 Brick Buttons";
pinctrl-names = "default";
pinctrl-0 = <_bias>;
-- 
2.17.0



Re: [PATCH] staging: lustre: Use 'kvfree()' for memory allocated by 'kvzalloc()'

2018-05-12 Thread NeilBrown
On Sat, May 12 2018, Christophe JAILLET wrote:

> 'buf' is allocated with 'kvzalloc()'. 'kvfree()' must be used to free it.
>
> Signed-off-by: Christophe JAILLET 

Reviewed-by: NeilBrown 

Thanks.
We could possible add:
Fixes: 11c647caf74b ("staging: lustre: obdclass: variable llog chunk size")

just for completeness.

NeilBrown

> ---
>  drivers/staging/lustre/lustre/obdclass/llog.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c 
> b/drivers/staging/lustre/lustre/obdclass/llog.c
> index 693e1129f1f9..5e04d133b596 100644
> --- a/drivers/staging/lustre/lustre/obdclass/llog.c
> +++ b/drivers/staging/lustre/lustre/obdclass/llog.c
> @@ -385,7 +385,7 @@ static int llog_process_thread(void *arg)
>   if (cd)
>   cd->lpcd_last_idx = last_called_index;
>  
> - kfree(buf);
> + kvfree(buf);
>   lpi->lpi_rc = rc;
>   return 0;
>  }
> -- 
> 2.17.0


signature.asc
Description: PGP signature


Re: [PATCH] staging: lustre: Use 'kvfree()' for memory allocated by 'kvzalloc()'

2018-05-12 Thread NeilBrown
On Sat, May 12 2018, Christophe JAILLET wrote:

> 'buf' is allocated with 'kvzalloc()'. 'kvfree()' must be used to free it.
>
> Signed-off-by: Christophe JAILLET 

Reviewed-by: NeilBrown 

Thanks.
We could possible add:
Fixes: 11c647caf74b ("staging: lustre: obdclass: variable llog chunk size")

just for completeness.

NeilBrown

> ---
>  drivers/staging/lustre/lustre/obdclass/llog.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c 
> b/drivers/staging/lustre/lustre/obdclass/llog.c
> index 693e1129f1f9..5e04d133b596 100644
> --- a/drivers/staging/lustre/lustre/obdclass/llog.c
> +++ b/drivers/staging/lustre/lustre/obdclass/llog.c
> @@ -385,7 +385,7 @@ static int llog_process_thread(void *arg)
>   if (cd)
>   cd->lpcd_last_idx = last_called_index;
>  
> - kfree(buf);
> + kvfree(buf);
>   lpi->lpi_rc = rc;
>   return 0;
>  }
> -- 
> 2.17.0


signature.asc
Description: PGP signature


Herzlichen Glückwunsch

2018-05-12 Thread Euro Millions
Herzlichen Glückwunsch, Sie haben €650.000,00 bei den monatlichen Gewinnspielen 
von Euro Millions / Google Promo am 5. Mai 2018 gewonnen.

Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden 
Informationen

Vollständiger Name
Heimatadresse
Geschlecht
Alter
Besetzung
Telefon

Mr.Rainer Wagner
Online-Koordinator 


Herzlichen Glückwunsch

2018-05-12 Thread Euro Millions
Herzlichen Glückwunsch, Sie haben €650.000,00 bei den monatlichen Gewinnspielen 
von Euro Millions / Google Promo am 5. Mai 2018 gewonnen.

Kontaktieren Sie unseren Schadenregulierungsbeauftragten mit den folgenden 
Informationen

Vollständiger Name
Heimatadresse
Geschlecht
Alter
Besetzung
Telefon

Mr.Rainer Wagner
Online-Koordinator 


Re: [RFC PATCH v3 5/5] usb: typec: tcpm: Support for Alternate Modes

2018-05-12 Thread Andy Shevchenko
On Fri, May 11, 2018 at 4:18 PM, Heikki Krogerus
 wrote:
> This adds more complete handling of VDMs and registration of
> partner alternate modes, and introduces callbacks for
> alternate mode operations.
>
> Only DFP role is supported for now.

> +   for (i = 0; i < cnt; i++)
> +   p[i] = le32_to_cpu(payload[i]);

I would recommend to consider to use le32_to_cpu_array().

Though, actually we have slightly different API for BE and LE cases.
For LE existing would be renamed to rather le32_to_cpus_array() and
establishing the former one in the similar way how be32_to_cpu_array()
is implemented.


-- 
With Best Regards,
Andy Shevchenko


Re: [RFC PATCH v3 5/5] usb: typec: tcpm: Support for Alternate Modes

2018-05-12 Thread Andy Shevchenko
On Fri, May 11, 2018 at 4:18 PM, Heikki Krogerus
 wrote:
> This adds more complete handling of VDMs and registration of
> partner alternate modes, and introduces callbacks for
> alternate mode operations.
>
> Only DFP role is supported for now.

> +   for (i = 0; i < cnt; i++)
> +   p[i] = le32_to_cpu(payload[i]);

I would recommend to consider to use le32_to_cpu_array().

Though, actually we have slightly different API for BE and LE cases.
For LE existing would be renamed to rather le32_to_cpus_array() and
establishing the former one in the similar way how be32_to_cpu_array()
is implemented.


-- 
With Best Regards,
Andy Shevchenko


[tip:x86/cpu] x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  3986a0a805e668a63fac0ca2cdfa8db951f87c4b
Gitweb: https://git.kernel.org/tip/3986a0a805e668a63fac0ca2cdfa8db951f87c4b
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:48:01 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:16 +0200

x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available

Derive topology information from Extended Topology Enumeration (CPUID
function 0xB) when the information is available.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524865681-112110-3-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/kernel/cpu/amd.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index bf27246bb7bd..55361ee04cc5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -327,6 +327,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
 
/* get information required for multi-node processors */
if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+   int err;
u32 eax, ebx, ecx, edx;
 
cpuid(0x801e, , , , );
@@ -344,6 +345,14 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
c->x86_max_cores /= smp_num_siblings;
}
 
+   /*
+* In case leaf B is available, use it to derive
+* topology information.
+*/
+   err = detect_extended_topology(c);
+   if (!err)
+   c->x86_coreid_bits = get_count_order(c->x86_max_cores);
+
cacheinfo_amd_init_llc_id(c, cpu, node_id);
 
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
@@ -378,7 +387,6 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
c->phys_proc_id = c->initial_apicid >> bits;
/* use socket ID also for last level cache */
per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
-   amd_get_topology(c);
 }
 
 u16 amd_get_nb_id(int cpu)
@@ -821,6 +829,7 @@ static void init_amd(struct cpuinfo_x86 *c)
/* Multi core CPU? */
if (c->extended_cpuid_level >= 0x8008) {
amd_detect_cmp(c);
+   amd_get_topology(c);
srat_detect_node(c);
}
 


[tip:x86/cpu] x86/CPU: Modify detect_extended_topology() to return result

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  6c4f5abaf3566dbf5b26e7b14f4392be400f12e3
Gitweb: https://git.kernel.org/tip/6c4f5abaf3566dbf5b26e7b14f4392be400f12e3
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:48:00 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:16 +0200

x86/CPU: Modify detect_extended_topology() to return result

Current implementation does not communicate whether it can successfully
detect CPUID function 0xB information. Therefore, modify the function to
return success or error codes. This will be used by subsequent patches.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Link: 
http://lkml.kernel.org/r/1524865681-112110-2-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/processor.h | 2 +-
 arch/x86/kernel/cpu/topology.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4fa4206029e3..7aa2caa82b2d 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -193,7 +193,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
-extern void detect_extended_topology(struct cpuinfo_x86 *c);
+extern int detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index b099024d339c..81c0afb39d0a 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -27,7 +27,7 @@
  * exists, use it for populating initial_apicid and cpu topology
  * detection.
  */
-void detect_extended_topology(struct cpuinfo_x86 *c)
+int detect_extended_topology(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
unsigned int eax, ebx, ecx, edx, sub_index;
@@ -36,7 +36,7 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
static bool printed;
 
if (c->cpuid_level < 0xb)
-   return;
+   return -1;
 
cpuid_count(0xb, SMT_LEVEL, , , , );
 
@@ -44,7 +44,7 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
 * check if the cpuid leaf 0xb is actually implemented.
 */
if (ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE))
-   return;
+   return -1;
 
set_cpu_cap(c, X86_FEATURE_XTOPOLOGY);
 
@@ -95,6 +95,6 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
   c->cpu_core_id);
printed = 1;
}
-   return;
 #endif
+   return 0;
 }


[tip:x86/cpu] x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  3986a0a805e668a63fac0ca2cdfa8db951f87c4b
Gitweb: https://git.kernel.org/tip/3986a0a805e668a63fac0ca2cdfa8db951f87c4b
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:48:01 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:16 +0200

x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available

Derive topology information from Extended Topology Enumeration (CPUID
function 0xB) when the information is available.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524865681-112110-3-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/kernel/cpu/amd.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index bf27246bb7bd..55361ee04cc5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -327,6 +327,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
 
/* get information required for multi-node processors */
if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+   int err;
u32 eax, ebx, ecx, edx;
 
cpuid(0x801e, , , , );
@@ -344,6 +345,14 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
c->x86_max_cores /= smp_num_siblings;
}
 
+   /*
+* In case leaf B is available, use it to derive
+* topology information.
+*/
+   err = detect_extended_topology(c);
+   if (!err)
+   c->x86_coreid_bits = get_count_order(c->x86_max_cores);
+
cacheinfo_amd_init_llc_id(c, cpu, node_id);
 
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
@@ -378,7 +387,6 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
c->phys_proc_id = c->initial_apicid >> bits;
/* use socket ID also for last level cache */
per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
-   amd_get_topology(c);
 }
 
 u16 amd_get_nb_id(int cpu)
@@ -821,6 +829,7 @@ static void init_amd(struct cpuinfo_x86 *c)
/* Multi core CPU? */
if (c->extended_cpuid_level >= 0x8008) {
amd_detect_cmp(c);
+   amd_get_topology(c);
srat_detect_node(c);
}
 


[tip:x86/cpu] x86/CPU: Modify detect_extended_topology() to return result

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  6c4f5abaf3566dbf5b26e7b14f4392be400f12e3
Gitweb: https://git.kernel.org/tip/6c4f5abaf3566dbf5b26e7b14f4392be400f12e3
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:48:00 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:16 +0200

x86/CPU: Modify detect_extended_topology() to return result

Current implementation does not communicate whether it can successfully
detect CPUID function 0xB information. Therefore, modify the function to
return success or error codes. This will be used by subsequent patches.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Link: 
http://lkml.kernel.org/r/1524865681-112110-2-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/processor.h | 2 +-
 arch/x86/kernel/cpu/topology.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4fa4206029e3..7aa2caa82b2d 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -193,7 +193,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
-extern void detect_extended_topology(struct cpuinfo_x86 *c);
+extern int detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index b099024d339c..81c0afb39d0a 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -27,7 +27,7 @@
  * exists, use it for populating initial_apicid and cpu topology
  * detection.
  */
-void detect_extended_topology(struct cpuinfo_x86 *c)
+int detect_extended_topology(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
unsigned int eax, ebx, ecx, edx, sub_index;
@@ -36,7 +36,7 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
static bool printed;
 
if (c->cpuid_level < 0xb)
-   return;
+   return -1;
 
cpuid_count(0xb, SMT_LEVEL, , , , );
 
@@ -44,7 +44,7 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
 * check if the cpuid leaf 0xb is actually implemented.
 */
if (ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE))
-   return;
+   return -1;
 
set_cpu_cap(c, X86_FEATURE_XTOPOLOGY);
 
@@ -95,6 +95,6 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
   c->cpu_core_id);
printed = 1;
}
-   return;
 #endif
+   return 0;
 }


[tip:x86/cpu] x86/CPU/AMD: Calculate last level cache ID from number of sharing threads

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  68091ee7ac3c1a8786fe1bebbd616b14236efb99
Gitweb: https://git.kernel.org/tip/68091ee7ac3c1a8786fe1bebbd616b14236efb99
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:34:37 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

x86/CPU/AMD: Calculate last level cache ID from number of sharing threads

Last Level Cache ID can be calculated from the number of threads sharing
the cache, which is available from CPUID Fn0x801D (Cache Properties).
This is used to left-shift the APIC ID to derive LLC ID.

Therefore, default to this method unless the APIC ID enumeration does not
follow the scheme.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-5-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/cacheinfo.h |  7 +++
 arch/x86/kernel/cpu/amd.c| 19 +++
 arch/x86/kernel/cpu/cacheinfo.c  | 39 +++
 3 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
new file mode 100644
index ..e958e28f7ab5
--- /dev/null
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_CACHEINFO_H
+#define _ASM_X86_CACHEINFO_H
+
+void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
+
+#endif /* _ASM_X86_CACHEINFO_H */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a37a83809665..bf27246bb7bd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -343,22 +344,8 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
c->x86_max_cores /= smp_num_siblings;
}
 
-   /*
-* We may have multiple LLCs if L3 caches exist, so check if we
-* have an L3 cache by looking at the L3 cache CPUID leaf.
-*/
-   if (cpuid_edx(0x8006)) {
-   if (c->x86 == 0x17) {
-   /*
-* LLC is at the core complex level.
-* Core complex id is ApicId[3].
-*/
-   per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
-   } else {
-   /* LLC is at the node level. */
-   per_cpu(cpu_llc_id, cpu) = node_id;
-   }
-   }
+   cacheinfo_amd_init_llc_id(c, cpu, node_id);
+
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
 
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 54d04d574148..a2e03c9401a1 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -637,6 +637,45 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
return i;
 }
 
+void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
+{
+   /*
+* We may have multiple LLCs if L3 caches exist, so check if we
+* have an L3 cache by looking at the L3 cache CPUID leaf.
+*/
+   if (!cpuid_edx(0x8006))
+   return;
+
+   if (c->x86 < 0x17) {
+   /* LLC is at the node level. */
+   per_cpu(cpu_llc_id, cpu) = node_id;
+   } else if (c->x86 == 0x17 &&
+  c->x86_model >= 0 && c->x86_model <= 0x1F) {
+   /*
+* LLC is at the core complex level.
+* Core complex ID is ApicId[3] for these processors.
+*/
+   per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+   } else {
+   /*
+* LLC ID is calculated from the number of threads sharing the
+* cache.
+* */
+   u32 eax, ebx, ecx, edx, num_sharing_cache = 0;
+   u32 llc_index = find_num_cache_leaves(c) - 1;
+
+   cpuid_count(0x801d, llc_index, , , , );
+   if (eax)
+   num_sharing_cache = ((eax >> 14) & 0xfff) + 1;
+
+   if (num_sharing_cache) {
+   int bits = get_count_order(num_sharing_cache) - 1;
+
+   per_cpu(cpu_llc_id, cpu) = c->apicid >> bits;
+   }
+   }
+}
+
 void init_amd_cacheinfo(struct cpuinfo_x86 *c)
 {
 


Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework​

2018-05-12 Thread David Lechner

On 05/11/2018 10:26 AM, Sekhar Nori wrote:

Hi David,

On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:

This series converts mach-davinci to use the common clock framework.

The series works like this, the first 3 patches fix some issues with the clock
drivers that have already been accepted into the mainline kernel.


I have not yet looked at the patches, but I got a bunch of W=1 warnings
and some sparse warnings when building your branch. Please take a look
at these. Unfortunately the output is mixed between sparse and compiler.
The "expression using sizeof(void)" can be ignored as its a known issue
with sparse, I believe.



I've started a common-clk-v11 branch on my GitHub that fixes most of these.
Also submitted "clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups" that
fixes a couple more. I've purposely not fixed the davinci_clk_reset_* functions
since there is already a patch that will remove those functions in the future.

I'll wait a bit longer for DT review before re-sending v11 of this series.





[tip:x86/cpu] x86/CPU/AMD: Calculate last level cache ID from number of sharing threads

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  68091ee7ac3c1a8786fe1bebbd616b14236efb99
Gitweb: https://git.kernel.org/tip/68091ee7ac3c1a8786fe1bebbd616b14236efb99
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:34:37 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

x86/CPU/AMD: Calculate last level cache ID from number of sharing threads

Last Level Cache ID can be calculated from the number of threads sharing
the cache, which is available from CPUID Fn0x801D (Cache Properties).
This is used to left-shift the APIC ID to derive LLC ID.

Therefore, default to this method unless the APIC ID enumeration does not
follow the scheme.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-5-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/cacheinfo.h |  7 +++
 arch/x86/kernel/cpu/amd.c| 19 +++
 arch/x86/kernel/cpu/cacheinfo.c  | 39 +++
 3 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
new file mode 100644
index ..e958e28f7ab5
--- /dev/null
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_CACHEINFO_H
+#define _ASM_X86_CACHEINFO_H
+
+void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
+
+#endif /* _ASM_X86_CACHEINFO_H */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a37a83809665..bf27246bb7bd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -343,22 +344,8 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
c->x86_max_cores /= smp_num_siblings;
}
 
-   /*
-* We may have multiple LLCs if L3 caches exist, so check if we
-* have an L3 cache by looking at the L3 cache CPUID leaf.
-*/
-   if (cpuid_edx(0x8006)) {
-   if (c->x86 == 0x17) {
-   /*
-* LLC is at the core complex level.
-* Core complex id is ApicId[3].
-*/
-   per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
-   } else {
-   /* LLC is at the node level. */
-   per_cpu(cpu_llc_id, cpu) = node_id;
-   }
-   }
+   cacheinfo_amd_init_llc_id(c, cpu, node_id);
+
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
 
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 54d04d574148..a2e03c9401a1 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -637,6 +637,45 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
return i;
 }
 
+void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
+{
+   /*
+* We may have multiple LLCs if L3 caches exist, so check if we
+* have an L3 cache by looking at the L3 cache CPUID leaf.
+*/
+   if (!cpuid_edx(0x8006))
+   return;
+
+   if (c->x86 < 0x17) {
+   /* LLC is at the node level. */
+   per_cpu(cpu_llc_id, cpu) = node_id;
+   } else if (c->x86 == 0x17 &&
+  c->x86_model >= 0 && c->x86_model <= 0x1F) {
+   /*
+* LLC is at the core complex level.
+* Core complex ID is ApicId[3] for these processors.
+*/
+   per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+   } else {
+   /*
+* LLC ID is calculated from the number of threads sharing the
+* cache.
+* */
+   u32 eax, ebx, ecx, edx, num_sharing_cache = 0;
+   u32 llc_index = find_num_cache_leaves(c) - 1;
+
+   cpuid_count(0x801d, llc_index, , , , );
+   if (eax)
+   num_sharing_cache = ((eax >> 14) & 0xfff) + 1;
+
+   if (num_sharing_cache) {
+   int bits = get_count_order(num_sharing_cache) - 1;
+
+   per_cpu(cpu_llc_id, cpu) = c->apicid >> bits;
+   }
+   }
+}
+
 void init_amd_cacheinfo(struct cpuinfo_x86 *c)
 {
 


Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework​

2018-05-12 Thread David Lechner

On 05/11/2018 10:26 AM, Sekhar Nori wrote:

Hi David,

On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:

This series converts mach-davinci to use the common clock framework.

The series works like this, the first 3 patches fix some issues with the clock
drivers that have already been accepted into the mainline kernel.


I have not yet looked at the patches, but I got a bunch of W=1 warnings
and some sparse warnings when building your branch. Please take a look
at these. Unfortunately the output is mixed between sparse and compiler.
The "expression using sizeof(void)" can be ignored as its a known issue
with sparse, I believe.



I've started a common-clk-v11 branch on my GitHub that fixes most of these.
Also submitted "clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups" that
fixes a couple more. I've purposely not fixed the davinci_clk_reset_* functions
since there is already a patch that will remove those functions in the future.

I'll wait a bit longer for DT review before re-sending v11 of this series.





[tip:x86/cpu] x86/CPU: Rename intel_cacheinfo.c to cacheinfo.c

2018-05-12 Thread tip-bot for Borislav Petkov
Commit-ID:  1d200c078d0e3e49e2995b9d25fef8926d491f4f
Gitweb: https://git.kernel.org/tip/1d200c078d0e3e49e2995b9d25fef8926d491f4f
Author: Borislav Petkov 
AuthorDate: Fri, 27 Apr 2018 16:34:36 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

x86/CPU: Rename intel_cacheinfo.c to cacheinfo.c

Since this file contains general cache-related information for x86,
rename the file to a more generic name.

Signed-off-by: Borislav Petkov 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-4-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/kernel/cpu/Makefile   | 2 +-
 arch/x86/kernel/cpu/{intel_cacheinfo.c => cacheinfo.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a66229f51b12..7a40196967cb 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -17,7 +17,7 @@ KCOV_INSTRUMENT_perf_event.o := n
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_common.o:= $(nostackp)
 
-obj-y  := intel_cacheinfo.o scattered.o topology.o
+obj-y  := cacheinfo.o scattered.o topology.o
 obj-y  += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/cacheinfo.c
similarity index 100%
rename from arch/x86/kernel/cpu/intel_cacheinfo.c
rename to arch/x86/kernel/cpu/cacheinfo.c


[tip:x86/cpu] x86/CPU: Rename intel_cacheinfo.c to cacheinfo.c

2018-05-12 Thread tip-bot for Borislav Petkov
Commit-ID:  1d200c078d0e3e49e2995b9d25fef8926d491f4f
Gitweb: https://git.kernel.org/tip/1d200c078d0e3e49e2995b9d25fef8926d491f4f
Author: Borislav Petkov 
AuthorDate: Fri, 27 Apr 2018 16:34:36 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

x86/CPU: Rename intel_cacheinfo.c to cacheinfo.c

Since this file contains general cache-related information for x86,
rename the file to a more generic name.

Signed-off-by: Borislav Petkov 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-4-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/kernel/cpu/Makefile   | 2 +-
 arch/x86/kernel/cpu/{intel_cacheinfo.c => cacheinfo.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a66229f51b12..7a40196967cb 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -17,7 +17,7 @@ KCOV_INSTRUMENT_perf_event.o := n
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_common.o:= $(nostackp)
 
-obj-y  := intel_cacheinfo.o scattered.o topology.o
+obj-y  := cacheinfo.o scattered.o topology.o
 obj-y  += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/cacheinfo.c
similarity index 100%
rename from arch/x86/kernel/cpu/intel_cacheinfo.c
rename to arch/x86/kernel/cpu/cacheinfo.c


[tip:x86/cpu] perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined cpu_llc_id

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  812af433038f984fd951224e8239b09188e36a13
Gitweb: https://git.kernel.org/tip/812af433038f984fd951224e8239b09188e36a13
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:34:35 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined cpu_llc_id

Current logic iterates over CPUID Fn801d leafs (Cache Properties)
to detect the last level cache, and derive the last-level cache ID.
However, this information is already available in the cpu_llc_id.
Therefore, make use of it instead.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: "Peter Zijlstra (Intel)" 
Cc: Janakarajan Natarajan 
Link: 
http://lkml.kernel.org/r/1524864877-111962-3-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/events/amd/uncore.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index f5cbbba99283..981ba5e8241b 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NUM_COUNTERS_NB4
 #define NUM_COUNTERS_L24
@@ -399,26 +400,8 @@ static int amd_uncore_cpu_starting(unsigned int cpu)
}
 
if (amd_uncore_llc) {
-   unsigned int apicid = cpu_data(cpu).apicid;
-   unsigned int nshared, subleaf, prev_eax = 0;
-
uncore = *per_cpu_ptr(amd_uncore_llc, cpu);
-   /*
-* Iterate over Cache Topology Definition leaves until no
-* more cache descriptions are available.
-*/
-   for (subleaf = 0; subleaf < 5; subleaf++) {
-   cpuid_count(0x801d, subleaf, , , , 
);
-
-   /* EAX[0:4] gives type of cache */
-   if (!(eax & 0x1f))
-   break;
-
-   prev_eax = eax;
-   }
-   nshared = ((prev_eax >> 14) & 0xfff) + 1;
-
-   uncore->id = apicid - (apicid % nshared);
+   uncore->id = per_cpu(cpu_llc_id, cpu);
 
uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc);
*per_cpu_ptr(amd_uncore_llc, cpu) = uncore;


[tip:x86/cpu] perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined cpu_llc_id

2018-05-12 Thread tip-bot for Suravee Suthikulpanit
Commit-ID:  812af433038f984fd951224e8239b09188e36a13
Gitweb: https://git.kernel.org/tip/812af433038f984fd951224e8239b09188e36a13
Author: Suravee Suthikulpanit 
AuthorDate: Fri, 27 Apr 2018 16:34:35 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:15 +0200

perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined cpu_llc_id

Current logic iterates over CPUID Fn801d leafs (Cache Properties)
to detect the last level cache, and derive the last-level cache ID.
However, this information is already available in the cpu_llc_id.
Therefore, make use of it instead.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: "Peter Zijlstra (Intel)" 
Cc: Janakarajan Natarajan 
Link: 
http://lkml.kernel.org/r/1524864877-111962-3-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/events/amd/uncore.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index f5cbbba99283..981ba5e8241b 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NUM_COUNTERS_NB4
 #define NUM_COUNTERS_L24
@@ -399,26 +400,8 @@ static int amd_uncore_cpu_starting(unsigned int cpu)
}
 
if (amd_uncore_llc) {
-   unsigned int apicid = cpu_data(cpu).apicid;
-   unsigned int nshared, subleaf, prev_eax = 0;
-
uncore = *per_cpu_ptr(amd_uncore_llc, cpu);
-   /*
-* Iterate over Cache Topology Definition leaves until no
-* more cache descriptions are available.
-*/
-   for (subleaf = 0; subleaf < 5; subleaf++) {
-   cpuid_count(0x801d, subleaf, , , , 
);
-
-   /* EAX[0:4] gives type of cache */
-   if (!(eax & 0x1f))
-   break;
-
-   prev_eax = eax;
-   }
-   nshared = ((prev_eax >> 14) & 0xfff) + 1;
-
-   uncore->id = apicid - (apicid % nshared);
+   uncore->id = per_cpu(cpu_llc_id, cpu);
 
uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc);
*per_cpu_ptr(amd_uncore_llc, cpu) = uncore;


[tip:x86/cpu] x86/CPU/AMD: Have smp_num_siblings and cpu_llc_id always be present

2018-05-12 Thread tip-bot for Borislav Petkov
Commit-ID:  f8b64d08dde2714c62751d18ba77f4aeceb161d3
Gitweb: https://git.kernel.org/tip/f8b64d08dde2714c62751d18ba77f4aeceb161d3
Author: Borislav Petkov 
AuthorDate: Fri, 27 Apr 2018 16:34:34 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:14 +0200

x86/CPU/AMD: Have smp_num_siblings and cpu_llc_id always be present

Move smp_num_siblings and cpu_llc_id to cpu/common.c so that they're
always present as symbols and not only in the CONFIG_SMP case. Then,
other code using them doesn't need ugly ifdeffery anymore. Get rid of
some ifdeffery.

Signed-off-by: Borislav Petkov 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-2-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/smp.h   |  1 -
 arch/x86/kernel/cpu/amd.c| 10 +-
 arch/x86/kernel/cpu/common.c |  7 +++
 arch/x86/kernel/smpboot.c|  7 ---
 4 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index f75bff8f9d82..547c4fe50711 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -171,7 +171,6 @@ static inline int wbinvd_on_all_cpus(void)
wbinvd();
return 0;
 }
-#define smp_num_siblings   1
 #endif /* CONFIG_SMP */
 
 extern unsigned disabled_cpus;
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 12bc0a1139da..a37a83809665 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -297,7 +297,6 @@ static int nearby_node(int apicid)
 }
 #endif
 
-#ifdef CONFIG_SMP
 /*
  * Fix up cpu_core_id for pre-F17h systems to be in the
  * [0 .. cores_per_node - 1] range. Not really needed but
@@ -375,7 +374,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
legacy_fixup_core_id(c);
}
 }
-#endif
 
 /*
  * On a AMD dual core setup the lower bits of the APIC id distinguish the 
cores.
@@ -383,7 +381,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
  */
 static void amd_detect_cmp(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_SMP
unsigned bits;
int cpu = smp_processor_id();
 
@@ -395,16 +392,11 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
/* use socket ID also for last level cache */
per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
amd_get_topology(c);
-#endif
 }
 
 u16 amd_get_nb_id(int cpu)
 {
-   u16 id = 0;
-#ifdef CONFIG_SMP
-   id = per_cpu(cpu_llc_id, cpu);
-#endif
-   return id;
+   return per_cpu(cpu_llc_id, cpu);
 }
 EXPORT_SYMBOL_GPL(amd_get_nb_id);
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185735e1..37c7c8334a00 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -66,6 +66,13 @@ cpumask_var_t cpu_callin_mask;
 /* representing cpus for which sibling maps can be computed */
 cpumask_var_t cpu_sibling_setup_mask;
 
+/* Number of siblings per CPU package */
+int smp_num_siblings = 1;
+EXPORT_SYMBOL(smp_num_siblings);
+
+/* Last level cache ID of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
+
 /* correctly size the local cpu masks */
 void __init setup_cpu_local_masks(void)
 {
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ff99e2b6fc54..91d48f3eeda8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -78,13 +78,6 @@
 #include 
 #include 
 
-/* Number of siblings per CPU package */
-int smp_num_siblings = 1;
-EXPORT_SYMBOL(smp_num_siblings);
-
-/* Last level cache ID of each logical CPU */
-DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
-
 /* representing HT siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map);
 EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);


[tip:x86/cpu] x86/CPU/AMD: Have smp_num_siblings and cpu_llc_id always be present

2018-05-12 Thread tip-bot for Borislav Petkov
Commit-ID:  f8b64d08dde2714c62751d18ba77f4aeceb161d3
Gitweb: https://git.kernel.org/tip/f8b64d08dde2714c62751d18ba77f4aeceb161d3
Author: Borislav Petkov 
AuthorDate: Fri, 27 Apr 2018 16:34:34 -0500
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:49:14 +0200

x86/CPU/AMD: Have smp_num_siblings and cpu_llc_id always be present

Move smp_num_siblings and cpu_llc_id to cpu/common.c so that they're
always present as symbols and not only in the CONFIG_SMP case. Then,
other code using them doesn't need ugly ifdeffery anymore. Get rid of
some ifdeffery.

Signed-off-by: Borislav Petkov 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1524864877-111962-2-git-send-email-suravee.suthikulpa...@amd.com

---
 arch/x86/include/asm/smp.h   |  1 -
 arch/x86/kernel/cpu/amd.c| 10 +-
 arch/x86/kernel/cpu/common.c |  7 +++
 arch/x86/kernel/smpboot.c|  7 ---
 4 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index f75bff8f9d82..547c4fe50711 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -171,7 +171,6 @@ static inline int wbinvd_on_all_cpus(void)
wbinvd();
return 0;
 }
-#define smp_num_siblings   1
 #endif /* CONFIG_SMP */
 
 extern unsigned disabled_cpus;
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 12bc0a1139da..a37a83809665 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -297,7 +297,6 @@ static int nearby_node(int apicid)
 }
 #endif
 
-#ifdef CONFIG_SMP
 /*
  * Fix up cpu_core_id for pre-F17h systems to be in the
  * [0 .. cores_per_node - 1] range. Not really needed but
@@ -375,7 +374,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
legacy_fixup_core_id(c);
}
 }
-#endif
 
 /*
  * On a AMD dual core setup the lower bits of the APIC id distinguish the 
cores.
@@ -383,7 +381,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
  */
 static void amd_detect_cmp(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_SMP
unsigned bits;
int cpu = smp_processor_id();
 
@@ -395,16 +392,11 @@ static void amd_detect_cmp(struct cpuinfo_x86 *c)
/* use socket ID also for last level cache */
per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
amd_get_topology(c);
-#endif
 }
 
 u16 amd_get_nb_id(int cpu)
 {
-   u16 id = 0;
-#ifdef CONFIG_SMP
-   id = per_cpu(cpu_llc_id, cpu);
-#endif
-   return id;
+   return per_cpu(cpu_llc_id, cpu);
 }
 EXPORT_SYMBOL_GPL(amd_get_nb_id);
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185735e1..37c7c8334a00 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -66,6 +66,13 @@ cpumask_var_t cpu_callin_mask;
 /* representing cpus for which sibling maps can be computed */
 cpumask_var_t cpu_sibling_setup_mask;
 
+/* Number of siblings per CPU package */
+int smp_num_siblings = 1;
+EXPORT_SYMBOL(smp_num_siblings);
+
+/* Last level cache ID of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
+
 /* correctly size the local cpu masks */
 void __init setup_cpu_local_masks(void)
 {
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ff99e2b6fc54..91d48f3eeda8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -78,13 +78,6 @@
 #include 
 #include 
 
-/* Number of siblings per CPU package */
-int smp_num_siblings = 1;
-EXPORT_SYMBOL(smp_num_siblings);
-
-/* Last level cache ID of each logical CPU */
-DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
-
 /* representing HT siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map);
 EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);


drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-12 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   427fbe89261d8f11cd20b5a4ba94e977061f69d6
commit: 58ca9ac1463d07d24b9fa8befe065192abca6f76 EDAC, skx_edac: Detect 
non-volatile DIMMs
date:   8 weeks ago
config: x86_64-randconfig-v0-05130337 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 58ca9ac1463d07d24b9fa8befe065192abca6f76
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/edac/skx_edac.o: In function `get_nvdimm_info':
>> drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

vim +399 drivers/edac/skx_edac.c

   387  
   388  static int get_nvdimm_info(struct dimm_info *dimm, struct skx_imc *imc,
   389 int chan, int dimmno)
   390  {
   391  int smbios_handle;
   392  u32 dev_handle;
   393  u16 flags;
   394  u64 size = 0;
   395  
   396  dev_handle = ACPI_NFIT_BUILD_DEVICE_HANDLE(dimmno, chan, 
imc->lmc,
   397 imc->src_id, 0);
   398  
 > 399  smbios_handle = nfit_get_smbios_id(dev_handle, );
   400  if (smbios_handle == -EOPNOTSUPP) {
   401  pr_warn_once(EDAC_MOD_STR ": Can't find size of NVDIMM. 
Try enabling CONFIG_ACPI_NFIT\n");
   402  goto unknown_size;
   403  }
   404  
   405  if (smbios_handle < 0) {
   406  skx_printk(KERN_ERR, "Can't find handle for NVDIMM 
ADR=%x\n", dev_handle);
   407  goto unknown_size;
   408  }
   409  
   410  if (flags & ACPI_NFIT_MEM_MAP_FAILED) {
   411  skx_printk(KERN_ERR, "NVDIMM ADR=%x is not mapped\n", 
dev_handle);
   412  goto unknown_size;
   413  }
   414  
   415  size = dmi_memdev_size(smbios_handle);
   416  if (size == ~0ull)
   417  skx_printk(KERN_ERR, "Can't find size for NVDIMM 
ADR=%x/SMBIOS=%x\n",
   418 dev_handle, smbios_handle);
   419  
   420  unknown_size:
   421  dimm->nr_pages = size >> PAGE_SHIFT;
   422  dimm->grain = 32;
   423  dimm->dtype = DEV_UNKNOWN;
   424  dimm->mtype = MEM_NVDIMM;
   425  dimm->edac_mode = EDAC_SECDED; /* likely better than this */
   426  
   427  edac_dbg(0, "mc#%d: channel %d, dimm %d, %llu Mb (%u pages)\n",
   428   imc->mc, chan, dimmno, size >> 20, dimm->nr_pages);
   429  
   430  snprintf(dimm->label, sizeof(dimm->label), 
"CPU_SrcID#%u_MC#%u_Chan#%u_DIMM#%u",
   431   imc->src_id, imc->lmc, chan, dimmno);
   432  
   433  return (size == 0 || size == ~0ull) ? 0 : 1;
   434  }
   435  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-12 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   427fbe89261d8f11cd20b5a4ba94e977061f69d6
commit: 58ca9ac1463d07d24b9fa8befe065192abca6f76 EDAC, skx_edac: Detect 
non-volatile DIMMs
date:   8 weeks ago
config: x86_64-randconfig-v0-05130337 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 58ca9ac1463d07d24b9fa8befe065192abca6f76
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/edac/skx_edac.o: In function `get_nvdimm_info':
>> drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

vim +399 drivers/edac/skx_edac.c

   387  
   388  static int get_nvdimm_info(struct dimm_info *dimm, struct skx_imc *imc,
   389 int chan, int dimmno)
   390  {
   391  int smbios_handle;
   392  u32 dev_handle;
   393  u16 flags;
   394  u64 size = 0;
   395  
   396  dev_handle = ACPI_NFIT_BUILD_DEVICE_HANDLE(dimmno, chan, 
imc->lmc,
   397 imc->src_id, 0);
   398  
 > 399  smbios_handle = nfit_get_smbios_id(dev_handle, );
   400  if (smbios_handle == -EOPNOTSUPP) {
   401  pr_warn_once(EDAC_MOD_STR ": Can't find size of NVDIMM. 
Try enabling CONFIG_ACPI_NFIT\n");
   402  goto unknown_size;
   403  }
   404  
   405  if (smbios_handle < 0) {
   406  skx_printk(KERN_ERR, "Can't find handle for NVDIMM 
ADR=%x\n", dev_handle);
   407  goto unknown_size;
   408  }
   409  
   410  if (flags & ACPI_NFIT_MEM_MAP_FAILED) {
   411  skx_printk(KERN_ERR, "NVDIMM ADR=%x is not mapped\n", 
dev_handle);
   412  goto unknown_size;
   413  }
   414  
   415  size = dmi_memdev_size(smbios_handle);
   416  if (size == ~0ull)
   417  skx_printk(KERN_ERR, "Can't find size for NVDIMM 
ADR=%x/SMBIOS=%x\n",
   418 dev_handle, smbios_handle);
   419  
   420  unknown_size:
   421  dimm->nr_pages = size >> PAGE_SHIFT;
   422  dimm->grain = 32;
   423  dimm->dtype = DEV_UNKNOWN;
   424  dimm->mtype = MEM_NVDIMM;
   425  dimm->edac_mode = EDAC_SECDED; /* likely better than this */
   426  
   427  edac_dbg(0, "mc#%d: channel %d, dimm %d, %llu Mb (%u pages)\n",
   428   imc->mc, chan, dimmno, size >> 20, dimm->nr_pages);
   429  
   430  snprintf(dimm->label, sizeof(dimm->label), 
"CPU_SrcID#%u_MC#%u_Chan#%u_DIMM#%u",
   431   imc->src_id, imc->lmc, chan, dimmno);
   432  
   433  return (size == 0 || size == ~0ull) ? 0 : 1;
   434  }
   435  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH] clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups

2018-05-12 Thread David Lechner
The clkdev lookups for the ASP0/1 devices on TI DM355 were declared, but
not assigned to any LPSC. This assigns the clkdev lookups to the
correct LPSCs.

Reported-by: Sekhar Nori 
Signed-off-by: David Lechner 
---
 drivers/clk/davinci/psc-dm355.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/davinci/psc-dm355.c b/drivers/clk/davinci/psc-dm355.c
index 001288dfdfb1..fb71ad81bb9c 100644
--- a/drivers/clk/davinci/psc-dm355.c
+++ b/drivers/clk/davinci/psc-dm355.c
@@ -41,14 +41,14 @@ static const struct davinci_lpsc_clk_info dm355_psc_info[] 
= {
LPSC(5,  0, timer3,  pll1_auxclk,  NULL,   0),
LPSC(6,  0, spi1,pll1_sysclk2, spi1_clkdev,0),
LPSC(7,  0, mmcsd1,  pll1_sysclk2, mmcsd1_clkdev,  0),
-   LPSC(8,  0, asp1,pll1_sysclk2, NULL,   0),
+   LPSC(8,  0, asp1,pll1_sysclk2, mcbsp1_clkdev,  0),
LPSC(9,  0, usb, pll1_sysclk2, usb_clkdev, 0),
LPSC(10, 0, pwm3,pll1_auxclk,  NULL,   0),
LPSC(11, 0, spi2,pll1_sysclk2, spi2_clkdev,0),
LPSC(12, 0, rto, pll1_auxclk,  NULL,   0),
LPSC(14, 0, aemif,   pll1_sysclk2, aemif_clkdev,   0),
LPSC(15, 0, mmcsd0,  pll1_sysclk2, mmcsd0_clkdev,  0),
-   LPSC(17, 0, asp0,pll1_sysclk2, NULL,   0),
+   LPSC(17, 0, asp0,pll1_sysclk2, mcbsp0_clkdev,  0),
LPSC(18, 0, i2c, pll1_auxclk,  i2c_clkdev, 0),
LPSC(19, 0, uart0,   pll1_auxclk,  uart0_clkdev,   0),
LPSC(20, 0, uart1,   pll1_auxclk,  uart1_clkdev,   0),
-- 
2.17.0



[PATCH] clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups

2018-05-12 Thread David Lechner
The clkdev lookups for the ASP0/1 devices on TI DM355 were declared, but
not assigned to any LPSC. This assigns the clkdev lookups to the
correct LPSCs.

Reported-by: Sekhar Nori 
Signed-off-by: David Lechner 
---
 drivers/clk/davinci/psc-dm355.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/davinci/psc-dm355.c b/drivers/clk/davinci/psc-dm355.c
index 001288dfdfb1..fb71ad81bb9c 100644
--- a/drivers/clk/davinci/psc-dm355.c
+++ b/drivers/clk/davinci/psc-dm355.c
@@ -41,14 +41,14 @@ static const struct davinci_lpsc_clk_info dm355_psc_info[] 
= {
LPSC(5,  0, timer3,  pll1_auxclk,  NULL,   0),
LPSC(6,  0, spi1,pll1_sysclk2, spi1_clkdev,0),
LPSC(7,  0, mmcsd1,  pll1_sysclk2, mmcsd1_clkdev,  0),
-   LPSC(8,  0, asp1,pll1_sysclk2, NULL,   0),
+   LPSC(8,  0, asp1,pll1_sysclk2, mcbsp1_clkdev,  0),
LPSC(9,  0, usb, pll1_sysclk2, usb_clkdev, 0),
LPSC(10, 0, pwm3,pll1_auxclk,  NULL,   0),
LPSC(11, 0, spi2,pll1_sysclk2, spi2_clkdev,0),
LPSC(12, 0, rto, pll1_auxclk,  NULL,   0),
LPSC(14, 0, aemif,   pll1_sysclk2, aemif_clkdev,   0),
LPSC(15, 0, mmcsd0,  pll1_sysclk2, mmcsd0_clkdev,  0),
-   LPSC(17, 0, asp0,pll1_sysclk2, NULL,   0),
+   LPSC(17, 0, asp0,pll1_sysclk2, mcbsp0_clkdev,  0),
LPSC(18, 0, i2c, pll1_auxclk,  i2c_clkdev, 0),
LPSC(19, 0, uart0,   pll1_auxclk,  uart0_clkdev,   0),
LPSC(20, 0, uart1,   pll1_auxclk,  uart1_clkdev,   0),
-- 
2.17.0



Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

2018-05-12 Thread Jacek Anaszewski

Hi Pavel,

On 05/12/2018 10:35 AM, Pavel Machek wrote:

Hi!


I disagree here. We already had the same discussion at the occasion
of the patch [0] and it turned out to be a dead-end [1]. Now we have
neither the driver nor the generic pattern interface.

We also already have some older LED class drivers that implement custom
pattern interfaces (e.g. drivers/leds/leds-lm3533.c) and the same
approach can be applied in this case.


Please don't. It was mistake to implement custom pattern interfaces
back then, it is still mistake now.


It turned out to be really hard to cover all known pattern generator
implementations with generic interface. Sure, it would be nice to have
one, but the whole discussion around [0] only unveiled the diversity of
parameters to cover. And still new devices appear on the market.

We would have to propose a set of pattern schemes and allow to
add new ones to it.


I believe that what I'm proposing below is close enough to universal.


If we really need solution now, I'd recommend "pattern" file with

"   ".

In this specific case, hardware only supports patterns in this format:

low_time 0 rise_time 255 high_time 255 fall_time 0

so driver would simply -EINVAL on anything else.


I'm fine with the pattern file, but the pattern format would have
to be defined in the per-driver ABI documentation. It wouldn't much
differ from the custom pattern approach though, unless I'm missing some
gain of having pattern setting in a uniformly named single sysfs file
(with semantics differing from driver to driver).


I'm proposing "  ..." sysfs file. It certainly
covers this hardware, it would be enough to cover the Qualcomm Pulse
generator (IIRC), and it would cover most uses cases of Nokia N900's
LED.

Yes, we would need to document limitations of each chip. But it should
be easily possible to run pattern designed for Spreadtrum on N900,
even if it would not work the other way around.

(If someone really wants to run complex patterns on simple hardware,
we can provide software emulation using same file format. I believe I
still have that patch somewhere.)


OK, I've revised the discussion under Qualcomm LPG patch set and
it seems that we have almost ready solution in [0], except the
pattern_repeat file you mention in [1]. So probably Baolin could
address your remarks from [1] and add pattern_repeat file to the
patch that begins thread [0].

[0] https://lkml.org/lkml/2017/11/15/27
[1] https://lkml.org/lkml/2017/12/8/470

--
Best regards,
Jacek Anaszewski


Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

2018-05-12 Thread Jacek Anaszewski

Hi Pavel,

On 05/12/2018 10:35 AM, Pavel Machek wrote:

Hi!


I disagree here. We already had the same discussion at the occasion
of the patch [0] and it turned out to be a dead-end [1]. Now we have
neither the driver nor the generic pattern interface.

We also already have some older LED class drivers that implement custom
pattern interfaces (e.g. drivers/leds/leds-lm3533.c) and the same
approach can be applied in this case.


Please don't. It was mistake to implement custom pattern interfaces
back then, it is still mistake now.


It turned out to be really hard to cover all known pattern generator
implementations with generic interface. Sure, it would be nice to have
one, but the whole discussion around [0] only unveiled the diversity of
parameters to cover. And still new devices appear on the market.

We would have to propose a set of pattern schemes and allow to
add new ones to it.


I believe that what I'm proposing below is close enough to universal.


If we really need solution now, I'd recommend "pattern" file with

"   ".

In this specific case, hardware only supports patterns in this format:

low_time 0 rise_time 255 high_time 255 fall_time 0

so driver would simply -EINVAL on anything else.


I'm fine with the pattern file, but the pattern format would have
to be defined in the per-driver ABI documentation. It wouldn't much
differ from the custom pattern approach though, unless I'm missing some
gain of having pattern setting in a uniformly named single sysfs file
(with semantics differing from driver to driver).


I'm proposing "  ..." sysfs file. It certainly
covers this hardware, it would be enough to cover the Qualcomm Pulse
generator (IIRC), and it would cover most uses cases of Nokia N900's
LED.

Yes, we would need to document limitations of each chip. But it should
be easily possible to run pattern designed for Spreadtrum on N900,
even if it would not work the other way around.

(If someone really wants to run complex patterns on simple hardware,
we can provide software emulation using same file format. I believe I
still have that patch somewhere.)


OK, I've revised the discussion under Qualcomm LPG patch set and
it seems that we have almost ready solution in [0], except the
pattern_repeat file you mention in [1]. So probably Baolin could
address your remarks from [1] and add pattern_repeat file to the
patch that begins thread [0].

[0] https://lkml.org/lkml/2017/11/15/27
[1] https://lkml.org/lkml/2017/12/8/470

--
Best regards,
Jacek Anaszewski


Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto

2018-05-12 Thread Thomas Gleixner
On Sat, 12 May 2018, Alexei Starovoitov wrote:
> On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
>  wrote:
> > I see no option, but to fix the kernel.
> > Regardless whether it's called user space breakage or kernel breakage.

There is a big difference. If you are abusing a kernel internal header in a
user space tool, then there is absolutely ZERO excuse for requesting that
the header in question has to be modified.

But yes, the situation is slightly different here because tools which
create trace event magic _HAVE_ to pull in kernel headers. At the same time
these tools depend on a compiler which failed to implement asm_goto for
fricking 8 years.

So while Boris is right, that nothing has to fiddle with a kernel only
header, I grumpily agree with you that we need a workaround in the kernel
for this particular issue.

> could you please ack the patch or better yet take it into tip tree
> and send to Linus asap ?

Nope. The patch is a horrible hack.

Why the heck do we need that extra fugly define? That has exactly zero
value simply because we already have a define which denotes availablity of
ASM GOTO: CC_HAVE_ASM_GOTO.

In case of samples/bpf/ and libbcc the compile does not go through the
arch/x86 Makefile which stops the build anyway when ASM_GOTO is
missing. Those builds merily pull in the headers and have their own build
magic, which is broken btw: Changing a kernel header which gets pulled into
the build does not rebuild anything in samples/bpf. Qualitee..

So we can just use CC_HAVE_ASM_GOTO and be done with it.

But we also want the tools which needs this to be aware of this. Peter
requested -D __BPF__ several times which got ignored. It's not too much of
a request to add that.

Find a patch which deos exactly this for samples/bpf, but also allows other
tools to build with a warning emitted so they get fixed.

Thanks,

tglx

8<
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -140,6 +140,20 @@ extern void clear_cpu_cap(struct cpuinfo
 
 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
 
+#ifndef CC_HAVE_ASM_GOTO
+
+/*
+ * Workaround for the sake of BPF compilation which utilizes kernel
+ * headers, but clang does not support ASM GOTO and fails the build.
+ */
+#ifndef __BPF__
+#warning "Compiler lacks ASM_GOTO support. Add -D __BPF__ to your compiler 
arguments"
+#endif
+
+#define static_cpu_has(bit)boot_cpu_has(bit)
+
+#else
+
 /*
  * Static testing of CPU features.  Used the same as boot_cpu_has().
  * These will statically patch the target code for additional
@@ -195,6 +209,7 @@ static __always_inline __pure bool _stat
boot_cpu_has(bit) : \
_static_cpu_has(bit)\
 )
+#endif
 
 #define cpu_has_bug(c, bit)cpu_has(c, (bit))
 #define set_cpu_bug(c, bit)set_cpu_cap(c, (bit))
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -255,7 +255,7 @@ verify_target_bpf: verify_cmds
 $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
-I$(srctree)/tools/testing/selftests/bpf/ \
-   -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
+   -D__KERNEL__ -D__BPF__ -Wno-unused-value -Wno-pointer-sign \
-D__TARGET_ARCH_$(ARCH) -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \


Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto

2018-05-12 Thread Thomas Gleixner
On Sat, 12 May 2018, Alexei Starovoitov wrote:
> On Thu, May 10, 2018 at 10:58 AM, Alexei Starovoitov
>  wrote:
> > I see no option, but to fix the kernel.
> > Regardless whether it's called user space breakage or kernel breakage.

There is a big difference. If you are abusing a kernel internal header in a
user space tool, then there is absolutely ZERO excuse for requesting that
the header in question has to be modified.

But yes, the situation is slightly different here because tools which
create trace event magic _HAVE_ to pull in kernel headers. At the same time
these tools depend on a compiler which failed to implement asm_goto for
fricking 8 years.

So while Boris is right, that nothing has to fiddle with a kernel only
header, I grumpily agree with you that we need a workaround in the kernel
for this particular issue.

> could you please ack the patch or better yet take it into tip tree
> and send to Linus asap ?

Nope. The patch is a horrible hack.

Why the heck do we need that extra fugly define? That has exactly zero
value simply because we already have a define which denotes availablity of
ASM GOTO: CC_HAVE_ASM_GOTO.

In case of samples/bpf/ and libbcc the compile does not go through the
arch/x86 Makefile which stops the build anyway when ASM_GOTO is
missing. Those builds merily pull in the headers and have their own build
magic, which is broken btw: Changing a kernel header which gets pulled into
the build does not rebuild anything in samples/bpf. Qualitee..

So we can just use CC_HAVE_ASM_GOTO and be done with it.

But we also want the tools which needs this to be aware of this. Peter
requested -D __BPF__ several times which got ignored. It's not too much of
a request to add that.

Find a patch which deos exactly this for samples/bpf, but also allows other
tools to build with a warning emitted so they get fixed.

Thanks,

tglx

8<
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -140,6 +140,20 @@ extern void clear_cpu_cap(struct cpuinfo
 
 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
 
+#ifndef CC_HAVE_ASM_GOTO
+
+/*
+ * Workaround for the sake of BPF compilation which utilizes kernel
+ * headers, but clang does not support ASM GOTO and fails the build.
+ */
+#ifndef __BPF__
+#warning "Compiler lacks ASM_GOTO support. Add -D __BPF__ to your compiler 
arguments"
+#endif
+
+#define static_cpu_has(bit)boot_cpu_has(bit)
+
+#else
+
 /*
  * Static testing of CPU features.  Used the same as boot_cpu_has().
  * These will statically patch the target code for additional
@@ -195,6 +209,7 @@ static __always_inline __pure bool _stat
boot_cpu_has(bit) : \
_static_cpu_has(bit)\
 )
+#endif
 
 #define cpu_has_bug(c, bit)cpu_has(c, (bit))
 #define set_cpu_bug(c, bit)set_cpu_cap(c, (bit))
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -255,7 +255,7 @@ verify_target_bpf: verify_cmds
 $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
-I$(srctree)/tools/testing/selftests/bpf/ \
-   -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
+   -D__KERNEL__ -D__BPF__ -Wno-unused-value -Wno-pointer-sign \
-D__TARGET_ARCH_$(ARCH) -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \


  1   2   3   4   >