[PATCH] net: dsa: loop: Check for memory allocation failure

[Christophe JAILLET]

If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
Return -ENOMEM instead, as done for some other memory allocation just a
few lines above.

Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/net/dsa/dsa_loop.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index f0fc4de4fc9a..a19e1781e9bb 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
return -ENOMEM;
 
ps = devm_kzalloc(>dev, sizeof(*ps), GFP_KERNEL);
+   if (!ps)
+   return -ENOMEM;
+
ps->netdev = dev_get_by_name(_net, pdata->netdev);
if (!ps->netdev)
return -EPROBE_DEFER;
-- 
2.11.0

[PATCH] net: dsa: loop: Check for memory allocation failure

[Christophe JAILLET]

If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
Return -ENOMEM instead, as done for some other memory allocation just a
few lines above.

Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")

Signed-off-by: Christophe JAILLET 
---
 drivers/net/dsa/dsa_loop.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index f0fc4de4fc9a..a19e1781e9bb 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
return -ENOMEM;
 
ps = devm_kzalloc(>dev, sizeof(*ps), GFP_KERNEL);
+   if (!ps)
+   return -ENOMEM;
+
ps->netdev = dev_get_by_name(_net, pdata->netdev);
if (!ps->netdev)
return -EPROBE_DEFER;
-- 
2.11.0

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

On Fri, May 5, 2017 at 8:55 PM, Robin Murphy  wrote:
> On 04/05/17 19:41, Oza Oza wrote:
> [...]
 5) leaves scope of adding PCI flag handling for inbound memory
 by the new function.
>>>
>>> Which flags would ever actually matter? DMA windows aren't going to be
>>> to config or I/O space, so the memory type can be assumed, and the
>>> 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
>>> DMA-able system memory isn't going to be read-sensitive, so the
>>> prefetchable flag shouldn't matter; and not being a BAR none of the
>>> others would be relevant either.
>>>
>>
>> Thanks Robin; for your reply and attention:
>>
>> agree with you, at present it would not matter,
>> but it does not mean that we do not scope it to make it matter in future.
>>
>> now where it could matter:
>> there is Relaxed Ordering for inbound memory for PCI.
>> According to standard, Relaxed Ordering (RO) bit can be set only for
>> Memory requests and completions (if present in the original request).
>> Also, according to transaction ordering rules, I/O and configuration
>> requests can still be re-ordered ahead of each other.
>> and we would like to make use of it.
>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>> the special about this memory is incoming PCI transactions can be
>> reordered and rest memory has to be strongly ordered.
>
> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
> explain how PCIe Relaxed Order has anything to do with the DT binding.
>
>> how it our SOC would make use of this is out of scope for the
>> discussion at this point of time, but I am just bringing in the
>> idea/point how flags could be useful
>> for inbound memory, since we would not like throw-away flags completely.
>
> The premise for implementing a PCI-specific parser is that you claim we
> need to do something with the phys.hi cell of a DT PCI address, rather
> than just taking the numerical part out of the phys.mid and phys.lo
> cells. Please make that argument in reference to the flags which that
> upper cell actually encodes, not unrelated things.
>

I think, the whole discussion around inbound flags is not what I
intended to bring.
this patch does nothing about inbound flag and never intends to solve
anything regarding inbound flags.
infact I would like to remove point 5 form the commit message. which
should keep it out of discussion completely.

let met tell what this patch is trying to address/solve 2 BUGs
1) fix wrong size return from of_dma_configure for PCI masters. (which
is right now BUG)

2) handles multiple dma-ranges cleanly

3) It takes care of dma-ranges being optional.

4) following is the comment on function of_dma_get_range (which is also a BUG)
"It returns -ENODEV if "dma-ranges" property was not found
 * for this device in DT."
which I think is wrong for PCI device, because if dma-ranges are
absent then instead of returning  -ENODEV,
it should return 0 with largest possible host memory.

it solves all the above 4 problems.

> [...]
 +int of_pci_get_dma_ranges(struct device_node *np, struct list_head 
 *resources)
 +{
 + struct device_node *node = of_node_get(np);
 + int rlen;
 + int ret = 0;
 + const int na = 3, ns = 2;
 + struct resource *res;
 + struct of_pci_range_parser parser;
 + struct of_pci_range range;
 +
 + if (!node)
 + return -EINVAL;
 +
 + parser.node = node;
 + parser.pna = of_n_addr_cells(node);
 + parser.np = parser.pna + na + ns;
 +
 + parser.range = of_get_property(node, "dma-ranges", );
 +
 + if (!parser.range) {
 + pr_debug("pcie device has no dma-ranges defined for 
 node(%s)\n",
 +   np->full_name);
 + ret = -EINVAL;
 + goto out;
 + }
 +
 + parser.end = parser.range + rlen / sizeof(__be32);
 +
 + for_each_of_pci_range(, ) {
>>>
>>> This is plain wrong - of_pci_range_parser_one() will translate upwards
>>> through parent "ranges" properties, which is completely backwards for
>>> DMA addresses.
>>>
>>> Robin.
>>>
>>
>> No it does not, this patch is thoroughly tested on our SOC and it works.
>> of_pci_range_parser_one does not translate upwards through parent. it
>> just sticks to given PCI parser.
>
> Frankly, I'm losing patience with this attitude. Please look at the code
> you call:
>
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
>
> struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
> *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
>
> if (!range)
> return NULL;
>
> if 

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

On Fri, May 5, 2017 at 8:55 PM, Robin Murphy  wrote:
> On 04/05/17 19:41, Oza Oza wrote:
> [...]
 5) leaves scope of adding PCI flag handling for inbound memory
 by the new function.
>>>
>>> Which flags would ever actually matter? DMA windows aren't going to be
>>> to config or I/O space, so the memory type can be assumed, and the
>>> 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
>>> DMA-able system memory isn't going to be read-sensitive, so the
>>> prefetchable flag shouldn't matter; and not being a BAR none of the
>>> others would be relevant either.
>>>
>>
>> Thanks Robin; for your reply and attention:
>>
>> agree with you, at present it would not matter,
>> but it does not mean that we do not scope it to make it matter in future.
>>
>> now where it could matter:
>> there is Relaxed Ordering for inbound memory for PCI.
>> According to standard, Relaxed Ordering (RO) bit can be set only for
>> Memory requests and completions (if present in the original request).
>> Also, according to transaction ordering rules, I/O and configuration
>> requests can still be re-ordered ahead of each other.
>> and we would like to make use of it.
>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>> the special about this memory is incoming PCI transactions can be
>> reordered and rest memory has to be strongly ordered.
>
> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
> explain how PCIe Relaxed Order has anything to do with the DT binding.
>
>> how it our SOC would make use of this is out of scope for the
>> discussion at this point of time, but I am just bringing in the
>> idea/point how flags could be useful
>> for inbound memory, since we would not like throw-away flags completely.
>
> The premise for implementing a PCI-specific parser is that you claim we
> need to do something with the phys.hi cell of a DT PCI address, rather
> than just taking the numerical part out of the phys.mid and phys.lo
> cells. Please make that argument in reference to the flags which that
> upper cell actually encodes, not unrelated things.
>

I think, the whole discussion around inbound flags is not what I
intended to bring.
this patch does nothing about inbound flag and never intends to solve
anything regarding inbound flags.
infact I would like to remove point 5 form the commit message. which
should keep it out of discussion completely.

let met tell what this patch is trying to address/solve 2 BUGs
1) fix wrong size return from of_dma_configure for PCI masters. (which
is right now BUG)

2) handles multiple dma-ranges cleanly

3) It takes care of dma-ranges being optional.

4) following is the comment on function of_dma_get_range (which is also a BUG)
"It returns -ENODEV if "dma-ranges" property was not found
 * for this device in DT."
which I think is wrong for PCI device, because if dma-ranges are
absent then instead of returning  -ENODEV,
it should return 0 with largest possible host memory.

it solves all the above 4 problems.

> [...]
 +int of_pci_get_dma_ranges(struct device_node *np, struct list_head 
 *resources)
 +{
 + struct device_node *node = of_node_get(np);
 + int rlen;
 + int ret = 0;
 + const int na = 3, ns = 2;
 + struct resource *res;
 + struct of_pci_range_parser parser;
 + struct of_pci_range range;
 +
 + if (!node)
 + return -EINVAL;
 +
 + parser.node = node;
 + parser.pna = of_n_addr_cells(node);
 + parser.np = parser.pna + na + ns;
 +
 + parser.range = of_get_property(node, "dma-ranges", );
 +
 + if (!parser.range) {
 + pr_debug("pcie device has no dma-ranges defined for 
 node(%s)\n",
 +   np->full_name);
 + ret = -EINVAL;
 + goto out;
 + }
 +
 + parser.end = parser.range + rlen / sizeof(__be32);
 +
 + for_each_of_pci_range(, ) {
>>>
>>> This is plain wrong - of_pci_range_parser_one() will translate upwards
>>> through parent "ranges" properties, which is completely backwards for
>>> DMA addresses.
>>>
>>> Robin.
>>>
>>
>> No it does not, this patch is thoroughly tested on our SOC and it works.
>> of_pci_range_parser_one does not translate upwards through parent. it
>> just sticks to given PCI parser.
>
> Frankly, I'm losing patience with this attitude. Please look at the code
> you call:
>
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
>
> struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
> *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
>
> if (!range)
> return NULL;
>
> if (!parser->range || 

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi Linus,

On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
 wrote:
>
> I actually would have preferred to not get any early merges, but what
> I was unhappy about is that I also didn't really get any heads-up
> about the cdev_device_add() conflict.
> 
> I did get notified about the other conflict (thanks, James), but
> somehow the cdev_device_add() changes didn't cause the same kind of
> notification.
> 
> So my unhappiness is not about me having to resolve things (I'm happy
> to do that) but about how apparently -next failed to notice that part
> of my merge resolution. Or maybe it was noticed in -next, but then the
> information about it got lost.
> 
> I prefer doing merge resolutions myself, but I *also* really really
> prefer the two sides of the conflict having been more aware of the
> clash.

Would that be this?

From: Stephen Rothwell 
To: Greg KH , Arnd Bergmann , Jarkko Sakkinen  

Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org, Logan  Gunthorpe 
, James Bottomley  
Subject: linux-next: manual merge of the char-misc tree with the tpmdd tree
Date: Fri, 24 Mar 2017 14:33:02 +1100

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/char/tpm/tpm-chip.c

between commits:

  67b67480db8b ("tpm: infrastructure for TPM spaces")
  b8e3586e8536 ("tpm: expose spaces via a device link /dev/tpmrm")

from the tpmdd tree and commit:

  8dbbf5825181 ("tpm-chip: utilize new cdev_device_add helper function")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/char/tpm/tpm-chip.c
index aade6995f310,935f0e92ad61..
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@@ -214,22 -186,7 +214,20 @@@ struct tpm_chip *tpm_chip_alloc(struct 
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
  
cdev_init(>cdev, _fops);
 +  cdev_init(>cdevs, _fops);
chip->cdev.owner = THIS_MODULE;
 +  chip->cdevs.owner = THIS_MODULE;
-   chip->cdev.kobj.parent = >dev.kobj;
-   chip->cdevs.kobj.parent = >devs.kobj;
 +
 +  chip->work_space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.context_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
 +  chip->work_space.session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.session_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
  
return chip;
  
@@@ -273,44 -229,13 +271,22 @@@ static int tpm_add_char_device(struct t
  {
int rc;
  
-   rc = cdev_add(>cdev, chip->dev.devt, 1);
+   rc = cdev_device_add(>cdev, >dev);
if (rc) {
dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
dev_name(>dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
 +  return rc;
 +  }
  
-   rc = device_add(>dev);
-   if (rc) {
-   dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
- 
-   cdev_del(>cdev);
-   return rc;
-   }
- 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = cdev_add(>cdevs, chip->devs.devt, 1);
-   if (rc) {
-   dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
-   }
- 
 +  if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = device_add(>devs);
++  rc = cdev_device_add(>cdevs, >devs);
 +  if (rc) {
 +  dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
++  "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
 +  dev_name(>devs), MAJOR(chip->devs.devt),
 +  MINOR(chip->devs.devt), rc);
-   cdev_del(>cdevs);
return rc;
}
  
@@@ -447,10 -371,6 +422,8 @@@ void tpm_chip_unregister(struct tpm_chi
  {
tpm_del_legacy_sysfs(chip);

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi Linus,

On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
 wrote:
>
> I actually would have preferred to not get any early merges, but what
> I was unhappy about is that I also didn't really get any heads-up
> about the cdev_device_add() conflict.
> 
> I did get notified about the other conflict (thanks, James), but
> somehow the cdev_device_add() changes didn't cause the same kind of
> notification.
> 
> So my unhappiness is not about me having to resolve things (I'm happy
> to do that) but about how apparently -next failed to notice that part
> of my merge resolution. Or maybe it was noticed in -next, but then the
> information about it got lost.
> 
> I prefer doing merge resolutions myself, but I *also* really really
> prefer the two sides of the conflict having been more aware of the
> clash.

Would that be this?

From: Stephen Rothwell 
To: Greg KH , Arnd Bergmann , Jarkko Sakkinen  

Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org, Logan  Gunthorpe 
, James Bottomley  
Subject: linux-next: manual merge of the char-misc tree with the tpmdd tree
Date: Fri, 24 Mar 2017 14:33:02 +1100

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/char/tpm/tpm-chip.c

between commits:

  67b67480db8b ("tpm: infrastructure for TPM spaces")
  b8e3586e8536 ("tpm: expose spaces via a device link /dev/tpmrm")

from the tpmdd tree and commit:

  8dbbf5825181 ("tpm-chip: utilize new cdev_device_add helper function")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/char/tpm/tpm-chip.c
index aade6995f310,935f0e92ad61..
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@@ -214,22 -186,7 +214,20 @@@ struct tpm_chip *tpm_chip_alloc(struct 
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
  
cdev_init(>cdev, _fops);
 +  cdev_init(>cdevs, _fops);
chip->cdev.owner = THIS_MODULE;
 +  chip->cdevs.owner = THIS_MODULE;
-   chip->cdev.kobj.parent = >dev.kobj;
-   chip->cdevs.kobj.parent = >devs.kobj;
 +
 +  chip->work_space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.context_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
 +  chip->work_space.session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.session_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
  
return chip;
  
@@@ -273,44 -229,13 +271,22 @@@ static int tpm_add_char_device(struct t
  {
int rc;
  
-   rc = cdev_add(>cdev, chip->dev.devt, 1);
+   rc = cdev_device_add(>cdev, >dev);
if (rc) {
dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
dev_name(>dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
 +  return rc;
 +  }
  
-   rc = device_add(>dev);
-   if (rc) {
-   dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
- 
-   cdev_del(>cdev);
-   return rc;
-   }
- 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = cdev_add(>cdevs, chip->devs.devt, 1);
-   if (rc) {
-   dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
-   }
- 
 +  if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = device_add(>devs);
++  rc = cdev_device_add(>cdevs, >devs);
 +  if (rc) {
 +  dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
++  "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
 +  dev_name(>devs), MAJOR(chip->devs.devt),
 +  MINOR(chip->devs.devt), rc);
-   cdev_del(>cdevs);
return rc;
}
  
@@@ -447,10 -371,6 +422,8 @@@ void tpm_chip_unregister(struct tpm_chi
  {
tpm_del_legacy_sysfs(chip);
tpm_bios_log_teardown(chip);
-   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
-   cdev_del(>cdevs);
-   device_del(>devs);
-   }
++  if (chip->flags & 

Re: [PATCH] firmware: Google VPD: Fix memory allocation error handling

[Christophe JAILLET]

Le 05/05/2017 à 21:56, Greg KH a écrit :

On Fri, May 05, 2017 at 09:08:44PM +0200, Christophe JAILLET wrote:

This patch fixes several issues:
- if the 1st 'kzalloc' fails, we dereference a NULL pointer
- if the 2nd 'kzalloc' fails, there is a memory leak
- if 'sysfs_create_bin_file' fails there is also a memory leak

Then it should be multiple patches, not fixing 3 things in one patch,
right?

thanks,

greg k-h

I can split it if you want, but the 3 points are more or less related 
and all belong to the same few lines of code. I didn't think having 3 
patches was needed in this case. I just wanted to give a detailed changelog.
If the commit message was only "This patch fixes memory allocation error 
handling in fct xxx' (as in the topic), I guess it would has been 
accepted (if it is correct of course) as-is.


Just tell me if you really prefer 3 patches, and I will resubmit.

CJ

Re: [PATCH] firmware: Google VPD: Fix memory allocation error handling

[Christophe JAILLET]

Le 05/05/2017 à 21:56, Greg KH a écrit :

On Fri, May 05, 2017 at 09:08:44PM +0200, Christophe JAILLET wrote:

This patch fixes several issues:
- if the 1st 'kzalloc' fails, we dereference a NULL pointer
- if the 2nd 'kzalloc' fails, there is a memory leak
- if 'sysfs_create_bin_file' fails there is also a memory leak

Then it should be multiple patches, not fixing 3 things in one patch,
right?

thanks,

greg k-h

I can split it if you want, but the 3 points are more or less related 
and all belong to the same few lines of code. I didn't think having 3 
patches was needed in this case. I just wanted to give a detailed changelog.
If the commit message was only "This patch fixes memory allocation error 
handling in fct xxx' (as in the topic), I guess it would has been 
accepted (if it is correct of course) as-is.


Just tell me if you really prefer 3 patches, and I will resubmit.

CJ

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Greg KH]

On Fri, May 05, 2017 at 09:42:40PM -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> > From: Chris Fries 
> > 
> > Add %paP and %padP for physical address that need to always be shown
> > regardless of kptr restrictions.
> 
> The commit message could be improved.

Good point, I'll work on that, thanks.

> I had to look at the actual code to see if %papP was supported.
> 
> > diff --git a/Documentation/printk-formats.txt 
> > b/Documentation/printk-formats.txt
> []
> > @@ -82,18 +82,20 @@ Struct Resources:
> >  
> >  Physical addresses types phys_addr_t:
> >  
> > -   %pa[p]  0x01234567 or 0x0123456789abcdef
> > +   %pa[p][P] 0x01234567 or 0x0123456789abcdef
> 
> Well, that's good.
> 
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> []
> > @@ -1394,23 +1394,29 @@ static noinline_for_stack
> >  char *address_val(char *buf, char *end, const void *addr, const char *fmt)
> >  {
> > unsigned long long num;
> > +   int cleanse = kptr_restrict_cleanse_addresses();
> 
> bool

I'll change this, thanks.

greg k-h

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Greg KH]

On Fri, May 05, 2017 at 09:42:40PM -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> > From: Chris Fries 
> > 
> > Add %paP and %padP for physical address that need to always be shown
> > regardless of kptr restrictions.
> 
> The commit message could be improved.

Good point, I'll work on that, thanks.

> I had to look at the actual code to see if %papP was supported.
> 
> > diff --git a/Documentation/printk-formats.txt 
> > b/Documentation/printk-formats.txt
> []
> > @@ -82,18 +82,20 @@ Struct Resources:
> >  
> >  Physical addresses types phys_addr_t:
> >  
> > -   %pa[p]  0x01234567 or 0x0123456789abcdef
> > +   %pa[p][P] 0x01234567 or 0x0123456789abcdef
> 
> Well, that's good.
> 
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> []
> > @@ -1394,23 +1394,29 @@ static noinline_for_stack
> >  char *address_val(char *buf, char *end, const void *addr, const char *fmt)
> >  {
> > unsigned long long num;
> > +   int cleanse = kptr_restrict_cleanse_addresses();
> 
> bool

I'll change this, thanks.

greg k-h

[PATCH] x86/boot: Correctly deeclare error() as noreturn

[Kees Cook]

The compressed boot function error() is used to halt execution, but it
wasn't marked with "noreturn". This fixes that in preparation for
supporting kernel FORTIFY_SOURCE, which uses the noreturn annotation
on panic, and calls error(). GCC would warn about a noreturn function
calling a non-noreturn function:

arch/x86/boot/compressed/misc.c: In function ‘fortify_panic’:
arch/x86/boot/compressed/misc.c:416:1: warning: ‘noreturn’ function does return
 }
 ^

Cc: Daniel Micay 
Signed-off-by: Kees Cook 
---
 arch/x86/boot/compressed/error.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/error.h b/arch/x86/boot/compressed/error.h
index 2e59dac07f9e..d732e608e3af 100644
--- a/arch/x86/boot/compressed/error.h
+++ b/arch/x86/boot/compressed/error.h
@@ -1,7 +1,9 @@
 #ifndef BOOT_COMPRESSED_ERROR_H
 #define BOOT_COMPRESSED_ERROR_H
 
+#include 
+
 void warn(char *m);
-void error(char *m);
+void error(char *m) __noreturn;
 
 #endif /* BOOT_COMPRESSED_ERROR_H */
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] x86/boot: Correctly deeclare error() as noreturn

[Kees Cook]

The compressed boot function error() is used to halt execution, but it
wasn't marked with "noreturn". This fixes that in preparation for
supporting kernel FORTIFY_SOURCE, which uses the noreturn annotation
on panic, and calls error(). GCC would warn about a noreturn function
calling a non-noreturn function:

arch/x86/boot/compressed/misc.c: In function ‘fortify_panic’:
arch/x86/boot/compressed/misc.c:416:1: warning: ‘noreturn’ function does return
 }
 ^

Cc: Daniel Micay 
Signed-off-by: Kees Cook 
---
 arch/x86/boot/compressed/error.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/error.h b/arch/x86/boot/compressed/error.h
index 2e59dac07f9e..d732e608e3af 100644
--- a/arch/x86/boot/compressed/error.h
+++ b/arch/x86/boot/compressed/error.h
@@ -1,7 +1,9 @@
 #ifndef BOOT_COMPRESSED_ERROR_H
 #define BOOT_COMPRESSED_ERROR_H
 
+#include 
+
 void warn(char *m);
-void error(char *m);
+void error(char *m) __noreturn;
 
 #endif /* BOOT_COMPRESSED_ERROR_H */
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

[Jassi Brar]

On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson
 wrote:
> On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote:

>> How is it supposed to work if a client queues more than one request?
>
> One such example is found in patch 5 in this series. There are two FIFOs
> in shared memory, one in each direction. Each fifo has a index-pair
> associated; a write-index is used by the writer to inform the reader
> where the valid data in the ring buffer ends and a read-index indicates
> to the writer how far behind the read is.
>
> The writer will just push data into the FIFO, each time firing off an
> APCS IPC interrupt and when the remote interrupt handler runs it will
> consume all the messages from the read-index to the write-index. All
> without the need for the reader to signal the writer that it has
> received the interrupts.
>
> In the event that the write-index catches up with the read-index a
> dedicated flag is set which will cause the reader to signal that the
> read-index is updated - allowing the writer to sleep waiting for room in
> the FIFO.
>
Interesting.Just for my enlightenment...

  Where does the writer sleep in the driver? I see it simply sets the
bit and leave.
Such a flag (or head and tail pointers matching) should be checked in
last_tx_done()

If you think RPM will _always_ be ready to accept new messages (though
we have seen that doesn't hold in some situations), then you don't
need last_tx_done. The client should call mbox_client_txdone() after
mbox_send_message().

thnx

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

[Jassi Brar]

On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson
 wrote:
> On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote:

>> How is it supposed to work if a client queues more than one request?
>
> One such example is found in patch 5 in this series. There are two FIFOs
> in shared memory, one in each direction. Each fifo has a index-pair
> associated; a write-index is used by the writer to inform the reader
> where the valid data in the ring buffer ends and a read-index indicates
> to the writer how far behind the read is.
>
> The writer will just push data into the FIFO, each time firing off an
> APCS IPC interrupt and when the remote interrupt handler runs it will
> consume all the messages from the read-index to the write-index. All
> without the need for the reader to signal the writer that it has
> received the interrupts.
>
> In the event that the write-index catches up with the read-index a
> dedicated flag is set which will cause the reader to signal that the
> read-index is updated - allowing the writer to sleep waiting for room in
> the FIFO.
>
Interesting.Just for my enlightenment...

  Where does the writer sleep in the driver? I see it simply sets the
bit and leave.
Such a flag (or head and tail pointers matching) should be checked in
last_tx_done()

If you think RPM will _always_ be ready to accept new messages (though
we have seen that doesn't hold in some situations), then you don't
need last_tx_done. The client should call mbox_client_txdone() after
mbox_send_message().

thnx

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Joe Perches]

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> From: Chris Fries 
> 
> Add %paP and %padP for physical address that need to always be shown
> regardless of kptr restrictions.

The commit message could be improved.

I had to look at the actual code to see if %papP was supported.

> diff --git a/Documentation/printk-formats.txt 
> b/Documentation/printk-formats.txt
[]
> @@ -82,18 +82,20 @@ Struct Resources:
>  
>  Physical addresses types phys_addr_t:
>  
> - %pa[p]  0x01234567 or 0x0123456789abcdef
> + %pa[p][P] 0x01234567 or 0x0123456789abcdef

Well, that's good.

> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
> @@ -1394,23 +1394,29 @@ static noinline_for_stack
>  char *address_val(char *buf, char *end, const void *addr, const char *fmt)
>  {
>   unsigned long long num;
> + int cleanse = kptr_restrict_cleanse_addresses();

bool

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Joe Perches]

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> From: Chris Fries 
> 
> Add %paP and %padP for physical address that need to always be shown
> regardless of kptr restrictions.

The commit message could be improved.

I had to look at the actual code to see if %papP was supported.

> diff --git a/Documentation/printk-formats.txt 
> b/Documentation/printk-formats.txt
[]
> @@ -82,18 +82,20 @@ Struct Resources:
>  
>  Physical addresses types phys_addr_t:
>  
> - %pa[p]  0x01234567 or 0x0123456789abcdef
> + %pa[p][P] 0x01234567 or 0x0123456789abcdef

Well, that's good.

> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
> @@ -1394,23 +1394,29 @@ static noinline_for_stack
>  char *address_val(char *buf, char *end, const void *addr, const char *fmt)
>  {
>   unsigned long long num;
> + int cleanse = kptr_restrict_cleanse_addresses();

bool

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

[David Gens]

On 2017-05-05 17:47, Thomas Garnier wrote:

On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss
 wrote:


On 04.05.2017 17:28, Thomas Garnier wrote:


Please read the documentation on submitting patches [1] and coding 
style [2].



I will have a closer look at that.


 - How this approach prevent the hardware attacks you mentioned? You
still have to keep a part of _text in the pagetable and an attacker
could discover it no? (and deduce the kernel base address).



These parts are moved to a different section (.user_mapped) which is 
at a possibly predictable location - the location of the randomized 
parts of the kernel is independent of the location of .user_mapped.
The code/data footprint for .user_mapped is quite small, helping to 
reduce or eliminate the attack surface...




If I get it right, it means you can leak the per-cpu address instead
of the kernel. Correct? That would be a problem because you can
elevate privilege by overwriting per-cpu variables. Leaking this
address means also defeating KASLR memory randomization [3] (cf paper
in the commit).

In theory you could put the code in the fixmap but you still have the
per-cpu variables and changing that is hard.

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=021182e52fe01c1f7b126f97fd6ba048dc4234fd


(Chiming in here, since we worked on something similar)

Assuming that their patch indeed leaks per-cpu addresses.. it might not 
necessarily
be required to change it. Since an adversary has to leak the per-cpu 
addresses
based on timing information you can work around that by inserting dummy 
entries
into the user mappings, with the goal of creating multiple candidate 
addresses
that show an identical measurement. For instance, you can create one 
entry for

every possible KASLR slot.



You also need to make it clear that btb attacks are still possible.



By just increasing the KASLR randomization range, btb attacks can be 
mitigated (for free).


Correct, I hope we can do that.




 - What is the perf impact?



It will vary for different machines. We have promising results (<1%) 
for an i7-6700K with representative benchmarks. However, for older 
systems or for workloads with a lot of pressure on some TLB levels, 
the performance may be much worse.


I think including performance data in both cases would be useful.


Best,
David

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

[David Gens]

On 2017-05-05 17:47, Thomas Garnier wrote:

On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss
 wrote:


On 04.05.2017 17:28, Thomas Garnier wrote:


Please read the documentation on submitting patches [1] and coding 
style [2].



I will have a closer look at that.


 - How this approach prevent the hardware attacks you mentioned? You
still have to keep a part of _text in the pagetable and an attacker
could discover it no? (and deduce the kernel base address).



These parts are moved to a different section (.user_mapped) which is 
at a possibly predictable location - the location of the randomized 
parts of the kernel is independent of the location of .user_mapped.
The code/data footprint for .user_mapped is quite small, helping to 
reduce or eliminate the attack surface...




If I get it right, it means you can leak the per-cpu address instead
of the kernel. Correct? That would be a problem because you can
elevate privilege by overwriting per-cpu variables. Leaking this
address means also defeating KASLR memory randomization [3] (cf paper
in the commit).

In theory you could put the code in the fixmap but you still have the
per-cpu variables and changing that is hard.

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=021182e52fe01c1f7b126f97fd6ba048dc4234fd


(Chiming in here, since we worked on something similar)

Assuming that their patch indeed leaks per-cpu addresses.. it might not 
necessarily
be required to change it. Since an adversary has to leak the per-cpu 
addresses
based on timing information you can work around that by inserting dummy 
entries
into the user mappings, with the goal of creating multiple candidate 
addresses
that show an identical measurement. For instance, you can create one 
entry for

every possible KASLR slot.



You also need to make it clear that btb attacks are still possible.



By just increasing the KASLR randomization range, btb attacks can be 
mitigated (for free).


Correct, I hope we can do that.




 - What is the perf impact?



It will vary for different machines. We have promising results (<1%) 
for an i7-6700K with representative benchmarks. However, for older 
systems or for workloads with a lot of pressure on some TLB levels, 
the performance may be much worse.


I think including performance data in both cases would be useful.


Best,
David

[patch] device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX

[Mike Galbraith]

ERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined!

Signed-off-by: Mike Galbraith 
---
 drivers/dax/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -19,7 +19,7 @@ config DEV_DAX
 
 config DEV_DAX_PMEM
tristate "PMEM DAX: direct access to persistent memory"
-   depends on LIBNVDIMM && NVDIMM_DAX
+   depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX
default DEV_DAX
help
  Support raw access to persistent memory.  Note that this

[patch] device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX

[Mike Galbraith]

ERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined!

Signed-off-by: Mike Galbraith 
---
 drivers/dax/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -19,7 +19,7 @@ config DEV_DAX
 
 config DEV_DAX_PMEM
tristate "PMEM DAX: direct access to persistent memory"
-   depends on LIBNVDIMM && NVDIMM_DAX
+   depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX
default DEV_DAX
help
  Support raw access to persistent memory.  Note that this

[RFC 6/6] drivers: uio: Un-restrict sysfs pointers for UIO

[Greg KH]

From: Chris Fries 

The addr and size on the UIO devices are required by userspace to function
properly.  Let's unrestrict these by adding the 'P' modifier to %p and %pa.

Cc: William Roberts 
Cc: Dave Weinstein 
Signed-off-by: Chris Fries 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/uio/uio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 60ce7fd54e89..d9eae52519f4 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -56,12 +56,12 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
 
 static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
 {
-   return sprintf(buf, "%pa\n", >addr);
+   return sprintf(buf, "%paP\n", >addr);
 }
 
 static ssize_t map_size_show(struct uio_mem *mem, char *buf)
 {
-   return sprintf(buf, "%pa\n", >size);
+   return sprintf(buf, "%paP\n", >size);
 }
 
 static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
-- 
2.12.2

[RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Greg KH]

From: Chris Fries 

Add %paP and %padP for physical address that need to always be shown
regardless of kptr restrictions.

Cc: William Roberts 
Cc: Dave Weinstein 
Signed-off-by: Chris Fries 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/printk-formats.txt | 10 ++
 lib/vsprintf.c   | 12 +---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8994c65aa3b0..7ee51269096f 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -82,18 +82,20 @@ Struct Resources:
 
 Physical addresses types phys_addr_t:
 
-   %pa[p]  0x01234567 or 0x0123456789abcdef
+   %pa[p][P] 0x01234567 or 0x0123456789abcdef
 
For printing a phys_addr_t type (and its derivatives, such as
resource_size_t) which can vary based on build options, regardless of
-   the width of the CPU data path. Passed by reference.
+   the width of the CPU data path. Passed by reference.  Use the trailing
+   'P' if it needs to be always shown.
 
 DMA addresses types dma_addr_t:
 
-   %pad0x01234567 or 0x0123456789abcdef
+   %pad[P] 0x01234567 or 0x0123456789abcdef
 
For printing a dma_addr_t type which can vary based on build options,
-   regardless of the width of the CPU data path. Passed by reference.
+   regardless of the width of the CPU data path. Passed by reference. Use
+   the trailing 'P' if it needs to be always shown.
 
 Raw buffer as an escaped string:
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 404d477d4bd2..37f9d615e622 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1394,23 +1394,29 @@ static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr, const char *fmt)
 {
unsigned long long num;
+   int cleanse = kptr_restrict_cleanse_addresses();
+   int decleanse_idx = 1;
int size;
 
switch (fmt[1]) {
case 'd':
num = *(const dma_addr_t *)addr;
size = sizeof(dma_addr_t);
+   decleanse_idx = 2;
break;
case 'p':
+   decleanse_idx = 2;
+   /* fall thru */
default:
num = *(const phys_addr_t *)addr;
size = sizeof(phys_addr_t);
break;
}
 
-   return special_hex_number(buf, end,
- kptr_restrict_cleanse_addresses() ? 0UL : num,
- size);
+   /* 'P' on the tail means don't restrict the pointer. */
+   cleanse = cleanse && (fmt[decleanse_idx] != 'P');
+
+   return special_hex_number(buf, end, cleanse ? 0UL : num, size);
 }
 
 static noinline_for_stack
-- 
2.12.2

[RFC 6/6] drivers: uio: Un-restrict sysfs pointers for UIO

[Greg KH]

From: Chris Fries 

The addr and size on the UIO devices are required by userspace to function
properly.  Let's unrestrict these by adding the 'P' modifier to %p and %pa.

Cc: William Roberts 
Cc: Dave Weinstein 
Signed-off-by: Chris Fries 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/uio/uio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 60ce7fd54e89..d9eae52519f4 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -56,12 +56,12 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
 
 static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
 {
-   return sprintf(buf, "%pa\n", >addr);
+   return sprintf(buf, "%paP\n", >addr);
 }
 
 static ssize_t map_size_show(struct uio_mem *mem, char *buf)
 {
-   return sprintf(buf, "%pa\n", >size);
+   return sprintf(buf, "%paP\n", >size);
 }
 
 static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
-- 
2.12.2

[RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

[Greg KH]

From: Chris Fries 

Add %paP and %padP for physical address that need to always be shown
regardless of kptr restrictions.

Cc: William Roberts 
Cc: Dave Weinstein 
Signed-off-by: Chris Fries 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/printk-formats.txt | 10 ++
 lib/vsprintf.c   | 12 +---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8994c65aa3b0..7ee51269096f 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -82,18 +82,20 @@ Struct Resources:
 
 Physical addresses types phys_addr_t:
 
-   %pa[p]  0x01234567 or 0x0123456789abcdef
+   %pa[p][P] 0x01234567 or 0x0123456789abcdef
 
For printing a phys_addr_t type (and its derivatives, such as
resource_size_t) which can vary based on build options, regardless of
-   the width of the CPU data path. Passed by reference.
+   the width of the CPU data path. Passed by reference.  Use the trailing
+   'P' if it needs to be always shown.
 
 DMA addresses types dma_addr_t:
 
-   %pad0x01234567 or 0x0123456789abcdef
+   %pad[P] 0x01234567 or 0x0123456789abcdef
 
For printing a dma_addr_t type which can vary based on build options,
-   regardless of the width of the CPU data path. Passed by reference.
+   regardless of the width of the CPU data path. Passed by reference. Use
+   the trailing 'P' if it needs to be always shown.
 
 Raw buffer as an escaped string:
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 404d477d4bd2..37f9d615e622 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1394,23 +1394,29 @@ static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr, const char *fmt)
 {
unsigned long long num;
+   int cleanse = kptr_restrict_cleanse_addresses();
+   int decleanse_idx = 1;
int size;
 
switch (fmt[1]) {
case 'd':
num = *(const dma_addr_t *)addr;
size = sizeof(dma_addr_t);
+   decleanse_idx = 2;
break;
case 'p':
+   decleanse_idx = 2;
+   /* fall thru */
default:
num = *(const phys_addr_t *)addr;
size = sizeof(phys_addr_t);
break;
}
 
-   return special_hex_number(buf, end,
- kptr_restrict_cleanse_addresses() ? 0UL : num,
- size);
+   /* 'P' on the tail means don't restrict the pointer. */
+   cleanse = cleanse && (fmt[decleanse_idx] != 'P');
+
+   return special_hex_number(buf, end, cleanse ? 0UL : num, size);
 }
 
 static noinline_for_stack
-- 
2.12.2

[RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

[Greg KH]

From: Dave Weinstein 

Add the kptr_restrict setting of 4 which results in %pa and
%p[rR] values being replaced by zeros.

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/sysctl/kernel.txt |  8 +++-
 kernel/sysctl.c |  3 +--
 lib/vsprintf.c  | 33 ++---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index c9f5da409868..df069ec42e4a 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -393,7 +393,13 @@ When kptr_restrict is set to (2), kernel pointers printed 
using
 %pK will be replaced with 0's regardless of privileges.
 
 When kptr_restrict is set to (3), kernel pointers printed using
-%p and %pK will be replaced with 0's regardless of privileges.
+%p and %pK will be replaced with 0's regardless of privileges,
+however kernel pointers printed using %pP will continue to be printed.
+
+When kptr_restrict is set to (4), kernel pointers printed with
+%p, %pK, %pa, and %p[rR] will be replaced with 0's regardless of
+privileges. Kernel pointers printed using %pP will continue to be
+printed.
 
 ==
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 1bfdd262c66a..acf7e6cb00b4 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -129,7 +129,6 @@ static unsigned long one_ul = 1;
 static int one_hundred = 100;
 static int one_thousand = 1000;
 #ifdef CONFIG_PRINTK
-static int three = 3;
 static int ten_thousand = 1;
 #endif
 #ifdef CONFIG_PERF_EVENTS
@@ -831,7 +830,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec_minmax_sysadmin,
.extra1 = ,
-   .extra2 = ,
+   .extra2 = ,
},
 #endif
{
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index f4e11dade1ab..75a49795fcae 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -405,6 +405,22 @@ static inline int 
kptr_restrict_always_cleanse_pointers(void)
return kptr_restrict >= 3;
 }
 
+/*
+ * Always cleanse physical addresses (%pa* specifiers)
+ */
+static inline int kptr_restrict_cleanse_addresses(void)
+{
+   return kptr_restrict >= 4;
+}
+
+/*
+ * Always cleanse resource addresses (%p[rR] specifiers)
+ */
+static inline int kptr_restrict_cleanse_resources(void)
+{
+   return kptr_restrict >= 4;
+}
+
 static noinline_for_stack
 char *number(char *buf, char *end, unsigned long long num,
 struct printf_spec spec)
@@ -757,6 +773,7 @@ char *resource_string(char *buf, char *end, struct resource 
*res,
 
char *p = sym, *pend = sym + sizeof(sym);
int decode = (fmt[0] == 'R') ? 1 : 0;
+   int cleanse = kptr_restrict_cleanse_resources();
const struct printf_spec *specp;
 
*p++ = '[';
@@ -784,10 +801,11 @@ char *resource_string(char *buf, char *end, struct 
resource *res,
p = string(p, pend, "size ", str_spec);
p = number(p, pend, resource_size(res), *specp);
} else {
-   p = number(p, pend, res->start, *specp);
+   p = number(p, pend, cleanse ? 0UL : res->start, *specp);
if (res->start != res->end) {
*p++ = '-';
-   p = number(p, pend, res->end, *specp);
+   p = number(p, pend, cleanse ?
+  res->end - res->start : res->end, *specp);
}
}
if (decode) {
@@ -1390,7 +1408,9 @@ char *address_val(char *buf, char *end, const void *addr, 
const char *fmt)
break;
}
 
-   return special_hex_number(buf, end, num, size);
+   return special_hex_number(buf, end,
+ kptr_restrict_cleanse_addresses() ? 0UL : num,
+ size);
 }
 
 static noinline_for_stack
@@ -1581,6 +1601,12 @@ char *flags_string(char *buf, char *end, void 
*flags_ptr, const char *fmt)
  *
  * Note: That for kptr_restrict set to 3, %p and %pK have the same
  * meaning.
+ *
+ * Note: That for kptr_restrict set to 4, %pa will null out the physical
+ * address.
+ *
+ * Note: That for kptr_restrict set to 4, %p[rR] will null out the memory
+ * address.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1738,6 +1764,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
}
case 2: /* restrict only %pK */
case 3: /* restrict all non-extensioned %p and %pK */
+   case 4: /* restrict all non-extensioned %p, %pK, %pa*, %p[rR] */
default:
ptr = NULL;
 

[RFC 4/6] lib: vsprintf: default kptr_restrict to the maximum value

[Greg KH]

From: Dave Weinstein 

Set the initial value of kptr_restrict to the maximum
setting rather than the minimum setting, to ensure that
early boot logging is not leaking information.

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 75a49795fcae..404d477d4bd2 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -395,7 +395,7 @@ struct printf_spec {
 #define FIELD_WIDTH_MAX ((1 << 23) - 1)
 #define PRECISION_MAX ((1 << 15) - 1)
 
-int kptr_restrict __read_mostly;
+int kptr_restrict __read_mostly = 4;
 
 /*
  * Always cleanse %p and %pK specifiers
-- 
2.12.2

[RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

[Greg KH]

From: Dave Weinstein 

Add the kptr_restrict setting of 4 which results in %pa and
%p[rR] values being replaced by zeros.

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/sysctl/kernel.txt |  8 +++-
 kernel/sysctl.c |  3 +--
 lib/vsprintf.c  | 33 ++---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index c9f5da409868..df069ec42e4a 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -393,7 +393,13 @@ When kptr_restrict is set to (2), kernel pointers printed 
using
 %pK will be replaced with 0's regardless of privileges.
 
 When kptr_restrict is set to (3), kernel pointers printed using
-%p and %pK will be replaced with 0's regardless of privileges.
+%p and %pK will be replaced with 0's regardless of privileges,
+however kernel pointers printed using %pP will continue to be printed.
+
+When kptr_restrict is set to (4), kernel pointers printed with
+%p, %pK, %pa, and %p[rR] will be replaced with 0's regardless of
+privileges. Kernel pointers printed using %pP will continue to be
+printed.
 
 ==
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 1bfdd262c66a..acf7e6cb00b4 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -129,7 +129,6 @@ static unsigned long one_ul = 1;
 static int one_hundred = 100;
 static int one_thousand = 1000;
 #ifdef CONFIG_PRINTK
-static int three = 3;
 static int ten_thousand = 1;
 #endif
 #ifdef CONFIG_PERF_EVENTS
@@ -831,7 +830,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec_minmax_sysadmin,
.extra1 = ,
-   .extra2 = ,
+   .extra2 = ,
},
 #endif
{
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index f4e11dade1ab..75a49795fcae 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -405,6 +405,22 @@ static inline int 
kptr_restrict_always_cleanse_pointers(void)
return kptr_restrict >= 3;
 }
 
+/*
+ * Always cleanse physical addresses (%pa* specifiers)
+ */
+static inline int kptr_restrict_cleanse_addresses(void)
+{
+   return kptr_restrict >= 4;
+}
+
+/*
+ * Always cleanse resource addresses (%p[rR] specifiers)
+ */
+static inline int kptr_restrict_cleanse_resources(void)
+{
+   return kptr_restrict >= 4;
+}
+
 static noinline_for_stack
 char *number(char *buf, char *end, unsigned long long num,
 struct printf_spec spec)
@@ -757,6 +773,7 @@ char *resource_string(char *buf, char *end, struct resource 
*res,
 
char *p = sym, *pend = sym + sizeof(sym);
int decode = (fmt[0] == 'R') ? 1 : 0;
+   int cleanse = kptr_restrict_cleanse_resources();
const struct printf_spec *specp;
 
*p++ = '[';
@@ -784,10 +801,11 @@ char *resource_string(char *buf, char *end, struct 
resource *res,
p = string(p, pend, "size ", str_spec);
p = number(p, pend, resource_size(res), *specp);
} else {
-   p = number(p, pend, res->start, *specp);
+   p = number(p, pend, cleanse ? 0UL : res->start, *specp);
if (res->start != res->end) {
*p++ = '-';
-   p = number(p, pend, res->end, *specp);
+   p = number(p, pend, cleanse ?
+  res->end - res->start : res->end, *specp);
}
}
if (decode) {
@@ -1390,7 +1408,9 @@ char *address_val(char *buf, char *end, const void *addr, 
const char *fmt)
break;
}
 
-   return special_hex_number(buf, end, num, size);
+   return special_hex_number(buf, end,
+ kptr_restrict_cleanse_addresses() ? 0UL : num,
+ size);
 }
 
 static noinline_for_stack
@@ -1581,6 +1601,12 @@ char *flags_string(char *buf, char *end, void 
*flags_ptr, const char *fmt)
  *
  * Note: That for kptr_restrict set to 3, %p and %pK have the same
  * meaning.
+ *
+ * Note: That for kptr_restrict set to 4, %pa will null out the physical
+ * address.
+ *
+ * Note: That for kptr_restrict set to 4, %p[rR] will null out the memory
+ * address.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1738,6 +1764,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
}
case 2: /* restrict only %pK */
case 3: /* restrict all non-extensioned %p and %pK */
+   case 4: /* restrict all non-extensioned %p, %pK, %pa*, %p[rR] */
default:
ptr = NULL;
break;
-- 
2.12.2

[RFC 4/6] lib: vsprintf: default kptr_restrict to the maximum value

[Greg KH]

From: Dave Weinstein 

Set the initial value of kptr_restrict to the maximum
setting rather than the minimum setting, to ensure that
early boot logging is not leaking information.

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 75a49795fcae..404d477d4bd2 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -395,7 +395,7 @@ struct printf_spec {
 #define FIELD_WIDTH_MAX ((1 << 23) - 1)
 #define PRECISION_MAX ((1 << 15) - 1)
 
-int kptr_restrict __read_mostly;
+int kptr_restrict __read_mostly = 4;
 
 /*
  * Always cleanse %p and %pK specifiers
-- 
2.12.2

[RFC 1/6] lib: vsprintf: additional kernel pointer filtering options

[Greg KH]

From: Dave Weinstein 

Add the kptr_restrict setting of 3 which results in both
%p and %pK values being replaced by zeros.

Add an additional %pP value inspired by the Grsecurity
option which explicitly whitelists pointers for output.

This patch is based on work by William Roberts


Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/printk-formats.txt |  5 +++
 Documentation/sysctl/kernel.txt  |  3 ++
 kernel/sysctl.c  |  3 +-
 lib/vsprintf.c   | 81 ++--
 4 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 5962949944fd..8994c65aa3b0 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -64,6 +64,11 @@ Kernel Pointers:
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
Documentation/sysctl/kernel.txt for more details.
 
+   %pP 0x01234567 or 0x0123456789abcdef
+
+   For printing kernel pointers which should always be shown, even to
+   unprivileged users.
+
 Struct Resources:
 
%pr [mem 0x6000-0x6fff flags 0x2200] or
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index bac23c198360..c9f5da409868 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -392,6 +392,9 @@ values to unprivileged users is a concern.
 When kptr_restrict is set to (2), kernel pointers printed using
 %pK will be replaced with 0's regardless of privileges.
 
+When kptr_restrict is set to (3), kernel pointers printed using
+%p and %pK will be replaced with 0's regardless of privileges.
+
 ==
 
 l2cr: (PPC only)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8c8714fcb53c..1bfdd262c66a 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -129,6 +129,7 @@ static unsigned long one_ul = 1;
 static int one_hundred = 100;
 static int one_thousand = 1000;
 #ifdef CONFIG_PRINTK
+static int three = 3;
 static int ten_thousand = 1;
 #endif
 #ifdef CONFIG_PERF_EVENTS
@@ -830,7 +831,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec_minmax_sysadmin,
.extra1 = ,
-   .extra2 = ,
+   .extra2 = ,
},
 #endif
{
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index e3bf4e0f10b5..f4e11dade1ab 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -395,6 +395,16 @@ struct printf_spec {
 #define FIELD_WIDTH_MAX ((1 << 23) - 1)
 #define PRECISION_MAX ((1 << 15) - 1)
 
+int kptr_restrict __read_mostly;
+
+/*
+ * Always cleanse %p and %pK specifiers
+ */
+static inline int kptr_restrict_always_cleanse_pointers(void)
+{
+   return kptr_restrict >= 3;
+}
+
 static noinline_for_stack
 char *number(char *buf, char *end, unsigned long long num,
 struct printf_spec spec)
@@ -1470,8 +1480,6 @@ char *flags_string(char *buf, char *end, void *flags_ptr, 
const char *fmt)
return format_flags(buf, end, flags, names);
 }
 
-int kptr_restrict __read_mostly;
-
 /*
  * Show a '%p' thing.  A kernel extension is that the '%p' is followed
  * by an extra set of alphanumeric characters that are extended format
@@ -1540,6 +1548,7 @@ int kptr_restrict __read_mostly;
  *   Do not use this feature without some mechanism to verify the
  *   correctness of the format string and va_list arguments.
  * - 'K' For a kernel pointer that should be hidden from unprivileged users
+ * - 'P' For a kernel pointer that should be shown to all users
  * - 'NF' For a netdev_features_t
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *a certain separator (' ' by default):
@@ -1569,6 +1578,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Note: That for kptr_restrict set to 3, %p and %pK have the same
+ * meaning.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1576,7 +1588,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
 {
const int default_width = 2 * sizeof(void *);
 
-   if (!ptr && *fmt != 'K') {
+   if (!ptr && *fmt != 'K' && !kptr_restrict_always_cleanse_pointers()) {
/*
 * Print (null) with the same width as a pointer so it makes
 * tabular output look nice.
@@ -1657,10 +1669,43 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,

[RFC 1/6] lib: vsprintf: additional kernel pointer filtering options

[Greg KH]

From: Dave Weinstein 

Add the kptr_restrict setting of 3 which results in both
%p and %pK values being replaced by zeros.

Add an additional %pP value inspired by the Grsecurity
option which explicitly whitelists pointers for output.

This patch is based on work by William Roberts


Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/printk-formats.txt |  5 +++
 Documentation/sysctl/kernel.txt  |  3 ++
 kernel/sysctl.c  |  3 +-
 lib/vsprintf.c   | 81 ++--
 4 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 5962949944fd..8994c65aa3b0 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -64,6 +64,11 @@ Kernel Pointers:
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
Documentation/sysctl/kernel.txt for more details.
 
+   %pP 0x01234567 or 0x0123456789abcdef
+
+   For printing kernel pointers which should always be shown, even to
+   unprivileged users.
+
 Struct Resources:
 
%pr [mem 0x6000-0x6fff flags 0x2200] or
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index bac23c198360..c9f5da409868 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -392,6 +392,9 @@ values to unprivileged users is a concern.
 When kptr_restrict is set to (2), kernel pointers printed using
 %pK will be replaced with 0's regardless of privileges.
 
+When kptr_restrict is set to (3), kernel pointers printed using
+%p and %pK will be replaced with 0's regardless of privileges.
+
 ==
 
 l2cr: (PPC only)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8c8714fcb53c..1bfdd262c66a 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -129,6 +129,7 @@ static unsigned long one_ul = 1;
 static int one_hundred = 100;
 static int one_thousand = 1000;
 #ifdef CONFIG_PRINTK
+static int three = 3;
 static int ten_thousand = 1;
 #endif
 #ifdef CONFIG_PERF_EVENTS
@@ -830,7 +831,7 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec_minmax_sysadmin,
.extra1 = ,
-   .extra2 = ,
+   .extra2 = ,
},
 #endif
{
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index e3bf4e0f10b5..f4e11dade1ab 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -395,6 +395,16 @@ struct printf_spec {
 #define FIELD_WIDTH_MAX ((1 << 23) - 1)
 #define PRECISION_MAX ((1 << 15) - 1)
 
+int kptr_restrict __read_mostly;
+
+/*
+ * Always cleanse %p and %pK specifiers
+ */
+static inline int kptr_restrict_always_cleanse_pointers(void)
+{
+   return kptr_restrict >= 3;
+}
+
 static noinline_for_stack
 char *number(char *buf, char *end, unsigned long long num,
 struct printf_spec spec)
@@ -1470,8 +1480,6 @@ char *flags_string(char *buf, char *end, void *flags_ptr, 
const char *fmt)
return format_flags(buf, end, flags, names);
 }
 
-int kptr_restrict __read_mostly;
-
 /*
  * Show a '%p' thing.  A kernel extension is that the '%p' is followed
  * by an extra set of alphanumeric characters that are extended format
@@ -1540,6 +1548,7 @@ int kptr_restrict __read_mostly;
  *   Do not use this feature without some mechanism to verify the
  *   correctness of the format string and va_list arguments.
  * - 'K' For a kernel pointer that should be hidden from unprivileged users
+ * - 'P' For a kernel pointer that should be shown to all users
  * - 'NF' For a netdev_features_t
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *a certain separator (' ' by default):
@@ -1569,6 +1578,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Note: That for kptr_restrict set to 3, %p and %pK have the same
+ * meaning.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1576,7 +1588,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
 {
const int default_width = 2 * sizeof(void *);
 
-   if (!ptr && *fmt != 'K') {
+   if (!ptr && *fmt != 'K' && !kptr_restrict_always_cleanse_pointers()) {
/*
 * Print (null) with the same width as a pointer so it makes
 * tabular output look nice.
@@ -1657,10 +1669,43 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
va_end(va);
return buf;
}
+   case 'N':
+   return netdev_bits(buf, end, ptr, 

[RFC 2/6] lib: vsprintf: whitelist stack traces

[Greg KH]

From: Dave Weinstein 

Use the %pP functionality to explicitly allow kernel
pointers to be logged for stack traces

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/kernel/traps.c | 4 ++--
 include/linux/kallsyms.h  | 2 +-
 kernel/printk/printk.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index e52be6aa44ee..b127be39011a 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -146,7 +146,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
unsigned long irq_stack_ptr;
int skip;
 
-   pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+   pr_debug("%s(regs = %pP tsk = %pP)\n", __func__, regs, tsk);
 
if (!tsk)
tsk = current;
@@ -252,7 +252,7 @@ static int __die(const char *str, int err, struct pt_regs 
*regs)
 
print_modules();
__show_regs(regs);
-   pr_emerg("Process %.*s (pid: %d, stack limit = 0x%p)\n",
+   pr_emerg("Process %.*s (pid: %d, stack limit = 0x%pP)\n",
 TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk),
 end_of_stack(tsk));
 
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 6883e197acb9..e4a205debe09 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -122,7 +122,7 @@ static inline void print_symbol(const char *fmt, unsigned 
long addr)
 
 static inline void print_ip_sym(unsigned long ip)
 {
-   printk("[<%p>] %pS\n", (void *) ip, (void *) ip);
+   printk("[<%pP>] %pS\n", (void *) ip, (void *) ip);
 }
 
 #endif /*_LINUX_KALLSYMS_H*/
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2984fb0f0257..d32e84e3ab6b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3110,7 +3110,7 @@ void show_regs_print_info(const char *log_lvl)
 {
dump_stack_print_info(log_lvl);
 
-   printk("%stask: %p task.stack: %p\n",
+   printk("%stask: %pP task.stack: %pP\n",
   log_lvl, current, task_stack_page(current));
 }
 
-- 
2.12.2

[RFC 2/6] lib: vsprintf: whitelist stack traces

[Greg KH]

From: Dave Weinstein 

Use the %pP functionality to explicitly allow kernel
pointers to be logged for stack traces

Cc: William Roberts 
Cc: Chris Fries 
Signed-off-by: Dave Weinstein 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/kernel/traps.c | 4 ++--
 include/linux/kallsyms.h  | 2 +-
 kernel/printk/printk.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index e52be6aa44ee..b127be39011a 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -146,7 +146,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
unsigned long irq_stack_ptr;
int skip;
 
-   pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+   pr_debug("%s(regs = %pP tsk = %pP)\n", __func__, regs, tsk);
 
if (!tsk)
tsk = current;
@@ -252,7 +252,7 @@ static int __die(const char *str, int err, struct pt_regs 
*regs)
 
print_modules();
__show_regs(regs);
-   pr_emerg("Process %.*s (pid: %d, stack limit = 0x%p)\n",
+   pr_emerg("Process %.*s (pid: %d, stack limit = 0x%pP)\n",
 TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk),
 end_of_stack(tsk));
 
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 6883e197acb9..e4a205debe09 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -122,7 +122,7 @@ static inline void print_symbol(const char *fmt, unsigned 
long addr)
 
 static inline void print_ip_sym(unsigned long ip)
 {
-   printk("[<%p>] %pS\n", (void *) ip, (void *) ip);
+   printk("[<%pP>] %pS\n", (void *) ip, (void *) ip);
 }
 
 #endif /*_LINUX_KALLSYMS_H*/
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2984fb0f0257..d32e84e3ab6b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3110,7 +3110,7 @@ void show_regs_print_info(const char *log_lvl)
 {
dump_stack_print_info(log_lvl);
 
-   printk("%stask: %p task.stack: %p\n",
+   printk("%stask: %pP task.stack: %pP\n",
   log_lvl, current, task_stack_page(current));
 }
 
-- 
2.12.2

[RFC 00/06] printk: add more new kernel pointer filter options.

[Greg KH]

Here's a short patch series from Chris Fries and Dave Weinstein that
implement some new restrictions when printing out kernel pointers, as
well as the ability to whitelist kernel pointers where needed.

These patches are based on work from William Roberts, and also is
inspired by grsecurity's %pP to specifically whitelist a kernel pointer,
where it is always needed, like the last patch in the series shows, in
the UIO drivers (UIO requires that you know the address, it's a hardware
address, nothing wrong with seeing that...)

I haven't done much to this patch series, only forward porting it from
an older kernel release (4.4) and a few minor tweaks.  It applies
cleanly on top of 4.11 as well as Linus's current development tree
(10502 patches into the 4.12-rc1 merge window).  I'm posting it now for
comments if anyone sees anything wrong with this approach, or thinks the
things that are being whitelisted should not be?

thanks,

greg k-h

 Documentation/printk-formats.txt |   15 +++-
 Documentation/sysctl/kernel.txt  |   11 +++
 arch/arm64/kernel/traps.c|4 -
 drivers/uio/uio.c|4 -
 include/linux/kallsyms.h |2
 kernel/printk/printk.c   |2
 kernel/sysctl.c  |6 -
 lib/vsprintf.c   |  128 ---
 8 files changed, 123 insertions(+), 49 deletions(-)

[RFC 00/06] printk: add more new kernel pointer filter options.

[Greg KH]

Here's a short patch series from Chris Fries and Dave Weinstein that
implement some new restrictions when printing out kernel pointers, as
well as the ability to whitelist kernel pointers where needed.

These patches are based on work from William Roberts, and also is
inspired by grsecurity's %pP to specifically whitelist a kernel pointer,
where it is always needed, like the last patch in the series shows, in
the UIO drivers (UIO requires that you know the address, it's a hardware
address, nothing wrong with seeing that...)

I haven't done much to this patch series, only forward porting it from
an older kernel release (4.4) and a few minor tweaks.  It applies
cleanly on top of 4.11 as well as Linus's current development tree
(10502 patches into the 4.12-rc1 merge window).  I'm posting it now for
comments if anyone sees anything wrong with this approach, or thinks the
things that are being whitelisted should not be?

thanks,

greg k-h

 Documentation/printk-formats.txt |   15 +++-
 Documentation/sysctl/kernel.txt  |   11 +++
 arch/arm64/kernel/traps.c|4 -
 drivers/uio/uio.c|4 -
 include/linux/kallsyms.h |2
 kernel/printk/printk.c   |2
 kernel/sysctl.c  |6 -
 lib/vsprintf.c   |  128 ---
 8 files changed, 123 insertions(+), 49 deletions(-)

Re: [PATCH 4.4 00/20] 4.4.67-stable review

[Greg Kroah-Hartman]

On Fri, May 05, 2017 at 07:58:50PM -0600, Shuah Khan wrote:
> On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.67 release.
> > There are 20 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun May  7 18:32:22 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.67-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

Re: [PATCH 4.4 00/20] 4.4.67-stable review

[Greg Kroah-Hartman]

On Fri, May 05, 2017 at 07:58:50PM -0600, Shuah Khan wrote:
> On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.67 release.
> > There are 20 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun May  7 18:32:22 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.67-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

[Kani, Toshimitsu]

> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu 
> wrote:
> > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:
> >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu 
> >> wrote:
> >  :
> >> > > ---
> >> > > Changes since the initial RFC:
> >> > > * s/writethru/wt/ since we already have ioremap_wt(),
> >> > > set_memory_wt(), etc. (Ingo)
> >> >
> >> > Sorry I should have said earlier, but I think the term "wt" is
> >> > misleading.  Non-temporal stores used in memcpy_wt() provide WC
> >> > semantics, not WT semantics.
> >>
> >> The non-temporal stores do, but memcpy_wt() is using a combination of
> >> non-temporal stores and explicit cache flushing.
> >>
> >> > How about using "nocache" as it's been
> >> > used in __copy_user_nocache()?
> >>
> >> The difference in my mind is that the "_nocache" suffix indicates
> >> opportunistic / optional cache pollution avoidance whereas "_wt"
> >> strictly arranges for caches not to contain dirty data upon
> >> completion of the routine. For example, non-temporal stores on older
> >> x86 cpus could potentially leave dirty data in the cache, so
> >> memcpy_wt on those cpus would need to use explicit cache flushing.
> >
> > I see.  I agree that its behavior is different from the existing one
> > with "_nocache".   That said, I think "wt" or "write-through" generally
> > means that writes allocate cachelines and keep them clean by writing to
> > memory.  So, subsequent reads to the destination will hit the
> > cachelines.  This is not the case with this interface.
> 
> True... maybe _nocache_strict()? Or, leave it _wt() until someone
> comes along and is surprised that the cache is not warm for reads
> after memcpy_wt(), at which point we can ask "why not just use plain
> memcpy then?", or set the page-attributes to WT.

I prefer _nocache_strict(), if it's not too long, since it avoids any
confusion.  If other arches actually implement it with WT semantics,
we might become the one to change it, instead of the caller.

Thanks,
-Toshi

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

[Kani, Toshimitsu]

> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu 
> wrote:
> > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:
> >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu 
> >> wrote:
> >  :
> >> > > ---
> >> > > Changes since the initial RFC:
> >> > > * s/writethru/wt/ since we already have ioremap_wt(),
> >> > > set_memory_wt(), etc. (Ingo)
> >> >
> >> > Sorry I should have said earlier, but I think the term "wt" is
> >> > misleading.  Non-temporal stores used in memcpy_wt() provide WC
> >> > semantics, not WT semantics.
> >>
> >> The non-temporal stores do, but memcpy_wt() is using a combination of
> >> non-temporal stores and explicit cache flushing.
> >>
> >> > How about using "nocache" as it's been
> >> > used in __copy_user_nocache()?
> >>
> >> The difference in my mind is that the "_nocache" suffix indicates
> >> opportunistic / optional cache pollution avoidance whereas "_wt"
> >> strictly arranges for caches not to contain dirty data upon
> >> completion of the routine. For example, non-temporal stores on older
> >> x86 cpus could potentially leave dirty data in the cache, so
> >> memcpy_wt on those cpus would need to use explicit cache flushing.
> >
> > I see.  I agree that its behavior is different from the existing one
> > with "_nocache".   That said, I think "wt" or "write-through" generally
> > means that writes allocate cachelines and keep them clean by writing to
> > memory.  So, subsequent reads to the destination will hit the
> > cachelines.  This is not the case with this interface.
> 
> True... maybe _nocache_strict()? Or, leave it _wt() until someone
> comes along and is surprised that the cache is not warm for reads
> after memcpy_wt(), at which point we can ask "why not just use plain
> memcpy then?", or set the page-attributes to WT.

I prefer _nocache_strict(), if it's not too long, since it avoids any
confusion.  If other arches actually implement it with WT semantics,
we might become the one to change it, instead of the caller.

Thanks,
-Toshi

[Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

[Nick Desaulniers]

Clang does not support this machine dependent option.

Older versions of GCC (pre 3.0) may not support this option, added in
2000, but it's unlikely they can still compile the kernel.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4430dd489620..5a0ac8411792 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -179,7 +179,7 @@ ifdef CONFIG_JUMP_LABEL
 endif
 
 ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
-   KBUILD_CFLAGS += -maccumulate-outgoing-args
+   KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args,)
 endif
 
 # Stackpointer is addressed different for 32 bit and 64 bit x86
-- 
2.11.0

[Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

[Nick Desaulniers]

Clang does not support this machine dependent option.

Older versions of GCC (pre 3.0) may not support this option, added in
2000, but it's unlikely they can still compile the kernel.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4430dd489620..5a0ac8411792 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -179,7 +179,7 @@ ifdef CONFIG_JUMP_LABEL
 endif
 
 ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
-   KBUILD_CFLAGS += -maccumulate-outgoing-args
+   KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args,)
 endif
 
 # Stackpointer is addressed different for 32 bit and 64 bit x86
-- 
2.11.0

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

[Dan Williams]

On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu  wrote:
> On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:
>> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu 
>> wrote:
>  :
>> > > ---
>> > > Changes since the initial RFC:
>> > > * s/writethru/wt/ since we already have ioremap_wt(),
>> > > set_memory_wt(), etc. (Ingo)
>> >
>> > Sorry I should have said earlier, but I think the term "wt" is
>> > misleading.  Non-temporal stores used in memcpy_wt() provide WC
>> > semantics, not WT semantics.
>>
>> The non-temporal stores do, but memcpy_wt() is using a combination of
>> non-temporal stores and explicit cache flushing.
>>
>> > How about using "nocache" as it's been
>> > used in __copy_user_nocache()?
>>
>> The difference in my mind is that the "_nocache" suffix indicates
>> opportunistic / optional cache pollution avoidance whereas "_wt"
>> strictly arranges for caches not to contain dirty data upon
>> completion of the routine. For example, non-temporal stores on older
>> x86 cpus could potentially leave dirty data in the cache, so
>> memcpy_wt on those cpus would need to use explicit cache flushing.
>
> I see.  I agree that its behavior is different from the existing one
> with "_nocache".   That said, I think "wt" or "write-through" generally
> means that writes allocate cachelines and keep them clean by writing to
> memory.  So, subsequent reads to the destination will hit the
> cachelines.  This is not the case with this interface.

True... maybe _nocache_strict()? Or, leave it _wt() until someone
comes along and is surprised that the cache is not warm for reads
after memcpy_wt(), at which point we can ask "why not just use plain
memcpy then?", or set the page-attributes to WT.

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

[Dan Williams]

On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu  wrote:
> On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:
>> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu 
>> wrote:
>  :
>> > > ---
>> > > Changes since the initial RFC:
>> > > * s/writethru/wt/ since we already have ioremap_wt(),
>> > > set_memory_wt(), etc. (Ingo)
>> >
>> > Sorry I should have said earlier, but I think the term "wt" is
>> > misleading.  Non-temporal stores used in memcpy_wt() provide WC
>> > semantics, not WT semantics.
>>
>> The non-temporal stores do, but memcpy_wt() is using a combination of
>> non-temporal stores and explicit cache flushing.
>>
>> > How about using "nocache" as it's been
>> > used in __copy_user_nocache()?
>>
>> The difference in my mind is that the "_nocache" suffix indicates
>> opportunistic / optional cache pollution avoidance whereas "_wt"
>> strictly arranges for caches not to contain dirty data upon
>> completion of the routine. For example, non-temporal stores on older
>> x86 cpus could potentially leave dirty data in the cache, so
>> memcpy_wt on those cpus would need to use explicit cache flushing.
>
> I see.  I agree that its behavior is different from the existing one
> with "_nocache".   That said, I think "wt" or "write-through" generally
> means that writes allocate cachelines and keep them clean by writing to
> memory.  So, subsequent reads to the destination will hit the
> cachelines.  This is not the case with this interface.

True... maybe _nocache_strict()? Or, leave it _wt() until someone
comes along and is surprised that the cache is not warm for reads
after memcpy_wt(), at which point we can ask "why not just use plain
memcpy then?", or set the page-attributes to WT.

Re: [PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

[Dan Carpenter]

Subject is too long.

On Sat, May 06, 2017 at 04:04:50AM +0300, Gideon Sheril wrote:
>  /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
> @@ -152,13 +152,13 @@ const struct camera_af_platform_data 
> *camera_get_af_platform_data(void)
>  EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
>  
>  int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
> -struct camera_sensor_platform_data 
> *plat_data,
> -enum intel_v4l2_subdev_type type)
> + struct 
> camera_sensor_platform_data *plat_data,
> + enum 
> intel_v4l2_subdev_type type)

Huh???

>  {
>   int i;
>   struct i2c_board_info *bi;
>   struct gmin_subdev *gs;
> -struct i2c_client *client = v4l2_get_subdevdata(subdev);
> + struct i2c_client *client = v4l2_get_subdevdata(subdev);


Wut?  How would this be correct?

regards,
dan carpenter

Re: [PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

[Dan Carpenter]

Subject is too long.

On Sat, May 06, 2017 at 04:04:50AM +0300, Gideon Sheril wrote:
>  /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
> @@ -152,13 +152,13 @@ const struct camera_af_platform_data 
> *camera_get_af_platform_data(void)
>  EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
>  
>  int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
> -struct camera_sensor_platform_data 
> *plat_data,
> -enum intel_v4l2_subdev_type type)
> + struct 
> camera_sensor_platform_data *plat_data,
> + enum 
> intel_v4l2_subdev_type type)

Huh???

>  {
>   int i;
>   struct i2c_board_info *bi;
>   struct gmin_subdev *gs;
> -struct i2c_client *client = v4l2_get_subdevdata(subdev);
> + struct i2c_client *client = v4l2_get_subdevdata(subdev);


Wut?  How would this be correct?

regards,
dan carpenter

Re: [PATCH 4.4 00/20] 4.4.67-stable review

[Shuah Khan]

On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.67 release.
> There are 20 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun May  7 18:32:22 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.67-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/20] 4.4.67-stable review

[Shuah Khan]

On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.67 release.
> There are 20 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun May  7 18:32:22 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.67-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/68] 3.18.52-stable review

[Shuah Khan]

On 05/05/2017 12:31 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.52 release.
> There are 68 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun May  7 18:31:52 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.52-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/68] 3.18.52-stable review

[Shuah Khan]

On 05/05/2017 12:31 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.52 release.
> There are 68 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun May  7 18:31:52 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.52-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

[Scott Branden]

Please note the 4.11 and 4.10 log results in my email were
reversed - see correction below.

Performance regression is observed - FIO performance in 4.11 is
much less than 4.10 on ARM64 based platform.

On 17-05-05 06:37 PM, Scott Branden wrote:

I have updated the kernel to 4.11 and see significant performance
drops using fio-2.9.

Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using
single core and task.
Percent performance drop becomes even worse if multi-cores and multi-
threads are used.

Platform is ARM64 based A72.  Can somebody reproduce the results or
know what may have changed to make such a dramatic change?

FIO command and resulting log output below using null_blk to remove
as many hardware specific driver dependencies as possible.

modprobe null_blk queue_mode=2 irqmode=0 completion_nsec=0
submit_queues=1 bs=4096

taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read

 281 KIOPS RESULT on 4.11 Kernel 

CORRECTION:
 281 KIOPS RESULT on 4.10 Kernel 


readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio,
iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [1098MB/0KB/0KB /s] [281K/0/0 iops]
[eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=2868: Mon Apr  3 20:24:25 2017
  read : io=16456MB, bw=1096.1MB/s, iops=280825, runt= 15001msec
  cpu  : usr=28.35%, sys=71.55%, ctx=1560, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%,

=64=100.0%

 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.0%

 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.1%

 issued: total=r=4212670/w=0/d=0, short=r=0/w=0/d=0,
drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=16456MB, aggrb=1096.1MB/s, minb=1096.1MB/s, maxb=1096.1MB/s,
mint=15001msec, maxt=15001msec

Disk stats (read/write):
  nullb0: ios=4185627/0, merge=0/0, ticks=3664/0, in_queue=3308,
util=22.05%


 207 KIOPS RESULT on 4.10 Kernel 

CORRECTION:
 281 KIOPS RESULT on 4.11 Kernel 


taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read
readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio,
iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [807.6MB/0KB/0KB /s] [207K/0/0 iops]
[eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=2832: Mon Apr  3 20:09:31 2017
  read : io=12109MB, bw=826620KB/s, iops=206654, runt= 15001msec
  cpu  : usr=24.62%, sys=75.28%, ctx=1571, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%,

=64=100.0%

 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.0%

 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.1%

 issued: total=r=3100030/w=0/d=0, short=r=0/w=0/d=0,
drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=12109MB, aggrb=826619KB/s, minb=826619KB/s, maxb=826619KB/s,
mint=15001msec, maxt=15001msec

Disk stats (read/write):
  nullb0: ios=3080149/0, merge=0/0, ticks=3952/0, in_queue=3560,
util=23.73%



Regards,
 Scott

Re: FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

[Scott Branden]

Please note the 4.11 and 4.10 log results in my email were
reversed - see correction below.

Performance regression is observed - FIO performance in 4.11 is
much less than 4.10 on ARM64 based platform.

On 17-05-05 06:37 PM, Scott Branden wrote:

I have updated the kernel to 4.11 and see significant performance
drops using fio-2.9.

Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using
single core and task.
Percent performance drop becomes even worse if multi-cores and multi-
threads are used.

Platform is ARM64 based A72.  Can somebody reproduce the results or
know what may have changed to make such a dramatic change?

FIO command and resulting log output below using null_blk to remove
as many hardware specific driver dependencies as possible.

modprobe null_blk queue_mode=2 irqmode=0 completion_nsec=0
submit_queues=1 bs=4096

taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read

 281 KIOPS RESULT on 4.11 Kernel 

CORRECTION:
 281 KIOPS RESULT on 4.10 Kernel 


readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio,
iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [1098MB/0KB/0KB /s] [281K/0/0 iops]
[eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=2868: Mon Apr  3 20:24:25 2017
  read : io=16456MB, bw=1096.1MB/s, iops=280825, runt= 15001msec
  cpu  : usr=28.35%, sys=71.55%, ctx=1560, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%,

=64=100.0%

 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.0%

 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.1%

 issued: total=r=4212670/w=0/d=0, short=r=0/w=0/d=0,
drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=16456MB, aggrb=1096.1MB/s, minb=1096.1MB/s, maxb=1096.1MB/s,
mint=15001msec, maxt=15001msec

Disk stats (read/write):
  nullb0: ios=4185627/0, merge=0/0, ticks=3664/0, in_queue=3308,
util=22.05%


 207 KIOPS RESULT on 4.10 Kernel 

CORRECTION:
 281 KIOPS RESULT on 4.11 Kernel 


taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read
readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio,
iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [807.6MB/0KB/0KB /s] [207K/0/0 iops]
[eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=2832: Mon Apr  3 20:09:31 2017
  read : io=12109MB, bw=826620KB/s, iops=206654, runt= 15001msec
  cpu  : usr=24.62%, sys=75.28%, ctx=1571, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%,

=64=100.0%

 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.0%

 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,

=64=0.1%

 issued: total=r=3100030/w=0/d=0, short=r=0/w=0/d=0,
drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=12109MB, aggrb=826619KB/s, minb=826619KB/s, maxb=826619KB/s,
mint=15001msec, maxt=15001msec

Disk stats (read/write):
  nullb0: ios=3080149/0, merge=0/0, ticks=3952/0, in_queue=3560,
util=23.73%



Regards,
 Scott

FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

[Scott Branden]

I have updated the kernel to 4.11 and see significant performance
drops using fio-2.9.

Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using
single core and task.
Percent performance drop becomes even worse if multi-cores and multi-
threads are used.

Platform is ARM64 based A72.  Can somebody reproduce the results or
know what may have changed to make such a dramatic change?

FIO command and resulting log output below using null_blk to remove
as many hardware specific driver dependencies as possible.

modprobe null_blk queue_mode=2 irqmode=0 completion_nsec=0
submit_queues=1 bs=4096

taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read

 281 KIOPS RESULT on 4.11 Kernel 
readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [1098MB/0KB/0KB /s] [281K/0/0 iops] 
[eta 00m:00s]

readtest: (groupid=0, jobs=1): err= 0: pid=2868: Mon Apr  3 20:24:25 2017
  read : io=16456MB, bw=1096.1MB/s, iops=280825, runt= 15001msec
  cpu  : usr=28.35%, sys=71.55%, ctx=1560, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, 
>=64=100.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.1%
 issued: total=r=4212670/w=0/d=0, short=r=0/w=0/d=0, 
drop=r=0/w=0/d=0

 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=16456MB, aggrb=1096.1MB/s, minb=1096.1MB/s, 
maxb=1096.1MB/s, mint=15001msec, maxt=15001msec


Disk stats (read/write):
  nullb0: ios=4185627/0, merge=0/0, ticks=3664/0, in_queue=3308, 
util=22.05%



 207 KIOPS RESULT on 4.10 Kernel 
taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1 
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k 
--iodepth=128 --time_based --runtime=15 --readwrite=read

readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [807.6MB/0KB/0KB /s] [207K/0/0 iops] 
[eta 00m:00s]

readtest: (groupid=0, jobs=1): err= 0: pid=2832: Mon Apr  3 20:09:31 2017
  read : io=12109MB, bw=826620KB/s, iops=206654, runt= 15001msec
  cpu  : usr=24.62%, sys=75.28%, ctx=1571, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, 
>=64=100.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.1%
 issued: total=r=3100030/w=0/d=0, short=r=0/w=0/d=0, 
drop=r=0/w=0/d=0

 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=12109MB, aggrb=826619KB/s, minb=826619KB/s, 
maxb=826619KB/s, mint=15001msec, maxt=15001msec


Disk stats (read/write):
  nullb0: ios=3080149/0, merge=0/0, ticks=3952/0, in_queue=3560, 
util=23.73%




Regards,
 Scott

FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

[Scott Branden]

I have updated the kernel to 4.11 and see significant performance
drops using fio-2.9.

Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using
single core and task.
Percent performance drop becomes even worse if multi-cores and multi-
threads are used.

Platform is ARM64 based A72.  Can somebody reproduce the results or
know what may have changed to make such a dramatic change?

FIO command and resulting log output below using null_blk to remove
as many hardware specific driver dependencies as possible.

modprobe null_blk queue_mode=2 irqmode=0 completion_nsec=0
submit_queues=1 bs=4096

taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k
--iodepth=128 --time_based --runtime=15 --readwrite=read

 281 KIOPS RESULT on 4.11 Kernel 
readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [1098MB/0KB/0KB /s] [281K/0/0 iops] 
[eta 00m:00s]

readtest: (groupid=0, jobs=1): err= 0: pid=2868: Mon Apr  3 20:24:25 2017
  read : io=16456MB, bw=1096.1MB/s, iops=280825, runt= 15001msec
  cpu  : usr=28.35%, sys=71.55%, ctx=1560, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, 
>=64=100.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.1%
 issued: total=r=4212670/w=0/d=0, short=r=0/w=0/d=0, 
drop=r=0/w=0/d=0

 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=16456MB, aggrb=1096.1MB/s, minb=1096.1MB/s, 
maxb=1096.1MB/s, mint=15001msec, maxt=15001msec


Disk stats (read/write):
  nullb0: ios=4185627/0, merge=0/0, ticks=3664/0, in_queue=3308, 
util=22.05%



 207 KIOPS RESULT on 4.10 Kernel 
taskset 0x1 fio --randrepeat=1 --ioengine=libaio --direct=1 --numjobs=1 
--gtod_reduce=1 --name=readtest --filename=/dev/nullb0 --bs=4k 
--iodepth=128 --time_based --runtime=15 --readwrite=read

readtest: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.9
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [807.6MB/0KB/0KB /s] [207K/0/0 iops] 
[eta 00m:00s]

readtest: (groupid=0, jobs=1): err= 0: pid=2832: Mon Apr  3 20:09:31 2017
  read : io=12109MB, bw=826620KB/s, iops=206654, runt= 15001msec
  cpu  : usr=24.62%, sys=75.28%, ctx=1571, majf=0, minf=146
  IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, 
>=64=100.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.1%
 issued: total=r=3100030/w=0/d=0, short=r=0/w=0/d=0, 
drop=r=0/w=0/d=0

 latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: io=12109MB, aggrb=826619KB/s, minb=826619KB/s, 
maxb=826619KB/s, mint=15001msec, maxt=15001msec


Disk stats (read/write):
  nullb0: ios=3080149/0, merge=0/0, ticks=3952/0, in_queue=3560, 
util=23.73%




Regards,
 Scott

[PATCH v5 1/3] mailbox: Make startup and shutdown ops optional

[Bjorn Andersson]

Some mailbox hardware doesn't have to perform any additional operations
on startup of shutdown, so make these optional.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Inline the conditionals, rather than breaking them out into separate
  functions

 drivers/mailbox/mailbox.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4671f8a12872..505651ce9dcc 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -352,11 +352,14 @@ struct mbox_chan *mbox_request_channel(struct mbox_client 
*cl, int index)
 
spin_unlock_irqrestore(>lock, flags);
 
-   ret = chan->mbox->ops->startup(chan);
-   if (ret) {
-   dev_err(dev, "Unable to startup the chan (%d)\n", ret);
-   mbox_free_channel(chan);
-   chan = ERR_PTR(ret);
+   if (chan->mbox->ops->startup) {
+   ret = chan->mbox->ops->startup(chan);
+
+   if (ret) {
+   dev_err(dev, "Unable to startup the chan (%d)\n", ret);
+   mbox_free_channel(chan);
+   chan = ERR_PTR(ret);
+   }
}
 
mutex_unlock(_mutex);
@@ -405,7 +408,8 @@ void mbox_free_channel(struct mbox_chan *chan)
if (!chan || !chan->cl)
return;
 
-   chan->mbox->ops->shutdown(chan);
+   if (chan->mbox->ops->shutdown)
+   chan->mbox->ops->shutdown(chan);
 
/* The queued TX requests are simply aborted, no callbacks are made */
spin_lock_irqsave(>lock, flags);
-- 
2.12.0

[PATCH v5 1/3] mailbox: Make startup and shutdown ops optional

[Bjorn Andersson]

Some mailbox hardware doesn't have to perform any additional operations
on startup of shutdown, so make these optional.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Inline the conditionals, rather than breaking them out into separate
  functions

 drivers/mailbox/mailbox.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4671f8a12872..505651ce9dcc 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -352,11 +352,14 @@ struct mbox_chan *mbox_request_channel(struct mbox_client 
*cl, int index)
 
spin_unlock_irqrestore(>lock, flags);
 
-   ret = chan->mbox->ops->startup(chan);
-   if (ret) {
-   dev_err(dev, "Unable to startup the chan (%d)\n", ret);
-   mbox_free_channel(chan);
-   chan = ERR_PTR(ret);
+   if (chan->mbox->ops->startup) {
+   ret = chan->mbox->ops->startup(chan);
+
+   if (ret) {
+   dev_err(dev, "Unable to startup the chan (%d)\n", ret);
+   mbox_free_channel(chan);
+   chan = ERR_PTR(ret);
+   }
}
 
mutex_unlock(_mutex);
@@ -405,7 +408,8 @@ void mbox_free_channel(struct mbox_chan *chan)
if (!chan || !chan->cl)
return;
 
-   chan->mbox->ops->shutdown(chan);
+   if (chan->mbox->ops->shutdown)
+   chan->mbox->ops->shutdown(chan);
 
/* The queued TX requests are simply aborted, no callbacks are made */
spin_lock_irqsave(>lock, flags);
-- 
2.12.0

[PATCH v5 3/3] mailbox: Introduce Qualcomm APCS IPC driver

[Bjorn Andersson]

This implements a driver that exposes the IPC bits found in the APCS
Global block in various Qualcomm platforms. The bits are used to signal
inter-processor communication signals from the application CPU to other
masters.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Updated commit message and Kconfig help text to remove remnants of "doorbell"

 drivers/mailbox/Kconfig |   8 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/qcom-apcs-ipc-mailbox.c | 128 
 3 files changed, 138 insertions(+)
 create mode 100644 drivers/mailbox/qcom-apcs-ipc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ceff415f201c..fffc64da61f9 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -124,6 +124,14 @@ config MAILBOX_TEST
  Test client to help with testing new Controller driver
  implementations.
 
+config QCOM_APCS_IPC
+   tristate "Qualcomm APCS IPC driver"
+   depends on ARCH_QCOM
+   help
+ Say y here to enable support for the APCS IPC mailbox driver,
+ providing an interface for invoking the inter-process communication
+ signals from the application processor to other masters.
+
 config TEGRA_HSP_MBOX
bool "Tegra HSP (Hardware Synchronization Primitives) Driver"
depends on ARCH_TEGRA_186_SOC
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 7dde4f609ae8..cc718c79669a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -30,4 +30,6 @@ obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
 
 obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
 
+obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
+
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c 
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
new file mode 100644
index ..41e31c66c7aa
--- /dev/null
+++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright (c) 2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QCOM_APCS_IPC_BITS 32
+
+struct qcom_apcs_ipc {
+   struct device *dev;
+
+   struct mbox_controller mbox;
+   struct mbox_chan mbox_chans[QCOM_APCS_IPC_BITS];
+
+   void __iomem *base;
+   unsigned long offset;
+};
+
+static int qcom_apcs_ipc_send_data(struct mbox_chan *chan, void *data)
+{
+   struct qcom_apcs_ipc *apcs = container_of(chan->mbox,
+ struct qcom_apcs_ipc, mbox);
+   unsigned long idx = (unsigned long)chan->con_priv;
+
+   writel(BIT(idx), apcs->base + apcs->offset);
+
+   return 0;
+}
+
+static const struct mbox_chan_ops qcom_apcs_ipc_ops = {
+   .send_data = qcom_apcs_ipc_send_data,
+};
+
+static int qcom_apcs_ipc_probe(struct platform_device *pdev)
+{
+   struct qcom_apcs_ipc *apcs;
+   struct resource *res;
+   unsigned long i;
+   int ret;
+
+   apcs = devm_kzalloc(>dev, sizeof(*apcs), GFP_KERNEL);
+   if (!apcs)
+   return -ENOMEM;
+
+   apcs->dev = >dev;
+   apcs->offset = (unsigned long)of_device_get_match_data(>dev);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   apcs->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(apcs->base))
+   return PTR_ERR(apcs->base);
+
+   /* Initialize channel identifiers */
+   for (i = 0; i < ARRAY_SIZE(apcs->mbox_chans); i++)
+   apcs->mbox_chans[i].con_priv = (void *)i;
+
+   apcs->mbox.dev = >dev;
+   apcs->mbox.ops = _apcs_ipc_ops;
+   apcs->mbox.chans = apcs->mbox_chans;
+   apcs->mbox.num_chans = ARRAY_SIZE(apcs->mbox_chans);
+
+   ret = mbox_controller_register(>mbox);
+   if (ret) {
+   dev_err(>dev, "failed to register APCS IPC controller\n");
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, apcs);
+
+   return 0;
+}
+
+static int qcom_apcs_ipc_remove(struct platform_device *pdev)
+{
+   struct qcom_apcs_ipc *apcs = platform_get_drvdata(pdev);
+
+   mbox_controller_unregister(>mbox);
+
+   return 0;
+}
+
+/* .data is the offset of the ipc register within the global block */
+static const struct of_device_id qcom_apcs_ipc_of_match[] = {
+   { .compatible = "qcom,msm8916-apcs-kpss-global", .data = (void *)8 },
+   { .compatible = 

[PATCH v5 2/3] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

[Bjorn Andersson]

Introduce a binding for the Qualcomm APCS global block, exposing a
mailbox for invoking interrupts on remote processors in the system.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- None

 .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt 
b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
new file mode 100644
index ..eaa9e780f412
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
@@ -0,0 +1,46 @@
+Binding for the Qualcomm APCS global block
+==
+
+This binding describes the APCS "global" block found in various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8916-apcs-kpss-global",
+   "qcom,msm8996-apcs-hmss-global"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: must specify the base address and size of the global block
+
+- #mbox-cells:
+   Usage: required
+   Value type: 
+   Definition: as described in mailbox.txt, must be 1
+
+
+= EXAMPLE
+The following example describes the APCS HMSS found in MSM8996 and part of the
+GLINK RPM referencing the "rpm_hlos" doorbell therein.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #mbox-cells = <1>;
+   };
+
+   rpm-glink {
+   compatible = "qcom,glink-rpm";
+
+   interrupts = ;
+
+   qcom,rpm-msg-ram = <_msg_ram>;
+
+   mboxes = <_glb 0>;
+   mbox-names = "rpm_hlos";
+   };
+
-- 
2.12.0

[PATCH v5 3/3] mailbox: Introduce Qualcomm APCS IPC driver

[Bjorn Andersson]

This implements a driver that exposes the IPC bits found in the APCS
Global block in various Qualcomm platforms. The bits are used to signal
inter-processor communication signals from the application CPU to other
masters.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Updated commit message and Kconfig help text to remove remnants of "doorbell"

 drivers/mailbox/Kconfig |   8 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/qcom-apcs-ipc-mailbox.c | 128 
 3 files changed, 138 insertions(+)
 create mode 100644 drivers/mailbox/qcom-apcs-ipc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ceff415f201c..fffc64da61f9 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -124,6 +124,14 @@ config MAILBOX_TEST
  Test client to help with testing new Controller driver
  implementations.
 
+config QCOM_APCS_IPC
+   tristate "Qualcomm APCS IPC driver"
+   depends on ARCH_QCOM
+   help
+ Say y here to enable support for the APCS IPC mailbox driver,
+ providing an interface for invoking the inter-process communication
+ signals from the application processor to other masters.
+
 config TEGRA_HSP_MBOX
bool "Tegra HSP (Hardware Synchronization Primitives) Driver"
depends on ARCH_TEGRA_186_SOC
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 7dde4f609ae8..cc718c79669a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -30,4 +30,6 @@ obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
 
 obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
 
+obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
+
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c 
b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
new file mode 100644
index ..41e31c66c7aa
--- /dev/null
+++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright (c) 2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QCOM_APCS_IPC_BITS 32
+
+struct qcom_apcs_ipc {
+   struct device *dev;
+
+   struct mbox_controller mbox;
+   struct mbox_chan mbox_chans[QCOM_APCS_IPC_BITS];
+
+   void __iomem *base;
+   unsigned long offset;
+};
+
+static int qcom_apcs_ipc_send_data(struct mbox_chan *chan, void *data)
+{
+   struct qcom_apcs_ipc *apcs = container_of(chan->mbox,
+ struct qcom_apcs_ipc, mbox);
+   unsigned long idx = (unsigned long)chan->con_priv;
+
+   writel(BIT(idx), apcs->base + apcs->offset);
+
+   return 0;
+}
+
+static const struct mbox_chan_ops qcom_apcs_ipc_ops = {
+   .send_data = qcom_apcs_ipc_send_data,
+};
+
+static int qcom_apcs_ipc_probe(struct platform_device *pdev)
+{
+   struct qcom_apcs_ipc *apcs;
+   struct resource *res;
+   unsigned long i;
+   int ret;
+
+   apcs = devm_kzalloc(>dev, sizeof(*apcs), GFP_KERNEL);
+   if (!apcs)
+   return -ENOMEM;
+
+   apcs->dev = >dev;
+   apcs->offset = (unsigned long)of_device_get_match_data(>dev);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   apcs->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(apcs->base))
+   return PTR_ERR(apcs->base);
+
+   /* Initialize channel identifiers */
+   for (i = 0; i < ARRAY_SIZE(apcs->mbox_chans); i++)
+   apcs->mbox_chans[i].con_priv = (void *)i;
+
+   apcs->mbox.dev = >dev;
+   apcs->mbox.ops = _apcs_ipc_ops;
+   apcs->mbox.chans = apcs->mbox_chans;
+   apcs->mbox.num_chans = ARRAY_SIZE(apcs->mbox_chans);
+
+   ret = mbox_controller_register(>mbox);
+   if (ret) {
+   dev_err(>dev, "failed to register APCS IPC controller\n");
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, apcs);
+
+   return 0;
+}
+
+static int qcom_apcs_ipc_remove(struct platform_device *pdev)
+{
+   struct qcom_apcs_ipc *apcs = platform_get_drvdata(pdev);
+
+   mbox_controller_unregister(>mbox);
+
+   return 0;
+}
+
+/* .data is the offset of the ipc register within the global block */
+static const struct of_device_id qcom_apcs_ipc_of_match[] = {
+   { .compatible = "qcom,msm8916-apcs-kpss-global", .data = (void *)8 },
+   { .compatible = "qcom,msm8996-apcs-hmss-global", .data = (void 

[PATCH v5 2/3] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

[Bjorn Andersson]

Introduce a binding for the Qualcomm APCS global block, exposing a
mailbox for invoking interrupts on remote processors in the system.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- None

 .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt 
b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
new file mode 100644
index ..eaa9e780f412
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
@@ -0,0 +1,46 @@
+Binding for the Qualcomm APCS global block
+==
+
+This binding describes the APCS "global" block found in various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8916-apcs-kpss-global",
+   "qcom,msm8996-apcs-hmss-global"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: must specify the base address and size of the global block
+
+- #mbox-cells:
+   Usage: required
+   Value type: 
+   Definition: as described in mailbox.txt, must be 1
+
+
+= EXAMPLE
+The following example describes the APCS HMSS found in MSM8996 and part of the
+GLINK RPM referencing the "rpm_hlos" doorbell therein.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #mbox-cells = <1>;
+   };
+
+   rpm-glink {
+   compatible = "qcom,glink-rpm";
+
+   interrupts = ;
+
+   qcom,rpm-msg-ram = <_msg_ram>;
+
+   mboxes = <_glb 0>;
+   mbox-names = "rpm_hlos";
+   };
+
-- 
2.12.0

Re: drivers/pcmcia/Kconfig

[as Bari]

Thanks for feedback! This appears to be my internal issue.

2017-05-06 4:10 GMT+03:00 Randy Dunlap :
> On 05/05/17 17:45, as Bari wrote:
>> PCCARD entry has menuconfig type. This makes it invisible from, for
>> example, gconfig, and we get additional pcmcia modules in builtin
>> tree. This is unexpected behaviour.
>> Looks like the entry was improperly refactored since 2.6.24.
>
> What kernel version are you testing?
> I don't see a problem in kernel 4.11 when using gconfig, xconfig,
> nconfig, or menuconfig.
> (That is, after opening up the Bus Options menu.)
>
>> I would like to hear others' opinion.
>
> I don't see a problem.  Maybe it is related to your
> kernel .config file.  You could post that for our testing.
>
> --
> ~Randy

Re: drivers/pcmcia/Kconfig

[as Bari]

Thanks for feedback! This appears to be my internal issue.

2017-05-06 4:10 GMT+03:00 Randy Dunlap :
> On 05/05/17 17:45, as Bari wrote:
>> PCCARD entry has menuconfig type. This makes it invisible from, for
>> example, gconfig, and we get additional pcmcia modules in builtin
>> tree. This is unexpected behaviour.
>> Looks like the entry was improperly refactored since 2.6.24.
>
> What kernel version are you testing?
> I don't see a problem in kernel 4.11 when using gconfig, xconfig,
> nconfig, or menuconfig.
> (That is, after opening up the Bus Options menu.)
>
>> I would like to hear others' opinion.
>
> I don't see a problem.  Maybe it is related to your
> kernel .config file.  You could post that for our testing.
>
> --
> ~Randy

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, May 5, 2017 at 5:51 PM,   wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario 
>> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
>> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
>> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
>> driver-...@vger.kernel.org; linux...@vger.kernel.org
>> Subject: Re: RFC: WMI Enhancements


> I meant that to say that at least for now Andy's wmi-mof driver should still 
> be merged.
> If something is going to build on top of this to do WBEM tools, they'll need 
> that MOF
> data once someone figures out how to nicely deconstruct it.
>

The thing I don't like about my own driver is that, as a WMI device
driver, it can be loaded before the rest of the bus finishes probing.
So user programs that are notified asynchronously that the wmi-mof
driver is loaded and try to use future functionality (ioctl to issue a
MOF-based method call?) might end up doing so before the rest of the
bus is probed.

This could be addressed by always exposing the wmi-mof device last
(sort of -- it can be a module) or perhaps by moving MOF functionality
to the core driver.  Or maybe it's not really a problem.

Also, isn't there a way to ask Microsoft to document this?  Are you
supposed to "ask a question" on this forum, perhaps:

https://msdn.microsoft.com/en-us/library/gg134029.aspx

I'm guessing the Samba team knows how to do this, too.

Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Fri, May 5, 2017 at 5:51 PM,   wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@infradead.org]
>> Sent: Friday, May 5, 2017 6:45 PM
>> To: Limonciello, Mario 
>> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
>> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
>> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
>> driver-...@vger.kernel.org; linux...@vger.kernel.org
>> Subject: Re: RFC: WMI Enhancements


> I meant that to say that at least for now Andy's wmi-mof driver should still 
> be merged.
> If something is going to build on top of this to do WBEM tools, they'll need 
> that MOF
> data once someone figures out how to nicely deconstruct it.
>

The thing I don't like about my own driver is that, as a WMI device
driver, it can be loaded before the rest of the bus finishes probing.
So user programs that are notified asynchronously that the wmi-mof
driver is loaded and try to use future functionality (ioctl to issue a
MOF-based method call?) might end up doing so before the rest of the
bus is probed.

This could be addressed by always exposing the wmi-mof device last
(sort of -- it can be a module) or perhaps by moving MOF functionality
to the core driver.  Or maybe it's not really a problem.

Also, isn't there a way to ask Microsoft to document this?  Are you
supposed to "ask a question" on this forum, perhaps:

https://msdn.microsoft.com/en-us/library/gg134029.aspx

I'm guessing the Samba team knows how to do this, too.

[RELEASE] LTTng-modules 2.10.0-rc1 (KeKriek) and LTTng-UST 2.10.0-rc1 (KeKriek)

[Mathieu Desnoyers]

Hi,

Here are release candidates 1 for LTTng kernel and user-space tracers 2.10.
This release is named "KeKriek", which is a sour mashed golden wheat ale
brewed by the Dunham microbrewery in Quebec.

The new features included are:

- A new "blocking" mode for LTTng-UST (it has been requested for a while).
  It blocks application tracing when buffers are full (for "discard mode
  tracing") rather than discarding events, until a user-specified timeout
  is reached (or indefinitely). It affects only applications launched with
  this environment variable set. See lttng-ust(3) for usage information.

- Add support for multiple star-globbing patterns in LTTng-UST and 
LTTng-modules.
  Now events can be enabled with a pattern containing many wildcards, e.g.
  'sche*_sw*t*h'. Those can also be used when comparing strings with filter,
  e.g.:
  lttng enable-event -u myevent --filter 'myfield == "abc*d*e*fg"'

- LTTng modules adds support for kernels 4.10 and 4.11 (which has been
  backported to 2.8 and 2.9 stable branches).

- LTTng modules adds the task CPU in threads state dump, improving precision
  of the scheduler model.

- LTTng modules now collects extend socketpair system call tracing data.


Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Changelog:

2017-05-05 (International Tuba Day) LTTng modules 2.10.0-rc1
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean
* Add RING_BUFFER_SNAPSHOT_SAMPLE_POSITIONS command
* Fix: Always build vmscan probe
* Cleanup: formatting in strutils_star_glob_match explanation
* Fix: introduce LTTNG_SIZE_MAX for older kernels
* Use SIZE_MAX instead of -1ULL for size_t parameter
* filter: use SIZE_MAX for size_t
* Fix: out of bound array access in filter code
* Add support for star globbing patterns in event names
* Filtering: add support for star-only globbing patterns
* Add string utilities
* lttng-abi.c: cleanup whitespaces
* Fix: use of uninitialized ret value in lttng_abi_open_metadata_stream
* Fix: kref changes for kernel 4.11
* Fix: atomic_add_unless() returns true/false rather than prior value
* Fix: timers cputime_t arguments replaced by ull in kernel 4.11
* Fix: update scsi instrumentation for kernel 4.11
* Fix: changes to the vm_op fault cb prototype in libringbuffer
* Fix: update btrfs instrumentation for kernel 4.11
* Fix: update mm_vmscan instrumentation for kernel 4.11
* Fix: section mismatch warning caused by __exit annotation
* socketpair: extend syscall socketpair tracing information
* Remove events/mainline unused headers
* update event README
* Fix: nmi-safe clock on 32-bit systems
* Fix: only include linux/cpuhotplug.h for kernels >= 4.10
* Fix: 4.10 hotplug adaptation backward compat
* Fix: 4.10 btrfs instrumentation update backward compat
* Update btrfs instrumentation for 4.10 kernel
* Adapt lttng-modules to Linux 4.10 cpu hotplug state machine
* btrfs instrumentation: update to 4.10 kernel
* timer instrumentation: adapt to ktime_t without union
* Add load/unload messages to kernel log
* Update version to 2.10.0-pre
* Fix: asoc instrumentation for RHEL 7.3
* Fix: SCSI instrumentation for SLES12 SP2
* Add SUSE Linux Enterprise kernel version tests
* Filter code relicensing to MIT license
* Add task cpu in process statedump
* Performance: add missing unlikely in reserve
* Fix: preemptible and migratable context error handling
* Fix: bump stable kernel version ranges for clock work-around

2017-05-05 (International Tuba Day) lttng-ust 2.10.0-rc1
* Clean-up: remove unused variables to silence gcc warning
* Add ustctl_snapshot_sample_positions ustctl command
* Cleanup: formatting in strutils_star_glob_match explanation
* doc/man: add typical `$` and `#` prompts to command lines
* Fix: add missing getenv.h include to ustctl.c
* Fix: race between lttng-ust getenv() and application setenv()
* Use SIZE_MAX instead of -1ULL for size_t parameter
* filter: use SIZE_MAX rather than UINT_MAX and tuncating -1ULL
* Fix: out of bound array access in filter code
* Correctly clean all generated JAR files
* Fix: List missing file in Java agent's Makefile
* Support generic globbing patterns in the Java agent
* Log more information in the Java TCP client
* Cleanup: Remove unused import in JUL Java agent
* Add support for star globbing patterns in event names
* Filtering: add support for star-only globbing patterns
* Add string utilities
* Fix: (un)install targets of Python agent
* Fix: include config.h to resolve HAVE_DLMOPEN

[RELEASE] LTTng-modules 2.10.0-rc1 (KeKriek) and LTTng-UST 2.10.0-rc1 (KeKriek)

[Mathieu Desnoyers]

Hi,

Here are release candidates 1 for LTTng kernel and user-space tracers 2.10.
This release is named "KeKriek", which is a sour mashed golden wheat ale
brewed by the Dunham microbrewery in Quebec.

The new features included are:

- A new "blocking" mode for LTTng-UST (it has been requested for a while).
  It blocks application tracing when buffers are full (for "discard mode
  tracing") rather than discarding events, until a user-specified timeout
  is reached (or indefinitely). It affects only applications launched with
  this environment variable set. See lttng-ust(3) for usage information.

- Add support for multiple star-globbing patterns in LTTng-UST and 
LTTng-modules.
  Now events can be enabled with a pattern containing many wildcards, e.g.
  'sche*_sw*t*h'. Those can also be used when comparing strings with filter,
  e.g.:
  lttng enable-event -u myevent --filter 'myfield == "abc*d*e*fg"'

- LTTng modules adds support for kernels 4.10 and 4.11 (which has been
  backported to 2.8 and 2.9 stable branches).

- LTTng modules adds the task CPU in threads state dump, improving precision
  of the scheduler model.

- LTTng modules now collects extend socketpair system call tracing data.


Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Changelog:

2017-05-05 (International Tuba Day) LTTng modules 2.10.0-rc1
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean
* Add RING_BUFFER_SNAPSHOT_SAMPLE_POSITIONS command
* Fix: Always build vmscan probe
* Cleanup: formatting in strutils_star_glob_match explanation
* Fix: introduce LTTNG_SIZE_MAX for older kernels
* Use SIZE_MAX instead of -1ULL for size_t parameter
* filter: use SIZE_MAX for size_t
* Fix: out of bound array access in filter code
* Add support for star globbing patterns in event names
* Filtering: add support for star-only globbing patterns
* Add string utilities
* lttng-abi.c: cleanup whitespaces
* Fix: use of uninitialized ret value in lttng_abi_open_metadata_stream
* Fix: kref changes for kernel 4.11
* Fix: atomic_add_unless() returns true/false rather than prior value
* Fix: timers cputime_t arguments replaced by ull in kernel 4.11
* Fix: update scsi instrumentation for kernel 4.11
* Fix: changes to the vm_op fault cb prototype in libringbuffer
* Fix: update btrfs instrumentation for kernel 4.11
* Fix: update mm_vmscan instrumentation for kernel 4.11
* Fix: section mismatch warning caused by __exit annotation
* socketpair: extend syscall socketpair tracing information
* Remove events/mainline unused headers
* update event README
* Fix: nmi-safe clock on 32-bit systems
* Fix: only include linux/cpuhotplug.h for kernels >= 4.10
* Fix: 4.10 hotplug adaptation backward compat
* Fix: 4.10 btrfs instrumentation update backward compat
* Update btrfs instrumentation for 4.10 kernel
* Adapt lttng-modules to Linux 4.10 cpu hotplug state machine
* btrfs instrumentation: update to 4.10 kernel
* timer instrumentation: adapt to ktime_t without union
* Add load/unload messages to kernel log
* Update version to 2.10.0-pre
* Fix: asoc instrumentation for RHEL 7.3
* Fix: SCSI instrumentation for SLES12 SP2
* Add SUSE Linux Enterprise kernel version tests
* Filter code relicensing to MIT license
* Add task cpu in process statedump
* Performance: add missing unlikely in reserve
* Fix: preemptible and migratable context error handling
* Fix: bump stable kernel version ranges for clock work-around

2017-05-05 (International Tuba Day) lttng-ust 2.10.0-rc1
* Clean-up: remove unused variables to silence gcc warning
* Add ustctl_snapshot_sample_positions ustctl command
* Cleanup: formatting in strutils_star_glob_match explanation
* doc/man: add typical `$` and `#` prompts to command lines
* Fix: add missing getenv.h include to ustctl.c
* Fix: race between lttng-ust getenv() and application setenv()
* Use SIZE_MAX instead of -1ULL for size_t parameter
* filter: use SIZE_MAX rather than UINT_MAX and tuncating -1ULL
* Fix: out of bound array access in filter code
* Correctly clean all generated JAR files
* Fix: List missing file in Java agent's Makefile
* Support generic globbing patterns in the Java agent
* Log more information in the Java TCP client
* Cleanup: Remove unused import in JUL Java agent
* Add support for star globbing patterns in event names
* Filtering: add support for star-only globbing patterns
* Add string utilities
* Fix: (un)install targets of Python agent
* Fix: include config.h to resolve HAVE_DLMOPEN

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

[Bjorn Andersson]

On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote:

> On Sat, May 6, 2017 at 1:23 AM, Jeffrey Hugo  wrote:
> > On 5/5/2017 1:22 PM, Jassi Brar wrote:
> >>
> >> On Sat, May 6, 2017 at 12:07 AM, Bjorn Andersson
> >>  wrote:
> >>>
> >
> > There is no way to determine if the remote processor has observed a message,
> > that does not involve pretty trivial race conditions.
> >
> Thanks for chiming in.
> How is it supposed to work if a client queues more than one request?

One such example is found in patch 5 in this series. There are two FIFOs
in shared memory, one in each direction. Each fifo has a index-pair
associated; a write-index is used by the writer to inform the reader
where the valid data in the ring buffer ends and a read-index indicates
to the writer how far behind the read is.

The writer will just push data into the FIFO, each time firing off an
APCS IPC interrupt and when the remote interrupt handler runs it will
consume all the messages from the read-index to the write-index. All
without the need for the reader to signal the writer that it has
received the interrupts.

In the event that the write-index catches up with the read-index a
dedicated flag is set which will cause the reader to signal that the
read-index is updated - allowing the writer to sleep waiting for room in
the FIFO.

> How do you know when it's ok to overwrite the FIFO and send the next
> command?

As long as there's enough space between the write-index and the
read-index we can write.

And we don't need any locks, because the writer is the only one changing
the write-index and the reader is the only one changing the read index.

>   Usually if h/w doesn't indicate, we cook up some ack packet for each
> command. Otherwise the protocol seems badly broken.
> 
>  If there is really nothing that can be done to check delivery of a
> message, I'll pick the driver as such. Best of luck :)

The protocols implemented on top will guarantee this, as needed, so it's
fine :)


I'll update patch 1 and repost patch 1 through 3 for you to merge in the
mailbox tree, patch 4 and 5 I'll pull into the rpmsg tree once I have
received some additional feedback. (We don't have any build time
dependencies between the two, so it's better to merge each driver
through their respective tree)

Thanks,
Bjorn

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

[Bjorn Andersson]

On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote:

> On Sat, May 6, 2017 at 1:23 AM, Jeffrey Hugo  wrote:
> > On 5/5/2017 1:22 PM, Jassi Brar wrote:
> >>
> >> On Sat, May 6, 2017 at 12:07 AM, Bjorn Andersson
> >>  wrote:
> >>>
> >
> > There is no way to determine if the remote processor has observed a message,
> > that does not involve pretty trivial race conditions.
> >
> Thanks for chiming in.
> How is it supposed to work if a client queues more than one request?

One such example is found in patch 5 in this series. There are two FIFOs
in shared memory, one in each direction. Each fifo has a index-pair
associated; a write-index is used by the writer to inform the reader
where the valid data in the ring buffer ends and a read-index indicates
to the writer how far behind the read is.

The writer will just push data into the FIFO, each time firing off an
APCS IPC interrupt and when the remote interrupt handler runs it will
consume all the messages from the read-index to the write-index. All
without the need for the reader to signal the writer that it has
received the interrupts.

In the event that the write-index catches up with the read-index a
dedicated flag is set which will cause the reader to signal that the
read-index is updated - allowing the writer to sleep waiting for room in
the FIFO.

> How do you know when it's ok to overwrite the FIFO and send the next
> command?

As long as there's enough space between the write-index and the
read-index we can write.

And we don't need any locks, because the writer is the only one changing
the write-index and the reader is the only one changing the read index.

>   Usually if h/w doesn't indicate, we cook up some ack packet for each
> command. Otherwise the protocol seems badly broken.
> 
>  If there is really nothing that can be done to check delivery of a
> message, I'll pick the driver as such. Best of luck :)

The protocols implemented on top will guarantee this, as needed, so it's
fine :)


I'll update patch 1 and repost patch 1 through 3 for you to merge in the
mailbox tree, patch 4 and 5 I'll pull into the rpmsg tree once I have
received some additional feedback. (We don't have any build time
dependencies between the two, so it's better to merge each driver
through their respective tree)

Thanks,
Bjorn

Re: drivers/pcmcia/Kconfig

[Randy Dunlap]

On 05/05/17 17:45, as Bari wrote:
> PCCARD entry has menuconfig type. This makes it invisible from, for
> example, gconfig, and we get additional pcmcia modules in builtin
> tree. This is unexpected behaviour.
> Looks like the entry was improperly refactored since 2.6.24.

What kernel version are you testing?
I don't see a problem in kernel 4.11 when using gconfig, xconfig,
nconfig, or menuconfig.
(That is, after opening up the Bus Options menu.)

> I would like to hear others' opinion.

I don't see a problem.  Maybe it is related to your
kernel .config file.  You could post that for our testing.

-- 
~Randy

Re: drivers/pcmcia/Kconfig

[Randy Dunlap]

On 05/05/17 17:45, as Bari wrote:
> PCCARD entry has menuconfig type. This makes it invisible from, for
> example, gconfig, and we get additional pcmcia modules in builtin
> tree. This is unexpected behaviour.
> Looks like the entry was improperly refactored since 2.6.24.

What kernel version are you testing?
I don't see a problem in kernel 4.11 when using gconfig, xconfig,
nconfig, or menuconfig.
(That is, after opening up the Bus Options menu.)

> I would like to hear others' opinion.

I don't see a problem.  Maybe it is related to your
kernel .config file.  You could post that for our testing.

-- 
~Randy

[PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

[Gideon Sheril]

atomisp_gmin_platform.c:
Fix ERROR: spaces instead of tabs and comma/assignment padding error.

Signed-off-by: Gideon Sheril 
---
 .../platform/intel-mid/atomisp_gmin_platform.c | 166 ++---
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..6953dca 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
 
 static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
 
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
 
 /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
@@ -152,13 +152,13 @@ const struct camera_af_platform_data 
*camera_get_af_platform_data(void)
 EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
 
 int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
-struct camera_sensor_platform_data *plat_data,
-enum intel_v4l2_subdev_type type)
+   struct 
camera_sensor_platform_data *plat_data,
+   enum 
intel_v4l2_subdev_type type)
 {
int i;
struct i2c_board_info *bi;
struct gmin_subdev *gs;
-struct i2c_client *client = v4l2_get_subdevdata(subdev);
+   struct i2c_client *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
 
dev_info(>dev, "register atomisp i2c module type %d\n", type);
@@ -172,7 +172,7 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
if (adev)
adev->power.flags.power_resources = 0;
 
-   for (i=0; i < MAX_SUBDEVS; i++)
+   for (i = 0; i < MAX_SUBDEVS; i++)
if (!pdata.subdevs[i].type)
break;
 
@@ -203,13 +203,13 @@ int atomisp_register_i2c_module(struct v4l2_subdev 
*subdev,
 EXPORT_SYMBOL_GPL(atomisp_register_i2c_module);
 
 struct v4l2_subdev *atomisp_gmin_find_subdev(struct i2c_adapter *adapter,
-struct i2c_board_info *board_info)
+struct i2c_board_info 
*board_info)
 {
int i;
-   for (i=0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
+   for (i = 0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
struct intel_v4l2_subdev_table *sd = [i];
if (sd->v4l2_subdev.i2c_adapter_id == adapter->nr &&
-   sd->v4l2_subdev.board_info.addr == board_info->addr)
+   sd->v4l2_subdev.board_info.addr == board_info->addr)
return sd->subdev;
}
return NULL;
@@ -270,45 +270,45 @@ static const struct gmin_cfg_var t100_vars[] = {
 };
 
 static const struct gmin_cfg_var mrd7_vars[] = {
-{"INT33F8:00_CamType", "1"},
-{"INT33F8:00_CsiPort", "1"},
-{"INT33F8:00_CsiLanes","2"},
-{"INT33F8:00_CsiFmt","13"},
-{"INT33F8:00_CsiBayer", "0"},
-{"INT33F8:00_CamClk", "0"},
-{"INT33F9:00_CamType", "1"},
-{"INT33F9:00_CsiPort", "0"},
-{"INT33F9:00_CsiLanes","1"},
-{"INT33F9:00_CsiFmt","13"},
-{"INT33F9:00_CsiBayer", "0"},
-{"INT33F9:00_CamClk", "1"},
-{},
+   {"INT33F8:00_CamType", "1"},
+   {"INT33F8:00_CsiPort", "1"},
+   {"INT33F8:00_CsiLanes", "2"},
+   {"INT33F8:00_CsiFmt", "13"},
+   {"INT33F8:00_CsiBayer", "0"},
+   {"INT33F8:00_CamClk", "0"},
+   {"INT33F9:00_CamType", "1"},
+   {"INT33F9:00_CsiPort", "0"},
+   {"INT33F9:00_CsiLanes", "1"},
+   {"INT33F9:00_CsiFmt", "13"},
+   {"INT33F9:00_CsiBayer", "0"},
+   {"INT33F9:00_CamClk", "1"},
+   {},
 };
 
 static const struct gmin_cfg_var ecs7_vars[] = {
-{"INT33BE:00_CsiPort", "1"},
-{"INT33BE:00_CsiLanes","2"},
-{"INT33BE:00_CsiFmt","13"},
-{"INT33BE:00_CsiBayer", "2"},
-{"INT33BE:00_CamClk", "0"},
-{"INT33F0:00_CsiPort", "0"},
-{"INT33F0:00_CsiLanes","1"},
-{"INT33F0:00_CsiFmt","13"},
-{"INT33F0:00_CsiBayer", "0"},
-{"INT33F0:00_CamClk", "1"},
-{"gmin_V2P8GPIO","402"},
-{},
+   {"INT33BE:00_CsiPort", "1"},
+   {"INT33BE:00_CsiLanes", "2"},
+   {"INT33BE:00_CsiFmt", "13"},
+   {"INT33BE:00_CsiBayer", "2"},
+   {"INT33BE:00_CamClk", "0"},
+   {"INT33F0:00_CsiPort", "0"},
+   

[PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

[Gideon Sheril]

atomisp_gmin_platform.c:
Fix ERROR: spaces instead of tabs and comma/assignment padding error.

Signed-off-by: Gideon Sheril 
---
 .../platform/intel-mid/atomisp_gmin_platform.c | 166 ++---
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..6953dca 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
 
 static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
 
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
 
 /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
@@ -152,13 +152,13 @@ const struct camera_af_platform_data 
*camera_get_af_platform_data(void)
 EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
 
 int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
-struct camera_sensor_platform_data *plat_data,
-enum intel_v4l2_subdev_type type)
+   struct 
camera_sensor_platform_data *plat_data,
+   enum 
intel_v4l2_subdev_type type)
 {
int i;
struct i2c_board_info *bi;
struct gmin_subdev *gs;
-struct i2c_client *client = v4l2_get_subdevdata(subdev);
+   struct i2c_client *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
 
dev_info(>dev, "register atomisp i2c module type %d\n", type);
@@ -172,7 +172,7 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
if (adev)
adev->power.flags.power_resources = 0;
 
-   for (i=0; i < MAX_SUBDEVS; i++)
+   for (i = 0; i < MAX_SUBDEVS; i++)
if (!pdata.subdevs[i].type)
break;
 
@@ -203,13 +203,13 @@ int atomisp_register_i2c_module(struct v4l2_subdev 
*subdev,
 EXPORT_SYMBOL_GPL(atomisp_register_i2c_module);
 
 struct v4l2_subdev *atomisp_gmin_find_subdev(struct i2c_adapter *adapter,
-struct i2c_board_info *board_info)
+struct i2c_board_info 
*board_info)
 {
int i;
-   for (i=0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
+   for (i = 0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
struct intel_v4l2_subdev_table *sd = [i];
if (sd->v4l2_subdev.i2c_adapter_id == adapter->nr &&
-   sd->v4l2_subdev.board_info.addr == board_info->addr)
+   sd->v4l2_subdev.board_info.addr == board_info->addr)
return sd->subdev;
}
return NULL;
@@ -270,45 +270,45 @@ static const struct gmin_cfg_var t100_vars[] = {
 };
 
 static const struct gmin_cfg_var mrd7_vars[] = {
-{"INT33F8:00_CamType", "1"},
-{"INT33F8:00_CsiPort", "1"},
-{"INT33F8:00_CsiLanes","2"},
-{"INT33F8:00_CsiFmt","13"},
-{"INT33F8:00_CsiBayer", "0"},
-{"INT33F8:00_CamClk", "0"},
-{"INT33F9:00_CamType", "1"},
-{"INT33F9:00_CsiPort", "0"},
-{"INT33F9:00_CsiLanes","1"},
-{"INT33F9:00_CsiFmt","13"},
-{"INT33F9:00_CsiBayer", "0"},
-{"INT33F9:00_CamClk", "1"},
-{},
+   {"INT33F8:00_CamType", "1"},
+   {"INT33F8:00_CsiPort", "1"},
+   {"INT33F8:00_CsiLanes", "2"},
+   {"INT33F8:00_CsiFmt", "13"},
+   {"INT33F8:00_CsiBayer", "0"},
+   {"INT33F8:00_CamClk", "0"},
+   {"INT33F9:00_CamType", "1"},
+   {"INT33F9:00_CsiPort", "0"},
+   {"INT33F9:00_CsiLanes", "1"},
+   {"INT33F9:00_CsiFmt", "13"},
+   {"INT33F9:00_CsiBayer", "0"},
+   {"INT33F9:00_CamClk", "1"},
+   {},
 };
 
 static const struct gmin_cfg_var ecs7_vars[] = {
-{"INT33BE:00_CsiPort", "1"},
-{"INT33BE:00_CsiLanes","2"},
-{"INT33BE:00_CsiFmt","13"},
-{"INT33BE:00_CsiBayer", "2"},
-{"INT33BE:00_CamClk", "0"},
-{"INT33F0:00_CsiPort", "0"},
-{"INT33F0:00_CsiLanes","1"},
-{"INT33F0:00_CsiFmt","13"},
-{"INT33F0:00_CsiBayer", "0"},
-{"INT33F0:00_CamClk", "1"},
-{"gmin_V2P8GPIO","402"},
-{},
+   {"INT33BE:00_CsiPort", "1"},
+   {"INT33BE:00_CsiLanes", "2"},
+   {"INT33BE:00_CsiFmt", "13"},
+   {"INT33BE:00_CsiBayer", "2"},
+   {"INT33BE:00_CamClk", "0"},
+   {"INT33F0:00_CsiPort", "0"},
+   {"INT33F0:00_CsiLanes", 

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario 
> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár 
> > > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > > p...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > > On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > > > > -Original Message-
> > > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > > Subject: Re: RFC: WMI Enhancements
> > > > > >
> > > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com
> wrote:
> > > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs 
> > > > > > > > which
> > > > > > > > will be exported to userspace after communication with vendor.
> > > > > > >
> > > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > > without needing to modify kernel for something that kernel won't
> > > > > > > need to do anything immediately.
> > > > > >
> > > > > > I understood it as there would be explicit whitelist in kernel and 
> > > > > > new
> > > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > > have kernel wmi driver.
> > > > > >
> > > > > > Exporting all GUIDs (to userspace) which are not bind to kernel 
> > > > > > driver
> > > > > > has one big problem. If kernel introduce new wmi driver for such 
> > > > > > GUID
> > > > > > then it block userspace to access it or at least would need to 
> > > > > > provide
> > > > > > audit filter and something would be probably filtered. It means that
> > > > > > some userspace applications which would use that GUIDs stops working
> > > > > > after upgrading to new kernel. And we can be in situation where 
> > > > > > *user*
> > > > > > need to decide: either use 3rd party userspace application from 
> > > > > > vendor
> > > > > > which provide some special settings for your laptop, or use kernel
> > > > > > module which provides standard rfkill/led/input class driver.
> > > > > >
> > > > >
> > > > > If this proposal goes forward it would sound like to me an audit 
> > > > > filter
> > > > > would become a prerequisite for any new WMI kernel driver.  This is 
> > > > > not
> > > > > a problem to me.
> > > >
> > > > Not for any wmi driver, only for those which would like to export wmi
> > > > device to userspace.
> > >
> > > Correct.
> > >
> > > >
> > > > > This audience recommends the way for users to configure the system but
> > > > > of course cannot stop users from doing what they decide to do.
> > > >
> > > > Of course, but in above hypothetical example, user is in situation where
> > > > is unable to use both 3rd vendor application and together kernel
> > > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > > manual module loading) what want to use.
> > > >
> > > > But ideal solution is that both 3rd vendor application for firmware
> > > > settings and also rfkill kernel driver would work together without need
> > > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > > >
> > > > > We're all in agreement that the kernel should keep responsibility for 
> > > > > some
> > > > > of these functionalities.
> > > > > If a new kernel WMI driver duplicates functionality that happens to 
> > > > > find its
> > > > > way in userspace and the kernel audits that out yes the userspace
> > > > > application may start to  have less functionality, but better support
> > > > > would live in the 

RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 5, 2017 6:45 PM
> To: Limonciello, Mario 
> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net;
> len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; platform-
> driver-...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > > -Original Message-
> > > From: Darren Hart [mailto:dvh...@infradead.org]
> > > Sent: Thursday, April 20, 2017 3:45 PM
> > > To: Pali Rohár 
> > > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > > p...@vger.kernel.org
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > > On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > > > > -Original Message-
> > > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org;
> platform-
> > > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > > Subject: Re: RFC: WMI Enhancements
> > > > > >
> > > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com
> wrote:
> > > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs 
> > > > > > > > which
> > > > > > > > will be exported to userspace after communication with vendor.
> > > > > > >
> > > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > > without needing to modify kernel for something that kernel won't
> > > > > > > need to do anything immediately.
> > > > > >
> > > > > > I understood it as there would be explicit whitelist in kernel and 
> > > > > > new
> > > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > > have kernel wmi driver.
> > > > > >
> > > > > > Exporting all GUIDs (to userspace) which are not bind to kernel 
> > > > > > driver
> > > > > > has one big problem. If kernel introduce new wmi driver for such 
> > > > > > GUID
> > > > > > then it block userspace to access it or at least would need to 
> > > > > > provide
> > > > > > audit filter and something would be probably filtered. It means that
> > > > > > some userspace applications which would use that GUIDs stops working
> > > > > > after upgrading to new kernel. And we can be in situation where 
> > > > > > *user*
> > > > > > need to decide: either use 3rd party userspace application from 
> > > > > > vendor
> > > > > > which provide some special settings for your laptop, or use kernel
> > > > > > module which provides standard rfkill/led/input class driver.
> > > > > >
> > > > >
> > > > > If this proposal goes forward it would sound like to me an audit 
> > > > > filter
> > > > > would become a prerequisite for any new WMI kernel driver.  This is 
> > > > > not
> > > > > a problem to me.
> > > >
> > > > Not for any wmi driver, only for those which would like to export wmi
> > > > device to userspace.
> > >
> > > Correct.
> > >
> > > >
> > > > > This audience recommends the way for users to configure the system but
> > > > > of course cannot stop users from doing what they decide to do.
> > > >
> > > > Of course, but in above hypothetical example, user is in situation where
> > > > is unable to use both 3rd vendor application and together kernel
> > > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > > manual module loading) what want to use.
> > > >
> > > > But ideal solution is that both 3rd vendor application for firmware
> > > > settings and also rfkill kernel driver would work together without need
> > > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > > >
> > > > > We're all in agreement that the kernel should keep responsibility for 
> > > > > some
> > > > > of these functionalities.
> > > > > If a new kernel WMI driver duplicates functionality that happens to 
> > > > > find its
> > > > > way in userspace and the kernel audits that out yes the userspace
> > > > > application may start to  have less functionality, but better support
> > > > > would live in the kernel and the user would be better supported by
> > > > > the stack (for example could use standard rfkill 

drivers/pcmcia/Kconfig

[as Bari]

PCCARD entry has menuconfig type. This makes it invisible from, for
example, gconfig, and we get additional pcmcia modules in builtin
tree. This is unexpected behaviour.
Looks like the entry was improperly refactored since 2.6.24.

I would like to hear others' opinion.

drivers/pcmcia/Kconfig

[as Bari]

PCCARD entry has menuconfig type. This makes it invisible from, for
example, gconfig, and we get additional pcmcia modules in builtin
tree. This is unexpected behaviour.
Looks like the entry was improperly refactored since 2.6.24.

I would like to hear others' opinion.

[ANNOUNCE] trace-cmd 2.6.1

[Steven Rostedt]

Announce of trace-cmd 2.6.1

It's been a while since I released any official version of trace-cmd, and
there's been lots of updates (although it took me a while to even push those up
to the repo). Here's a brief list of what's happened since 2.6:

  trace-cmd record:

--max-graph-depth has been added.

--ts-offset has been added.

For more details, see the man pages.

  trace-cmd report:

-I was added (no events with 'h' set)

-S was added (no events with 's' set)

--ts-offset was added

--tv2tsecs was added

--tsdiff was added

  trace-cmd list:

--debug (undocumented) for my use mostly.

Bug fixes:

  Fixed the timestamp format issue (rounding error)

  Output fixes

  Fix build with NO_PTRACE=1

  Make sure plog() gets to console before crashing

  Do not call malloc or realloc and friends from signal handler


Clean ups:

   Lots of removal of malloc_or_die()

Enhancements:

  Use of set_event_pid and event-fork option. When available, use them instead
  of writing in pid filters into the event and function filters. Also means
  ptrace is not needed for tracing children.

  trace-cmd start/record -n will now update set_graph_notrace

  Filtering out trace-cmd recorder threads when filtering is used.

  Add "%" (modulus) processing in print formats.

  '~' is handled within print_flags

  Auto completion for bash.

  New "trace-msg" protocol for listen, added.

  Use of /var/run and /var/lib instead of /usr/local/*

  Some helpers for external users.

  Force "NO_PYTHON=1" if swig is not installed


And there were other cleanups, bug fixes and enhancements. Also kernelshark got
some loving too.

Now, my versioning has been up to now pretty much haphazard in what I've been
doing. I'm finally getting around to fixing that too.

This is the 2.6.1 stable release of 2.6, which is where I'm also going to fork
my 2.7 development from. All new updates for v2.6 will go in the
trace-cmd-stable-v2.6 branch, and will not be released till there's a 2.6.2
ready. The first commit to the master branch on top of that will be a change to
create a 2.7.dev version, which will not be a tag. Only number releases will
be. When 2.7 is released, I will create a trace-cmd-stable-v2.7 which will
start at that commit for bug fixes only. The next commit in master after the
2.7 commit will be a change to make a 2.8.dev, where all new development will
be on top of that. This will make version numbers more meaningful. Only v2.6.1
will be a ".1" release in the master branch after this, as I'm starting the
process at this release.

I will try harder to keep master up to date, with the latest development. But
if you run "trace-cmd --version" and there's a ".dev" attached to it, that
means that your trace-cmd may be unstable. Only the full number releases will
go through full testing. I hope this makes sense.

-- Steve

[ANNOUNCE] trace-cmd 2.6.1

[Steven Rostedt]

Announce of trace-cmd 2.6.1

It's been a while since I released any official version of trace-cmd, and
there's been lots of updates (although it took me a while to even push those up
to the repo). Here's a brief list of what's happened since 2.6:

  trace-cmd record:

--max-graph-depth has been added.

--ts-offset has been added.

For more details, see the man pages.

  trace-cmd report:

-I was added (no events with 'h' set)

-S was added (no events with 's' set)

--ts-offset was added

--tv2tsecs was added

--tsdiff was added

  trace-cmd list:

--debug (undocumented) for my use mostly.

Bug fixes:

  Fixed the timestamp format issue (rounding error)

  Output fixes

  Fix build with NO_PTRACE=1

  Make sure plog() gets to console before crashing

  Do not call malloc or realloc and friends from signal handler


Clean ups:

   Lots of removal of malloc_or_die()

Enhancements:

  Use of set_event_pid and event-fork option. When available, use them instead
  of writing in pid filters into the event and function filters. Also means
  ptrace is not needed for tracing children.

  trace-cmd start/record -n will now update set_graph_notrace

  Filtering out trace-cmd recorder threads when filtering is used.

  Add "%" (modulus) processing in print formats.

  '~' is handled within print_flags

  Auto completion for bash.

  New "trace-msg" protocol for listen, added.

  Use of /var/run and /var/lib instead of /usr/local/*

  Some helpers for external users.

  Force "NO_PYTHON=1" if swig is not installed


And there were other cleanups, bug fixes and enhancements. Also kernelshark got
some loving too.

Now, my versioning has been up to now pretty much haphazard in what I've been
doing. I'm finally getting around to fixing that too.

This is the 2.6.1 stable release of 2.6, which is where I'm also going to fork
my 2.7 development from. All new updates for v2.6 will go in the
trace-cmd-stable-v2.6 branch, and will not be released till there's a 2.6.2
ready. The first commit to the master branch on top of that will be a change to
create a 2.7.dev version, which will not be a tag. Only number releases will
be. When 2.7 is released, I will create a trace-cmd-stable-v2.7 which will
start at that commit for bug fixes only. The next commit in master after the
2.7 commit will be a change to make a 2.8.dev, where all new development will
be on top of that. This will make version numbers more meaningful. Only v2.6.1
will be a ".1" release in the master branch after this, as I'm starting the
process at this release.

I will try harder to keep master up to date, with the latest development. But
if you run "trace-cmd --version" and there's a ".dev" attached to it, that
means that your trace-cmd may be unstable. Only the full number releases will
go through full testing. I hope this makes sense.

-- Steve

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár 
> > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > p...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > > > -Original Message-
> > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > To: Limonciello, Mario 
> > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > > platform-
> > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > Subject: Re: RFC: WMI Enhancements
> > > > >
> > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs 
> > > > > > > which
> > > > > > > will be exported to userspace after communication with vendor.
> > > > > >
> > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > without needing to modify kernel for something that kernel won't
> > > > > > need to do anything immediately.
> > > > >
> > > > > I understood it as there would be explicit whitelist in kernel and new
> > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > have kernel wmi driver.
> > > > >
> > > > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > > > then it block userspace to access it or at least would need to provide
> > > > > audit filter and something would be probably filtered. It means that
> > > > > some userspace applications which would use that GUIDs stops working
> > > > > after upgrading to new kernel. And we can be in situation where *user*
> > > > > need to decide: either use 3rd party userspace application from vendor
> > > > > which provide some special settings for your laptop, or use kernel
> > > > > module which provides standard rfkill/led/input class driver.
> > > > >
> > > >
> > > > If this proposal goes forward it would sound like to me an audit filter
> > > > would become a prerequisite for any new WMI kernel driver.  This is not
> > > > a problem to me.
> > >
> > > Not for any wmi driver, only for those which would like to export wmi
> > > device to userspace.
> > 
> > Correct.
> > 
> > >
> > > > This audience recommends the way for users to configure the system but
> > > > of course cannot stop users from doing what they decide to do.
> > >
> > > Of course, but in above hypothetical example, user is in situation where
> > > is unable to use both 3rd vendor application and together kernel
> > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > manual module loading) what want to use.
> > >
> > > But ideal solution is that both 3rd vendor application for firmware
> > > settings and also rfkill kernel driver would work together without need
> > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > >
> > > > We're all in agreement that the kernel should keep responsibility for 
> > > > some
> > > > of these functionalities.
> > > > If a new kernel WMI driver duplicates functionality that happens to 
> > > > find its
> > > > way in userspace and the kernel audits that out yes the userspace
> > > > application may start to  have less functionality, but better support
> > > > would live in the kernel and the user would be better supported by
> > > > the stack (for example could use standard rfkill userspace utilities).
> > >
> > 
> > Pali has raised a very good point which I want to get some feedback from 
> > Linus,
> > and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very 
> > pragmatic
> > approach which I certainly appreciate, we have a very strong position that 
> > we do
> > not break userspace.
> > 
> > There have been exceptions for specific pseudo filesystems and such, but 
> > they
> > are rare. We would need to document the WMI commitment from the kernel to
> > userspace (e.g. any call may be filtered based on current Linux kernel WMI
> > usage, which may change over time). This 

Re: RFC: WMI Enhancements

[Darren Hart]

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár 
> > Cc: Limonciello, Mario ; r...@rjwysocki.net;
> > l...@amacapital.net; len.br...@intel.com; corentin.ch...@gmail.com;
> > l...@kernel.org; andriy.shevche...@linux.intel.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-
> > p...@vger.kernel.org
> > Subject: Re: RFC: WMI Enhancements
> > 
> > On Thu, Apr 20, 2017 at 03:14:31PM +0200, Pali Rohár wrote:
> > > On Wednesday 19 April 2017 17:24:00 mario.limoncie...@dell.com wrote:
> > > > > -Original Message-
> > > > > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > > > > Sent: Wednesday, April 19, 2017 11:55 AM
> > > > > To: Limonciello, Mario 
> > > > > Cc: dvh...@infradead.org; r...@rjwysocki.net; l...@amacapital.net;
> > > > > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org;
> > > > > andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org; 
> > > > > platform-
> > > > > driver-...@vger.kernel.org; linux...@vger.kernel.org
> > > > > Subject: Re: RFC: WMI Enhancements
> > > > >
> > > > > On Wednesday 19 April 2017 18:29:53 mario.limoncie...@dell.com wrote:
> > > > > > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs 
> > > > > > > which
> > > > > > > will be exported to userspace after communication with vendor.
> > > > > >
> > > > > > What about GUID's not yet used by kernel drivers?  Would those
> > > > > > default to whitelist default to blacklist?  My preference would be
> > > > > > to default to whitelist. This allows new GUID's to be added later
> > > > > > without needing to modify kernel for something that kernel won't
> > > > > > need to do anything immediately.
> > > > >
> > > > > I understood it as there would be explicit whitelist in kernel and new
> > > > > GUIDs would be needed to add into whitelist, even those which do not
> > > > > have kernel wmi driver.
> > > > >
> > > > > Exporting all GUIDs (to userspace) which are not bind to kernel driver
> > > > > has one big problem. If kernel introduce new wmi driver for such GUID
> > > > > then it block userspace to access it or at least would need to provide
> > > > > audit filter and something would be probably filtered. It means that
> > > > > some userspace applications which would use that GUIDs stops working
> > > > > after upgrading to new kernel. And we can be in situation where *user*
> > > > > need to decide: either use 3rd party userspace application from vendor
> > > > > which provide some special settings for your laptop, or use kernel
> > > > > module which provides standard rfkill/led/input class driver.
> > > > >
> > > >
> > > > If this proposal goes forward it would sound like to me an audit filter
> > > > would become a prerequisite for any new WMI kernel driver.  This is not
> > > > a problem to me.
> > >
> > > Not for any wmi driver, only for those which would like to export wmi
> > > device to userspace.
> > 
> > Correct.
> > 
> > >
> > > > This audience recommends the way for users to configure the system but
> > > > of course cannot stop users from doing what they decide to do.
> > >
> > > Of course, but in above hypothetical example, user is in situation where
> > > is unable to use both 3rd vendor application and together kernel
> > > rfkill/led/input driver. User must decide (by e.g. modprobe blacklist or
> > > manual module loading) what want to use.
> > >
> > > But ideal solution is that both 3rd vendor application for firmware
> > > settings and also rfkill kernel driver would work together without need
> > > to rmmod/modprobe modules and without restarting 3rd vendor application.
> > >
> > > > We're all in agreement that the kernel should keep responsibility for 
> > > > some
> > > > of these functionalities.
> > > > If a new kernel WMI driver duplicates functionality that happens to 
> > > > find its
> > > > way in userspace and the kernel audits that out yes the userspace
> > > > application may start to  have less functionality, but better support
> > > > would live in the kernel and the user would be better supported by
> > > > the stack (for example could use standard rfkill userspace utilities).
> > >
> > 
> > Pali has raised a very good point which I want to get some feedback from 
> > Linus,
> > and perhaps tglx, hpa, and gregkh on. While Mario is expressing a very 
> > pragmatic
> > approach which I certainly appreciate, we have a very strong position that 
> > we do
> > not break userspace.
> > 
> > There have been exceptions for specific pseudo filesystems and such, but 
> > they
> > are rare. We would need to document the WMI commitment from the kernel to
> > userspace (e.g. any call may be filtered based on current Linux kernel WMI
> > usage, which may change over time). This sounds troublesome... will give 
> > this
> > some more thought.
> > 
> 
> There 

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

[Borislav Petkov]

On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote:
> (Including the folks from SGI since this was hit on a UV system)

Wasn't there a BIOS fix supplied at some point which obviated the need
to boot with efi=old_map on SGI boxes?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

[Borislav Petkov]

On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote:
> (Including the folks from SGI since this was hit on a UV system)

Wasn't there a BIOS fix supplied at some point which obviated the need
to boot with efi=old_map on SGI boxes?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH] cxlflash: Select IRQ_POLL

[Guenter Roeck]

The driver now uses IRQ_POLL and needs to select it to avoid the following
build error.

ERROR: ".irq_poll_complete" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_sched" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_disable" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_init" [drivers/scsi/cxlflash/cxlflash.ko] undefined!

Fixes: cba06e6de403 ("scsi: cxlflash: Implement IRQ polling for RRQ processing")
Signed-off-by: Guenter Roeck 
---
 drivers/scsi/cxlflash/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
index c052104e523e..a011c5dbf214 100644
--- a/drivers/scsi/cxlflash/Kconfig
+++ b/drivers/scsi/cxlflash/Kconfig
@@ -5,6 +5,7 @@
 config CXLFLASH
tristate "Support for IBM CAPI Flash"
depends on PCI && SCSI && CXL && EEH
+   select IRQ_POLL
default m
help
  Allows CAPI Accelerated IO to Flash
-- 
2.7.4

[PATCH] cxlflash: Select IRQ_POLL

[Guenter Roeck]

The driver now uses IRQ_POLL and needs to select it to avoid the following
build error.

ERROR: ".irq_poll_complete" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_sched" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_disable" [drivers/scsi/cxlflash/cxlflash.ko] undefined!
ERROR: ".irq_poll_init" [drivers/scsi/cxlflash/cxlflash.ko] undefined!

Fixes: cba06e6de403 ("scsi: cxlflash: Implement IRQ polling for RRQ processing")
Signed-off-by: Guenter Roeck 
---
 drivers/scsi/cxlflash/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
index c052104e523e..a011c5dbf214 100644
--- a/drivers/scsi/cxlflash/Kconfig
+++ b/drivers/scsi/cxlflash/Kconfig
@@ -5,6 +5,7 @@
 config CXLFLASH
tristate "Support for IBM CAPI Flash"
depends on PCI && SCSI && CXL && EEH
+   select IRQ_POLL
default m
help
  Allows CAPI Accelerated IO to Flash
-- 
2.7.4

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

[J. R. Okajima]

Joonas Lahtinen:
> Filing a bug in freedesktop.org with all the details is the fastest way
> of getting help. Without the bug (and with such little information as
> the previous e-mail) it's hard to estimate the extent and nature of the
> bug.

My original report was
http://marc.info/?l=linux-kernel=149313183203325=2

The report contained
- kernel command line options
- lockdep msg
- call trace
but it didn't look drm/i915 shrinker is related. It was git-bisect which
lead me to drm/i915 shrinker.


> I've anyway gone and prepared a patch to drop the RCU sync completely
> from shrinker phase, as discussed originally with Chris.

Thank you.
I don't know whether the fix is good to me or not yet. I will test your
fix, but I am busy now and my test will be a few weeks later. Other
people may want the fix soon. So I'd suggest you to reproduce the
problem on your side. I guess "mem=1G" or "mem=512M" will make it easier
to reproduce the problem.
Of course, if you are sure the fix is correct, then you don't have to
wait for my test. Release it soon for other people.


J. R. Okajima

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

[J. R. Okajima]

Joonas Lahtinen:
> Filing a bug in freedesktop.org with all the details is the fastest way
> of getting help. Without the bug (and with such little information as
> the previous e-mail) it's hard to estimate the extent and nature of the
> bug.

My original report was
http://marc.info/?l=linux-kernel=149313183203325=2

The report contained
- kernel command line options
- lockdep msg
- call trace
but it didn't look drm/i915 shrinker is related. It was git-bisect which
lead me to drm/i915 shrinker.


> I've anyway gone and prepared a patch to drop the RCU sync completely
> from shrinker phase, as discussed originally with Chris.

Thank you.
I don't know whether the fix is good to me or not yet. I will test your
fix, but I am busy now and my test will be a few weeks later. Other
people may want the fix soon. So I'd suggest you to reproduce the
problem on your side. I guess "mem=1G" or "mem=512M" will make it easier
to reproduce the problem.
Of course, if you are sure the fix is correct, then you don't have to
wait for my test. Release it soon for other people.


J. R. Okajima

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

# Changes since v5:
* added acks/reviews

# Changes since v4:
* fixed typo

# Changes since v3:
* use get_user_ns and put_user_ns to take and drop references to the owner
  user namespace because CONFIG_USER_NS is an option

# Changes since v2:
* take/drop reference to user namespace on tty struct alloc/free to prevent
  use-after-free.

# Changes since v1:
* added owner_user_ns to tty_struct to enable capability checks against
  the namespace that created the tty.
* rewording in different places to make patchset purpose clear
* Added Documentation

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

# Changes since v5:
* added acks/reviews

# Changes since v4:
* fixed typo

# Changes since v3:
* use get_user_ns and put_user_ns to take and drop references to the owner
  user namespace because CONFIG_USER_NS is an option

# Changes since v2:
* take/drop reference to user namespace on tty struct alloc/free to prevent
  use-after-free.

# Changes since v1:
* added owner_user_ns to tty_struct to enable capability checks against
  the namespace that created the tty.
* rewording in different places to make patchset purpose clear
* Added Documentation

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This introduces the tiocsti_restrict sysctl, whose default is controlled via
CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts
all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch depends on patch 1/2

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

Acked-by: Serge Hallyn 
Reviewed-by: Kees Cook 
Signed-off-by: Matt Brown 
---
 Documentation/sysctl/kernel.txt | 21 +
 drivers/tty/tty_io.c|  6 ++
 include/linux/tty.h |  2 ++
 kernel/sysctl.c | 12 
 security/Kconfig| 13 +
 5 files changed, 54 insertions(+)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index bac23c1..f7985cf 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -89,6 +89,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- tiocsti_restrict
 - unknown_nmi_panic
 - watchdog
 - watchdog_thresh
@@ -987,6 +988,26 @@ available RAM pages threads-max is reduced accordingly.
 
 ==
 
+tiocsti_restrict:
+
+This toggle indicates whether unprivileged users are prevented
+from using the TIOCSTI ioctl to inject commands into other processes
+which share a tty session.
+
+When tiocsti_restrict is set to (0) there are no restrictions(accept
+the default restriction of only being able to injection commands into
+one's own tty). When tiocsti_restrict is set to (1), users must
+have CAP_SYS_ADMIN to use the TIOCSTI ioctl.
+
+When user namespaces are in use, the check for the capability
+CAP_SYS_ADMIN is done against the user namespace that originally
+opened the tty.
+
+The kernel config option CONFIG_SECURITY_TIOCSTI_RESTRICT sets the
+default value of tiocsti_restrict.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c276814..fe68d14 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2297,11 +2297,17 @@ static int tty_fasync(int fd, struct file *filp, int on)
  * FIXME: may race normal receive processing
  */
 
+int tiocsti_restrict = IS_ENABLED(CONFIG_SECURITY_TIOCSTI_RESTRICT);
+
 static int tiocsti(struct tty_struct *tty, char __user *p)
 {
char ch, mbz = 0;
struct tty_ldisc *ld;
 
+   if (tiocsti_restrict && !ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)) {
+   pr_warn_ratelimited("TIOCSTI ioctl call blocked for 
non-privileged process\n");
+   return -EPERM;
+   }
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
diff --git a/include/linux/tty.h b/include/linux/tty.h
index d902d42..2fd7f49 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -344,6 +344,8 @@ struct tty_file_private {
struct list_head list;
 };
 
+extern int tiocsti_restrict;
+
 /* tty magic number */
 #define TTY_MAGIC

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

[Matt Brown]

This patch adds struct user_namespace *owner_user_ns to the tty_struct.
Then it is set to current_user_ns() in the alloc_tty_struct function.

This is done to facilitate capability checks against the original user
namespace that allocated the tty.

E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

This combined with the use of user namespace's will allow hardening
protections to be built to mitigate container escapes that utilize TTY
ioctls such as TIOCSTI.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256

Acked-by: Serge Hallyn 
Reviewed-by: Kees Cook 
Signed-off-by: Matt Brown 
---
 drivers/tty/tty_io.c | 2 ++
 include/linux/tty.h  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index e6d1a65..c276814 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -171,6 +171,7 @@ static void free_tty_struct(struct tty_struct *tty)
put_device(tty->dev);
kfree(tty->write_buf);
tty->magic = 0xDEADDEAD;
+   put_user_ns(tty->owner_user_ns);
kfree(tty);
 }
 
@@ -3191,6 +3192,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver 
*driver, int idx)
tty->index = idx;
tty_line_name(driver, idx, tty->name);
tty->dev = tty_get_device(tty);
+   tty->owner_user_ns = get_user_ns(current_user_ns());
 
return tty;
 }
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 1017e904..d902d42 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /*
@@ -333,6 +334,7 @@ struct tty_struct {
/* If the tty has a pending do_SAK, queue it here - akpm */
struct work_struct SAK_work;
struct tty_port *port;
+   struct user_namespace *owner_user_ns;
 };
 
 /* Each of a tty's open files has private_data pointing to tty_file_private */
-- 
2.10.2

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

This introduces the tiocsti_restrict sysctl, whose default is controlled via
CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts
all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch depends on patch 1/2

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.

Threat Model/Patch Rational:

>From grsecurity's config for GRKERNSEC_HARDEN_TTY.

 | There are very few legitimate uses for this functionality and it
 | has made vulnerabilities in several 'su'-like programs possible in
 | the past.  Even without these vulnerabilities, it provides an
 | attacker with an easy mechanism to move laterally among other
 | processes within the same user's compromised session.

So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.

This is also an excellent writeup about the issue:


When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.

Acked-by: Serge Hallyn 
Reviewed-by: Kees Cook 
Signed-off-by: Matt Brown 
---
 Documentation/sysctl/kernel.txt | 21 +
 drivers/tty/tty_io.c|  6 ++
 include/linux/tty.h |  2 ++
 kernel/sysctl.c | 12 
 security/Kconfig| 13 +
 5 files changed, 54 insertions(+)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index bac23c1..f7985cf 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -89,6 +89,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- tiocsti_restrict
 - unknown_nmi_panic
 - watchdog
 - watchdog_thresh
@@ -987,6 +988,26 @@ available RAM pages threads-max is reduced accordingly.
 
 ==
 
+tiocsti_restrict:
+
+This toggle indicates whether unprivileged users are prevented
+from using the TIOCSTI ioctl to inject commands into other processes
+which share a tty session.
+
+When tiocsti_restrict is set to (0) there are no restrictions(accept
+the default restriction of only being able to injection commands into
+one's own tty). When tiocsti_restrict is set to (1), users must
+have CAP_SYS_ADMIN to use the TIOCSTI ioctl.
+
+When user namespaces are in use, the check for the capability
+CAP_SYS_ADMIN is done against the user namespace that originally
+opened the tty.
+
+The kernel config option CONFIG_SECURITY_TIOCSTI_RESTRICT sets the
+default value of tiocsti_restrict.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c276814..fe68d14 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2297,11 +2297,17 @@ static int tty_fasync(int fd, struct file *filp, int on)
  * FIXME: may race normal receive processing
  */
 
+int tiocsti_restrict = IS_ENABLED(CONFIG_SECURITY_TIOCSTI_RESTRICT);
+
 static int tiocsti(struct tty_struct *tty, char __user *p)
 {
char ch, mbz = 0;
struct tty_ldisc *ld;
 
+   if (tiocsti_restrict && !ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)) {
+   pr_warn_ratelimited("TIOCSTI ioctl call blocked for 
non-privileged process\n");
+   return -EPERM;
+   }
if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
diff --git a/include/linux/tty.h b/include/linux/tty.h
index d902d42..2fd7f49 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -344,6 +344,8 @@ struct tty_file_private {
struct list_head list;
 };
 
+extern int tiocsti_restrict;
+
 /* tty magic number */
 #define TTY_MAGIC  0x5401
 
diff --git a/kernel/sysctl.c 

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

[Matt Brown]

This patch adds struct user_namespace *owner_user_ns to the tty_struct.
Then it is set to current_user_ns() in the alloc_tty_struct function.

This is done to facilitate capability checks against the original user
namespace that allocated the tty.

E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

This combined with the use of user namespace's will allow hardening
protections to be built to mitigate container escapes that utilize TTY
ioctls such as TIOCSTI.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256

Acked-by: Serge Hallyn 
Reviewed-by: Kees Cook 
Signed-off-by: Matt Brown 
---
 drivers/tty/tty_io.c | 2 ++
 include/linux/tty.h  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index e6d1a65..c276814 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -171,6 +171,7 @@ static void free_tty_struct(struct tty_struct *tty)
put_device(tty->dev);
kfree(tty->write_buf);
tty->magic = 0xDEADDEAD;
+   put_user_ns(tty->owner_user_ns);
kfree(tty);
 }
 
@@ -3191,6 +3192,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver 
*driver, int idx)
tty->index = idx;
tty_line_name(driver, idx, tty->name);
tty->dev = tty_get_device(tty);
+   tty->owner_user_ns = get_user_ns(current_user_ns());
 
return tty;
 }
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 1017e904..d902d42 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /*
@@ -333,6 +334,7 @@ struct tty_struct {
/* If the tty has a pending do_SAK, queue it here - akpm */
struct work_struct SAK_work;
struct tty_port *port;
+   struct user_namespace *owner_user_ns;
 };
 
 /* Each of a tty's open files has private_data pointing to tty_file_private */
-- 
2.10.2

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

[Michael Ellerman]

Linus Torvalds  writes:
> On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman  wrote:
>>
>> Also due to a screw-up on my part, we need a hunk added when you merge
>> the powerpc tree with the KVM tree:
>>
>> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
>> index 7807ee17af4b..ffe1da95033a 100644
>> --- a/arch/powerpc/kvm/book3s_xive.c
>> +++ b/arch/powerpc/kvm/book3s_xive.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> I haven't seen a pull request from Paolo yet, so possibly you'll need
>> to add that later when you merge the KVM tree.
>
> Ok. I won't catch this in my allmodconfig build due to the
> ppc-specific nature of it, so I'll probably forget about this and not
> catch it.

Yeah fair enough.

> Paolo, Radim, can you try to remind me about this conflict when you
> send the KVM pull request?

I Cc'ed Paolo, and will try and keep an eye out for the KVM pull request
in case he forgets to mention it.

> Also:
>
>>   - Larger virtual address space on 64-bit server CPUs. By default we
>> use a 128TB virtual address space, but a process can request access
>> to the full 512TB by passing a hint to mmap().
>
> I'm assuming/hoping this uses the same logic as the upcoming 47+ bit
> 5-level page table x86 support? Sounds like it, but I didn't check the
> code.
>
> See "x86/mm: Allow to have userspace mappings above 47-bits" which
> hasn't been merged yet, but has been discussed on linux-mm, for
> example.

Yep. We were tracking that discussion, and made changes to make our
semantics match x86.

If anything changes on the x86 side before it merges we can update our
code to match, hopefully prior to 4.12 releasing.

There's also a selftest for the mmap behaviour, written by one of our
guys, which is coming via mm I think, so that should help make sure the
semantics match.

cheers

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

[Michael Ellerman]

Linus Torvalds  writes:
> On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman  wrote:
>>
>> Also due to a screw-up on my part, we need a hunk added when you merge
>> the powerpc tree with the KVM tree:
>>
>> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
>> index 7807ee17af4b..ffe1da95033a 100644
>> --- a/arch/powerpc/kvm/book3s_xive.c
>> +++ b/arch/powerpc/kvm/book3s_xive.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> I haven't seen a pull request from Paolo yet, so possibly you'll need
>> to add that later when you merge the KVM tree.
>
> Ok. I won't catch this in my allmodconfig build due to the
> ppc-specific nature of it, so I'll probably forget about this and not
> catch it.

Yeah fair enough.

> Paolo, Radim, can you try to remind me about this conflict when you
> send the KVM pull request?

I Cc'ed Paolo, and will try and keep an eye out for the KVM pull request
in case he forgets to mention it.

> Also:
>
>>   - Larger virtual address space on 64-bit server CPUs. By default we
>> use a 128TB virtual address space, but a process can request access
>> to the full 512TB by passing a hint to mmap().
>
> I'm assuming/hoping this uses the same logic as the upcoming 47+ bit
> 5-level page table x86 support? Sounds like it, but I didn't check the
> code.
>
> See "x86/mm: Allow to have userspace mappings above 47-bits" which
> hasn't been merged yet, but has been discussed on linux-mm, for
> example.

Yep. We were tracking that discussion, and made changes to make our
semantics match x86.

If anything changes on the x86 side before it merges we can update our
code to match, hopefully prior to 4.12 releasing.

There's also a selftest for the mmap behaviour, written by one of our
guys, which is coming via mm I think, so that should help make sure the
semantics match.

cheers

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

[Kees Cook]

On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche
 wrote:
> On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
>> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
>> index cceddd995a4b..a5c97342fd5d 100644
>> --- a/drivers/scsi/qedf/qedf_main.c
>> +++ b/drivers/scsi/qedf/qedf_main.c
>> @@ -2895,7 +2895,7 @@ static int __qedf_probe(struct pci_dev *pdev, int mode)
>>   slowpath_params.drv_minor = QEDF_DRIVER_MINOR_VER;
>>   slowpath_params.drv_rev = QEDF_DRIVER_REV_VER;
>>   slowpath_params.drv_eng = QEDF_DRIVER_ENG_VER;
>> - memcpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>> + strncpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>>   rc = qed_ops->common->slowpath_start(qedf->cdev, _params);
>>   if (rc) {
>>   QEDF_ERR(&(qedf->dbg_ctx), "Cannot start slowpath.\n");
>
> Hello Kees,
>
> Although this patch looks fine to me, isn't strlcpy() preferred over 
> strncpy()?

strlcpy doesn't zero-pad, so I think strncpy is preferred here,
otherwise we may risk leaving portions of the destination buffer
filled with uninitialized data, maybe leaking kernel memory contents.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

[Kees Cook]

On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche
 wrote:
> On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
>> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
>> index cceddd995a4b..a5c97342fd5d 100644
>> --- a/drivers/scsi/qedf/qedf_main.c
>> +++ b/drivers/scsi/qedf/qedf_main.c
>> @@ -2895,7 +2895,7 @@ static int __qedf_probe(struct pci_dev *pdev, int mode)
>>   slowpath_params.drv_minor = QEDF_DRIVER_MINOR_VER;
>>   slowpath_params.drv_rev = QEDF_DRIVER_REV_VER;
>>   slowpath_params.drv_eng = QEDF_DRIVER_ENG_VER;
>> - memcpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>> + strncpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>>   rc = qed_ops->common->slowpath_start(qedf->cdev, _params);
>>   if (rc) {
>>   QEDF_ERR(&(qedf->dbg_ctx), "Cannot start slowpath.\n");
>
> Hello Kees,
>
> Although this patch looks fine to me, isn't strlcpy() preferred over 
> strncpy()?

strlcpy doesn't zero-pad, so I think strncpy is preferred here,
otherwise we may risk leaving portions of the destination buffer
filled with uninitialized data, maybe leaking kernel memory contents.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

[Robert Richter]

On 05.05.17 17:38:05, Geetha sowjanya wrote:
> From: Linu Cherian 
> 
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
> 
> This option when turned on, replaces all page 1 offsets used for
> EVTQ_PROD/CONS, PRIQ_PROD/CONS register access with page 0 offsets.
> 
> Signed-off-by: Linu Cherian 
> Signed-off-by: Geetha Sowjanya 
> ---
>  .../devicetree/bindings/iommu/arm,smmu-v3.txt  |  6 +++
>  drivers/iommu/arm-smmu-v3.c| 44 
> --
>  2 files changed, 38 insertions(+), 12 deletions(-)

> @@ -1995,8 +2011,10 @@ static int arm_smmu_init_queues(struct arm_smmu_device 
> *smmu)
>   if (!(smmu->features & ARM_SMMU_FEAT_PRI))
>   return 0;
>  
> - return arm_smmu_init_one_queue(smmu, >priq.q, ARM_SMMU_PRIQ_PROD,
> -ARM_SMMU_PRIQ_CONS, PRIQ_ENT_DWORDS);
> + return arm_smmu_init_one_queue(smmu, >priq.q,
> +ARM_SMMU_PRIQ_PROD(smmu),
> +ARM_SMMU_PRIQ_CONS(smmu),
> +PRIQ_ENT_DWORDS);

I would also suggest Robin's idea from the v1 review here. This works
if we rework arm_smmu_init_one_queue() to pass addresses instead of
offsets.

This would make these widespread offset calculations obsolete.

-Robert

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

[Robert Richter]

On 05.05.17 17:38:05, Geetha sowjanya wrote:
> From: Linu Cherian 
> 
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
> 
> This option when turned on, replaces all page 1 offsets used for
> EVTQ_PROD/CONS, PRIQ_PROD/CONS register access with page 0 offsets.
> 
> Signed-off-by: Linu Cherian 
> Signed-off-by: Geetha Sowjanya 
> ---
>  .../devicetree/bindings/iommu/arm,smmu-v3.txt  |  6 +++
>  drivers/iommu/arm-smmu-v3.c| 44 
> --
>  2 files changed, 38 insertions(+), 12 deletions(-)

> @@ -1995,8 +2011,10 @@ static int arm_smmu_init_queues(struct arm_smmu_device 
> *smmu)
>   if (!(smmu->features & ARM_SMMU_FEAT_PRI))
>   return 0;
>  
> - return arm_smmu_init_one_queue(smmu, >priq.q, ARM_SMMU_PRIQ_PROD,
> -ARM_SMMU_PRIQ_CONS, PRIQ_ENT_DWORDS);
> + return arm_smmu_init_one_queue(smmu, >priq.q,
> +ARM_SMMU_PRIQ_PROD(smmu),
> +ARM_SMMU_PRIQ_CONS(smmu),
> +PRIQ_ENT_DWORDS);

I would also suggest Robin's idea from the v1 review here. This works
if we rework arm_smmu_init_one_queue() to pass addresses instead of
offsets.

This would make these widespread offset calculations obsolete.

-Robert

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

[Bart Van Assche]

On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
> index cceddd995a4b..a5c97342fd5d 100644
> --- a/drivers/scsi/qedf/qedf_main.c
> +++ b/drivers/scsi/qedf/qedf_main.c
> @@ -2895,7 +2895,7 @@ static int __qedf_probe(struct pci_dev *pdev, int mode)
>   slowpath_params.drv_minor = QEDF_DRIVER_MINOR_VER;
>   slowpath_params.drv_rev = QEDF_DRIVER_REV_VER;
>   slowpath_params.drv_eng = QEDF_DRIVER_ENG_VER;
> - memcpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
> + strncpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>   rc = qed_ops->common->slowpath_start(qedf->cdev, _params);
>   if (rc) {
>   QEDF_ERR(&(qedf->dbg_ctx), "Cannot start slowpath.\n");

Hello Kees,

Although this patch looks fine to me, isn't strlcpy() preferred over strncpy()?

Bart.

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

[Bart Van Assche]

On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote:
> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
> index cceddd995a4b..a5c97342fd5d 100644
> --- a/drivers/scsi/qedf/qedf_main.c
> +++ b/drivers/scsi/qedf/qedf_main.c
> @@ -2895,7 +2895,7 @@ static int __qedf_probe(struct pci_dev *pdev, int mode)
>   slowpath_params.drv_minor = QEDF_DRIVER_MINOR_VER;
>   slowpath_params.drv_rev = QEDF_DRIVER_REV_VER;
>   slowpath_params.drv_eng = QEDF_DRIVER_ENG_VER;
> - memcpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
> + strncpy(slowpath_params.name, "qedf", QED_DRV_VER_STR_SIZE);
>   rc = qed_ops->common->slowpath_start(qedf->cdev, _params);
>   if (rc) {
>   QEDF_ERR(&(qedf->dbg_ctx), "Cannot start slowpath.\n");

Hello Kees,

Although this patch looks fine to me, isn't strlcpy() preferred over strncpy()?

Bart.

[PATCH] perf, tools: Support srccode output

[Andi Kleen]

From: Andi Kleen 

When looking at PT or brstackinsn traces with perf script
it can be very useful to see the source code. This adds a simple
facility to print them with perf script, if the information
is available through dwarf

% perf record ...
% perf script -F insn,ip,sym,srccode
...

  4004c6 main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004c6 main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004b3 main
6   v++;

% perf record -b ...
% perf script -F insn,ip,sym,srccode,brstackinsn

...
4004c6 main
main+39:
004004cdinsn: 7e e4 # PRED
5   for (i = 0; i < 1000; i++)
004004b3insn: 8b 05 67 0b 20 00
6   v++;
004004b9insn: 83 c0 01
6   v++;
004004bcinsn: 89 05 5e 0b 20 00
6   v++;
004004c2insn: 83 45 fc 01
5   for (i = 0; i < 1000; i++)
004004c6insn: 81 7d fc 7f 96 98 00
5   for (i = 0; i < 1000; i++)
004004cdinsn: 7e e4 # PRED
5   for (i = 0; i < 1000; i++)
004004b3insn: 8b 05 67 0b 20 00
6   v++;
004004b9insn: 83 c0 01
6   v++;
004004bcinsn: 89 05 5e 0b 20 00
6   v++;
004004c2insn: 83 45 fc 01
5   for (i = 0; i < 1000; i++)
004004c6insn: 81 7d fc 7f 96 98 00
5   for (i = 0; i < 1000; i++)
004004cdinsn: 7e e4 # PRED

Not supported for callchains currently, would need some
layout changes there.

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt |   3 +-
 tools/perf/builtin-script.c  |  38 ++-
 tools/perf/util/Build|   1 +
 tools/perf/util/evsel_fprintf.c  |   1 +
 tools/perf/util/map.c|  29 ++
 tools/perf/util/map.h|   2 +
 tools/perf/util/srccode.c| 163 +++
 tools/perf/util/srccode.h|   7 ++
 8 files changed, 242 insertions(+), 2 deletions(-)
 create mode 100644 tools/perf/util/srccode.c
 create mode 100644 tools/perf/util/srccode.h

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index cb0eda3925e6..a8fdc798e259 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,8 @@ OPTIONS
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
 srcline, period, iregs, brstack, brstacksym, flags, bpf-output, 
brstackinsn,
-callindent, insn, insnlen. Field list can be prepended with the type, 
trace, sw or hw,
+   callindent, insn, insnlen, srccode.
+   Field list can be prepended with the type, trace, sw or hw,
 to indicate to which event type the field list applies.
 e.g., -F sw:comm,tid,time,ip,sym  and -F trace:time,cpu,trace
 
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d05aec491cff..7f078e39d474 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -85,6 +85,7 @@ enum perf_output_field {
PERF_OUTPUT_INSN= 1U << 21,
PERF_OUTPUT_INSNLEN = 1U << 22,
PERF_OUTPUT_BRSTACKINSN = 1U << 23,
+   PERF_OUTPUT_SRCCODE = 1U << 24,
 };
 
 struct output_option {
@@ -115,6 +116,7 @@ struct output_option {
{.str = "insn", .field = PERF_OUTPUT_INSN},
{.str = "insnlen", .field = PERF_OUTPUT_INSNLEN},
{.str = "brstackinsn", .field = PERF_OUTPUT_BRSTACKINSN},
+   {.str = "srccode", .field = PERF_OUTPUT_SRCCODE},
 };
 
 /* default set to maintain compatibility with current format */
@@ -304,7 +306,7 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
   "to DSO.\n");
return -EINVAL;
}
-   if (PRINT_FIELD(SRCLINE) && !PRINT_FIELD(IP)) {
+   if ((PRINT_FIELD(SRCLINE) || PRINT_FIELD(SRCCODE)) && !PRINT_FIELD(IP)) 
{
pr_err("Display of source line number requested but sample IP 
is not\n"
   

[PATCH] perf, tools: Support srccode output

[Andi Kleen]

From: Andi Kleen 

When looking at PT or brstackinsn traces with perf script
it can be very useful to see the source code. This adds a simple
facility to print them with perf script, if the information
is available through dwarf

% perf record ...
% perf script -F insn,ip,sym,srccode
...

  4004c6 main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004c6 main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004cd main
5   for (i = 0; i < 1000; i++)
   4004b3 main
6   v++;

% perf record -b ...
% perf script -F insn,ip,sym,srccode,brstackinsn

...
4004c6 main
main+39:
004004cdinsn: 7e e4 # PRED
5   for (i = 0; i < 1000; i++)
004004b3insn: 8b 05 67 0b 20 00
6   v++;
004004b9insn: 83 c0 01
6   v++;
004004bcinsn: 89 05 5e 0b 20 00
6   v++;
004004c2insn: 83 45 fc 01
5   for (i = 0; i < 1000; i++)
004004c6insn: 81 7d fc 7f 96 98 00
5   for (i = 0; i < 1000; i++)
004004cdinsn: 7e e4 # PRED
5   for (i = 0; i < 1000; i++)
004004b3insn: 8b 05 67 0b 20 00
6   v++;
004004b9insn: 83 c0 01
6   v++;
004004bcinsn: 89 05 5e 0b 20 00
6   v++;
004004c2insn: 83 45 fc 01
5   for (i = 0; i < 1000; i++)
004004c6insn: 81 7d fc 7f 96 98 00
5   for (i = 0; i < 1000; i++)
004004cdinsn: 7e e4 # PRED

Not supported for callchains currently, would need some
layout changes there.

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt |   3 +-
 tools/perf/builtin-script.c  |  38 ++-
 tools/perf/util/Build|   1 +
 tools/perf/util/evsel_fprintf.c  |   1 +
 tools/perf/util/map.c|  29 ++
 tools/perf/util/map.h|   2 +
 tools/perf/util/srccode.c| 163 +++
 tools/perf/util/srccode.h|   7 ++
 8 files changed, 242 insertions(+), 2 deletions(-)
 create mode 100644 tools/perf/util/srccode.c
 create mode 100644 tools/perf/util/srccode.h

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index cb0eda3925e6..a8fdc798e259 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,8 @@ OPTIONS
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
 srcline, period, iregs, brstack, brstacksym, flags, bpf-output, 
brstackinsn,
-callindent, insn, insnlen. Field list can be prepended with the type, 
trace, sw or hw,
+   callindent, insn, insnlen, srccode.
+   Field list can be prepended with the type, trace, sw or hw,
 to indicate to which event type the field list applies.
 e.g., -F sw:comm,tid,time,ip,sym  and -F trace:time,cpu,trace
 
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d05aec491cff..7f078e39d474 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -85,6 +85,7 @@ enum perf_output_field {
PERF_OUTPUT_INSN= 1U << 21,
PERF_OUTPUT_INSNLEN = 1U << 22,
PERF_OUTPUT_BRSTACKINSN = 1U << 23,
+   PERF_OUTPUT_SRCCODE = 1U << 24,
 };
 
 struct output_option {
@@ -115,6 +116,7 @@ struct output_option {
{.str = "insn", .field = PERF_OUTPUT_INSN},
{.str = "insnlen", .field = PERF_OUTPUT_INSNLEN},
{.str = "brstackinsn", .field = PERF_OUTPUT_BRSTACKINSN},
+   {.str = "srccode", .field = PERF_OUTPUT_SRCCODE},
 };
 
 /* default set to maintain compatibility with current format */
@@ -304,7 +306,7 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
   "to DSO.\n");
return -EINVAL;
}
-   if (PRINT_FIELD(SRCLINE) && !PRINT_FIELD(IP)) {
+   if ((PRINT_FIELD(SRCLINE) || PRINT_FIELD(SRCCODE)) && !PRINT_FIELD(IP)) 
{
pr_err("Display of source line number requested but sample IP 
is not\n"
   "selected. Hence, no address to lookup the source