Re: [PATCH v2 1/2] net: sched: make default fifo qdiscs appear in the dump

[Jiri Kosina]

On Wed, 8 Mar 2017, Eric Dumazet wrote:

> > +++ b/net/sched/sch_qfq.c
> > @@ -494,6 +494,8 @@ static int qfq_change_class(struct Qdisc *sch, u32 
> > classid, u32 parentid,
> > goto destroy_class;
> > }
> >  
> > +   if (cl->qdisc != _qdisc)
> > +   qdisc_hash_add(cl->qdisc, true);
> 
> 
> Please move the test in qdisc_hash_add() instead of copy/pasting it all
> over the places ?

Well, qdisc_hash_add() has a WARN_ON() (inherited from what 
qdisc_list_add() used to do) for that particular case to catch cases where 
singleton qdisc would make it there from other places by mistake. By 
putting this test there we'll effectively giving up on this warning should 
it ever point to a bug.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2 05/21] x86/xen: split off enlighten_hvm.c

[Juergen Gross]

On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Move PVHVM related code to enlighten_hvm.c. Three functions:
> xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop
> static qualifier from them. These functions will go to common code once
> it is split from enlighten.c.
> 
> Signed-off-by: Vitaly Kuznetsov 

Reviewed-by: Juergen Gross 


Juergen

[PATCH 16/26] IB/ocrdma: Adjust a null pointer check in ocrdma_alloc_resources()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 7 Mar 2017 22:34:33 +0100

The script "checkpatch.pl" pointed information out like the following.

Comparison to NULL could be written "!dev->stag_arr".

Thus fix the affected source code place.

Signed-off-by: Markus Elfring 
---
 drivers/infiniband/hw/ocrdma/ocrdma_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c 
b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
index 93113feeb2d5..fbf672c79d5f 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
@@ -238,7 +238,7 @@ static int ocrdma_alloc_resources(struct ocrdma_dev *dev)
 
dev->stag_arr = kcalloc(OCRDMA_MAX_STAG, sizeof(*dev->stag_arr),
GFP_KERNEL);
-   if (dev->stag_arr == NULL)
+   if (!dev->stag_arr)
goto alloc_err;
 
ocrdma_alloc_pd_pool(dev);
-- 
2.12.0

Re: [PATCH 3/6] mm/migrate: Add copy_pages_mthread function

[Anshuman Khandual]

On 02/17/2017 05:57 PM, kbuild test robot wrote:
> Hi Zi,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.10-rc8 next-20170216]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Anshuman-Khandual/Enable-parallel-page-migration/20170217-200523
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>mm/copy_pages_mthread.c: In function 'copy_pages_mthread':
>>> mm/copy_pages_mthread.c:49:10: warning: assignment discards 'const' 
>>> qualifier from pointer target type [-Wdiscarded-qualifiers]
>  cpumask = cpumask_of_node(node);

My bad. This fixes the above warning. Will fix it up next time
around.

diff --git a/mm/copy_pages_mthread.c b/mm/copy_pages_mthread.c
index 9ad2ef6..46b22b1 100644
--- a/mm/copy_pages_mthread.c
+++ b/mm/copy_pages_mthread.c
@@ -46,7 +46,7 @@ int copy_pages_mthread(struct page *to, struct page
*from, int nr_pages)
int cpu_id_list[32] = {0};

node = page_to_nid(to);
-   cpumask = cpumask_of_node(node);
+   cpumask = (struct cpumask *) cpumask_of_node(node);
cthreads = nr_copythreads;
cthreads = min_t(unsigned int, cthreads, cpumask_weight(cpumask));
cthreads = (cthreads / 2) * 2;

Re: [PATCH 20/26] IB/ocrdma: Delete an unnecessary variable assignment in ocrdma_alloc_mr()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 6:52 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 10:00:41 +0100
>
> Delete an assignment for the local variable "status" in an if branch
> because the desired failure indication is already specified by a constant
> error code at the end.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index 05d55d361cfe..af8798fd35b1 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -3031,10 +3031,8 @@ struct ib_mr *ocrdma_alloc_mr(struct ib_pd *ibpd,
> return ERR_PTR(-ENOMEM);
>
> mr->pages = kcalloc(max_num_sg, sizeof(*mr->pages), GFP_KERNEL);
> -   if (!mr->pages) {
> -   status = -ENOMEM;
> +   if (!mr->pages)
> goto pl_err;
> -   }
>
> status = ocrdma_get_pbl_info(dev, mr, max_num_sg);
> if (status)
> --
> 2.12.0
>

Re: [PATCH v2 2/2] Staging: comedi: comedi_fops: Fix "out of minor numbers for board device files"

[Ian Abbott]

On 07/03/17 18:13, Cheah Kok Cheong wrote:

If comedi module is loaded with the following max allowed parameter
[comedi_num_legacy_minors=48], subsequent loading of an auto-configured
device will fail at auto-configuration. If there's no fall back in
place then module loading will fail.

In this case, a default to auto-configure comedi_test module failed
to auto-configure with the following messages. It loaded but fell back
to unconfigured mode.

comedi_test comedi_testd: ran out of minor numbers for board device files
comedi_test comedi_testd: driver 'comedi_test' could not create device.
comedi_test: unable to auto-configure device

This is due to changes in commit 38b9722a4414
("staging: comedi: avoid releasing legacy minors automatically") which
will not allocate a minor number when comedi_num_legacy_minors equals
COMEDI_NUM_BOARD_MINORS. COMEDI_NUM_BOARD_MINORS is defined to be
0x30 which is 48.


Sorry, I don't consider this to be a bug.  The number of minor device 
numbers available for auto-configured devices is 48 minus 
comedi_num_legacy_minors.  Using up all available minor device numbers 
is a useful test case for running out of minor device numbers, although 
this relies on knowing the limit is 48.  Perhaps the description of the 
module parameter could be improved to mention the limits, as could the 
error message when running out of minor device numbers.


Commit 38b9722a4414 is irrelevant here.  Prior to that commit, the first 
'comedi_num_legacy_minors' minor numbers were still allocated to legacy 
devices created during module initialization, leaving 48 minus 
comedi_num_legacy_minors minors (possibly none) available for 
auto-configured devices.



This goes for a simple fix which limit comedi_num_legacy_minors to 47
instead of tinkering with comedi_alloc_board_minor() and
comedi_release_hardware_device().

Fix: commit 38b9722a4414 ("staging: comedi: avoid releasing legacy minors
automatically")

Signed-off-by: Cheah Kok Cheong 
---

V2:
-Amend commit log to specify that comedi_test module failed
 to auto-configure and fell back to unconfigured mode.
 For other devices with no fall back, module loading will fail.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[PATCH v5 14/19] scsi: pmcraid: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/pmcraid.c | 10 +-
 drivers/scsi/pmcraid.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 49e70a3..0f893c4 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4699,13 +4699,13 @@ pmcraid_release_control_blocks(
return;
 
for (i = 0; i < max_index; i++) {
-   pci_pool_free(pinstance->control_pool,
+   dma_pool_free(pinstance->control_pool,
  pinstance->cmd_list[i]->ioa_cb,
  pinstance->cmd_list[i]->ioa_cb_bus_addr);
pinstance->cmd_list[i]->ioa_cb = NULL;
pinstance->cmd_list[i]->ioa_cb_bus_addr = 0;
}
-   pci_pool_destroy(pinstance->control_pool);
+   dma_pool_destroy(pinstance->control_pool);
pinstance->control_pool = NULL;
 }
 
@@ -4762,8 +4762,8 @@ static int pmcraid_allocate_control_blocks(struct 
pmcraid_instance *pinstance)
pinstance->host->unique_id);
 
pinstance->control_pool =
-   pci_pool_create(pinstance->ctl_pool_name,
-   pinstance->pdev,
+   dma_pool_create(pinstance->ctl_pool_name,
+   >pdev->dev,
sizeof(struct pmcraid_control_block),
PMCRAID_IOARCB_ALIGNMENT, 0);
 
@@ -4772,7 +4772,7 @@ static int pmcraid_allocate_control_blocks(struct 
pmcraid_instance *pinstance)
 
for (i = 0; i < PMCRAID_MAX_CMD; i++) {
pinstance->cmd_list[i]->ioa_cb =
-   pci_pool_alloc(
+   dma_pool_alloc(
pinstance->control_pool,
GFP_KERNEL,
&(pinstance->cmd_list[i]->ioa_cb_bus_addr));
diff --git a/drivers/scsi/pmcraid.h b/drivers/scsi/pmcraid.h
index 568b18a..acf5a7b 100644
--- a/drivers/scsi/pmcraid.h
+++ b/drivers/scsi/pmcraid.h
@@ -755,7 +755,7 @@ struct pmcraid_instance {
 
/* structures related to command blocks */
struct kmem_cache *cmd_cachep;  /* cache for cmd blocks */
-   struct pci_pool *control_pool;  /* pool for control blocks */
+   struct dma_pool *control_pool;  /* pool for control blocks */
char   cmd_pool_name[64];   /* name of cmd cache */
char   ctl_pool_name[64];   /* name of control cache */
 
-- 
2.9.3

[PATCH v5 11/19] scsi: megaraid: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_mbox.c   | 33 +++
 drivers/scsi/megaraid/megaraid_mm.c | 32 +++---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 29 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 66 +
 4 files changed, 77 insertions(+), 83 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c 
b/drivers/scsi/megaraid/megaraid_mbox.c
index f0987f2..7dfc2e2 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
 
// Allocate memory for 16-bytes aligned mailboxes
-   raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
-   adapter->pdev,
+   raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
+   >pdev->dev,
sizeof(mbox64_t) + 16,
16, 0);
 
@@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
mbox_pci_blk = raid_dev->mbox_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   mbox_pci_blk[i].vaddr = pci_pool_alloc(
+   mbox_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->mbox_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 * share common memory pool. Passthru structures piggyback on memory
 * allocted to extended passthru since passthru is smaller of the two
 */
-   raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
-   adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
+   raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
+   >pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
 
if (raid_dev->epthru_pool_handle == NULL) {
goto fail_setup_dma_pool;
@@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   epthru_pci_blk[i].vaddr = pci_pool_alloc(
+   epthru_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->epthru_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
// Allocate memory for each scatter-gather list. Request for 512 bytes
// alignment for each sg list
-   raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
-   adapter->pdev,
+   raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
+   >pdev->dev,
sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
512, 0);
 
@@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   sg_pci_blk[i].vaddr = pci_pool_alloc(
+   sg_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->sg_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1249,29 +1249,26 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
+   dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
sg_pci_blk[i].dma_addr);
}
-   if (raid_dev->sg_pool_handle)
-   pci_pool_destroy(raid_dev->sg_pool_handle);
+   dma_pool_destroy(raid_dev->sg_pool_handle);
 
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && epthru_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->epthru_pool_handle,
+   dma_pool_free(raid_dev->epthru_pool_handle,
epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_addr);
}
-   if (raid_dev->epthru_pool_handle)
-  

RE: out of range LBA using sg_raw

[Kashyap Desai]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Wednesday, March 08, 2017 9:37 PM
> To: Kashyap Desai
> Cc: Christoph Hellwig; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: Re: out of range LBA using sg_raw
>
> On Wed, Mar 08, 2017 at 09:29:28PM +0530, Kashyap Desai wrote:
> > Thanks Chris. It is understood to have sanity in driver, but how
> > critical such checks where SG_IO type interface send pass-through
request.
> ?
> > Are you suggesting as good to have sanity or very important as there
> > may be a real-time exposure other than SG_IO interface ? I am confused
> > over must or good to have check.
> > Also one more fault I can generate using below sg_raw command -
>
> SCSI _devices_ need to sanity check any input and fail commands instead
of
> crashing or causing other problems.  Normal SCSI HBA drivers don't need
to
> do that as they don't interpret CDBs.  Megaraid (and a few other raid
drivers)
> are special in that they take on part of the device functionality and do
> interpret CDBs sometimes.  In that case you'll need to do all that
sanity
> checking and generate proper errors.
>
> It would be nice to have come common helpers for this shared between
> everyone interpreting SCSI CBD (e.g. the SCSI target code, the NVMe SCSI
> emulation and the various RAID drivers).

Thanks Chris.  I will  continue on this and will come back with changes.
Let me check with Broadcom internally and figure out all possible
scenarios for megaraid_sas.

Thanks, Kashyap

Re: [PATCH v2 1/4] ntb_hw_amd: Style fixes: open code macros that just obfuscate code

[Jon Mason]

On Tue, Jan 10, 2017 at 05:33:36PM -0700, Logan Gunthorpe wrote:
> As per a comments in [1] by Greg Kroah-Hartman, the ndev_* macros should
> be cleaned up. This makes it more clear what's actually going on when
> reading the code.
> 
> [1] http://www.spinics.net/lists/linux-pci/msg56904.html
> 
> Signed-off-by: Logan Gunthorpe 

Applied to my ntb-next branch

Thanks,
Jon

> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 59 
> ++---
>  drivers/ntb/hw/amd/ntb_hw_amd.h |  3 ---
>  2 files changed, 31 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 019a158..0135fcf 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -98,10 +98,10 @@ static int amd_ntb_mw_get_range(struct ntb_dev *ntb, int 
> idx,
>   return bar;
>  
>   if (base)
> - *base = pci_resource_start(ndev->ntb.pdev, bar);
> + *base = pci_resource_start(ntb->pdev, bar);
>  
>   if (size)
> - *size = pci_resource_len(ndev->ntb.pdev, bar);
> + *size = pci_resource_len(ntb->pdev, bar);
>  
>   if (align)
>   *align = SZ_4K;
> @@ -126,7 +126,7 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
> idx,
>   if (bar < 0)
>   return bar;
>  
> - mw_size = pci_resource_len(ndev->ntb.pdev, bar);
> + mw_size = pci_resource_len(ntb->pdev, bar);
>  
>   /* make sure the range fits in the usable mw size */
>   if (size > mw_size)
> @@ -135,7 +135,7 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
> idx,
>   mmio = ndev->self_mmio;
>   peer_mmio = ndev->peer_mmio;
>  
> - base_addr = pci_resource_start(ndev->ntb.pdev, bar);
> + base_addr = pci_resource_start(ntb->pdev, bar);
>  
>   if (bar != 1) {
>   xlat_reg = AMD_BAR23XLAT_OFFSET + ((bar - 2) << 2);
> @@ -225,7 +225,7 @@ static int amd_ntb_link_is_up(struct ntb_dev *ntb,
>   if (width)
>   *width = NTB_LNK_STA_WIDTH(ndev->lnk_sta);
>  
> - dev_dbg(ndev_dev(ndev), "link is up.\n");
> + dev_dbg(>pdev->dev, "link is up.\n");
>  
>   ret = 1;
>   } else {
> @@ -234,7 +234,7 @@ static int amd_ntb_link_is_up(struct ntb_dev *ntb,
>   if (width)
>   *width = NTB_WIDTH_NONE;
>  
> - dev_dbg(ndev_dev(ndev), "link is down.\n");
> + dev_dbg(>pdev->dev, "link is down.\n");
>   }
>  
>   return ret;
> @@ -254,7 +254,7 @@ static int amd_ntb_link_enable(struct ntb_dev *ntb,
>  
>   if (ndev->ntb.topo == NTB_TOPO_SEC)
>   return -EINVAL;
> - dev_dbg(ndev_dev(ndev), "Enabling Link.\n");
> + dev_dbg(>pdev->dev, "Enabling Link.\n");
>  
>   ntb_ctl = readl(mmio + AMD_CNTL_OFFSET);
>   ntb_ctl |= (PMM_REG_CTL | SMM_REG_CTL);
> @@ -275,7 +275,7 @@ static int amd_ntb_link_disable(struct ntb_dev *ntb)
>  
>   if (ndev->ntb.topo == NTB_TOPO_SEC)
>   return -EINVAL;
> - dev_dbg(ndev_dev(ndev), "Enabling Link.\n");
> + dev_dbg(>pdev->dev, "Enabling Link.\n");
>  
>   ntb_ctl = readl(mmio + AMD_CNTL_OFFSET);
>   ntb_ctl &= ~(PMM_REG_CTL | SMM_REG_CTL);
> @@ -466,18 +466,19 @@ static void amd_ack_smu(struct amd_ntb_dev *ndev, u32 
> bit)
>  static void amd_handle_event(struct amd_ntb_dev *ndev, int vec)
>  {
>   void __iomem *mmio = ndev->self_mmio;
> + struct device *dev = >ntb.pdev->dev;
>   u32 status;
>  
>   status = readl(mmio + AMD_INTSTAT_OFFSET);
>   if (!(status & AMD_EVENT_INTMASK))
>   return;
>  
> - dev_dbg(ndev_dev(ndev), "status = 0x%x and vec = %d\n", status, vec);
> + dev_dbg(dev, "status = 0x%x and vec = %d\n", status, vec);
>  
>   status &= AMD_EVENT_INTMASK;
>   switch (status) {
>   case AMD_PEER_FLUSH_EVENT:
> - dev_info(ndev_dev(ndev), "Flush is done.\n");
> + dev_info(dev, "Flush is done.\n");
>   break;
>   case AMD_PEER_RESET_EVENT:
>   amd_ack_smu(ndev, AMD_PEER_RESET_EVENT);
> @@ -503,7 +504,7 @@ static void amd_handle_event(struct amd_ntb_dev *ndev, 
> int vec)
>   status = readl(mmio + AMD_PMESTAT_OFFSET);
>   /* check if this is WAKEUP event */
>   if (status & 0x1)
> - dev_info(ndev_dev(ndev), "Wakeup is done.\n");
> + dev_info(dev, "Wakeup is done.\n");
>  
>   amd_ack_smu(ndev, AMD_PEER_D0_EVENT);
>  
> @@ -512,14 +513,14 @@ static void amd_handle_event(struct amd_ntb_dev *ndev, 
> int vec)
> AMD_LINK_HB_TIMEOUT);
>   break;
>   default:
> - dev_info(ndev_dev(ndev), "event status = 0x%x.\n", status);
> + dev_info(dev, "event status = 0x%x.\n", status);
>   break;
>   }
>  }
>  
>  static irqreturn_t 

Re: [PATCH v2 2/4] ntb_hw_intel: Style fixes: open code macros that just obfuscate code

[Jon Mason]

On Tue, Jan 10, 2017 at 05:33:37PM -0700, Logan Gunthorpe wrote:
> As per a comments in [1] by Greg Kroah-Hartman, the ndev_* macros should
> be cleaned up. This makes it more clear what's actually going on when
> reading the code.
> 
> [1] http://www.spinics.net/lists/linux-pci/msg56904.html
> 
> Signed-off-by: Logan Gunthorpe 

Applied to my ntb-next branch

Thanks,
Jon

> ---
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 192 
> ++--
>  drivers/ntb/hw/intel/ntb_hw_intel.h |   3 -
>  2 files changed, 95 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index eca9688..6456f54 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -270,12 +270,12 @@ static inline int ndev_db_addr(struct intel_ntb_dev 
> *ndev,
>  
>   if (db_addr) {
>   *db_addr = reg_addr + reg;
> - dev_dbg(ndev_dev(ndev), "Peer db addr %llx\n", *db_addr);
> + dev_dbg(>ntb.pdev->dev, "Peer db addr %llx\n", *db_addr);
>   }
>  
>   if (db_size) {
>   *db_size = ndev->reg->db_size;
> - dev_dbg(ndev_dev(ndev), "Peer db size %llx\n", *db_size);
> + dev_dbg(>ntb.pdev->dev, "Peer db size %llx\n", *db_size);
>   }
>  
>   return 0;
> @@ -368,7 +368,8 @@ static inline int ndev_spad_addr(struct intel_ntb_dev 
> *ndev, int idx,
>  
>   if (spad_addr) {
>   *spad_addr = reg_addr + reg + (idx << 2);
> - dev_dbg(ndev_dev(ndev), "Peer spad addr %llx\n", *spad_addr);
> + dev_dbg(>ntb.pdev->dev, "Peer spad addr %llx\n",
> + *spad_addr);
>   }
>  
>   return 0;
> @@ -409,7 +410,7 @@ static irqreturn_t ndev_interrupt(struct intel_ntb_dev 
> *ndev, int vec)
>   if ((ndev->hwerr_flags & NTB_HWERR_MSIX_VECTOR32_BAD) && (vec == 31))
>   vec_mask |= ndev->db_link_mask;
>  
> - dev_dbg(ndev_dev(ndev), "vec %d vec_mask %llx\n", vec, vec_mask);
> + dev_dbg(>ntb.pdev->dev, "vec %d vec_mask %llx\n", vec, vec_mask);
>  
>   ndev->last_ts = jiffies;
>  
> @@ -428,7 +429,7 @@ static irqreturn_t ndev_vec_isr(int irq, void *dev)
>  {
>   struct intel_ntb_vec *nvec = dev;
>  
> - dev_dbg(ndev_dev(nvec->ndev), "irq: %d  nvec->num: %d\n",
> + dev_dbg(>ndev->ntb.pdev->dev, "irq: %d  nvec->num: %d\n",
>   irq, nvec->num);
>  
>   return ndev_interrupt(nvec->ndev, nvec->num);
> @@ -438,7 +439,7 @@ static irqreturn_t ndev_irq_isr(int irq, void *dev)
>  {
>   struct intel_ntb_dev *ndev = dev;
>  
> - return ndev_interrupt(ndev, irq - ndev_pdev(ndev)->irq);
> + return ndev_interrupt(ndev, irq - ndev->ntb.pdev->irq);
>  }
>  
>  static int ndev_init_isr(struct intel_ntb_dev *ndev,
> @@ -448,7 +449,7 @@ static int ndev_init_isr(struct intel_ntb_dev *ndev,
>   struct pci_dev *pdev;
>   int rc, i, msix_count, node;
>  
> - pdev = ndev_pdev(ndev);
> + pdev = ndev->ntb.pdev;
>  
>   node = dev_to_node(>dev);
>  
> @@ -487,7 +488,7 @@ static int ndev_init_isr(struct intel_ntb_dev *ndev,
>   goto err_msix_request;
>   }
>  
> - dev_dbg(ndev_dev(ndev), "Using %d msix interrupts\n", msix_count);
> + dev_dbg(>dev, "Using %d msix interrupts\n", msix_count);
>   ndev->db_vec_count = msix_count;
>   ndev->db_vec_shift = msix_shift;
>   return 0;
> @@ -515,7 +516,7 @@ static int ndev_init_isr(struct intel_ntb_dev *ndev,
>   if (rc)
>   goto err_msi_request;
>  
> - dev_dbg(ndev_dev(ndev), "Using msi interrupts\n");
> + dev_dbg(>dev, "Using msi interrupts\n");
>   ndev->db_vec_count = 1;
>   ndev->db_vec_shift = total_shift;
>   return 0;
> @@ -533,7 +534,7 @@ static int ndev_init_isr(struct intel_ntb_dev *ndev,
>   if (rc)
>   goto err_intx_request;
>  
> - dev_dbg(ndev_dev(ndev), "Using intx interrupts\n");
> + dev_dbg(>dev, "Using intx interrupts\n");
>   ndev->db_vec_count = 1;
>   ndev->db_vec_shift = total_shift;
>   return 0;
> @@ -547,7 +548,7 @@ static void ndev_deinit_isr(struct intel_ntb_dev *ndev)
>   struct pci_dev *pdev;
>   int i;
>  
> - pdev = ndev_pdev(ndev);
> + pdev = ndev->ntb.pdev;
>  
>   /* Mask all doorbell interrupts */
>   ndev->db_mask = ndev->db_valid_mask;
> @@ -744,7 +745,7 @@ static ssize_t ndev_ntb_debugfs_read(struct file *filp, 
> char __user *ubuf,
>   union { u64 v64; u32 v32; u16 v16; u8 v8; } u;
>  
>   ndev = filp->private_data;
> - pdev = ndev_pdev(ndev);
> + pdev = ndev->ntb.pdev;
>   mmio = ndev->self_mmio;
>  
>   buf_size = min(count, 0x800ul);
> @@ -1019,7 +1020,8 @@ static void ndev_init_debugfs(struct intel_ntb_dev 
> *ndev)
>   ndev->debugfs_info = NULL;
>   } else {
>   ndev->debugfs_dir =
> - 

Re: Kernel without RTC

[Thomas Gleixner]

On Wed, 8 Mar 2017, Alexandre Belloni wrote:
> On 08/03/2017 at 13:33:33 +, Hadimani, Jagadish wrote:
> > Hello Alexandre,
> > 
> > I guess the Linux kernel uses HPET timer...
> > But can we can force Linux kernel to use Tsc or per core timer...
> > 
> 
> That is probably the case but your are targeting the wrong subsystem.
> The timekeeping is done using two different devices: clocksource and
> clockevent. Usually, the drivers are in drivers/clocksource. I'm
> definitively not an expert in x86 but the clockevent seems to be
> registered from arch/x86/kernel/hpet.c and the clocksource from
> arch/x86/kernel/tsc.c
> 
> IIRC the clocksource is optional but the clockevent is mandatory so if
> you don't have an HPET, you will need to register a clockevent device
> from somewhere else.
> 
> Maybe the simplest thing to do is to ask the x86 maintainers and the
> time maintainers. Luckily for you, they are the same people (Thomas and
> Ingo, added in cc).

The scheduler uses TSC anyway.

The RTC is only used for setting the wall clock time at boot and for
figuring out the time a system spent in suspend. If you don't have an RTC
then the boot wall clock time will be simply 1/1/1970 00:00:00.

Jagadish, can you please explain what your problem is. Does the system fail
to boot or does it behave strange or what?

Thanks,

tglx

Re: [PATCH 17/26] IB/ocrdma: Use kmalloc_array() in ocrdma_create_srq()

[Devesh Sharma]

On Wed, Mar 8, 2017 at 6:47 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 08:45:31 +0100
>
> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus use the corresponding function "kmalloc_array".
>
>   This issue was detected by using the Coccinelle software.
>
> * Replace the specification of a data type by a pointer dereference
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index bc9fb144e57b..ef670ac1cbe9 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -1910,8 +1910,9 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
>
> srq->bit_fields_len = (srq->rq.max_cnt / 32) +
> (srq->rq.max_cnt % 32 ? 1 : 0);
> -   srq->idx_bit_fields =
> -   kmalloc(srq->bit_fields_len * sizeof(u32), GFP_KERNEL);

Lets stick to kmalloc here?

> +   srq->idx_bit_fields = kmalloc_array(srq->bit_fields_len,
> +   
> sizeof(*srq->idx_bit_fields),
> +   GFP_KERNEL);
> if (srq->idx_bit_fields == NULL)
> goto arm_err;
> memset(srq->idx_bit_fields, 0xff,
> --
> 2.12.0
>

Re: [PATCH v2 02/21] x86/xen: globalize have_vcpu_info_placement

[Juergen Gross]

On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> have_vcpu_info_placement applies to both PV and HVM and as we're going
> to split the code we need to make it global.
> 
> Rename to xen_have_vcpu_info_placement.
> 
> Signed-off-by: Vitaly Kuznetsov 

Reviewed-by: Juergen Gross 


Juergen

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

[Christoph Hellwig]

On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote:
> From: Michal Hocko 
> 
> KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently
> so it relied on the default page allocator behavior for the given set
> of flags. This means that small allocations actually never failed.
> 
> Now that we have __GFP_RETRY_MAYFAIL flag which works independently on the
> allocation request size we can map KM_MAYFAIL to it. The allocator will
> try as hard as it can to fulfill the request but fails eventually if
> the progress cannot be made.

I don't think we really need this - KM_MAYFAIL is basically just
a flag to not require the retry loop around kmalloc for those places
in XFS that can deal with allocation failures.  But if the default
behavior is to not fail we'll happily take that.

Re: [PATCH 0/7] 5-level paging: prepare generic code

[Kirill A. Shutemov]

On Wed, Mar 08, 2017 at 03:25:01PM +0100, Michal Hocko wrote:
> Btw. my build test machinery has reported this:
> microblaze/allnoconfig

Thanks.

Fixup is below. I guess it should be folded into 4/7.

diff --git a/arch/microblaze/include/asm/page.h 
b/arch/microblaze/include/asm/page.h
index fd850879854d..d506bb0893f9 100644
--- a/arch/microblaze/include/asm/page.h
+++ b/arch/microblaze/include/asm/page.h
@@ -95,7 +95,8 @@ typedef struct { unsigned long pgd; } pgd_t;
 #   else /* CONFIG_MMU */
 typedef struct { unsigned long ste[64]; }  pmd_t;
 typedef struct { pmd_t pue[1]; }   pud_t;
-typedef struct { pud_t pge[1]; }   pgd_t;
+typedef struct { pud_t p4e[1]; }   p4d_t;
+typedef struct { p4d_t pge[1]; }   pgd_t;
 #   endif /* CONFIG_MMU */
 
 # define pte_val(x)((x).pte)
-- 
 Kirill A. Shutemov

[PATCH v3 0/3] Bind RMI4 over SMBus from PS/2

[Benjamin Tissoires]

Hi Dmitry,

This is mostly a resend of the PS/2-SMBus binding (last 3 patches of now 3 years
of trial and errors).
I integrated both warnings raised by Coccinelle, and squashed 4/3 into 3/3.

I really would like your opinion on this solution. If we could have a full
cycle in linux-next that would be ideal too :)

Cheers,
Benjamin

Benjamin Tissoires (3):
  input: serio - allow others to specify a driver for a serio device
  Input: synaptics - allocate a Synaptics Intertouch device
  Input: add a PS/2 to SMBus platform module

 drivers/input/misc/Kconfig  |  11 ++
 drivers/input/misc/Makefile |   1 +
 drivers/input/misc/ps2_smbus.c  | 424 
 drivers/input/mouse/synaptics.c | 103 ++
 drivers/input/mouse/synaptics.h |   1 +
 drivers/input/serio/serio.c |  20 ++
 include/linux/serio.h   |   5 +
 7 files changed, 565 insertions(+)
 create mode 100644 drivers/input/misc/ps2_smbus.c

-- 
2.9.3

Re: [PATCH] x86, kasan: add KASAN checks to atomic operations

[Mark Rutland]

On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland  wrote:
> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
> > atomic implementations such that we can instrument them explicitly in a
> > core header. That means that the implementation and semantics of the
> > atomics don't change at all.
> >
> > Note that we could initially do this just for x86 and arm64), e.g. by
> > having those explicitly include an 
> > at the end of their .
> 
> How exactly do you want to do this incrementally?
> I don't feel ready to shuffle all archs, but doing x86 in one patch
> and then arm64 in another looks tractable.

I guess we'd have three patches: one adding the header and any core
infrastructure, followed by separate patches migrating arm64 and x86
over.

Thanks,
Mark.

Re: [PATCH] x86, kasan: add KASAN checks to atomic operations

[Mark Rutland]

On Wed, Mar 08, 2017 at 04:45:58PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:43 PM, Mark Rutland  wrote:
> > On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> >> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland  wrote:
> >> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
> >> > atomic implementations such that we can instrument them explicitly in a
> >> > core header. That means that the implementation and semantics of the
> >> > atomics don't change at all.
> >> >
> >> > Note that we could initially do this just for x86 and arm64), e.g. by
> >> > having those explicitly include an 
> >> > at the end of their .
> >>
> >> How exactly do you want to do this incrementally?
> >> I don't feel ready to shuffle all archs, but doing x86 in one patch
> >> and then arm64 in another looks tractable.
> >
> > I guess we'd have three patches: one adding the header and any core
> > infrastructure, followed by separate patches migrating arm64 and x86
> > over.
> 
> But if we add e.g. atomic_read() which forwards to arch_atomic_read()
> to , it will break all archs that don't rename its
> atomic_read() to arch_atomic_read().

... as above, that'd be handled by placing this in an
 file, that we only include at the
end of the arch implementation.

So we'd only include that on arm64 and x86, without needing to change
the names elsewhere.

Thanks,
Mark.

Re: [PATCH] mux-core: make it explicitly non-modular

[Peter Rosin]

On 2017-03-08 15:38, Paul Gortmaker wrote:
> [Re: [PATCH] mux-core: make it explicitly non-modular] On 08/03/2017 (Wed 
> 10:38) Peter Rosin wrote:
> 
>> On 2017-03-07 23:41, Paul Gortmaker wrote:
>>> The Kconfig currently controlling compilation of this code is:
>>>
>>> drivers/mux/Kconfig:menuconfig MULTIPLEXER
>>> drivers/mux/Kconfig:bool "Multiplexer subsystem"
>>>
>>> ...meaning that it currently is not being built as a module by anyone.
>>>
>>> Lets remove the couple traces of modular infrastructure use, so that
>>> when reading the driver there is no doubt it is builtin-only.
>>>
>>> Hence we delete the MODULE_LICENSE tag etc. since all that information
>>> is already contained at the top of the file in the comments.
>>
>> Hi Paul,
>>
>> Yup, it is confirmed, I don't really know what I'm doing. In particular
>> when in comes to modules... I did wonder about this when I wrote the
>> code and one specific thing I wondered about was how module loading is
>> triggered.
>>
>> I can imagine that calling a function that happens to be exported from
>> a module triggers its loading and that failure to load the module leads
>> to an oops. But I don't know if that is even remotely correct? Is it?
> 
> No, that would be pretty user unfriendly.  When you "insmod" a module,
> the kernel checks just like a linker, that all the functions it wants to
> use are available.  If they are not, then the kernel fails to load it.
> But it fails gracefully with a list of the unresolved symbols.
> 
> Obviously managing all the module interdependencies manually would be
> tedious, so that is what what "depmod" does.  Then loading of a module
> is usually done with "modprobe", which will consult the depmod data and
> then "insmod" the required modules in the needed order.

Ahhh, insmod etc, that was a different millennia. I've been pretty much
away from Linux for a looong while...

>> Is there a short answer? Or what should I read for a longer one?
> 
> Well, now that you know it won't oops from a module needing a module,
> perhaps you do now want to make the core support modular?  If I look in
> my ARM build, I see:
> 
> paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$ ls -l
> total 96
> -rw-rw-r-- 1 paul paul   399 Mar  7 16:41 built-in.mod.c
> -rw-rw-r-- 1 paul paul 15999 Mar  7 16:41 built-in.o
> -rw-rw-r-- 1 paul paul 0 Mar  7 16:12 modules.builtin
> -rw-rw-r-- 1 paul paul65 Mar  7 16:41 modules.order
> -rw-rw-r-- 1 paul paul  8324 Mar  7 16:49 mux-adg792a.ko
> -rw-rw-r-- 1 paul paul  1566 Mar  7 16:46 mux-adg792a.mod.c
> -rw-rw-r-- 1 paul paul  3552 Mar  7 16:47 mux-adg792a.mod.o
> -rw-rw-r-- 1 paul paul  6824 Mar  7 16:41 mux-adg792a.o
> -rw-rw-r-- 1 paul paul 20472 Mar  7 16:41 mux-core.o
> -rw-rw-r-- 1 paul paul  7680 Mar  7 16:49 mux-gpio.ko
> -rw-rw-r-- 1 paul paul  1550 Mar  7 16:46 mux-gpio.mod.c
> -rw-rw-r-- 1 paul paul  3408 Mar  7 16:47 mux-gpio.mod.o
> -rw-rw-r-- 1 paul paul  6360 Mar  7 16:41 mux-gpio.o
> paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$ 
> 
> Note that mux-core doesn't have a .ko (modular variant) and also you can
> confirm with nm that everything in mux-core.o is in built-in.o (in this
> case the nm outputs are virtually identical).

Yes, I was aware that the mux core was not set up to be built as a module,
and that was intentional. But the only reason for that was that I thought
subsystem cores were never modular. The module related remains that
you removed were just that, remains from other code used as a template.

> But if you do make that a module too, you will need the MODULE_LICENSE
> tag.  The kernel also checks that license compatibility is maintained ;
> i.e. a proprietary module can't use functions from another module doing
> EXPORT_SYMBOL_GPL.
> 
>> Anyway, I'll add this to the queue, and fold it if I happen to rebase.
> 
> Oh, and speaking of EXPORT_SYMBOL, I should have added 
> to your file with the patch I sent, since it does do exports.

Ok, I assume that it should be included by the individual drivers as well?

> Hope that helps,
> Paul.

Yup, it helps, but it doesn't really help with making the call if it
should be possible to build the mux core as module or not. What things
are not possible to build as modules? E.g. there's the mux_ida thing,
will that work as expected if the mux core is modular (and possibly
unloaded)? Isn't there a risk that names will be reused and confusing
and cause bugs? Or is there a way to block a module from being unloaded?

Hmmm, there's also the ".owner = THIS_MODULE" line in mux-core.c that
seems related, is that line valid for non-modular "units"?

Cheers,
peda

> --
> 
>> Thanks!
>>
>> Cheers,
>> peda
>>
>>> Cc: Peter Rosin 
>>> Cc: Jonathan Cameron 
>>> Signed-off-by: Paul Gortmaker 
>>> ---
>>>
>>> [feel free to fold this change into the original addition commit if
>>>  you happen to be rebasing for 

Re: [PATCH 3/5] fs, xfs: convert xlog_ticket.t_ref from atomic_t to refcount_t

[Christoph Hellwig]

> - ASSERT(atomic_read(>t_ref) > 0);
> - atomic_inc(>t_ref);
> + ASSERT(refcount_read(>t_ref) > 0);
> + refcount_inc(>t_ref);

With strict refcount semantics refcount_inc should check that
the count is larger than 0, otherwise we'd need to use 
recount_inc_not_zero or whatever you're going to call it.

Is that something the recount code does / could do?

[PATCH] tun: remove copyright printing

[Corentin Labbe]

Printing copyright does not give any useful information on the boot
process.
Furthermore, the email address printed is obsolete since
commit ba57b6f20429 ("MAINTAINERS: fix bouncing tun/tap entries")

Signed-off-by: Corentin Labbe 
---
 drivers/net/tun.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index dc1b1dd..f58b7d8 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2570,7 +2570,6 @@ static int __init tun_init(void)
int ret = 0;
 
pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
-   pr_info("%s\n", DRV_COPYRIGHT);
 
ret = rtnl_link_register(_link_ops);
if (ret) {
-- 
2.10.2

[GIT PULL][PATCH 0/2] ktest: Fixes for 4.11

[Steven Rostedt]

Linus,

Greg Kroah-Hartman reported to me that the ktest of v4.10 locked up in an
infinite loop while doing the make mrproper. Looking into the cause I noticed
that a recent update to the function run_command (used for running all
shell commands, including "make mrproper") changed the internal loop to
use the function wait_for_input. The wait_for_input uses select to look
at two file descriptors. One is the file descriptor of the command it is
running, the other is STDIN. The STDIN check was not checking the return
status of the sysread call, and was also just writing a lot of data into
syswrite without regard to the size of the data read.

Changing the code to check the return status of sysread, and also to still
process the passed in descriptor data without looping back to the select
fixed Greg's problem.

While looking at this code I also realized that the loop did not honor
the timeout if STDIN always had input (or for some reason return error).
this could prevent wait_for_input to timeout on the file descriptor it
is suppose to be waiting for. That is fixed too.

Please pull the latest ktest-v4.11-rc1 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
ktest-v4.11-rc1

Tag SHA1: 6692cf546881262ada6b98dc7f0ee374922e669b
Head SHA1: f7c6401ff84ab8c281a29aa0a787f7eb346e


Steven Rostedt (VMware) (2):
  ktest: Fix while loop in wait_for_input
  ktest: Make sure wait_for_input does honor the timeout


 tools/testing/ktest/ktest.pl | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

RE: out of range LBA using sg_raw

[Kashyap Desai]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Wednesday, March 08, 2017 8:41 PM
> To: Kashyap Desai
> Cc: linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org
> Subject: Re: out of range LBA using sg_raw
>
> Hi Kashyap,
>
> for SG_IO passthrough requests we can't validate command validity for
> commands as the block layer treats them as opaque.  The SCSI device
> implementation needs to handle incorrect parameter to be robust.
>
> For your fast path bypass the megaraid driver assumes part of the SCSI
device
> implementation, so it will have to check for validity.

Thanks Chris. It is understood to have sanity in driver, but how critical
such checks where SG_IO type interface send pass-through request. ?
Are you suggesting as good to have sanity or very important as there may
be a real-time exposure other than SG_IO interface ? I am confused over
must or good to have check.
Also one more fault I can generate using below sg_raw command -

"sg_raw -r 32k /dev/sdx 28 00 01 4f ff ff 00 00 08 00"

Provide more scsi data length compare to actual SG buffer. Do you suggest
such SG_IO interface vulnerability is good to be captured in driver.

I am just curious to know how badly we have to scrutinize each packet
before sending to Fast Path  as we are in IO path and recommend only
important checks to be added.

Thanks, Kashyap

Re: [RFT PATCH] mips: workpad_defconfig: convert to use libata PATA drivers

[Bartlomiej Zolnierkiewicz]

Hi Ralf,

When patches converting MIPS defconfigs to libata PATA were
applied this one got lost somehow. Please consider merging
(it applies fine to v4.11-rc1).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

On Monday, September 14, 2015 05:51:58 PM Bartlomiej Zolnierkiewicz wrote:
> IDE subsystem has been deprecated since 2009 and the majority
> (if not all) of Linux distributions have switched to use
> libata for ATA support exclusively.  However there are still
> some users (mostly old or/and embedded non-x86 systems) that
> have not converted from using IDE subsystem to libata PATA
> drivers.  This doesn't seem to be good thing in the long-term
> for Linux as while there is less and less PATA systems left
> in use:
> 
> * testing efforts are divided between two subsystems
> 
> * having duplicate drivers for same hardware confuses users
> 
> This patch converts workpad_defconfig to use libata PATA
> drivers.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
> Build tested only.
> If you have affected hardware please test.  Thank you.
> 
>  arch/mips/configs/workpad_defconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/configs/workpad_defconfig 
> b/arch/mips/configs/workpad_defconfig
> index ee4b2be..1b556cd 100644
> --- a/arch/mips/configs/workpad_defconfig
> +++ b/arch/mips/configs/workpad_defconfig
> @@ -28,10 +28,10 @@ CONFIG_IP_MULTICAST=y
>  # CONFIG_IPV6 is not set
>  CONFIG_NETWORK_SECMARK=y
>  CONFIG_BLK_DEV_RAM=m
> -# CONFIG_MISC_DEVICES is not set
> -CONFIG_IDE=y
> -CONFIG_BLK_DEV_IDECS=m
> -CONFIG_IDE_GENERIC=y
> +CONFIG_BLK_DEV_SD=y
> +CONFIG_ATA=y
> +CONFIG_PATA_PCMCIA=m
> +CONFIG_PATA_LEGACY=y
>  CONFIG_NETDEVICES=y
>  # CONFIG_NETDEV_1000 is not set
>  # CONFIG_NETDEV_1 is not set

RE: out of range LBA using sg_raw

[Kashyap Desai]

> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@sandisk.com]
> Sent: Wednesday, March 08, 2017 9:35 PM
> To: h...@infradead.org; kashyap.de...@broadcom.com
> Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: out of range LBA using sg_raw
>
> On Wed, 2017-03-08 at 21:29 +0530, Kashyap Desai wrote:
> > Also one more fault I can generate using below sg_raw command -
> >
> > "sg_raw -r 32k /dev/sdx 28 00 01 4f ff ff 00 00 08 00"
> >
> > Provide more scsi data length compare to actual SG buffer. Do you
> > suggest such SG_IO interface vulnerability is good to be captured in
driver.
>
> That's not a vulnerability of the SG I/O interface. A SCSI device has to
set the
> residual count correctly if the SCSI data length does not match the size
of the
> data buffer.

Thanks Bart.  I will pass this information to Broadcom firmware dev. May
be a Tx/Rx (DMA) related code in MR (also for Fusion IT HBA)  cannot
handle due to some sanity checks are not passed.

>
> Bart.

[PATCH 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node

[Gregory CLEMENT]

Armada 37xx SoC embedded an EHCI controller. This patch adds the device
tree node enabling its support.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 6 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 864936acc316..aa39339b6582 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -134,6 +134,12 @@
status = "okay";
 };
 
+/* CON27 */
+ {
+   status = "okay";
+};
+
+
  {
status = "okay";
phy0: ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 4c7ff32acb97..25ae5ccaf1bf 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -204,6 +204,13 @@
status = "disabled";
};
 
+   usb2: usb@5e000 {
+   compatible = "marvell,armada-3700-ehci";
+   reg = <0x5e000 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   };
+
xor@60900 {
compatible = "marvell,armada-3700-xor";
reg = <0x60900 0x100
-- 
2.11.0

Re: [PATCH] x86, kasan: add KASAN checks to atomic operations

[Dmitry Vyukov]

On Mon, Mar 6, 2017 at 9:35 PM, Peter Zijlstra  wrote:
> On Mon, Mar 06, 2017 at 04:20:18PM +, Mark Rutland wrote:
>> > >> So the problem is doing load/stores from asm bits, and GCC
>> > >> (traditionally) doesn't try and interpret APP asm bits.
>> > >>
>> > >> However, could we not write a GCC plugin that does exactly that?
>> > >> Something that interprets the APP asm bits and generates these KASAN
>> > >> bits that go with it?
>
>> I don't think there's much you'll be able to do within the compiler,
>> assuming you mean to derive this from the asm block inputs and outputs.
>
> Nah, I was thinking about a full asm interpreter.
>
>> Those can hide address-generation (e.g. with per-cpu stuff), which the
>> compiler may erroneously be detected as racing.
>>
>> Those may also take fake inputs (e.g. the sp input to arm64's
>> __my_cpu_offset()) which may confuse matters.
>>
>> Parsing the assembly itself will be *extremely* painful due to the way
>> that's set up for run-time patching.
>
> Argh, yah, completely forgot about all that alternative and similar
> nonsense :/



I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
consequently x86/arm64) initially, it becomes more realistic. For the
tools we don't care about absolute efficiency and this gets rid of
Will's points (2), (4) and (6) here https://lwn.net/Articles/691295/.
Re (3) I think rmb/wmb can be reasonably replaced with
atomic_thread_fence(acquire/release). Re (5) situation with
correctness becomes better very quickly as more people use them in
user-space. Since KASAN is not intended to be used in production (or
at least such build is expected to crash), we can afford to shake out
any remaining correctness issues in such build. (1) I don't fully
understand, what exactly is the problem with seq_cst?

I've sketched a patch that does it, and did some testing with/without
KASAN on x86_64.

In short, it adds include/linux/atomic_compiler.h which is included
from include/linux/atomic.h when CONFIG_COMPILER_ATOMIC is defined;
and  is not included when CONFIG_COMPILER_ATOMIC is
defined.
For bitops it is similar except that only parts of asm/bitops.h are
selectively disabled when CONFIG_COMPILER_ATOMIC, because it also
defines other stuff.
asm/barriers.h is left intact for now. We don't need it for KASAN. But
for KTSAN we can do similar thing -- selectively disable some of the
barriers in asm/barriers.h (e.g. leaving dma_rmb/wmb per arch).

Such change would allow us to support atomic ops for multiple arches
for all of KASAN/KTSAN/KMSAN.

Thoughts?
diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index 14635c5ea025..7bcb10544fc1 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -1,6 +1,10 @@
 #ifndef _ASM_X86_ATOMIC_H
 #define _ASM_X86_ATOMIC_H
 
+#ifdef CONFIG_COMPILER_ATOMIC
+#error "should not be included"
+#endif
+
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 854022772c5b..e42b85f1ed75 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -68,6 +68,7 @@
  * Note that @nr may be almost arbitrarily large; this function is not
  * restricted to acting on a single-word quantity.
  */
+#ifndef CONFIG_COMPILER_BITOPS
 static __always_inline void
 set_bit(long nr, volatile unsigned long *addr)
 {
@@ -81,6 +82,7 @@ set_bit(long nr, volatile unsigned long *addr)
 			: BITOP_ADDR(addr) : "Ir" (nr) : "memory");
 	}
 }
+#endif
 
 /**
  * __set_bit - Set a bit in memory
@@ -106,6 +108,7 @@ static __always_inline void __set_bit(long nr, volatile unsigned long *addr)
  * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
  * in order to ensure changes are visible on other processors.
  */
+#ifndef CONFIG_COMPILER_BITOPS
 static __always_inline void
 clear_bit(long nr, volatile unsigned long *addr)
 {
@@ -119,6 +122,7 @@ clear_bit(long nr, volatile unsigned long *addr)
 			: "Ir" (nr));
 	}
 }
+#endif
 
 /*
  * clear_bit_unlock - Clears a bit in memory
@@ -128,17 +132,20 @@ clear_bit(long nr, volatile unsigned long *addr)
  * clear_bit() is atomic and implies release semantics before the memory
  * operation. It can be used for an unlock.
  */
+#ifndef CONFIG_COMPILER_BITOPS
 static __always_inline void clear_bit_unlock(long nr, volatile unsigned long *addr)
 {
 	barrier();
 	clear_bit(nr, addr);
 }
+#endif
 
 static __always_inline void __clear_bit(long nr, volatile unsigned long *addr)
 {
 	asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
 }
 
+#ifndef CONFIG_COMPILER_BITOPS
 static __always_inline bool clear_bit_unlock_is_negative_byte(long nr, volatile unsigned long *addr)
 {
 	bool negative;
@@ -151,6 +158,7 @@ static __always_inline bool clear_bit_unlock_is_negative_byte(long nr, volatile
 
 // Let everybody know we have it
 #define clear_bit_unlock_is_negative_byte clear_bit_unlock_is_negative_byte
+#endif
 
 /*
  * __clear_bit_unlock - Clears a bit 

[PATCH 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the
Armada 37xx use the EHCI orion controller. This patch allow to build
the driver when ARCH_MVEBU is selected.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..870c42d89298 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
 
 config USB_EHCI_HCD_ORION
tristate  "Support for Marvell EBU on-chip EHCI USB controller"
-   depends on USB_EHCI_HCD && PLAT_ORION
+   depends on USB_EHCI_HCD && PLAT_ORION || ARCH_MVEBU
default y
---help---
  Enables support for the on-chip EHCI controller on Marvell's
-- 
2.11.0

Re: [PATCH] pinctrl: samsung: fix segfault when using external interrupts on s3c24xx

[Krzysztof Kozlowski]

On Mon, Mar 06, 2017 at 09:15:16AM -0400, Sergio Prado wrote:
> Hi Krzysztof,
> 
> > > This is a regression from commit 8b1bd11c1f8f529057369c5b3702d13fd24e2765.
> > 
> > Checkpatch should complain here about commit format.
> > 
> > > 
> > > Tested on FriendlyARM mini2440.
> > > 
> > 
> > Please add:
> >   Fixes: 8b1bd11c1f8f ("pinctrl: samsung: Add the support the multiple 
> > IORESOURCE_MEM for one pin-bank")
> >   Cc: 
> > 
> 
> OK.
> 
> > > Signed-off-by: Sergio Prado 
> > > ---
> > >  drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
> > > b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> > > index b82a003546ae..1b8d887796e8 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> > > +++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> > > @@ -356,8 +356,8 @@ static inline void s3c24xx_demux_eint(struct irq_desc 
> > > *desc,
> > >  {
> > >   struct s3c24xx_eint_data *data = irq_desc_get_handler_data(desc);
> > >   struct irq_chip *chip = irq_desc_get_chip(desc);
> > > - struct irq_data *irqd = irq_desc_get_irq_data(desc);
> > > - struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
> > > + struct samsung_pinctrl_drv_data *d = data->drvdata;
> > > + struct samsung_pin_bank *bank = d->pin_banks;
> > 
> > I think 'pin_banks' point to all banks of given controller not to the
> > currently accessed one.
> 
> Understood. I think it worked in my tests because on s3c2440 all banks
> have the same eint base address.
> 
> So what do you think is the best approach to solve this problem?

Maybe you can get to this through:
s3c24xx_eint_domain_data = s3c24xx_eint_data->domains[virq].host_data;
s3c24xx_eint_domain_data->bank

It is getting slightly more complicated...

Best regards,
Krzysztof

[PATCH v2 7/9] mm: ensure that we set mapping error if writeout() fails

[Jeff Layton]

If writepage fails during a page migration, then we need to ensure that
fsync will see it by flagging the mapping.

Signed-off-by: Jeff Layton 
---
 mm/migrate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 9a0897a14d37..a9c0b46865b7 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -789,7 +789,11 @@ static int writeout(struct address_space *mapping, struct 
page *page)
/* unlocked. Relock */
lock_page(page);
 
-   return (rc < 0) ? -EIO : -EAGAIN;
+   if (rc < 0) {
+   mapping_set_error(mapping, rc);
+   return -EIO;
+   }
+   return -EAGAIN;
 }
 
 /*
-- 
2.9.3

[PATCH v2 2/9] mm: drop "wait" parameter from write_one_page

[Jeff Layton]

The callers all set it to 1. Also, make it clear that this function will
not set any sort of AS_* error, and that the caller must do so if
necessary. No existing caller uses this on normal files, so none of them
need it.

Signed-off-by: Jeff Layton 
---
 fs/exofs/dir.c|  2 +-
 fs/ext2/dir.c |  2 +-
 fs/jfs/jfs_metapage.c |  4 ++--
 fs/minix/dir.c|  2 +-
 fs/sysv/dir.c |  2 +-
 fs/ufs/dir.c  |  2 +-
 include/linux/mm.h|  2 +-
 mm/page-writeback.c   | 14 +++---
 8 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 42f9a0a0c4ca..e163ed980c20 100644
--- a/fs/exofs/dir.c
+++ b/fs/exofs/dir.c
@@ -72,7 +72,7 @@ static int exofs_commit_chunk(struct page *page, loff_t pos, 
unsigned len)
set_page_dirty(page);
 
if (IS_DIRSYNC(dir))
-   err = write_one_page(page, 1);
+   err = write_one_page(page);
else
unlock_page(page);
 
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index d9650c9508e4..e2709695b177 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -100,7 +100,7 @@ static int ext2_commit_chunk(struct page *page, loff_t pos, 
unsigned len)
}
 
if (IS_DIRSYNC(dir)) {
-   err = write_one_page(page, 1);
+   err = write_one_page(page);
if (!err)
err = sync_inode_metadata(dir, 1);
} else {
diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
index 489aaa1403e5..744fa3c079e6 100644
--- a/fs/jfs/jfs_metapage.c
+++ b/fs/jfs/jfs_metapage.c
@@ -711,7 +711,7 @@ void force_metapage(struct metapage *mp)
get_page(page);
lock_page(page);
set_page_dirty(page);
-   write_one_page(page, 1);
+   write_one_page(page);
clear_bit(META_forcewrite, >flag);
put_page(page);
 }
@@ -756,7 +756,7 @@ void release_metapage(struct metapage * mp)
set_page_dirty(page);
if (test_bit(META_sync, >flag)) {
clear_bit(META_sync, >flag);
-   write_one_page(page, 1);
+   write_one_page(page);
lock_page(page); /* write_one_page unlocks the page */
}
} else if (mp->lsn) /* discard_metapage doesn't remove it */
diff --git a/fs/minix/dir.c b/fs/minix/dir.c
index 7edc9b395700..baa9721f1299 100644
--- a/fs/minix/dir.c
+++ b/fs/minix/dir.c
@@ -57,7 +57,7 @@ static int dir_commit_chunk(struct page *page, loff_t pos, 
unsigned len)
mark_inode_dirty(dir);
}
if (IS_DIRSYNC(dir))
-   err = write_one_page(page, 1);
+   err = write_one_page(page);
else
unlock_page(page);
return err;
diff --git a/fs/sysv/dir.c b/fs/sysv/dir.c
index 5bdae85ceef7..f5191cb2c947 100644
--- a/fs/sysv/dir.c
+++ b/fs/sysv/dir.c
@@ -45,7 +45,7 @@ static int dir_commit_chunk(struct page *page, loff_t pos, 
unsigned len)
mark_inode_dirty(dir);
}
if (IS_DIRSYNC(dir))
-   err = write_one_page(page, 1);
+   err = write_one_page(page);
else
unlock_page(page);
return err;
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index de01b8f2aa78..48609f1d9580 100644
--- a/fs/ufs/dir.c
+++ b/fs/ufs/dir.c
@@ -53,7 +53,7 @@ static int ufs_commit_chunk(struct page *page, loff_t pos, 
unsigned len)
mark_inode_dirty(dir);
}
if (IS_DIRSYNC(dir))
-   err = write_one_page(page, 1);
+   err = write_one_page(page);
else
unlock_page(page);
return err;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0d65dd72c0f4..0ac8fe63769a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2164,7 +2164,7 @@ extern void filemap_map_pages(struct vm_fault *vmf,
 extern int filemap_page_mkwrite(struct vm_fault *vmf);
 
 /* mm/page-writeback.c */
-int write_one_page(struct page *page, int wait);
+int write_one_page(struct page *page);
 void task_dirty_inc(struct task_struct *tsk);
 
 /* readahead.c */
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d8ac2a7fb9e7..de0dbf12e2c1 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2361,15 +2361,16 @@ int do_writepages(struct address_space *mapping, struct 
writeback_control *wbc)
 }
 
 /**
- * write_one_page - write out a single page and optionally wait on I/O
+ * write_one_page - write out a single page and wait on I/O
  * @page: the page to write
- * @wait: if true, wait on writeout
  *
  * The page must be locked by the caller and will be unlocked upon return.
  *
- * write_one_page() returns a negative error code if I/O failed.
+ * write_one_page() returns a negative error code if I/O failed. Note that
+ * the address_space is not marked for error. The caller must do this if
+ * needed.
  */
-int write_one_page(struct page *page, 

[PATCH v2 8/9] mm: don't TestClearPageError in __filemap_fdatawait_range

[Jeff Layton]

The -EIO returned here can end up overriding whatever error is marked in
the address space. This means that an -ENOSPC error (AS_ENOSPC) can end
up being turned into -EIO if a page gets PG_error set on it during error
handling.

Read errors are also sometimes tracked on a per-page level using
PG_error. Suppose we have a read error on a page, and then that page is
subsequently dirtied by overwriting the whole page. Writeback doesn't
clear PG_error, so we can then end up successfully writing back that
page and still return -EIO on fsync.

Worse yet, PG_error is cleared during a sync() syscall, but the -EIO
return from this code is silently discarded. Any subsystem that is
relying on PG_error to report errors during fsync or close is already
broken due to this. All you need is a stray sync() call on the box
at the wrong time and you've lost the error.

Since the handling of the PG_error flag is somewhat inconsistent across
subsystems, let's just rely on marking the address space when there are
writeback errors. Change the TestClearPageError call to ClearPageError,
and make __filemap_fdatawait_range a void return function.

Signed-off-by: Jeff Layton 
---
 mm/filemap.c | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index fc123b9833e1..150559e94f8a 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -376,17 +376,16 @@ int filemap_flush(struct address_space *mapping)
 }
 EXPORT_SYMBOL(filemap_flush);
 
-static int __filemap_fdatawait_range(struct address_space *mapping,
+static void __filemap_fdatawait_range(struct address_space *mapping,
 loff_t start_byte, loff_t end_byte)
 {
pgoff_t index = start_byte >> PAGE_SHIFT;
pgoff_t end = end_byte >> PAGE_SHIFT;
struct pagevec pvec;
int nr_pages;
-   int ret = 0;
 
if (end_byte < start_byte)
-   goto out;
+   return;
 
pagevec_init(, 0);
while ((index <= end) &&
@@ -403,14 +402,11 @@ static int __filemap_fdatawait_range(struct address_space 
*mapping,
continue;
 
wait_on_page_writeback(page);
-   if (TestClearPageError(page))
-   ret = -EIO;
+   ClearPageError(page);
}
pagevec_release();
cond_resched();
}
-out:
-   return ret;
 }
 
 /**
@@ -430,14 +426,8 @@ static int __filemap_fdatawait_range(struct address_space 
*mapping,
 int filemap_fdatawait_range(struct address_space *mapping, loff_t start_byte,
loff_t end_byte)
 {
-   int ret, ret2;
-
-   ret = __filemap_fdatawait_range(mapping, start_byte, end_byte);
-   ret2 = filemap_check_errors(mapping);
-   if (!ret)
-   ret = ret2;
-
-   return ret;
+   __filemap_fdatawait_range(mapping, start_byte, end_byte);
+   return filemap_check_errors(mapping);
 }
 EXPORT_SYMBOL(filemap_fdatawait_range);
 
-- 
2.9.3

[PATCH v2 3/9] mm: clear any AS_* errors when returning error on any fsync or close

[Jeff Layton]

Currently we don't clear the address space error when there is a -EIO
error on fsynci, due to writeback initiation failure. If writes fail
with -EIO and the mapping is flagged with an AS_EIO or AS_ENOSPC error,
then we can end up returning errors on two fsync calls, even when a
write between them succeeded (or there was no write).

Ensure that we also clear out any mapping errors when initiating
writeback fails with -EIO in filemap_write_and_wait and
filemap_write_and_wait_range.

Suggested-by: Jan Kara 
Signed-off-by: Jeff Layton 
---
 mm/filemap.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 1694623a6289..fc123b9833e1 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -488,7 +488,7 @@ EXPORT_SYMBOL(filemap_fdatawait);
 
 int filemap_write_and_wait(struct address_space *mapping)
 {
-   int err = 0;
+   int err;
 
if ((!dax_mapping(mapping) && mapping->nrpages) ||
(dax_mapping(mapping) && mapping->nrexceptional)) {
@@ -499,10 +499,18 @@ int filemap_write_and_wait(struct address_space *mapping)
 * But the -EIO is special case, it may indicate the worst
 * thing (e.g. bug) happened, so we avoid waiting for it.
 */
-   if (err != -EIO) {
+   if (likely(err != -EIO)) {
int err2 = filemap_fdatawait(mapping);
if (!err)
err = err2;
+   } else {
+   /*
+* Clear the error in the address space since we're
+* returning an error here. -EIO takes precedence over
+* everything else though, so we can just discard
+* the return here.
+*/
+   filemap_check_errors(mapping);
}
} else {
err = filemap_check_errors(mapping);
@@ -537,6 +545,14 @@ int filemap_write_and_wait_range(struct address_space 
*mapping,
lstart, lend);
if (!err)
err = err2;
+   } else {
+   /*
+* Clear the error in the address space since we're
+* returning an error here. -EIO takes precedence over
+* everything else though, so we can just discard
+* the return here.
+*/
+   filemap_check_errors(mapping);
}
} else {
err = filemap_check_errors(mapping);
-- 
2.9.3

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

[Rich Felker]

On Wed, Mar 08, 2017 at 10:53:00AM -0500, Carlos O'Donell wrote:
> On 11/11/2016 07:08 AM, Felix Janda wrote:
> > Currently, libc-compat.h detects inclusion of specific glibc headers,
> > and defines corresponding _UAPI_DEF_* macros, which in turn are used in
> > uapi headers to prevent definition of conflicting structures/constants.
> > There is no such detection for other c libraries, for them the
> > _UAPI_DEF_* macros are always defined as 1, and so none of the possibly
> > conflicting definitions are suppressed.
> > 
> > This patch enables non-glibc c libraries to request the suppression of
> > any specific interface by defining the corresponding _UAPI_DEF_* macro
> > as 0.
> > 
> > This patch together with the recent musl libc commit
> > 
> > http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> Would it be possible to amend the musl patch to define the macros to 1.

I don't follow. They're defined to 0 explicitly to tell the kernel
headers not to define their own versions of these structs, etc. since
they would clash. Defining to 1 would have the opposite meaning.

Rich

Re: [PATCH v5 2/5] powerpc: kretprobes: override default function entry offset

[Arnaldo Carvalho de Melo]

Em Wed, Mar 08, 2017 at 07:54:12PM +0530, Naveen N. Rao escreveu:
> Hi Michael,
> 
> On 2017/03/08 09:43PM, Michael Ellerman wrote:
> > "Naveen N. Rao"  writes:
> > 
> > > With ABIv2, we offset 8 bytes into a function to get at the local entry
> > > point.
> > >
> > > Acked-by: Ananth N Mavinakayanahalli 
> > > Acked-by: Michael Ellerman 
> > > Signed-off-by: Naveen N. Rao 
> > > ---
> > >  arch/powerpc/kernel/kprobes.c | 9 +
> > >  1 file changed, 9 insertions(+)
> > 
> > I'm OK with this change, and I'm happy for it to go with the rest of the
> > series via acme's tree:
> > 
> > Acked-by: Michael Ellerman 
> > 
> > 
> > But, you've also sent a series to do KPROBES_ON_FTRACE, and that also
> > touches this function, see the 2nd to last hunk at:
> > 
> >   https://patchwork.ozlabs.org/patch/730675/
> > 
> > 
> > If this goes via acme's tree it will be awkward for me to merge the
> > series above via the powerpc tree.
> 
> Ah yes, indeed.
> 
> > 
> > So we could do topic branches and so on, or we could just drop this
> > patch from this series, and I'll merge it as part of the other series.
> > It won't do anything useful until it's merged with a tree that also has
> > the rest of this series. Or something else I haven't thought of.
> 
> The arch-independent change that this depends on has been picked up by 
> Arnaldo and pushed to Ingo:
> https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg115211.html
> 
> I'm guessing this will go into v4.11? In which case, this powerpc patch 
> should also go in. Otherwise kretprobes will be broken on powerpc64le.

I don't think so, I've put it in a perf/core branch, meaning its not
strictly fixes, could be processed in the next merge window if Ingo
thinks we've passed the current merge window threshold for such kind of
changes, and he merged it into perf/core, meaning, at this time, that it
is aimed for 4.12.
 
> I wasn't sure if you were planning on picking up KPROBES_ON_FTRACE for 
> v4.11. If so, it would be good to take this patch through the powerpc 
> tree. Otherwise, this can go via Ingo's tree.

If you guys convince Ingo that this should go _now_, then just cherry
pick what was merged into tip/perf/core that is needed for the arch
specific stuff and go from there.

- Arnaldo

Re: [PATCH 10/10] Bluetooth: add nokia driver

[Rob Herring]

On Tue, Mar 7, 2017 at 3:08 PM, Sebastian Reichel  wrote:
> Hi Rob,
>
> On Tue, Mar 07, 2017 at 10:30:51AM -0600, Rob Herring wrote:
>> On Sat, Mar 4, 2017 at 5:58 AM, Sebastian Reichel  wrote:
>> > This adds a driver for the Nokia H4+ protocol, which is used
>> > at least on the Nokia N9, N900 & N950.
>> >
>> > Signed-off-by: Sebastian Reichel 
>> > ---
>> >  .../devicetree/bindings/net/nokia-bluetooth.txt|  51 ++
>>
>> This should be separate and before the dts files.
>>
>> >  drivers/bluetooth/Kconfig  |  12 +
>> >  drivers/bluetooth/Makefile |   2 +
>> >  drivers/bluetooth/hci_nokia.c  | 839 
>> > +
>> >  4 files changed, 904 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/net/nokia-bluetooth.txt
>> >  create mode 100644 drivers/bluetooth/hci_nokia.c
>> >
>> > diff --git a/Documentation/devicetree/bindings/net/nokia-bluetooth.txt 
>> > b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
>> > new file mode 100644
>> > index ..6c80a92f31e2
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
>> > @@ -0,0 +1,51 @@
>> > +Nokia Bluetooth Chips
>> > +-
>> > +
>> > +Nokia phones often come with UART connected bluetooth chips from different
>> > +vendors and modified device API. Those devices speak a protocol named H4+
>> > +by Nokia, which is similar to the H4 protocol from the Bluetooth standard.
>> > +In addition to the H4 protocol it specifies two more UART status lines for
>> > +wakeup of UART transceivers to improve power management and a few new 
>> > packet
>> > +types used to negotiate uart speed.
>> > +
>> > +Required properties:
>> > +
>> > + - compatible: should be one of the following:
>> > +   * "nokia,brcm,bcm2048"
>> > +   * "nokia,ti,wl1271-bluetooth"
>>
>> Drop the chip vendors' prefix here. I don't really want to start a
>> pattern of 2 vendor prefixes.
>
> Right, I think we discussed this before, but I don't remember the
> result. How about
>
> - compatible: should contain "nokia,h4p-bluetooth" as well as one of the 
> following:
>  * "brcm,bcm2048-nokia"
>  * "ti,wl1271-blueooth-nokia"

Sure, that's fine (other than the typo).

> For the driver it should be enough to know "nokia,h4p-bluetooth"
> actually. The device identifies itself in the negotiation reply.
>
>> > + - reset-gpios: GPIO specifier, used to reset the BT module
>>
>> Need to state active state.
>
> ok. Any suggestion about the wording? The BT chips use usually
> active low reset pin. The driver handles all GPIOs as active
> high with the DT binding translating this transparently.

Just having "active low" in there is enough.

Personally I find the GPIO translating confusing...

Rob

Re: [PATCH 19/26] IB/ocrdma: Improve another size determination in ocrdma_alloc_mr()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 6:50 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 09:54:42 +0100
>
> Replace the specification of a data type by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index 330617e1ef75..05d55d361cfe 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -3030,7 +3030,7 @@ struct ib_mr *ocrdma_alloc_mr(struct ib_pd *ibpd,
> if (!mr)
> return ERR_PTR(-ENOMEM);
>
> -   mr->pages = kcalloc(max_num_sg, sizeof(u64), GFP_KERNEL);
> +   mr->pages = kcalloc(max_num_sg, sizeof(*mr->pages), GFP_KERNEL);
> if (!mr->pages) {
> status = -ENOMEM;
> goto pl_err;
> --
> 2.12.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] x86/platform: Add a low priority low frequency NMI call chain

[Mike Travis]

On 3/8/2017 2:28 AM, Ingo Molnar wrote:
> 
> * Mike Travis  wrote:
> 
>>
>>
>> On 3/6/2017 11:42 PM, Ingo Molnar wrote:
>>>
>>> * Mike Travis  wrote:
>>>
 Add a new NMI call chain that is called last after all other NMI handlers
 have been checked and did not "handle" the NMI.  This mimics the current
 NMI_UNKNOWN call chain except it eliminates the WARNING message about
 multiple NMI handlers registering on this call chain.

 This call chain dramatically lowers the NMI call frequency when high
 frequency NMI tools are in use, notably the perf tools.  It is required
 for NMI handlers that cannot sustain a high NMI call rate without
 ramifications to the system operability.
>>>
>>> So how about we just turn off that warning instead? I don't remember the 
>>> last time 
>>> it actually _helped_ us find any kernel or hardware bug - and it has caused 
>>> tons 
>>> of problems...
>>
>> I can do that, with an even simpler patch...
>>
>>>
>>> It's not like we warn about excess regular IRQs either - we either handle 
>>> them or 
>>> at most increase a counter somewhere. We could do the same for NMIs: 
>>> introduce a 
>>> counter somewhere that counts the number of seemingly unhandled NMIs.
>>
>> Really "unknown" NMI errors are reported by either the "dazed and
>> confused" message or if the panic on unknown nmi is set, then the
>> system will panic.  So unknown NMI occurrences are already being
>> dealt with.
> 
> So I'd even remove the 'dazed and confused' message - has it ever helped us?

I can remove it though it seems to have become an institution, or more
correctly, a common term of reference. :)  It does precede the decision
to either attempt to continue system operation, or panic the system
immediately.

> If NMIs are generated but not handled properly then developers and users will 
> notice it just like when IRQs are lost: either through bad system behavior or 
> via 
> weird stats in procfs. The kernel log should not get spammed.

Having some notice is probably a good thing even if for archaic reasons.
We recently discovered that an internal system error triggered an NMI
event.  Without any notice, the system would not have been suspected of
acting strangely, but data could potentially have been silently lost.
(NMI seems by far the least standard standard in the x86 architecture.)

Also, I don't think IRQs and NMIs are in the same league.  Missing an
IRQ means an expected I/O operation did not occur.  Prudent drivers can
set a timeout to notice missing interrupts.

Missing an NMI usually means that something unexpected occurred but was
not dealt with.  Losing perf interrupts is recoverable since there
will be another along shortly.  But missing an NMI due to a system
failure event is not.  (Why NMI is heavily overloaded, and not very
standardized.)

> 
> So if you could expose the lost NMI stats via procfs or debugfs then we could 
> remove both the warning and the dazed-and-confused spam on the system log.

I can add this.

> 
> This should make perf all around more usable on UV systems, right?

I'm not sure this is accurate.  Perf is currently very usable on UV.
But as we increase our online fault analysis procedures, this warning
message stood out as a glaring example of a false positive.  Note it
is not warning of anything except there is more than one NMI handler
registering on this "call after all other handlers have been called
and did not claim the NMI" chain.

So let me know if I should go ahead with the above (remove some or
all indications that an unclaimed NMI event occurred, and add a
reporting facility for NMI stats.)

Thanks!
Mike

Re: [PATCH 23/26] IB/ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 6:58 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 10:58:34 +0100
>
> 1. Return zero in one case directly.
>
> 2. Return the value from a call of the function "_ocrdma_dealloc_pd"
>without using an extra assignment for the local variable.
>
> 3. Remove the variable "status" in this function then.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index 1d25512416f5..ae0d343d1731 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -755,7 +755,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd)
> struct ocrdma_pd *pd = get_ocrdma_pd(ibpd);
> struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device);
> struct ocrdma_ucontext *uctx = NULL;
> -   int status = 0;
> u64 usr_db;
>
> uctx = pd->uctx;
> @@ -769,11 +768,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd)
>
> if (is_ucontext_pd(uctx, pd)) {
> ocrdma_release_ucontext_pd(uctx);
> -   return status;
> +   return 0;
> }
> }
> -   status = _ocrdma_dealloc_pd(dev, pd);
> -   return status;
> +   return _ocrdma_dealloc_pd(dev, pd);
>  }
>
>  static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr,
> --
> 2.12.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [lkp-robot] [locking/ww_mutex] 857811a371: INFO:task_blocked_for_more_than#seconds

[Fengguang Wu]

On Wed, Mar 08, 2017 at 12:13:12PM +, Chris Wilson wrote:

On Wed, Mar 08, 2017 at 09:08:54AM +0800, kernel test robot wrote:


FYI, we noticed the following commit:

commit: 857811a37129f5d2ba162d7be3986eff44724014 ("locking/ww_mutex: Adjust the lock 
number for stress test")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


Now the test is running, it takes too long. :)


Sorry that's right. Up to now the 0day robot still cannot guarantee
the timely reporting of a runtime regression, nor can it guarantee
bisecting of a new regression even when some test actually triggered
the bug.

One fundamental challenge is, there are ~50,000 runtime "regressions"
queued for bisect. Obviously there is no way to bisect them all. So a
large portion of real regressions never get a chance to be bisected.
Not to mention the problem of bisect reliability and efficiency.

Most of the test "regressions" may be duplicates to each other (eg. a
bug in mainline kernel will also show up in various developer trees).
A great portion of them may also be random noises (eg. performance
fluctuations). We've tried various approaches to improve the
de-duplicate, filtering, prioritize etc. algorithms. Together with
increased test coverage, they have been reflected in our slowly
increasing report numbers. However there is still a long way to go.

Thanks,
Fengguang

Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |   14 +-
>  arch/x86/mm/mem_encrypt.c  |3 +++
>  include/linux/mem_encrypt.h|6 ++
>  3 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/mem_encrypt.h 
> b/arch/x86/include/asm/mem_encrypt.h
> index 1fd5426..9799835 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -20,10 +20,16 @@
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>  
>  extern unsigned long sme_me_mask;
> +extern unsigned int sev_enabled;

So there's a function name sev_enabled() and an int sev_enabled too.

It looks to me like you want to call the function "sev_enable()" -
similar to sme_enable(), convert it to C code - i.e., I don't see what
would speak against it - and rename that sev_enc_bit to sev_enabled and
use it everywhere when testing SEV status.

>  static inline bool sme_active(void)
>  {
> - return (sme_me_mask) ? true : false;
> + return (sme_me_mask && !sev_enabled) ? true : false;
> +}
> +
> +static inline bool sev_active(void)
> +{
> + return (sme_me_mask && sev_enabled) ? true : false;

Then, those read strange: like SME and SEV are mutually exclusive. Why?
I might have an idea but I'd like for you to confirm it :-)

Then, you're calling sev_enabled in startup_32() but we can enter
in arch/x86/boot/compressed/head_64.S::startup_64() too, when we're
loaded by a 64-bit bootloader, which would then theoretically bypass
sev_enabled().

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH 5/5] staging/lustre: Use generic range rwlock

[Davidlohr Bueso]

On Tue, 07 Mar 2017, Oleg Drokin wrote:

On Mar 7, 2017, at 12:03 AM, Davidlohr Bueso wrote:


This replaces the in-house version, which is also derived
from Jan's interval tree implementation.

Cc: oleg.dro...@intel.com
Cc: andreas.dil...@intel.com
Cc: jsimm...@infradead.org
Cc: lustre-de...@lists.lustre.org

Signed-off-by: Davidlohr Bueso 
---
XXX: compile tested only. In house uses 'ulong long', generic uses 'ulong', is 
this a problem?


Hm, cannot seem to find the other patches in this series anywhere to verify and 
my subscription to linux-kernel broke as it turns out.


You can find the full series here:

https://lwn.net/Articles/716383/


You mean the range is ulong? So only can have this working up to 2G offsets on 
the
32bit systems and then wrap around?


Yes.

Thanks,
Davidlohr

Re: [PATCH] x86, kasan: add KASAN checks to atomic operations

[Dmitry Vyukov]

On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland  wrote:
> Hi,
>
> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
>> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
>> consequently x86/arm64) initially, it becomes more realistic. For the
>> tools we don't care about absolute efficiency and this gets rid of
>> Will's points (2), (4) and (6) here https://lwn.net/Articles/691295/.
>> Re (3) I think rmb/wmb can be reasonably replaced with
>> atomic_thread_fence(acquire/release). Re (5) situation with
>> correctness becomes better very quickly as more people use them in
>> user-space. Since KASAN is not intended to be used in production (or
>> at least such build is expected to crash), we can afford to shake out
>> any remaining correctness issues in such build. (1) I don't fully
>> understand, what exactly is the problem with seq_cst?
>
> I'll have to leave it to Will to have the final word on these; I'm
> certainly not familiar enough with the C11 memory model to comment on
> (1).
>
> However, w.r.t. (3), I don't think we can substitute rmb() and wmb()
> with atomic_thread_fence_acquire() and atomic_thread_fence_release()
> respectively on arm64.
>
> The former use barriers with full system scope, whereas the latter may
> be limited to the inner shareable domain. While I'm not sure of the
> precise intended semantics of wmb() and rmb(), I believe this
> substitution would break some cases (e.g. communicating with a
> non-coherent master).
>
> Note that regardless, we'd have to special-case __iowmb() to use a full
> system barrier.
>
> Also, w.r.t. (5), modulo the lack of atomic instrumentation, people use
> KASAN today, with compilers that are known to have bugs in their atomics
> (e.g. GCC bug 69875). Thus, we cannot rely on the compiler's
> implementation of atomics without introducing a functional regression.
>
>> i'Ve sketched a patch that does it, and did some testing with/without
>> KASAN on x86_64.
>>
>> In short, it adds include/linux/atomic_compiler.h which is included
>> from include/linux/atomic.h when CONFIG_COMPILER_ATOMIC is defined;
>> and  is not included when CONFIG_COMPILER_ATOMIC is
>> defined.
>> For bitops it is similar except that only parts of asm/bitops.h are
>> selectively disabled when CONFIG_COMPILER_ATOMIC, because it also
>> defines other stuff.
>> asm/barriers.h is left intact for now. We don't need it for KASAN. But
>> for KTSAN we can do similar thing -- selectively disable some of the
>> barriers in asm/barriers.h (e.g. leaving dma_rmb/wmb per arch).
>>
>> Such change would allow us to support atomic ops for multiple arches
>> for all of KASAN/KTSAN/KMSAN.
>>
>> Thoughts?
>
> As in my other reply, I'd prefer that we wrapped the (arch-specific)
> atomic implementations such that we can instrument them explicitly in a
> core header. That means that the implementation and semantics of the
> atomics don't change at all.
>
> Note that we could initially do this just for x86 and arm64), e.g. by
> having those explicitly include an 
> at the end of their .

How exactly do you want to do this incrementally?
I don't feel ready to shuffle all archs, but doing x86 in one patch
and then arm64 in another looks tractable.


> For architectures which can use the compiler's atomics, we can allow
> them to do so, skipping the redundant explicit instrumentation.
>
> Other than being potentially slower (which we've established we don't
> care too much about above), is there a problem with that approach?

RFC: SysRq nice-all-RT-tasks is broken

[Laurent Dufour]

Hi,

It appears that triggering the SysRq nice-all-RT-tasks from the console
while a real task is active is leading to panic the system like this :

 sysrq: SysRq : Nice All RT Tasks
 [ cut here ]
 kernel BUG at /build/linux-twbIHf/linux-4.10.0/kernel/sched/core.c:4089!
 Oops: Exception in kernel mode, sig: 5 [#1]
 SMP NR_CPUS=2048
 NUMA
 pSeries
 Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace
fscache pseries_rng vmx_crypto binfmt_misc dm_multipath scsi_dh_rdac
scsi_dh_emc scsi_dh_alua sunrpc ip_tables x_tables autofs4 btrfs xor
raid6_pq ses enclosure scsi_transport_sas crc32c_vpmsum mlx5_core be2net
ipr devlink
 CPU: 100 PID: 0 Comm: swapper/100 Not tainted 4.10.0-8-generic #10-Ubuntu
 task: c003b6179c00 task.stack: c003b620c000
 NIP: c01044f0 LR: c010e524 CTR: c06d0ec0
 REGS: c0077fc978d0 TRAP: 0700   Not tainted  (4.10.0-8-generic)
 MSR: 80029033 
   CR: 28002228  XER: 2001
 CFAR: c010e520 SOFTE: 0
 GPR00: c010e524 c0077fc97b50 c143c900 c0038785fa00
 GPR04: c0077fc97c00   
 GPR08:  0001  0406
 GPR12: 28002228 c7b58400 c003b620ff90 1ede2d80
 GPR16:    
 GPR20: 0001   
 GPR24:  c0077a0f8b50 0063 
 GPR28: c0038785fa00 c0077fc97c00  c0038785fa00
 NIP [c01044f0] __sched_setscheduler+0x90/0xd30
 LR [c010e524] normalize_rt_tasks+0x184/0x1c0
 Call Trace:
 [c0077fc97be0] [c010e524] normalize_rt_tasks+0x184/0x1c0
 [c0077fc97c60] [c06d0ee0] sysrq_handle_unrt+0x20/0x40
 [c0077fc97c80] [c06d1c98] __handle_sysrq+0xe8/0x280
 [c0077fc97d20] [c06eab38] hvc_poll+0x1c8/0x360
 [c0077fc97dc0] [c06ebd74] hvc_handle_interrupt+0x24/0x50
 [c0077fc97de0] [c01453d0] __handle_irq_event_percpu+0x90/0x2c0
 [c0077fc97ea0] [c0145638] handle_irq_event_percpu+0x38/0x90
 [c0077fc97ee0] [c01456f4] handle_irq_event+0x64/0xb0
 [c0077fc97f10] [c014add8] handle_fasteoi_irq+0xe8/0x290
 [c0077fc97f40] [c0143ebc] generic_handle_irq+0x4c/0x80
 [c0077fc97f60] [c00167b0] __do_irq+0x80/0x1d0
 [c0077fc97f90] [c0029414] call_do_irq+0x14/0x24
 [c003b620fa40] [c0016994] do_IRQ+0x94/0x140
 [c003b620fa80] [c0008be4] hardware_interrupt_common+0x114/0x120
 --- interrupt: 501 at plpar_hcall_norets+0x1c/0x28
 LR = check_and_cede_processor+0x34/0x50
 [c003b620fd70] [c003b620fe10] 0xc003b620fe10 (unreliable)
 [c003b620fdd0] [c095db50] shared_cede_loop+0x50/0x150
 [c003b620fe00] [c095accc] cpuidle_enter_state+0x16c/0x430
 [c003b620fe60] [c012c8bc] call_cpuidle+0x4c/0x90
 [c003b620fe80] [c012cce0] do_idle+0x2c0/0x330
 [c003b620ff00] [c012cfa8] cpu_startup_entry+0x38/0x50
 [c003b620ff30] [c0044180] start_secondary+0x330/0x370
 [c003b620ff90] [c000aa6c] start_secondary_prolog+0x10/0x14
 Instruction dump:
 7c7f1b78 7cb62b78 7cdb3378 2b8a0006 7d5507b4 419e0010 83440014 235a0063
 7f5a07b4 78290464 8129000c 552902ee <0b09> 2f95 419c04b8 2f950005
 ---[ end trace 891618fbca78ebe7 ]---

I got it on Power and on X86_64, but I guess it should happen in all
architectures.
Here are the steps to recreate it :
1. Create a RT task : sudo chrt -f 50 /bin/sleep 99
2. On the console trigger the 'nice-all-RT-tasks' SYS-RQ.

The panic is triggered by the BUG_ON(in_interrupt()) introduced by this
commit:

66e5393a78b3 ("[PATCH] BUG() if setscheduler is called from interrupt
context")

Since SysRq is run from the interrupt context, the panic is expected.

Looking at the code, I'm wondering if the BUG_ON() is still required in
__sched_setscheduler(). But I'm not so confident, so requesting your
advise here.

Thanks,
Laurent.

[GIT PULL][PATCH 1/2] ktest: Fix while loop in wait_for_input

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The run_command function was changed to use the wait_for_input function to
allow having a timeout if the command to run takes too much time. There was
a bug in the wait_for_input where it could end up going into an infinite
loop. There's two issues here. One is that the return value of the sysread
wasn't used for the write (to write a proper size), and that it should
continue processing the passed in file descriptor too even if there was
input. There was no check for error, if for some reason STDIN returned an
error, the function would go into an infinite loop and never exit.

Reported-by: Greg Kroah-Hartman 
Tested-by: Greg Kroah-Hartman 
Fixes: 6e98d1b4415f ("ktest: Add timeout to ssh command")
Signed-off-by: Steven Rostedt (VMware) 
---
 tools/testing/ktest/ktest.pl | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 29470b554711..0c006a2f165d 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1904,11 +1904,12 @@ sub wait_for_input
 
# copy data from stdin to the console
if (vec($rout, fileno(\*STDIN), 1) == 1) {
-   sysread(\*STDIN, $buf, 1000);
-   syswrite($fp, $buf, 1000);
-   next;
+   $nr = sysread(\*STDIN, $buf, 1000);
+   syswrite($fp, $buf, $nr) if ($nr > 0);
}
 
+   next if (vec($rout, fileno($fp), 1) != 1);
+
$line = "";
 
# try to read one char at a time
-- 
2.10.2

[GIT PULL][PATCH 2/2] ktest: Make sure wait_for_input does honor the timeout

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The function wait_for_input takes in a timeout, and even has a default
timeout. But if for some reason the STDIN descriptor keeps sending in data,
the function will never time out. The timout is to wait for the data from
the passed in file descriptor, not for STDIN. Adding a test in the case
where there's no data from the passed in file descriptor that checks to see
if the timeout passed, will ensure that it will timeout properly even if
there's input in STDIN.

Signed-off-by: Steven Rostedt (VMware) 
---
 tools/testing/ktest/ktest.pl | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 0c006a2f165d..49f7c8b9d9c4 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1880,6 +1880,7 @@ sub get_grub_index {
 sub wait_for_input
 {
 my ($fp, $time) = @_;
+my $start_time;
 my $rin;
 my $rout;
 my $nr;
@@ -1895,12 +1896,12 @@ sub wait_for_input
 vec($rin, fileno($fp), 1) = 1;
 vec($rin, fileno(\*STDIN), 1) = 1;
 
+$start_time = time;
+
 while (1) {
$nr = select($rout=$rin, undef, undef, $time);
 
-   if ($nr <= 0) {
-   return undef;
-   }
+   last if ($nr <= 0);
 
# copy data from stdin to the console
if (vec($rout, fileno(\*STDIN), 1) == 1) {
@@ -1908,7 +1909,11 @@ sub wait_for_input
syswrite($fp, $buf, $nr) if ($nr > 0);
}
 
-   next if (vec($rout, fileno($fp), 1) != 1);
+   # The timeout is based on time waiting for the fp data
+   if (vec($rout, fileno($fp), 1) != 1) {
+   last if (defined($time) && (time - $start_time > $time));
+   next;
+   }
 
$line = "";
 
@@ -1918,12 +1923,11 @@ sub wait_for_input
last if ($ch eq "\n");
}
 
-   if (!length($line)) {
-   return undef;
-   }
+   last if (!length($line));
 
return $line;
 }
+return undef;
 }
 
 sub reboot_to {
-- 
2.10.2

Re: [RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> DMA access to memory mapped as encrypted while SEV is active can not be
> encrypted during device write or decrypted during device read. In order
> for DMA to properly work when SEV is active, the swiotlb bounce buffers
> must be used.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/mem_encrypt.c |   77 
> +
>  1 file changed, 77 insertions(+)
> 
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 090419b..7df5f4c 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -197,8 +197,81 @@ void __init sme_early_init(void)
>   /* Update the protection map with memory encryption mask */
>   for (i = 0; i < ARRAY_SIZE(protection_map); i++)
>   protection_map[i] = pgprot_encrypted(protection_map[i]);
> +
> + if (sev_active())
> + swiotlb_force = SWIOTLB_FORCE;
> +}
> +
> +static void *sme_alloc(struct device *dev, size_t size, dma_addr_t 
> *dma_handle,
> +gfp_t gfp, unsigned long attrs)
> +{
> + unsigned long dma_mask;
> + unsigned int order;
> + struct page *page;
> + void *vaddr = NULL;
> +
> + dma_mask = dma_alloc_coherent_mask(dev, gfp);
> + order = get_order(size);
> +
> + gfp &= ~__GFP_ZERO;

Please add a comment around here that swiotlb_alloc_coherent() will
memset(, 0, ) the memory. It took me a while to figure out what the
situation is.

Also, Joerg says the __GFP_ZERO is not absolutely necessary but it has
not been fixed in the other DMA alloc* functions because of fears that
something would break. That bit could also be part of the comment.

> +
> + page = alloc_pages_node(dev_to_node(dev), gfp, order);
> + if (page) {
> + dma_addr_t addr;
> +
> + /*
> +  * Since we will be clearing the encryption bit, check the
> +  * mask with it already cleared.
> +  */
> + addr = phys_to_dma(dev, page_to_phys(page)) & ~sme_me_mask;
> + if ((addr + size) > dma_mask) {
> + __free_pages(page, get_order(size));
> + } else {
> + vaddr = page_address(page);
> + *dma_handle = addr;
> + }
> + }
> +
> + if (!vaddr)
> + vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
> +
> + if (!vaddr)
> + return NULL;
> +
> + /* Clear the SME encryption bit for DMA use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, *dma_handle))) {
> + set_memory_decrypted((unsigned long)vaddr, 1 << order);
> + *dma_handle &= ~sme_me_mask;
> + }
> +
> + return vaddr;
>  }
>  
> +static void sme_free(struct device *dev, size_t size, void *vaddr,
> +  dma_addr_t dma_handle, unsigned long attrs)
> +{
> + /* Set the SME encryption bit for re-use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, dma_handle)))
> + set_memory_encrypted((unsigned long)vaddr,
> +  1 << get_order(size));
> +
> + swiotlb_free_coherent(dev, size, vaddr, dma_handle);
> +}
> +
> +static struct dma_map_ops sme_dma_ops = {

WARNING: struct dma_map_ops should normally be const
#112: FILE: arch/x86/mm/mem_encrypt.c:261:
+static struct dma_map_ops sme_dma_ops = {

Please integrate scripts/checkpatch.pl in your patch creation workflow.
Some of the warnings/errors *actually* make sense.


> + .alloc  = sme_alloc,
> + .free   = sme_free,
> + .map_page   = swiotlb_map_page,
> + .unmap_page = swiotlb_unmap_page,
> + .map_sg = swiotlb_map_sg_attrs,
> + .unmap_sg   = swiotlb_unmap_sg_attrs,
> + .sync_single_for_cpu= swiotlb_sync_single_for_cpu,
> + .sync_single_for_device = swiotlb_sync_single_for_device,
> + .sync_sg_for_cpu= swiotlb_sync_sg_for_cpu,
> + .sync_sg_for_device = swiotlb_sync_sg_for_device,
> + .mapping_error  = swiotlb_dma_mapping_error,
> +};
> +
>  /* Architecture __weak replacement functions */
>  void __init mem_encrypt_init(void)
>  {
> @@ -208,6 +281,10 @@ void __init mem_encrypt_init(void)
>   /* Call into SWIOTLB to update the SWIOTLB DMA buffers */
>   swiotlb_update_mem_attributes();
>  
> + /* Use SEV DMA operations if SEV is active */

That's obvious. The WHY is not.

> + if (sev_active())
> + dma_ops = _dma_ops;
> +
>   pr_info("AMD Secure Memory Encryption (SME) active\n");
>  }
>  
> 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
 wrote:
> This is v6 of this series. The five previous submissions can be found
> here [1], here [2], here[3], here[4], and here[5]. This version addresses
> the comments received in v4 plus improvements of the handling of emulation
> in 64-bit builds. Please see details in the change log.
>

Hi Ingo and Thomas-

I think this series is in good enough shape that you should consider
making a topic branch (x86/umip?) for it so that it can soak in -next
and further development can be done incrementally.  In the unlikely
event that a major problem shows up, you could skip the pull request
to Linus for a cycle.

--Andy

Re: [v6 PATCH 15/21] x86/mm: Relocate page fault error codes to traps.h

[Andy Lutomirski]

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
 wrote:
> Up to this point, only fault.c used the definitions of the page fault error
> codes. Thus, it made sense to keep them within such file. Other portions of
> code might be interested in those definitions too. For instance, the User-
> Mode Instruction Prevention emulation code will use such definitions to
> emulate a page fault when it is unable to successfully copy the results
> of the emulated instructions to user space.
>
> While relocating the error code enumeration, the prefix X86_ is used to
> make it consistent with the rest of the definitions in traps.h. Of course,
> code using the enumeration had to be updated as well. No functional changes
> were performed.
>

Reviewed-by: Andy Lutomirski 

Re: [GIT PULL][PATCH 0/2] ktest: Fixes for 4.11

[Steven Rostedt]

On Wed, 08 Mar 2017 10:55:21 -0500
Steven Rostedt  wrote:

> Linus,
> 
> Greg Kroah-Hartman reported to me that the ktest of v4.10 locked up in an

That should have been v4.11-rc1.

-- Steve

[PATCH v5 15/19] usb: gadget: amd5536udc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/usb/gadget/udc/amd5536udc.c | 8 
 drivers/usb/gadget/udc/amd5536udc.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/amd5536udc.c 
b/drivers/usb/gadget/udc/amd5536udc.c
index ea03ca7..270876b 100644
--- a/drivers/usb/gadget/udc/amd5536udc.c
+++ b/drivers/usb/gadget/udc/amd5536udc.c
@@ -583,7 +583,7 @@ udc_alloc_request(struct usb_ep *usbep, gfp_t gfp)
 
if (ep->dma) {
/* ep0 in requests are allocated from data pool here */
-   dma_desc = pci_pool_alloc(ep->dev->data_requests, gfp,
+   dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
>td_phys);
if (!dma_desc) {
kfree(req);
@@ -622,7 +622,7 @@ static int udc_free_dma_chain(struct udc *dev, struct 
udc_request *req)
td = phys_to_virt(td_last->next);
 
for (i = 1; i < req->chain_len; i++) {
-   pci_pool_free(dev->data_requests, td,
+   dma_pool_free(dev->data_requests, td,
  (dma_addr_t)td_last->next);
td_last = td;
td = phys_to_virt(td_last->next);
@@ -652,7 +652,7 @@ udc_free_request(struct usb_ep *usbep, struct usb_request 
*usbreq)
if (req->chain_len > 1)
udc_free_dma_chain(ep->dev, req);
 
-   pci_pool_free(ep->dev->data_requests, req->td_data,
+   dma_pool_free(ep->dev->data_requests, req->td_data,
req->td_phys);
}
kfree(req);
@@ -847,7 +847,7 @@ static int udc_create_dma_chain(
for (i = buf_len; i < bytes; i += buf_len) {
/* create or determine next desc. */
if (create_new_chain) {
-   td = pci_pool_alloc(ep->dev->data_requests,
+   td = dma_pool_alloc(ep->dev->data_requests,
gfp_flags, _addr);
if (!td)
return -ENOMEM;
diff --git a/drivers/usb/gadget/udc/amd5536udc.h 
b/drivers/usb/gadget/udc/amd5536udc.h
index 4638d70..85d5aa5 100644
--- a/drivers/usb/gadget/udc/amd5536udc.h
+++ b/drivers/usb/gadget/udc/amd5536udc.h
@@ -545,8 +545,8 @@ struct udc {
u32 __iomem *txfifo;
 
/* DMA desc pools */
-   struct pci_pool *data_requests;
-   struct pci_pool *stp_requests;
+   struct dma_pool *data_requests;
+   struct dma_pool *stp_requests;
 
/* device data */
unsigned long   phys_addr;
-- 
2.9.3

Re: [PATCH] futex: move debug_rt_mutex_free_waiter() further down

[Steven Rostedt]

On Wed, 8 Mar 2017 16:37:32 +0100
Sebastian Andrzej Siewior  wrote:

> On 2017-03-08 16:29:02 [+0100], To Peter Zijlstra wrote:
> > Without this, futex_requeue_pi_signal_restart will trigger
> > 
> > |kernel BUG at locking/rtmutex_common.h:55!
> > |Call Trace:
> > | rt_mutex_cleanup_proxy_lock+0x54/0x90
> > | futex_wait_requeue_pi.constprop.21+0x387/0x4d0
> > | do_futex+0x289/0xbf0
> > |RIP: remove_waiter+0x157/0x170 RSP: c9e0fbe0
> > 
> > with BUG  != pointer once this patch is applied.  
> 
> My wording is wrong. This BUG_ON() statement described here in this
> patch (together with the test case mentioned) will trigger once
> 
>  "[PATCH -v5 12/14] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()"
> 
> is applied.
>

Now I read this. Ignore my last email.

-- Steve

[PATCH v5 02/19] dmaengine: pch_dma: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/dma/pch_dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index f9028e9..afd8f27 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -123,7 +123,7 @@ struct pch_dma_chan {
 struct pch_dma {
struct dma_device   dma;
void __iomem *membase;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct pch_dma_regs regs;
struct pch_dma_desc_regs ch_regs[MAX_CHAN_NR];
struct pch_dma_chan channels[MAX_CHAN_NR];
@@ -437,7 +437,7 @@ static struct pch_dma_desc *pdc_alloc_desc(struct dma_chan 
*chan, gfp_t flags)
struct pch_dma *pd = to_pd(chan->device);
dma_addr_t addr;
 
-   desc = pci_pool_zalloc(pd->pool, flags, );
+   desc = dma_pool_zalloc(pd->pool, flags, );
if (desc) {
INIT_LIST_HEAD(>tx_list);
dma_async_tx_descriptor_init(>txd, chan);
@@ -549,7 +549,7 @@ static void pd_free_chan_resources(struct dma_chan *chan)
spin_unlock_irq(_chan->lock);
 
list_for_each_entry_safe(desc, _d, _list, desc_node)
-   pci_pool_free(pd->pool, desc, desc->txd.phys);
+   dma_pool_free(pd->pool, desc, desc->txd.phys);
 
pdc_enable_irq(chan, 0);
 }
@@ -880,7 +880,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
goto err_iounmap;
}
 
-   pd->pool = pci_pool_create("pch_dma_desc_pool", pdev,
+   pd->pool = dma_pool_create("pch_dma_desc_pool", >dev,
   sizeof(struct pch_dma_desc), 4, 0);
if (!pd->pool) {
dev_err(>dev, "Failed to alloc DMA descriptors\n");
@@ -931,7 +931,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
return 0;
 
 err_free_pool:
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
 err_free_irq:
free_irq(pdev->irq, pd);
 err_iounmap:
@@ -963,7 +963,7 @@ static void pch_dma_remove(struct pci_dev *pdev)
tasklet_kill(_chan->tasklet);
}
 
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
pci_iounmap(pdev, pd->membase);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3

[PATCH v5 04/19] net: e100: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/intel/e100.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 2b7323d..d1002c2 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -607,7 +607,7 @@ struct nic {
struct mem *mem;
dma_addr_t dma_addr;
 
-   struct pci_pool *cbs_pool;
+   struct dma_pool *cbs_pool;
dma_addr_t cbs_dma_addr;
u8 adaptive_ifs;
u8 tx_threshold;
@@ -1892,7 +1892,7 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
-   pci_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
+   dma_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1910,7 +1910,7 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
 
-   nic->cbs = pci_pool_alloc(nic->cbs_pool, GFP_KERNEL,
+   nic->cbs = dma_pool_alloc(nic->cbs_pool, GFP_KERNEL,
  >cbs_dma_addr);
if (!nic->cbs)
return -ENOMEM;
@@ -2958,8 +2958,8 @@ static int e100_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
netif_err(nic, probe, nic->netdev, "Cannot register net device, 
aborting\n");
goto err_out_free;
}
-   nic->cbs_pool = pci_pool_create(netdev->name,
-  nic->pdev,
+   nic->cbs_pool = dma_pool_create(netdev->name,
+  >pdev->dev,
   nic->params.cbs.max * sizeof(struct cb),
   sizeof(u32),
   0);
@@ -2999,7 +2999,7 @@ static void e100_remove(struct pci_dev *pdev)
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
-   pci_pool_destroy(nic->cbs_pool);
+   dma_pool_destroy(nic->cbs_pool);
free_netdev(netdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Kishon Vijay Abraham I]

Hi,

On Friday 17 February 2017 10:50 PM, Joao Pinto wrote:
> Às 9:50 AM de 2/17/2017, Kishon Vijay Abraham I escreveu:
>> Add endpoint mode support to designware driver. This uses the
>> EP Core layer introduced recently to add endpoint mode support.
>> *Any* function driver can now use this designware device
>> in order to achieve the EP functionality.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/pci/dwc/Kconfig  |5 +
>>  drivers/pci/dwc/Makefile |1 +
>>  drivers/pci/dwc/pcie-designware-ep.c |  342 
>> ++
>>  drivers/pci/dwc/pcie-designware.c|   51 +
>>  drivers/pci/dwc/pcie-designware.h|   72 +++
>>  5 files changed, 471 insertions(+)
>>  create mode 100644 drivers/pci/dwc/pcie-designware-ep.c
>>
>> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
>> index dfb8a69..00335c7 100644
>> --- a/drivers/pci/dwc/Kconfig
>> +++ b/drivers/pci/dwc/Kconfig
>> @@ -9,6 +9,11 @@ config PCIE_DW_HOST
>>  depends on PCI_MSI_IRQ_DOMAIN
>>  select PCIE_DW
>>  
>> +config PCIE_DW_EP
>> +bool
>> +depends on PCI_ENDPOINT
>> +select PCIE_DW
>> +
>>  config PCI_DRA7XX
>>  bool "TI DRA7xx PCIe controller"
>>  depends on PCI
>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>> index a2df13c..b38425d 100644
>> --- a/drivers/pci/dwc/Makefile
>> +++ b/drivers/pci/dwc/Makefile
>> @@ -1,5 +1,6 @@
>>  obj-$(CONFIG_PCIE_DW) += pcie-designware.o
>>  obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
>> +obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
>>  obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
>>  obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
>>  obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
>> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
>> b/drivers/pci/dwc/pcie-designware-ep.c
>> new file mode 100644
>> index 000..e465c5e
>> --- /dev/null
>> +++ b/drivers/pci/dwc/pcie-designware-ep.c
>> @@ -0,0 +1,342 @@
>> +/**
>> + * Synopsys Designware PCIe Endpoint controller driver
>> + *
>> + * Copyright (C) 2017 Texas Instruments
>> + * Author: Kishon Vijay Abraham I 
>> + *
>> + * This program is free software: you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 of
>> + * the License 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see 
>> >  >.
>> + */
>> +
>> +#include 
>> +
>> +#include "pcie-designware.h"
>> +#include 
>> +#include 
>> +
>> +void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
>> +{
>> +struct pci_epc *epc = ep->epc;
>> +struct pci_epf *epf;
>> +
>> +list_for_each_entry(epf, >pci_epf, list)
>> +pci_epf_linkup(epf);
>> +}
>> +
>> +static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
>> +{
>> +u32 reg;
>> +
>> +reg = PCI_BASE_ADDRESS_0 + (4 * bar);
>> +dw_pcie_write_dbi(pci, pci->dbi_base2, reg, 0x4, 0x0);
>> +dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x4, 0x0);
>> +}
>> +
>> +static int dw_pcie_ep_write_header(struct pci_epc *epc,
>> +   struct pci_epf_header *hdr)
>> +{
>> +struct dw_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> +void __iomem *base = pci->dbi_base;
>> +
>> +dw_pcie_write_dbi(pci, base, PCI_VENDOR_ID, 0x2, hdr->vendorid);
>> +dw_pcie_write_dbi(pci, base, PCI_DEVICE_ID, 0x2, hdr->deviceid);
>> +dw_pcie_write_dbi(pci, base, PCI_REVISION_ID, 0x1, hdr->revid);
>> +dw_pcie_write_dbi(pci, base, PCI_CLASS_PROG, 0x1, hdr->progif_code);
>> +dw_pcie_write_dbi(pci, base, PCI_CLASS_DEVICE, 0x2,
>> +  hdr->subclass_code | hdr->baseclass_code << 8);
>> +dw_pcie_write_dbi(pci, base, PCI_CACHE_LINE_SIZE, 0x1,
>> +  hdr->cache_line_size);
>> +dw_pcie_write_dbi(pci, base, PCI_SUBSYSTEM_VENDOR_ID, 0x2,
>> +  hdr->subsys_vendor_id);
>> +dw_pcie_write_dbi(pci, base, PCI_SUBSYSTEM_ID, 0x2, hdr->subsys_id);
>> +dw_pcie_write_dbi(pci, base, PCI_INTERRUPT_PIN, 0x1,
>> +  hdr->interrupt_pin);
>> +
>> +return 0;
>> +}
>> +
>> +static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
>> +  dma_addr_t cpu_addr,
>> +  enum 

Re: [PATCH] platform/x86: dell-laptop: Handle return error form dell_get_intensity.

[Pali Rohár]

Hi!

On Wednesday 08 March 2017 17:52:27 Arvind Yadav wrote:
> Here, dell_get_intensity can return an error.

Right. That is truth and we should check for errors.

> So we can assgine props.brightness as max_brightness.

But why to max_brightness? Seems that this is incorrect handling of
error too...

> This change is done using Coccinelle.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/platform/x86/dell-laptop.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index f57dd28..0891de3 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -2053,6 +2053,9 @@ static int __init dell_init(void)
>  
>   dell_backlight_device->props.brightness =
>   dell_get_intensity(dell_backlight_device);
> + if (dell_backlight_device->props.brightness < 0) {
> + dell_backlight_device->props.brightness = 
> props.max_brightness;
> + }
>   backlight_update_status(dell_backlight_device);
>   }
>  

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

Re: [PATCH v3 3/3] printk: fix double printing with earlycon

[Aleksey Makarov]

On 03/08/2017 06:33 AM, Sergey Senozhatsky wrote:

Hello,

sorry for the delay.

On (03/07/17 15:54), Aleksey Makarov wrote:

On 03/06/2017 03:59 PM, Sergey Senozhatsky wrote:

On (03/03/17 18:49), Aleksey Makarov wrote:
[..]

+static enum { CONSOLE_MATCH, CONSOLE_MATCH_RETURN, CONSOLE_MATCH_NEXT }
+match_console(struct console *newcon, struct console_cmdline *c)


that enum in function return is interesting :)
can we make it less hackish?

We probably can, but I can not figure out how to do that.
Suggestions will be appreciated.
We should signal 3 different outcomes.
I thought that using standard errnos is not quite desciptive.


no problems with the enum on its own. errnos probably can also do
the trick.

the way it's defined, however, is a bit unusual and may be
inconvenient - we can add, say, 5 more CONSOLE_MATCH_FOO someday
in the future and match_console() function definition thus will be:

static enum { CONSOLE_MATCH, CONSOLE_MATCH_RETURN, CONSOLE_MATCH_NEXT,
CONSOLE_MATCH_FOO1, CONSOLE_MATCH_FOO2,
CONSOLE_MATCH_FOO3, CONSOLE_MATCH_FOO4,
CONSOLE_MATCH_FOO5}
match_console(struct console *newcon, struct console_cmdline *c)
{
...
}

or something like this

static enum { CONSOLE_MATCH,
CONSOLE_MATCH_RETURN,
CONSOLE_MATCH_NEXT,
CONSOLE_MATCH_FOO1,
CONSOLE_MATCH_FOO2,
CONSOLE_MATCH_FOO3,
CONSOLE_MATCH_FOO4,
CONSOLE_MATCH_FOO5 }
match_console(struct console *newcon, struct console_cmdline *c)
{
..
}

or anything else. which is, to my admittedly imperfect taste, slightly
"unpretty".


I agree that this enum thing does not look good and I have an idea how to
get rid of it completely.  The idea is to factor out the braille
code to a separate pass.  That way the match function can return a boolean
value.


I am traveling now so I will need some time to
send a new version of this patch.

Thank you
Aleksey Makarov



[..]

+   /*
 *  See if this console matches one we selected on
 *  the command line.
 */
for (i = 0, c = console_cmdline;
 i < MAX_CMDLINECONSOLES && c->name[0];
 i++, c++) {
-   if (!newcon->match ||
-   newcon->match(newcon, c->name, c->index, c->options) != 0) {
-   /* default matching */
-   BUILD_BUG_ON(sizeof(c->name) != sizeof(newcon->name));
-   if (strcmp(c->name, newcon->name) != 0)
-   continue;
-   if (newcon->index >= 0 &&
-   newcon->index != c->index)
-   continue;
-   if (newcon->index < 0)
-   newcon->index = c->index;
-
-   if (_braille_register_console(newcon, c))
-   return;

-   if (newcon->setup &&
-   newcon->setup(newcon, c->options) != 0)
-   break;
-   }
+   if (preferred_console == i)
+   continue;

-   newcon->flags |= CON_ENABLED;
-   if (i == preferred_console) {
-   newcon->flags |= CON_CONSDEV;
-   has_preferred = true;
+   switch (match_console(newcon, c)) {
+   case CONSOLE_MATCH:
+   goto match;
+   case CONSOLE_MATCH_RETURN:
+   return;
+   default:
+   break;


sorry, it was a rather long for me today. need to look more at this.
for what is now CONSOLE_MATCH_NEXT we used to have continue,


CONSOLE_MATCH is for the case when the console matches against the description,
CONSOLE_MATCH_NEXT - it does not, we should try next,


my bad, sorry. I misread the patch: there was another `break' right after
that switch, that you have removed; and I just wrongly concluded that
CONSOLE_MATCH_NEXT would now 'break' from 'default' label *and* `break'
from the console_cmdline loop right after it.

bikeshedding:
may be explicit CONSOLE_MATCH_NEXT test will save us from problems (in
case if match_console() will return more codes someday), may be it won't.
hard to say. 'default: continue' is probably OK. or may be can do without
that 'match' label at all. something like this (_may be_)

for (i = 0, c = console_cmdline; ... ) {
if (preferred_console == i)
continue;

match = match_console(newcon, c);
if (match == CONSOLE_MATCH_NEXT)
continue;
if (match == CONSOLE_MATCH_FOUND)
break;
if (match == CONSOLE_MATCH_STOP)
return;
}
...



CONSOLE_MATCH_RETURN  -  basically means that we should stop matching.
can we thus rename it to 

Re: [PATCH 10/26] IB/ocrdma: Improve another size determination in ocrdma_init_emb_mqe()

[Devesh Sharma]

Acked-by: Devesh Sharma 

On Wed, Mar 8, 2017 at 7:52 PM, Yuval Shaia  wrote:
> On Wed, Mar 08, 2017 at 02:02:46PM +0100, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Tue, 7 Mar 2017 20:33:29 +0100
>>
>> Replace the specification of a data structure by a pointer dereference
>> as the parameter for the operator "sizeof" to make the corresponding size
>> determination a bit safer according to the Linux coding style convention.
>>
>> Signed-off-by: Markus Elfring 
>> ---
>>  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
>> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
>> index 7d1e1caa90de..aa32bc9f323d 100644
>> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
>> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
>> @@ -352,7 +352,7 @@ static void *ocrdma_init_emb_mqe(u8 opcode, u32 cmd_len)
>>  {
>>   struct ocrdma_mqe *mqe;
>>
>> - mqe = kzalloc(sizeof(struct ocrdma_mqe), GFP_KERNEL);
>> + mqe = kzalloc(sizeof(*mqe), GFP_KERNEL);
>>   if (!mqe)
>>   return NULL;
>>   mqe->hdr.spcl_sge_cnt_emb |=
>
> Reviewed-by: Yuval Shaia 
>
>> --
>> 2.12.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] zswap: Zero-filled pages handling

[Dan Streetman]

On Wed, Mar 8, 2017 at 6:47 AM, Srividya Desireddy
 wrote:
>
> On Sat, Mar 4, 2017 at 02:55 AM, Dan Streetman  wrote:
>> On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly
>>  wrote:
>>> On 25 February 2017 at 20:12, Srividya Desireddy
>>>  wrote:
 From: Srividya Desireddy 
 Date: Thu, 23 Feb 2017 15:04:06 +0530
 Subject: [PATCH] zswap: Zero-filled pages handling
>>
>> your email is base64-encoded; please send plain text emails.
>>

 Zswap is a cache which compresses the pages that are being swapped out
 and stores them into a dynamically allocated RAM-based memory pool.
 Experiments have shown that around 10-20% of pages stored in zswap
 are zero-filled pages (i.e. contents of the page are all zeros), but
>>
>> 20%?  that's a LOT of zero pages...which seems like applications are
>> wasting a lot of memory.  what kind of workload are you testing with?
>>
>
> I have tested this patch with different workloaded on different devices.
> On Ubuntu PC with 2GB RAM, while executing kernel build and other test
> scripts ~15% of pages in zswap were zero pages. With multimedia workload
> more than 20% of zswap pages were found to be zero pages.
> On a ARM Quad Core 32-bit device with 1.5GB RAM an average 10% of zero
> pages were found on launching and relaunching 15 applications.
>
 these pages are handled as normal pages by compressing and allocating
 memory in the pool.

 This patch adds a check in zswap_frontswap_store() to identify zero-filled
 page before compression of the page. If the page is a zero-filled page, set
 zswap_entry.zeroflag and skip the compression of the page and alloction
 of memory in zpool. In zswap_frontswap_load(), check if the zeroflag is
 set for the page in zswap_entry. If the flag is set, memset the page with
 zero. This saves the decompression time during load.

 The overall overhead caused to check for a zero-filled page is very minimal
 when compared to the time saved by avoiding compression and allocation in
 case of zero-filled pages. Although, compressed size of a zero-filled page
 is very less, with this patch load time of a zero-filled page is reduced by
 80% when compared to baseline.
>>>
>>> Is it possible to share the benchmark details?
>>
>> Was there an answer to this?
>>
>
> This patch is tested on a ARM Quad Core 32-bit device with 1.5GB RAM by
> launching and relaunching different applications. With the patch, an
> average of 5000 pages zero pages found in zswap out of the ~5 pages
> stored in zswap and application launch time improved by ~3%.
>
> Test Parameters BaselineWith patch  Improvement
> ---
> Total RAM   1343MB  1343MB
> Available RAM   451MB   445MB -6MB
> Avg. Memfree69MB70MB  1MB
> Avg. Swap Used  226MB   215MB -11MB
> Avg. App entry time 644msec 623msec   3%
>
> With patch, every page swapped to zswap is checked if it is a zero
> page or not and for all the zero pages compression and memory allocation
> operations are skipped. Overall there is an improvement of 30% in zswap
> store time.
> In case of non-zero pages there is no overhead during zswap page load. For
> zero pages there is a improvement of more than 60% in the zswap load time
> as the zero page decompression is avoided.
>
> The below table shows the execution time profiling of the patch.
>
> Zswap Store Operation BaselineWith patch  % Improvement
> --
> * Zero page check-- 22.5ms
>  (for non-zero pages)
> * Zero page check-- 24ms
>  (for zero pages)
> * Compression time  55ms --
>  (of zero pages)
> * Allocation time   14ms --
>  (to store compressed
>   zero pages)
> -
> Total   69ms46.5ms 32%
>
> Zswap Load Operation BaselineWith patch  % Improvement
> -
> * Decompression time  30.4ms--
>  (of zero pages)
> * Zero page check +-- 10.04ms
>  memset operation
>  (of zero pages)
> -
> Total 30.4ms  10.04ms   66%
>
> *The execution times may vary with test device used.
>
>>>
>>>

 Signed-off-by: Srividya Desireddy 
 ---
  mm/zswap.c |   48 +---
  1 file changed, 45 insertions(+), 3 deletions(-)

 diff --git a/mm/zswap.c b/mm/zswap.c
 index 067a0d6..a574008 100644
 --- a/mm/zswap.c
 +++ b/mm/zswap.c
 

Re: [PATCH 24/26] IB/ocrdma: One jump label less in ocrdma_alloc_ucontext_pd()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 7:00 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 11:11:35 +0100
>
> This issue was detected by using the Coccinelle software.
>
> 1. Return directly if a call of the function "_ocrdma_alloc_pd" failed.
>
> 2. Reduce the scope for the local variable "status" to one case
>of an if statement.
>
> 3. Delete the jump label "err" then.
>
> 4. Return zero as a constant at the end.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index ae0d343d1731..d3cb8e2f099f 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -484,19 +484,17 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev 
> *dev,
> struct ocrdma_ucontext *uctx,
> struct ib_udata *udata)
>  {
> -   int status = 0;
> -
> uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata);
> if (IS_ERR(uctx->cntxt_pd)) {
> -   status = PTR_ERR(uctx->cntxt_pd);
> +   int status = PTR_ERR(uctx->cntxt_pd);
> +
> uctx->cntxt_pd = NULL;
> -   goto err;
> +   return status;
> }
>
> uctx->cntxt_pd->uctx = uctx;
> uctx->cntxt_pd->ibpd.device = >ibdev;
> -err:
> -   return status;
> +   return 0;
>  }
>
>  static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx)
> --
> 2.12.0
>

RE: [PATCH V2] x86, perf: Add Top Down events to Intel Goldmont

[Liang, Kan]

Ping.
Any comments for this patch?

Thanks,
Kan

> 
> From: Kan Liang 
> 
> Goldmont supports full Top Down level 1 metrics (FrontendBound,
> Retiring, Backend Bound and Bad Speculation).
> It has 3 wide pipeline.
> 
> Signed-off-by: Kan Liang 
> ---
> 
> Changes since V1:
>  - Change event list style
> 
>  arch/x86/events/intel/core.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index eb1484c..4244bed 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -1553,6 +1553,27 @@ static __initconst const u64
> slm_hw_cache_event_ids
>   },
>  };
> 
> +EVENT_ATTR_STR(topdown-total-slots, td_total_slots_glm, "event=0x3c");
> +EVENT_ATTR_STR(topdown-total-slots.scale, td_total_slots_scale_glm, "3");
> +/* UOPS_NOT_DELIVERED.ANY */
> +EVENT_ATTR_STR(topdown-fetch-bubbles, td_fetch_bubbles_glm,
> "event=0x9c");
> +/* ISSUE_SLOTS_NOT_CONSUMED.RECOVERY */
> +EVENT_ATTR_STR(topdown-recovery-bubbles, td_recovery_bubbles_glm,
> "event=0xca,umask=0x02");
> +/* UOPS_RETIRED.ANY */
> +EVENT_ATTR_STR(topdown-slots-retired, td_slots_retired_glm,
> "event=0xc2");
> +/* UOPS_ISSUED.ANY */
> +EVENT_ATTR_STR(topdown-slots-issued, td_slots_issued_glm,
> "event=0x0e");
> +
> +static struct attribute *glm_events_attrs[] = {
> + EVENT_PTR(td_total_slots_glm),
> + EVENT_PTR(td_total_slots_scale_glm),
> + EVENT_PTR(td_fetch_bubbles_glm),
> + EVENT_PTR(td_recovery_bubbles_glm),
> + EVENT_PTR(td_slots_issued_glm),
> + EVENT_PTR(td_slots_retired_glm),
> + NULL
> +};
> +
>  static struct extra_reg intel_glm_extra_regs[] __read_mostly = {
>   /* must define OFFCORE_RSP_X first, see intel_fixup_er() */
>   INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0,
> 0x760005ffbfull, RSP_0),
> @@ -3750,6 +3771,7 @@ __init int intel_pmu_init(void)
>   x86_pmu.pebs_prec_dist = true;
>   x86_pmu.lbr_pt_coexist = true;
>   x86_pmu.flags |= PMU_FL_HAS_RSP_1;
> + x86_pmu.cpu_events = glm_events_attrs;
>   pr_cont("Goldmont events, ");
>   break;
> 
> --
> 2.4.3

Re: [PATCH 15/26] IB/ocrdma: Delete an error message for a failed memory allocation in ocrdma_add()

[Devesh Sharma]

Acked-By: Devesh sharma 

On Wed, Mar 8, 2017 at 6:43 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 7 Mar 2017 22:23:17 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_main.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> index c49b4491d4e7..93113feeb2d5 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> @@ -304,10 +304,9 @@ static struct ocrdma_dev *ocrdma_add(struct be_dev_info 
> *dev_info)
> struct ocrdma_dev *dev;
>
> dev = (struct ocrdma_dev *)ib_alloc_device(sizeof(*dev));
> -   if (!dev) {
> -   pr_err("Unable to allocate ib device\n");
> +   if (!dev)
> return NULL;
> -   }
> +
> dev->mbx_cmd = kzalloc(sizeof(struct ocrdma_mqe_emb_cmd), GFP_KERNEL);
> if (!dev->mbx_cmd)
> goto idr_err;
> --
> 2.12.0
>

Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

[Johannes Thumshirn]

On 03/08/2017 02:48 PM, Reshetova, Elena wrote:

On 03/06/2017 03:21 PM, Elena Reshetova wrote:

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.


The subject is wrong, should be something like "scsi: libfc convert
fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.

Other than that
Acked-by: Johannes Thumshirn 


Turns out that it is better that all these patches go through the respective 
maintainer trees, if present.
If I send an updated patch (with subject fixed), could you merge it through 
your tree?


Yes, but this would be the normal scsi tree from Martin and James.

Please include my Ack in the re-sends.

Thanks a lot,
Johannes


--
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH v2 1/2] net: sched: make default fifo qdiscs appear in the dump

[Eric Dumazet]

On Wed, 2017-03-08 at 13:03 +0100, Jiri Kosina wrote:


> +++ b/net/sched/sch_qfq.c
> @@ -494,6 +494,8 @@ static int qfq_change_class(struct Qdisc *sch, u32 
> classid, u32 parentid,
>   goto destroy_class;
>   }
>  
> + if (cl->qdisc != _qdisc)
> + qdisc_hash_add(cl->qdisc, true);


Please move the test in qdisc_hash_add() instead of copy/pasting it all
over the places ?

This is control path, keep it small, thanks !

Re: [PATCH 0/2] ARM: dts: socfpga: Add support for PMU on Arria5/Cyclone5

[Dinh Nguyen]

On 02/28/2017 09:52 AM, Florian Vaussard wrote:
> Hi,
> 
> These patches add suport for ARM Performance Monitor Units on Arria5 and
> Cyclone5 SoCFPGA. This was tested on a Cyclone 5 SoC DK board.
> 
> Side note: the same change can be probably applied to Arria10 as well,
> but we do not have the hardware here to test.
> 
> Regards,
> Florian
> 
> Florian Vaussard (2):
>   ARM: dts: socfpga: Add labels for CPU nodes
>   ARM: dts: socfpga: Add support for PMU
> 
>  arch/arm/boot/dts/socfpga.dtsi | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 

Applied!

Thanks,

Dinh

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

[Uladzislau Rezki]

Hello.

Let's decide how to proceed with https://lkml.org/lkml/2017/2/14/334 patch.
Despite it is not a big change, i think it is important and ready to
be submited,
unless there are still any comments.

--
Uladzislau Rezki

On Thu, Feb 16, 2017 at 12:20 PM, Uladzislau Rezki  wrote:
> On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann
>  wrote:
>> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote:
>
>
> So that is useful information that should have been in the Changelog.
>
> OK, can you respin this patch with adjusted Changelog and taking Mike's
> feedback?
>
 Yes, i will prepare a patch accordingly, no problem.

>
> Also, I worry about the effects of this on !PREEMPT kernels, the first
> hunk (which explicitly states is about latency) should be under
> CONFIG_PREEMPT to match the similar case we already have in
> detach_tasks().
>>
>>
>> This one uses #ifdef CONFIG_PREEMPT whereas you use
>> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this?
>>
> I just wanted to put it under one line instead of using #ifdefs in my
> second hunk,
> so that is a matter of taste. Also, please find below different
> variants of how it can be
> rewriten:
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE)
> #endif
> if ((load / 2) > env->imbalance)
> goto next;
> 
>
> 
> #ifdef CONFIG_PREEMPT
> if (env->idle != CPU_NEWLY_IDLE &&
> (load / 2) > env->imbalance)
> goto next;
> #else
> if ((load / 2) > env->imbalance)
> goto next;
> #endif
> 
>
> If somebody has any preferences or concerns, please comment, i will
> re-spin the patch.
>
> --
> Uladzislau Rezki

Re: [PATCH 1/2] reset: add reset-simple to unify socfpga, stm32, and sunxi

[Andre Przywara]

Hi,

On 08/03/17 12:20, Philipp Zabel wrote:
> On Wed, 2017-03-08 at 12:05 +0100, Alexandre Torgue wrote:
>> Hi Philipp,
>>
>> On 03/08/2017 11:19 AM, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 08/03/17 09:54, Philipp Zabel wrote:
 Reset operations for simple reset controllers with reset lines that can
 be controlled by toggling bits in (mostly) contiguous register ranges
 using read-modify-write cycles under a spinlock. So far this covers the
 socfpga, stm32, and sunxi drivers.
>>>
>>> Wow, that looks nice, thanks for that.
>>>
>>> But can't we go one step further and unify those driver into one file then?
>>> And either have different probe functions to cover the different DT
>>> requirements or to just have one unified probe checking for the super
>>> set of all properties?
>>
>> I agree with Andre. It looks nice and it should be a good thing to have 
>> a common probe inside reset-simple.c
>> Maybe only "nresets" and "inverted"  DT properties are needed.
> 
> Adding DT properties is not an option, as the driver would have to work
> with the existing bindings. We could merge them into one file, with a
> single probe function that configures different parameters depending on
> the of_device_id returned by of_match_device.

Yes, either that or we could just parse all possible properties, as
allowing additional properties on top of the documented binding doc
shouldn't hurt, I think. That's what I mean with super-set. I have to
check if this is acceptable, though.

And I think it would be worthwhile to create a generic binding (or at
least a generic compatible string) on the way, specifying all the
existing properties there, so new drivers could just use that without
having to add their own compatible string to the *driver* (but just to
the binding doc). This would have the advantage of new SoCs possibly
being supported without actual kernel changes.

Cheers,
Andre.

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Kishon Vijay Abraham I]

Hi,

On Wednesday 08 March 2017 05:07 PM, Joao Pinto wrote:
> Às 11:35 AM de 3/8/2017, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Wednesday 08 March 2017 05:02 PM, Joao Pinto wrote:
>>>
>>> Hi Kishon,
>>>
> Can you provide PCIE_GET_ATU_INB_UNR_REG_OFFSET (similar to
> PCIE_GET_ATU_OUTB_UNR_REG_OFFSET)?

 Yes of course, I will send you the definition soon.
>>>
>>> As promissed here is the definition for Inbound:
>>>
>>> +/* register address builder */
>>> +#define PCIE_GET_ATU_INB_UNR_REG_ADDR(region, register)\
>>> +   ((0x3 << 20) | (region << 9) |  \
>>> +   (0x1 << 8) | (register << 2))
>>
>> Cool, thanks!
> 
> No problem! If you have doubts, please let me know.

Okay, so this looks slightly different than the outbound macro since it takes
the register argument. In the case of outbound PCIE_GET_ATU_OUTB_UNR_REG_OFFSET
returns the offset which was used like
dw_pcie_write_dbi(pci, base, offset + reg, 0x4, val);

How should the value from PCIE_GET_ATU_INB_UNR_REG_ADDR be used?

Thanks
Kishon

[PATCH v5 10/19] scsi: lpfc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
some comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/lpfc/lpfc.h   |  14 +++---
 drivers/scsi/lpfc/lpfc_init.c  |  16 +++
 drivers/scsi/lpfc/lpfc_mem.c   | 106 -
 drivers/scsi/lpfc/lpfc_nvme.c  |   6 +--
 drivers/scsi/lpfc/lpfc_nvmet.c |   4 +-
 drivers/scsi/lpfc/lpfc_scsi.c  |  12 ++---
 6 files changed, 77 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 257bbdd..c6f82db 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -935,13 +935,13 @@ struct lpfc_hba {
struct list_head active_rrq_list;
spinlock_t hbalock;
 
-   /* pci_mem_pools */
-   struct pci_pool *lpfc_sg_dma_buf_pool;
-   struct pci_pool *lpfc_mbuf_pool;
-   struct pci_pool *lpfc_hrb_pool; /* header receive buffer pool */
-   struct pci_pool *lpfc_drb_pool; /* data receive buffer pool */
-   struct pci_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
-   struct pci_pool *txrdy_payload_pool;
+   /* dma_mem_pools */
+   struct dma_pool *lpfc_sg_dma_buf_pool;
+   struct dma_pool *lpfc_mbuf_pool;
+   struct dma_pool *lpfc_hrb_pool; /* header receive buffer pool */
+   struct dma_pool *lpfc_drb_pool; /* data receive buffer pool */
+   struct dma_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
+   struct dma_pool *txrdy_payload_pool;
struct lpfc_dma_pool lpfc_mbuf_safety_pool;
 
mempool_t *mbox_mem_pool;
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 661bd25..4569350 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3151,7 +3151,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_put,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3162,7 +3162,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_get,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3193,7 +3193,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_put, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3204,7 +3204,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_get, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3517,7 +3517,7 @@ lpfc_sli4_scsi_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, psb,
 struct lpfc_scsi_buf, list);
if (psb) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  psb->data, psb->dma_handle);
kfree(psb);
}
@@ -3652,7 +3652,7 @@ lpfc_sli4_nvme_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, lpfc_ncmd,
 struct lpfc_nvme_buf, list);
if (lpfc_ncmd) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
@@ -6673,8 +6673,8 @@ lpfc_create_shost(struct 

[PATCH v5 13/19] scsi: mvsas: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mvsas/mv_init.c | 6 +++---
 drivers/scsi/mvsas/mv_sas.c  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 8280046..41d2276 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -125,8 +125,7 @@ static void mvs_free(struct mvs_info *mvi)
else
slot_nr = MVS_CHIP_SLOT_SZ;
 
-   if (mvi->dma_pool)
-   pci_pool_destroy(mvi->dma_pool);
+   dma_pool_destroy(mvi->dma_pool);
 
if (mvi->tx)
dma_free_coherent(mvi->dev,
@@ -296,7 +295,8 @@ static int mvs_alloc(struct mvs_info *mvi, struct Scsi_Host 
*shost)
goto err_out;
 
sprintf(pool_name, "%s%d", "mvs_dma_pool", mvi->id);
-   mvi->dma_pool = pci_pool_create(pool_name, mvi->pdev, MVS_SLOT_BUF_SZ, 
16, 0);
+   mvi->dma_pool = dma_pool_create(pool_name, >pdev->dev,
+   MVS_SLOT_BUF_SZ, 16, 0);
if (!mvi->dma_pool) {
printk(KERN_DEBUG "failed to create dma pool %s.\n", 
pool_name);
goto err_out;
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..ee81d10 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -790,7 +790,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
slot->n_elem = n_elem;
slot->slot_tag = tag;
 
-   slot->buf = pci_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
+   slot->buf = dma_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
if (!slot->buf) {
rc = -ENOMEM;
goto err_out_tag;
@@ -840,7 +840,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
return rc;
 
 err_out_slot_buf:
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
 err_out_tag:
mvs_tag_free(mvi, tag);
 err_out:
@@ -918,7 +918,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi, struct 
sas_task *task,
}
 
if (slot->buf) {
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
slot->buf = NULL;
}
list_del_init(>entry);
-- 
2.9.3

[PATCH v5 12/19] scsi: mpt3sas: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 73 +
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5b7aec5..5ae1c23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3200,9 +3200,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->sense) {
-   pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
-   if (ioc->sense_dma_pool)
-   pci_pool_destroy(ioc->sense_dma_pool);
+   dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
+   dma_pool_destroy(ioc->sense_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"sense_pool(0x%p): free\n",
ioc->name, ioc->sense));
@@ -3210,9 +3209,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply) {
-   pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
-   if (ioc->reply_dma_pool)
-   pci_pool_destroy(ioc->reply_dma_pool);
+   dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
+   dma_pool_destroy(ioc->reply_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_pool(0x%p): free\n",
ioc->name, ioc->reply));
@@ -3220,10 +3218,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply_free) {
-   pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
+   dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
ioc->reply_free_dma);
-   if (ioc->reply_free_dma_pool)
-   pci_pool_destroy(ioc->reply_free_dma_pool);
+   dma_pool_destroy(ioc->reply_free_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_free_pool(0x%p): free\n",
ioc->name, ioc->reply_free));
@@ -3234,7 +3231,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
do {
rps = >reply_post[i];
if (rps->reply_post_free) {
-   pci_pool_free(
+   dma_pool_free(
ioc->reply_post_free_dma_pool,
rps->reply_post_free,
rps->reply_post_free_dma);
@@ -3246,8 +3243,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
} while (ioc->rdpq_array_enable &&
   (++i < ioc->reply_queue_count));
 
-   if (ioc->reply_post_free_dma_pool)
-   pci_pool_destroy(ioc->reply_post_free_dma_pool);
+   dma_pool_destroy(ioc->reply_post_free_dma_pool);
kfree(ioc->reply_post);
}
 
@@ -3268,12 +3264,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
if (ioc->chain_lookup) {
for (i = 0; i < ioc->chain_depth; i++) {
if (ioc->chain_lookup[i].chain_buffer)
-   pci_pool_free(ioc->chain_dma_pool,
+   dma_pool_free(ioc->chain_dma_pool,
ioc->chain_lookup[i].chain_buffer,
ioc->chain_lookup[i].chain_buffer_dma);
}
-   if (ioc->chain_dma_pool)
-   pci_pool_destroy(ioc->chain_dma_pool);
+   dma_pool_destroy(ioc->chain_dma_pool);
free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
ioc->chain_lookup = NULL;
}
@@ -3448,23 +3443,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
-   ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
-   ioc->pdev, sz, 16, 0);
+   ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
+   >pdev->dev, sz, 16, 0);
if (!ioc->reply_post_free_dma_pool) {
pr_err(MPT3SAS_FMT
-"reply_post_free pool: pci_pool_create failed\n",
+"reply_post_free pool: dma_pool_create failed\n",
 ioc->name);
goto out;
}
i = 0;
do {
ioc->reply_post[i].reply_post_free =
-   pci_pool_alloc(ioc->reply_post_free_dma_pool,
+   

[PATCH v5 08/19] scsi: be2iscsi: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/be2iscsi/be_iscsi.c | 6 +++---
 drivers/scsi/be2iscsi/be_main.c  | 6 +++---
 drivers/scsi/be2iscsi/be_main.h  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index a484457..d76ef77 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -87,8 +87,8 @@ struct iscsi_cls_session *beiscsi_session_create(struct 
iscsi_endpoint *ep,
return NULL;
sess = cls_session->dd_data;
beiscsi_sess = sess->dd_data;
-   beiscsi_sess->bhs_pool =  pci_pool_create("beiscsi_bhs_pool",
-  phba->pcidev,
+   beiscsi_sess->bhs_pool =  dma_pool_create("beiscsi_bhs_pool",
+  >pcidev->dev,
   sizeof(struct be_cmd_bhs),
   64, 0);
if (!beiscsi_sess->bhs_pool)
@@ -113,7 +113,7 @@ void beiscsi_session_destroy(struct iscsi_cls_session 
*cls_session)
struct beiscsi_session *beiscsi_sess = sess->dd_data;
 
printk(KERN_INFO "In beiscsi_session_destroy\n");
-   pci_pool_destroy(beiscsi_sess->bhs_pool);
+   dma_pool_destroy(beiscsi_sess->bhs_pool);
iscsi_session_teardown(cls_session);
 }
 
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 32b2713..dd43480 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4307,7 +4307,7 @@ static void beiscsi_cleanup_task(struct iscsi_task *task)
pwrb_context = _ctrlr->wrb_context[cri_index];
 
if (io_task->cmd_bhs) {
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
task->hdr = NULL;
@@ -4424,7 +4424,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
struct beiscsi_session *beiscsi_sess = beiscsi_conn->beiscsi_sess;
dma_addr_t paddr;
 
-   io_task->cmd_bhs = pci_pool_alloc(beiscsi_sess->bhs_pool,
+   io_task->cmd_bhs = dma_pool_alloc(beiscsi_sess->bhs_pool,
  GFP_ATOMIC, );
if (!io_task->cmd_bhs)
return -ENOMEM;
@@ -4551,7 +4551,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
if (io_task->pwrb_handle)
free_wrb_handle(phba, pwrb_context, io_task->pwrb_handle);
io_task->pwrb_handle = NULL;
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
return -ENOMEM;
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 2188579..cf58d31 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -446,7 +446,7 @@ struct beiscsi_hba {
 test_bit(BEISCSI_HBA_ONLINE, >state))
 
 struct beiscsi_session {
-   struct pci_pool *bhs_pool;
+   struct dma_pool *bhs_pool;
 };
 
 /**
-- 
2.9.3

[PATCH v5 09/19] scsi: csiostor: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
the name of some variables and the content of comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/csiostor/csio_hw.h   |  2 +-
 drivers/scsi/csiostor/csio_init.c | 11 ++-
 drivers/scsi/csiostor/csio_scsi.c |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 029bef8..55b04fc 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -465,7 +465,7 @@ struct csio_hw {
struct csio_pport   pport[CSIO_MAX_PPORTS]; /* Ports (XGMACs) */
struct csio_hw_params   params; /* Hw parameters */
 
-   struct pci_pool *scsi_pci_pool; /* PCI pool for SCSI */
+   struct dma_pool *scsi_dma_pool; /* DMA pool for SCSI */
mempool_t   *mb_mempool;/* Mailbox memory pool*/
mempool_t   *rnode_mempool; /* rnode memory pool */
 
diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index dbe416f..292964c 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -485,9 +485,10 @@ csio_resource_alloc(struct csio_hw *hw)
if (!hw->rnode_mempool)
goto err_free_mb_mempool;
 
-   hw->scsi_pci_pool = pci_pool_create("csio_scsi_pci_pool", hw->pdev,
-   CSIO_SCSI_RSP_LEN, 8, 0);
-   if (!hw->scsi_pci_pool)
+   hw->scsi_dma_pool = dma_pool_create("csio_scsi_dma_pool",
+   >pdev->dev, CSIO_SCSI_RSP_LEN,
+   8, 0);
+   if (!hw->scsi_dma_pool)
goto err_free_rn_pool;
 
return 0;
@@ -505,8 +506,8 @@ csio_resource_alloc(struct csio_hw *hw)
 static void
 csio_resource_free(struct csio_hw *hw)
 {
-   pci_pool_destroy(hw->scsi_pci_pool);
-   hw->scsi_pci_pool = NULL;
+   dma_pool_destroy(hw->scsi_dma_pool);
+   hw->scsi_dma_pool = NULL;
mempool_destroy(hw->rnode_mempool);
hw->rnode_mempool = NULL;
mempool_destroy(hw->mb_mempool);
diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..dab0d3f 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -2445,7 +2445,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
 
/* Allocate Dma buffers for Response Payload */
dma_buf = >dma_buf;
-   dma_buf->vaddr = pci_pool_alloc(hw->scsi_pci_pool, GFP_KERNEL,
+   dma_buf->vaddr = dma_pool_alloc(hw->scsi_dma_pool, GFP_KERNEL,
_buf->paddr);
if (!dma_buf->vaddr) {
csio_err(hw,
@@ -2485,7 +2485,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
@@ -2516,7 +2516,7 @@ csio_scsim_exit(struct csio_scsim *scm)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(scm->hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(scm->hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
-- 
2.9.3

Re: problem with block: Move bdi_unregister() to del_gendisk() commit 165a5e22fafb127ecb5914e12e8c32a1f0d3f820

[Jan Kara]

On Wed 08-03-17 20:37:54, Arthur Marsh wrote:
> 
> On one of my pc's I have 2 PATA disks (one, WDC below is used for booting,
> the other SAMSUNG is not mounted), plus an IBM SCSI disk using a DPT 2044W
> controller with eata driver and sometimes a Verbatim Storengo USB stick.
> 
> On recent 4.10.0+ kernel builds (i386), the resulting kernel would pause
> during the start-up when the USB stick was inserted but boot normally
> otherwise.
> 
> A git-bisect lead to:
> 
> commit 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
> Author: Jan Kara 
> Date:   Wed Feb 8 08:05:56 2017 +0100
> 
> block: Move bdi_unregister() to del_gendisk()
> 
> Commit 6cd18e711dd8 "block: destroy bdi before blockdev is
> unregistered." moved bdi unregistration (at that time through
> bdi_destroy()) from blk_release_queue() to blk_cleanup_queue() because
> it needs to happen before blk_unregister_region() call in del_gendisk()
> for MD. SCSI though will free up the device number from sd_remove()
> called through a maze of callbacks from device_del() in
> __scsi_remove_device() before blk_cleanup_queue() and thus similar races
> as described in 6cd18e711dd8 can happen for SCSI as well as reported by
> Omar [1].
> 
> Moving bdi_unregister() to del_gendisk() works for MD and fixes the
> problem for SCSI since del_gendisk() gets called from sd_remove() before
> freeing the device number.
> 
> This also makes device_add_disk() (calling bdi_register_owner()) more
> symmetric with del_gendisk().
> 
> [1] http://marc.info/?l=linux-block=148554717109098=2

Thanks for report and the analysis! The real culprit seems to be:

 [4.614530] BUG: unable to handle kernel NULL pointer dereference at 
0258
 [4.614606] IP: sd_revalidate_disk+0x12/0x1460 [sd_mod]
 [4.614668] *pdpt = 370de001 *pde =  
 [4.614788] Oops:  [#1] PREEMPT SMP
 [4.614847] Modules linked in: uas sd_mod usb_storage psmouse pata_via 
ehci_pci uhci_hcd ehci_hcd via_rhine usbcore eata mii i2c_viapro usb_common 
libata scsi_mod
 [4.614970] CPU: 0 PID: 127 Comm: kworker/u4:5 Not tainted 4.10.0+ #652
 [4.615035] Hardware name: System manufacturer System Product Name/A8V-MX, 
BIOS 050312/06/2005
 [4.615117] Workqueue: events_unbound async_run_entry_fn
 [4.615180] task: f71b9080 task.stack: f729c000
 [4.615243] EIP: sd_revalidate_disk+0x12/0x1460 [sd_mod]
 [4.615305] EFLAGS: 00010296 CPU: 0
 [4.615363] EAX: f7261000 EBX:  ECX:  EDX: f7196000
 [4.615426] ESI: f7196000 EDI: f7261000 EBP: f729deac ESP: f729de44
 [4.615489]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
 [4.615552] CR0: 80050033 CR2: 0258 CR3: 370ce6c0 CR4: 06f0
 [4.615615] Call Trace:
 [4.615675]  ? kobject_uevent+0xa/0x10
 [4.615736]  ? blk_integrity_add+0x41/0x50
 [4.615797]  ? device_add_disk+0x275/0x450
 [4.615861]  sd_probe_async+0x103/0x1b0 [sd_mod]
 [4.615923]  ? preempt_count_sub+0x26/0x70
 [4.615984]  async_run_entry_fn+0x30/0x170
 [4.616045]  ? preempt_count_sub+0x26/0x70
 [4.616107]  process_one_work+0x235/0x670
 [4.616167]  ? process_one_work+0x1a3/0x670
 [4.616229]  worker_thread+0x2f/0x4c0
 [4.616288]  ? preempt_count_add+0x82/0xc0
 [4.616349]  ? process_one_work+0x670/0x670
 [4.616410]  kthread+0xd0/0x100
 [4.616467]  ? process_one_work+0x670/0x670
 [4.616528]  ? kthread_create_on_node+0x30/0x30
 [4.616591]  ret_from_fork+0x21/0x2c
 [4.616652] Code: 43 02 31 c0 8b 5d f4 c9 c3 8d 75 e4 89 34 24 e8 95 0a fb 
ff eb d4 8d 76 00 55 89 e5 57 56 53 83 ec 5c 8b 98 0c 03 00 00 89 45 c8 <8b> 93 
58 02 00 00 8b 43 04 89 45 d8 8b 82 08 03 00 00 89 45 d0
 [4.616840] EIP: sd_revalidate_disk+0x12/0x1460 [sd_mod] SS:ESP: 
0068:f729de44
 [4.616914] CR2: 0258
 [4.616973] ---[ end trace b1bff84fe33f3677 ]---

in your log. And this apparently happened because disk->private_data was
NULL. Can you try whether attached patches fix the problem for you?

Honza


> 
> When booting the bad kernel, I would eventually get a prompt to press the
> enter key to boot and it eventually started, but the SCSI disk partitions
> were not found by blkid nor could they be mounted.
> 
> lsscsi reports:
> 
> [0:0:6:0]diskIBM  DCAS-34330W  S65A  /dev/sda
> [1:0:0:0]diskATA  WDC WD3200AAJB-0 2C01  /dev/sdc
> [2:0:0:0]cd/dvd  HL-DT-ST DVDRAM GSA-4163B A103  /dev/sr0
> [2:0:1:0]diskATA  SAMSUNG SP4002H  0-57  /dev/sdd
> [3:0:0:0]diskVerbatim STORE N GO   5.00  /dev/sdb
> 
> blkid reports:
> 
> /dev/sdb1: LABEL="STORENGO" UUID="B08B-79DA" TYPE="vfat"
> PARTUUID="961d9655-01"
> /dev/sdc1: UUID="bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea" TYPE="ext3"
> PTTYPE="dos" PARTUUID="000750bf-01"
> /dev/sdc5: UUID="26b7280a-f40c-49dd-a086-dbbb9b7e3def" TYPE="swap"
> 

Re: [PATCH] mux-core: make it explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH] mux-core: make it explicitly non-modular] On 08/03/2017 (Wed 
10:38) Peter Rosin wrote:

> On 2017-03-07 23:41, Paul Gortmaker wrote:
> > The Kconfig currently controlling compilation of this code is:
> > 
> > drivers/mux/Kconfig:menuconfig MULTIPLEXER
> > drivers/mux/Kconfig:bool "Multiplexer subsystem"
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > Lets remove the couple traces of modular infrastructure use, so that
> > when reading the driver there is no doubt it is builtin-only.
> > 
> > Hence we delete the MODULE_LICENSE tag etc. since all that information
> > is already contained at the top of the file in the comments.
> 
> Hi Paul,
> 
> Yup, it is confirmed, I don't really know what I'm doing. In particular
> when in comes to modules... I did wonder about this when I wrote the
> code and one specific thing I wondered about was how module loading is
> triggered.
> 
> I can imagine that calling a function that happens to be exported from
> a module triggers its loading and that failure to load the module leads
> to an oops. But I don't know if that is even remotely correct? Is it?

No, that would be pretty user unfriendly.  When you "insmod" a module,
the kernel checks just like a linker, that all the functions it wants to
use are available.  If they are not, then the kernel fails to load it.
But it fails gracefully with a list of the unresolved symbols.

Obviously managing all the module interdependencies manually would be
tedious, so that is what what "depmod" does.  Then loading of a module
is usually done with "modprobe", which will consult the depmod data and
then "insmod" the required modules in the needed order.

> Is there a short answer? Or what should I read for a longer one?

Well, now that you know it won't oops from a module needing a module,
perhaps you do now want to make the core support modular?  If I look in
my ARM build, I see:

paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$ ls -l
total 96
-rw-rw-r-- 1 paul paul   399 Mar  7 16:41 built-in.mod.c
-rw-rw-r-- 1 paul paul 15999 Mar  7 16:41 built-in.o
-rw-rw-r-- 1 paul paul 0 Mar  7 16:12 modules.builtin
-rw-rw-r-- 1 paul paul65 Mar  7 16:41 modules.order
-rw-rw-r-- 1 paul paul  8324 Mar  7 16:49 mux-adg792a.ko
-rw-rw-r-- 1 paul paul  1566 Mar  7 16:46 mux-adg792a.mod.c
-rw-rw-r-- 1 paul paul  3552 Mar  7 16:47 mux-adg792a.mod.o
-rw-rw-r-- 1 paul paul  6824 Mar  7 16:41 mux-adg792a.o
-rw-rw-r-- 1 paul paul 20472 Mar  7 16:41 mux-core.o
-rw-rw-r-- 1 paul paul  7680 Mar  7 16:49 mux-gpio.ko
-rw-rw-r-- 1 paul paul  1550 Mar  7 16:46 mux-gpio.mod.c
-rw-rw-r-- 1 paul paul  3408 Mar  7 16:47 mux-gpio.mod.o
-rw-rw-r-- 1 paul paul  6360 Mar  7 16:41 mux-gpio.o
paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$ 

Note that mux-core doesn't have a .ko (modular variant) and also you can
confirm with nm that everything in mux-core.o is in built-in.o (in this
case the nm outputs are virtually identical).

But if you do make that a module too, you will need the MODULE_LICENSE
tag.  The kernel also checks that license compatibility is maintained ;
i.e. a proprietary module can't use functions from another module doing
EXPORT_SYMBOL_GPL.

> Anyway, I'll add this to the queue, and fold it if I happen to rebase.

Oh, and speaking of EXPORT_SYMBOL, I should have added 
to your file with the patch I sent, since it does do exports.

Hope that helps,
Paul.
--

> Thanks!
> 
> Cheers,
> peda
> 
> > Cc: Peter Rosin 
> > Cc: Jonathan Cameron 
> > Signed-off-by: Paul Gortmaker 
> > ---
> > 
> > [feel free to fold this change into the original addition commit if
> >  you happen to be rebasing for some other reason... ]
> > 
> >  drivers/mux/mux-core.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> > index 46088a0f9677..7b4af6370e37 100644
> > --- a/drivers/mux/mux-core.c
> > +++ b/drivers/mux/mux-core.c
> > @@ -15,7 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -408,7 +408,3 @@ void devm_mux_control_put(struct device *dev, struct 
> > mux_control *mux)
> >  EXPORT_SYMBOL_GPL(devm_mux_control_put);
> >  
> >  subsys_initcall(mux_init);
> > -
> > -MODULE_DESCRIPTION("Multiplexer subsystem");
> > -MODULE_AUTHOR("Peter Rosin  > -MODULE_LICENSE("GPL v2");
> > 
> 

[PATCH 26/26] IB/ocrdma: Adjust further ten checks for null pointers

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 8 Mar 2017 12:50:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl“ pointed information out like the following.

Comparison to NULL could be written !…

Thus fix affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index bfd86fd08847..bd719e7f134e 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -267,7 +267,7 @@ static int ocrdma_add_mmap(struct ocrdma_ucontext *uctx, 
u64 phy_addr,
struct ocrdma_mm *mm;
 
mm = kzalloc(sizeof(*mm), GFP_KERNEL);
-   if (mm == NULL)
+   if (!mm)
return -ENOMEM;
mm->key.phy_addr = phy_addr;
mm->key.len = len;
@@ -1187,7 +1187,7 @@ static int ocrdma_add_qpn_map(struct ocrdma_dev *dev, 
struct ocrdma_qp *qp)
 {
int status = -EINVAL;
 
-   if (qp->id < OCRDMA_MAX_QP && dev->qp_tbl[qp->id] == NULL) {
+   if (qp->id < OCRDMA_MAX_QP && !dev->qp_tbl[qp->id]) {
dev->qp_tbl[qp->id] = qp;
status = 0;
}
@@ -1355,11 +1355,11 @@ static int ocrdma_alloc_wr_id_tbl(struct ocrdma_qp *qp)
 {
qp->wqe_wr_id_tbl = kcalloc(qp->sq.max_cnt, sizeof(*qp->wqe_wr_id_tbl),
GFP_KERNEL);
-   if (qp->wqe_wr_id_tbl == NULL)
+   if (!qp->wqe_wr_id_tbl)
return -ENOMEM;
qp->rqe_wr_id_tbl = kcalloc(qp->rq.max_cnt, sizeof(*qp->rqe_wr_id_tbl),
GFP_KERNEL);
-   if (qp->rqe_wr_id_tbl == NULL)
+   if (!qp->rqe_wr_id_tbl)
return -ENOMEM;
 
return 0;
@@ -1419,7 +1419,7 @@ struct ib_qp *ocrdma_create_qp(struct ib_pd *ibpd,
goto gen_err;
}
ocrdma_set_qp_init_params(qp, pd, attrs);
-   if (udata == NULL)
+   if (!udata)
qp->cap_flags |= (OCRDMA_QP_MW_BIND | OCRDMA_QP_LKEY0 |
OCRDMA_QP_FAST_REG);
 
@@ -1431,7 +1431,7 @@ struct ib_qp *ocrdma_create_qp(struct ib_pd *ibpd,
goto mbx_err;
 
/* user space QP's wr_id table are managed in library */
-   if (udata == NULL) {
+   if (!udata) {
status = ocrdma_alloc_wr_id_tbl(qp);
if (status)
goto map_err;
@@ -1892,11 +1892,11 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
if (status)
goto err;
 
-   if (udata == NULL) {
+   if (!udata) {
srq->rqe_wr_id_tbl = kcalloc(srq->rq.max_cnt,
 sizeof(*srq->rqe_wr_id_tbl),
 GFP_KERNEL);
-   if (srq->rqe_wr_id_tbl == NULL)
+   if (!srq->rqe_wr_id_tbl)
goto arm_err;
 
srq->bit_fields_len = (srq->rq.max_cnt / 32) +
@@ -1904,7 +1904,7 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
srq->idx_bit_fields = kmalloc_array(srq->bit_fields_len,

sizeof(*srq->idx_bit_fields),
GFP_KERNEL);
-   if (srq->idx_bit_fields == NULL)
+   if (!srq->idx_bit_fields)
goto arm_err;
memset(srq->idx_bit_fields, 0xff,
   srq->bit_fields_len * sizeof(*srq->idx_bit_fields));
@@ -2878,7 +2878,7 @@ static int ocrdma_poll_hwcq(struct ocrdma_cq *cq, int 
num_entries,
if (qpn == 0)
goto skip_cqe;
qp = dev->qp_tbl[qpn];
-   BUG_ON(qp == NULL);
+   BUG_ON(!qp);
 
expand = is_cqe_for_sq(cqe)
 ? ocrdma_poll_scqe(qp, cqe, ibwc, , )
-- 
2.12.0

Re: [PATCH 15/26] IB/ocrdma: Delete an error message for a failed memory allocation in ocrdma_add()

[Yuval Shaia]

On Wed, Mar 08, 2017 at 02:13:11PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 7 Mar 2017 22:23:17 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

Suggesting to add blank line here.

> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_main.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> index c49b4491d4e7..93113feeb2d5 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> @@ -304,10 +304,9 @@ static struct ocrdma_dev *ocrdma_add(struct be_dev_info 
> *dev_info)
>   struct ocrdma_dev *dev;
>  
>   dev = (struct ocrdma_dev *)ib_alloc_device(sizeof(*dev));
> - if (!dev) {
> - pr_err("Unable to allocate ib device\n");
> + if (!dev)
>   return NULL;
> - }
> +

Reviewed-by: Yuval Shaia 

>   dev->mbx_cmd = kzalloc(sizeof(struct ocrdma_mqe_emb_cmd), GFP_KERNEL);
>   if (!dev->mbx_cmd)
>   goto idr_err;
> -- 
> 2.12.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

[Thomas Garnier]

Thanks for the change.

Acked-by: Thomas Garnier 

On Wed, Mar 8, 2017 at 12:35 AM, Bhupesh Sharma  wrote:
> On Wed, Mar 8, 2017 at 1:48 PM, Dave Young  wrote:
>> On 03/08/17 at 03:47pm, Baoquan He wrote:
>>> EFI allocates runtime services regions top-down, starting from EFI_VA_START
>>> to EFI_VA_END. So EFI_VA_START is bigger than EFI_VA_END and is the end of
>>> EFI region. The upper boundary of memory regions randomized by KASLR should
>>> be EFI_VA_END if it's adjacent to EFI region, but not EFI_VA_START.
>>>
>>> Correct it in this patch.
>>>
>>> Signed-off-by: Baoquan He 
>>> ---
>>>  arch/x86/mm/kaslr.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
>>> index 887e571..aed2064 100644
>>> --- a/arch/x86/mm/kaslr.c
>>> +++ b/arch/x86/mm/kaslr.c
>>> @@ -48,7 +48,7 @@ static const unsigned long vaddr_start = 
>>> __PAGE_OFFSET_BASE;
>>>  #if defined(CONFIG_X86_ESPFIX64)
>>>  static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
>>>  #elif defined(CONFIG_EFI)
>>> -static const unsigned long vaddr_end = EFI_VA_START;
>>> +static const unsigned long vaddr_end = EFI_VA_END;
>>>  #else
>>>  static const unsigned long vaddr_end = __START_KERNEL_map;
>>>  #endif
>>> @@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void)
>>>*/
>>>   BUILD_BUG_ON(vaddr_start >= vaddr_end);
>>>   BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
>>> -  vaddr_end >= EFI_VA_START);
>>> +  vaddr_end >= EFI_VA_END);
>>>   BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
>>> IS_ENABLED(CONFIG_EFI)) &&
>>>vaddr_end >= __START_KERNEL_map);
>>> --
>>> 2.5.5
>>>
>>
>> Acked-by: Dave Young 
>>
>
> Thanks Bao for this fix. This makes the KASLR code consistent with
> Address space markers hints in [1]
>
> [1] http://lxr.free-electrons.com/source/arch/x86/mm/dump_pagetables.c#L82
>
> Reviewed-by: Bhupesh Sharma 
>
> Regards,
> Bhupesh



-- 
Thomas

Re: [v6 PATCH 19/21] x86/traps: Fixup general protection faults caused by UMIP

[Andy Lutomirski]

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
 wrote:
> If the User-Mode Instruction Prevention CPU feature is available and
> enabled, a general protection fault will be issued if the instructions
> sgdt, sldt, sidt, str or smsw are executed from user-mode context
> (CPL > 0). If the fault was caused by any of the instructions protected
> by UMIP, fixup_umip_exception will emulate dummy results for these
> instructions. If emulation is successful, the result is passed to the
> user space program and no SIGSEGV signal is emitted.
>
> Please note that fixup_umip_exception also caters for the case when
> the fault originated while running in virtual-8086 mode.

Reviewed-by: Andy Lutomirski 

[PATCH v5 18/19] usb: host: Remove remaining pci_pool in comments

[Romain Perier]

This replaces remaining occurences of pci_pool by dma_pool, as
this is the new API that could be used for that purpose.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/usb/host/ehci-hcd.c | 2 +-
 drivers/usb/host/fotg210-hcd.c  | 2 +-
 drivers/usb/host/oxu210hp-hcd.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index ac2c4ea..6e834b83 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -597,7 +597,7 @@ static int ehci_run (struct usb_hcd *hcd)
/*
 * hcc_params controls whether ehci->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 1c5b34b..ced08dc 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -5047,7 +5047,7 @@ static int fotg210_run(struct usb_hcd *hcd)
/*
 * hcc_params controls whether fotg210->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index bcf531c..ed20fb3 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -2708,7 +2708,7 @@ static int oxu_run(struct usb_hcd *hcd)
 
/* hcc_params controls whether oxu->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
-- 
2.9.3

Re: v4.11-rc1 boot time regression

[Andy Shevchenko]

On Wed, Mar 8, 2017 at 10:26 AM, Thomas Gleixner  wrote:
> On Tue, 7 Mar 2017, Andy Shevchenko wrote:
>> On Tue, Mar 7, 2017 at 9:21 PM, Linus Torvalds
>>  wrote:
>> > On Tue, Mar 7, 2017 at 11:02 AM, Andy Shevchenko
>> >  wrote:
>> >>
>> >> 60 seconds of wait for what exactly? I have no clue right now. Any 
>> >> suggestions?
>> >
>> > Ugh. If it is something that is actively sleeping, sysrq-t during the
>> > pause might give a hint.
>>
>> Unfortunately seems I can't do this. I managed to disable watchdog in
>> U-Boot, but seems console is not yet switched to the driver my blind
>> key presses went nowhere.
>>
>> > But it could be just a timer thing with nobody actively waiting for
>> > it, just a general init completion thing, and then it wouldn't show up
>> > as a thread with a backtrace. In that case you might need to bisect
>> > it..
>>
>> Looks like it's the only way if 60 seconds doesn't ring a bell to anyone...
>> Anyway, now (as you know :-) ) quite late in Hki, have to give my body
>> a bit of sleep.
>
> A shot in the dark:
>
> Could you try Linus head first, especially commit:
>
> fa3aa7a54fe6 ("jiffies: Revert bogus conversion of NSEC_PER_SEC to TICK_NSEC")
>
> which fixes: 93825f2ec736 ("jiffies: Reuse TICK_NSEC instead of 
> NSEC_PER_JIFFY")

Thomas, you are cool! That is the one. Thanks!

-- 
With Best Regards,
Andy Shevchenko

[PATCH v5 16/19] usb: gadget: net2280: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/usb/gadget/udc/net2280.c | 12 ++--
 drivers/usb/gadget/udc/net2280.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 8550441..089081e 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -569,7 +569,7 @@ static struct usb_request
if (ep->dma) {
struct net2280_dma  *td;
 
-   td = pci_pool_alloc(ep->dev->requests, gfp_flags,
+   td = dma_pool_alloc(ep->dev->requests, gfp_flags,
>td_dma);
if (!td) {
kfree(req);
@@ -597,7 +597,7 @@ static void net2280_free_request(struct usb_ep *_ep, struct 
usb_request *_req)
req = container_of(_req, struct net2280_request, req);
WARN_ON(!list_empty(>queue));
if (req->td)
-   pci_pool_free(ep->dev->requests, req->td, req->td_dma);
+   dma_pool_free(ep->dev->requests, req->td, req->td_dma);
kfree(req);
 }
 
@@ -3578,10 +3578,10 @@ static void net2280_remove(struct pci_dev *pdev)
for (i = 1; i < 5; i++) {
if (!dev->ep[i].dummy)
continue;
-   pci_pool_free(dev->requests, dev->ep[i].dummy,
+   dma_pool_free(dev->requests, dev->ep[i].dummy,
dev->ep[i].td_dma);
}
-   pci_pool_destroy(dev->requests);
+   dma_pool_destroy(dev->requests);
}
if (dev->got_irq)
free_irq(pdev->irq, dev);
@@ -3723,7 +3723,7 @@ static int net2280_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 
/* DMA setup */
/* NOTE:  we know only the 32 LSBs of dma addresses may be nonzero */
-   dev->requests = pci_pool_create("requests", pdev,
+   dev->requests = dma_pool_create("requests", >dev,
sizeof(struct net2280_dma),
0 /* no alignment requirements */,
0 /* or page-crossing issues */);
@@ -3735,7 +3735,7 @@ static int net2280_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
for (i = 1; i < 5; i++) {
struct net2280_dma  *td;
 
-   td = pci_pool_alloc(dev->requests, GFP_KERNEL,
+   td = dma_pool_alloc(dev->requests, GFP_KERNEL,
>ep[i].td_dma);
if (!td) {
ep_dbg(dev, "can't get dummy %d\n", i);
diff --git a/drivers/usb/gadget/udc/net2280.h b/drivers/usb/gadget/udc/net2280.h
index 2736a95..1088c37 100644
--- a/drivers/usb/gadget/udc/net2280.h
+++ b/drivers/usb/gadget/udc/net2280.h
@@ -187,7 +187,7 @@ struct net2280 {
struct usb338x_ll_chi_regs  __iomem *ll_chicken_reg;
struct usb338x_pl_regs  __iomem *plregs;
 
-   struct pci_pool *requests;
+   struct dma_pool *requests;
/* statistics...*/
 };
 
-- 
2.9.3

[PATCH v5 19/19] PCI: Remove PCI pool macro functions

[Romain Perier]

Now that all the drivers use dma pool API, we can remove the macro
functions for PCI pool.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 include/linux/pci.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..04a0703 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1281,15 +1281,6 @@ int pci_set_vga_state(struct pci_dev *pdev, bool decode,
 #include 
 #include 
 
-#definepci_pool dma_pool
-#define pci_pool_create(name, pdev, size, align, allocation) \
-   dma_pool_create(name, >dev, size, align, allocation)
-#definepci_pool_destroy(pool) dma_pool_destroy(pool)
-#definepci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, 
handle)
-#definepci_pool_zalloc(pool, flags, handle) \
-   dma_pool_zalloc(pool, flags, handle)
-#definepci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, 
addr)
-
 struct msix_entry {
u32 vector; /* kernel uses to write allocated vector */
u16 entry;  /* driver uses to specify entry, OS writes */
-- 
2.9.3

[PATCH v5 17/19] usb: gadget: pch_udc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Felipe Balbi 
---
 drivers/usb/gadget/udc/pch_udc.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index a97da64..84dcbcd 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -355,8 +355,8 @@ struct pch_udc_dev {
vbus_session:1,
set_cfg_not_acked:1,
waiting_zlp_ack:1;
-   struct pci_pool *data_requests;
-   struct pci_pool *stp_requests;
+   struct dma_pool *data_requests;
+   struct dma_pool *stp_requests;
dma_addr_t  dma_addr;
struct usb_ctrlrequest  setup_data;
void __iomem*base_addr;
@@ -1522,7 +1522,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev 
*dev,
/* do not free first desc., will be done by free for request */
td = phys_to_virt(addr);
addr2 = (dma_addr_t)td->next;
-   pci_pool_free(dev->data_requests, td, addr);
+   dma_pool_free(dev->data_requests, td, addr);
td->next = 0x00;
addr = addr2;
}
@@ -1539,7 +1539,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev 
*dev,
  *
  * Return codes:
  * 0:  success,
- * -ENOMEM:pci_pool_alloc invocation fails
+ * -ENOMEM:dma_pool_alloc invocation fails
  */
 static int pch_udc_create_dma_chain(struct pch_udc_ep *ep,
struct pch_udc_request *req,
@@ -1565,7 +1565,7 @@ static int pch_udc_create_dma_chain(struct pch_udc_ep *ep,
if (bytes <= buf_len)
break;
last = td;
-   td = pci_pool_alloc(ep->dev->data_requests, gfp_flags,
+   td = dma_pool_alloc(ep->dev->data_requests, gfp_flags,
_addr);
if (!td)
goto nomem;
@@ -1770,7 +1770,7 @@ static struct usb_request *pch_udc_alloc_request(struct 
usb_ep *usbep,
if (!ep->dev->dma_addr)
return >req;
/* ep0 in requests are allocated from data pool here */
-   dma_desc = pci_pool_alloc(ep->dev->data_requests, gfp,
+   dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
  >td_data_phys);
if (NULL == dma_desc) {
kfree(req);
@@ -1809,7 +1809,7 @@ static void pch_udc_free_request(struct usb_ep *usbep,
if (req->td_data != NULL) {
if (req->chain_len > 1)
pch_udc_free_dma_chain(ep->dev, req);
-   pci_pool_free(ep->dev->data_requests, req->td_data,
+   dma_pool_free(ep->dev->data_requests, req->td_data,
  req->td_data_phys);
}
kfree(req);
@@ -2914,7 +2914,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
void*ep0out_buf;
 
/* DMA setup */
-   dev->data_requests = pci_pool_create("data_requests", dev->pdev,
+   dev->data_requests = dma_pool_create("data_requests", >pdev->dev,
sizeof(struct pch_udc_data_dma_desc), 0, 0);
if (!dev->data_requests) {
dev_err(>pdev->dev, "%s: can't get request data pool\n",
@@ -2923,7 +2923,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
}
 
/* dma desc for setup data */
-   dev->stp_requests = pci_pool_create("setup requests", dev->pdev,
+   dev->stp_requests = dma_pool_create("setup requests", >pdev->dev,
sizeof(struct pch_udc_stp_dma_desc), 0, 0);
if (!dev->stp_requests) {
dev_err(>pdev->dev, "%s: can't get setup request pool\n",
@@ -2931,7 +2931,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
return -ENOMEM;
}
/* setup */
-   td_stp = pci_pool_alloc(dev->stp_requests, GFP_KERNEL,
+   td_stp = dma_pool_alloc(dev->stp_requests, GFP_KERNEL,
>ep[UDC_EP0OUT_IDX].td_stp_phys);
if (!td_stp) {
dev_err(>pdev->dev,
@@ -2941,7 +2941,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
dev->ep[UDC_EP0OUT_IDX].td_stp = td_stp;
 
/* data: 0 packets !? */
-   td_data = pci_pool_alloc(dev->data_requests, GFP_KERNEL,
+   td_data = dma_pool_alloc(dev->data_requests, GFP_KERNEL,
>ep[UDC_EP0OUT_IDX].td_data_phys);
if (!td_data) {
dev_err(>pdev->dev,
@@ -3021,22 +3021,21 @@ 

Re: out of range LBA using sg_raw

[Christoph Hellwig]

On Wed, Mar 08, 2017 at 09:29:28PM +0530, Kashyap Desai wrote:
> Thanks Chris. It is understood to have sanity in driver, but how critical
> such checks where SG_IO type interface send pass-through request. ?
> Are you suggesting as good to have sanity or very important as there may
> be a real-time exposure other than SG_IO interface ? I am confused over
> must or good to have check.
> Also one more fault I can generate using below sg_raw command -

SCSI _devices_ need to sanity check any input and fail commands instead
of crashing or causing other problems.  Normal SCSI HBA drivers don't
need to do that as they don't interpret CDBs.  Megaraid (and a few other
raid drivers) are special in that they take on part of the device
functionality and do interpret CDBs sometimes.  In that case you'll
need to do all that sanity checking and generate proper errors.

It would be nice to have come common helpers for this shared between
everyone interpreting SCSI CBD (e.g. the SCSI target code, the NVMe
SCSI emulation and the various RAID drivers).

Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

Hi Alban,

On Wed, 8 Mar 2017 16:20:01 +0100
Alban  wrote:

> On Tue, 7 Mar 2017 22:01:07 +0100
> Boris Brezillon  wrote:
> 
> > On Tue,  7 Mar 2017 09:26:03 +0100
> > Alban  wrote:
> >   
> > > Config data for drivers, like MAC addresses, is often stored in MTD.
> > > Add a binding that define how such data storage can be represented in
> > > device tree.
> > > 
> > > Signed-off-by: Alban 
> > > ---
> > > Changelog:
> > > v2: * Added a "Required properties" section with the nvmem-provider
> > >   property
> > > ---
> > >  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 33 
> > > ++
> > >  1 file changed, 33 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt 
> > > b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > > new file mode 100644
> > > index 000..8ed25e6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > > @@ -0,0 +1,33 @@
> > > += NVMEM in MTD =
> > > +
> > > +Config data for drivers, like MAC addresses, is often stored in MTD.
> > > +This binding define how such data storage can be represented in device 
> > > tree.
> > > +
> > > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> > > +property to their node.
> > 
> > If everyone agrees that this is actually needed, then it should
> > definitely go in the nvmem binding doc, and we should patch all nvmem
> > providers to define this property (even if we keep supporting nodes
> > that are not defining it). I'm not fully convinced yet, but I might be
> > wrong.  
> 
> I really like to hear what the DT people think about this.

That was the plan.

> 
> > I also think we should take the "nvmem under flash node without partitions"
> > into account now, or at least have a clear plan on how we want to represent
> > it.
> > 
> > Something like that?  
> 
> Yes, but with the following extras:
> 
> > flash {  
> nvmem-provider;
> > partitions {
> > part@X {
> > nvmem {  
>   compatible = "nvmem-cells";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > 
> > cell@Y {
> > };
> > };
> > };
> > };
> > 
> > nvmem {  
>   compatible = "nvmem-cells";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > 
> > cell@X {
> > };
> > };
> > };
> >
> > Note that patching nvmem core to support the subnode case should be
> > pretty easy (see below).  
> 
> This shouldn't be needed as nothing would change for the NVMEM devices,
> what could be added is a check for the "nvmem-provider" property.
> To support the proposed binding we would only need a minor change to
> of_nvmem_cell_get():
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 408b521ee520..6231ea27c9f4 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -444,6 +444,10 @@ struct nvmem_device *nvmem_register(const struct 
> nvmem_config *config)
> if (!config->dev)
> return ERR_PTR(-EINVAL);
> 
> +   if (config->dev->of_node &&
> +   !of_property_read_bool(config->dev->of_node, "nvmem-provider"))
> +   return ERR_PTR(-ENODEV);
> +
> nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
> if (!nvmem)
> return ERR_PTR(-ENOMEM);
> @@ -777,6 +781,15 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node 
> *np,
> if (!nvmem_np)
> return ERR_PTR(-EINVAL);
> 
> +   /* handle the new cell binding */
> +   if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
> +   nvmem_np = of_get_next_parent(cell_np);
> +   if (!nvmem_np)
> +   return ERR_PTR(-EINVAL);
> +   if (!of_property_read_bool(nvmem_np, "nvmem-provider"))
> +   return ERR_PTR(-ENODEV);
> +   }
> +
> nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
> if (IS_ERR(nvmem))
> return ERR_CAST(nvmem);
> 

Yep, works too. Let's wait for a DT review, before taking a decision.

Thanks,

Boris

[PATCH v2 1/9] mm: fix mapping_set_error call in me_pagecache_dirty

[Jeff Layton]

The error code should be negative. Since this ends up in the default
case anyway, this is harmless, but it's less confusing to negate it.

Signed-off-by: Jeff Layton 
---
 mm/memory-failure.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 27f7210e7fab..4b56e53e5378 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -674,7 +674,7 @@ static int me_pagecache_dirty(struct page *p, unsigned long 
pfn)
 * the first EIO, but we're not worse than other parts
 * of the kernel.
 */
-   mapping_set_error(mapping, EIO);
+   mapping_set_error(mapping, -EIO);
}
 
return me_pagecache_clean(p, pfn);
-- 
2.9.3

Re: [PATCH 11/26] IB/ocrdma: Delete unnecessary braces

[Yuval Shaia]

On Wed, Mar 08, 2017 at 02:04:56PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 7 Mar 2017 21:12:56 +0100
> 
> Do not use curly brackets at some source code places
> where a single statement should be sufficient.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> index aa32bc9f323d..d5b988b011d1 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> @@ -1092,14 +1092,14 @@ static int ocrdma_mbx_cmd(struct ocrdma_dev *dev, 
> struct ocrdma_mqe *mqe)
>   if (cqe_status || ext_status) {
>   pr_err("%s() cqe_status=0x%x, ext_status=0x%x,",
>  __func__, cqe_status, ext_status);
> - if (rsp) {
> + if (rsp)
>   /* This is for embedded cmds. */
>   pr_err("opcode=0x%x, subsystem=0x%x\n",
>  (rsp->subsys_op & OCRDMA_MBX_RSP_OPCODE_MASK) >>
>   OCRDMA_MBX_RSP_OPCODE_SHIFT,
>   (rsp->subsys_op & OCRDMA_MBX_RSP_SUBSYS_MASK) >>
>   OCRDMA_MBX_RSP_SUBSYS_SHIFT);
> - }
> +

Reviewed-by: Yuval Shaia 

>   status = ocrdma_get_mbx_cqe_errno(cqe_status);
>   goto mbx_err;
>   }
> @@ -1600,10 +1600,9 @@ void ocrdma_alloc_pd_pool(struct ocrdma_dev *dev)
>   return;
>  
>   status = ocrdma_mbx_alloc_pd_range(dev);
> - if (status) {
> + if (status)
>   pr_err("%s(%d) Unable to initialize PD pool, using default.\n",
>__func__, dev->id);
> - }
>  }
>  
>  static void ocrdma_free_pd_pool(struct ocrdma_dev *dev)
> @@ -2997,11 +2996,10 @@ static int ocrdma_parse_dcbxcfg_rsp(struct ocrdma_dev 
> *dev, int ptype,
>   goto out;
>   }
>   }
> - if (slindx == OCRDMA_MAX_SERVICE_LEVEL_INDEX) {
> + if (slindx == OCRDMA_MAX_SERVICE_LEVEL_INDEX)
>   pr_info("%s ocrdma%d application priority not 
> set for 0x%x protocol\n",
>   dev_name(>nic_info.pdev->dev),
>   dev->id, proto);
> - }
>   }
>   }
>  
> @@ -3158,16 +3156,17 @@ static int ocrdma_modify_eqd(struct ocrdma_dev *dev, 
> struct ocrdma_eq *eq,
>int num)
>  {
>   int num_eqs, i = 0;
> - if (num > 8) {
> +
> + if (num > 8)
>   while (num) {
>   num_eqs = min(num, 8);
>   ocrdma_mbx_modify_eqd(dev, [i], num_eqs);
>   i += num_eqs;
>   num -= num_eqs;
>   }
> - } else {
> + else
>   ocrdma_mbx_modify_eqd(dev, eq, num);
> - }
> +
>   return 0;
>  }
>  
> -- 
> 2.12.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig

[Juergen Gross]

On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> All code to supprot Xen PV will get under this new option. For the

s/supprot/support/

> beginning, check for it in the common code.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  arch/x86/kernel/cpu/hypervisor.c |  4 +++-
>  arch/x86/kernel/process_64.c |  2 +-
>  arch/x86/xen/Kconfig | 23 ++-
>  3 files changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/hypervisor.c 
> b/arch/x86/kernel/cpu/hypervisor.c
> index a77f18d..ce6fcc3 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -28,8 +28,10 @@
>  
>  static const __initconst struct hypervisor_x86 * const hypervisors[] =
>  {
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_PV
>   _hyper_xen_pv,
> +#endif
> +#ifdef CONFIG_XEN_PVHVM
>   _hyper_xen_hvm,
>  #endif
>   _hyper_vmware,
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index a61e141..5e8d129 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -438,7 +438,7 @@ __switch_to(struct task_struct *prev_p, struct 
> task_struct *next_p)
>task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
>   __switch_to_xtra(prev_p, next_p, tss);
>  
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_PV
>   /*
>* On Xen PV, IOPL bits in pt_regs->flags have no effect, and
>* current_pt_regs()->flags may not match the current task's
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 76b6dbd..c387560 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -6,7 +6,6 @@ config XEN
>   bool "Xen guest support"
>   depends on PARAVIRT
>   select PARAVIRT_CLOCK
> - select XEN_HAVE_PVMMU
>   select XEN_HAVE_VPMU
>   depends on X86_64 || (X86_32 && X86_PAE)
>   depends on X86_LOCAL_APIC && X86_TSC
> @@ -15,18 +14,32 @@ config XEN
> kernel to boot in a paravirtualized environment under the
> Xen hypervisor.
>  
> +config XEN_PV
> + bool "Xen PV guest support"
> + default y
> + depends on XEN

select XEN_HAVE_PVMMU is missing ...

> + help
> +   Support running as a Xen PV guest.
> +
>  config XEN_DOM0
> - def_bool y
> - depends on XEN && PCI_XEN && SWIOTLB_XEN
> + bool "Xen PV Dom0 support"
> + default y
> + depends on XEN_PV && PCI_XEN && SWIOTLB_XEN
>   depends on X86_IO_APIC && ACPI && PCI
> + select XEN_HAVE_PVMMU

... and can be dropped here


Juergen

Re: [PATCH 16/26] IB/ocrdma: Adjust a null pointer check in ocrdma_alloc_resources()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 6:45 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 7 Mar 2017 22:34:33 +0100
>
> The script "checkpatch.pl" pointed information out like the following.
>
> Comparison to NULL could be written "!dev->stag_arr".
>
> Thus fix the affected source code place.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> index 93113feeb2d5..fbf672c79d5f 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> @@ -238,7 +238,7 @@ static int ocrdma_alloc_resources(struct ocrdma_dev *dev)
>
> dev->stag_arr = kcalloc(OCRDMA_MAX_STAG, sizeof(*dev->stag_arr),
> GFP_KERNEL);
> -   if (dev->stag_arr == NULL)
> +   if (!dev->stag_arr)
> goto alloc_err;
>
> ocrdma_alloc_pd_pool(dev);
> --
> 2.12.0
>

Re: [PATCH] x86, kasan: add KASAN checks to atomic operations

[Mark Rutland]

Hi,

On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
> consequently x86/arm64) initially, it becomes more realistic. For the
> tools we don't care about absolute efficiency and this gets rid of
> Will's points (2), (4) and (6) here https://lwn.net/Articles/691295/.
> Re (3) I think rmb/wmb can be reasonably replaced with
> atomic_thread_fence(acquire/release). Re (5) situation with
> correctness becomes better very quickly as more people use them in
> user-space. Since KASAN is not intended to be used in production (or
> at least such build is expected to crash), we can afford to shake out
> any remaining correctness issues in such build. (1) I don't fully
> understand, what exactly is the problem with seq_cst?

I'll have to leave it to Will to have the final word on these; I'm
certainly not familiar enough with the C11 memory model to comment on
(1).

However, w.r.t. (3), I don't think we can substitute rmb() and wmb()
with atomic_thread_fence_acquire() and atomic_thread_fence_release()
respectively on arm64.

The former use barriers with full system scope, whereas the latter may
be limited to the inner shareable domain. While I'm not sure of the
precise intended semantics of wmb() and rmb(), I believe this
substitution would break some cases (e.g. communicating with a
non-coherent master).

Note that regardless, we'd have to special-case __iowmb() to use a full
system barrier.

Also, w.r.t. (5), modulo the lack of atomic instrumentation, people use
KASAN today, with compilers that are known to have bugs in their atomics
(e.g. GCC bug 69875). Thus, we cannot rely on the compiler's
implementation of atomics without introducing a functional regression.

> i'Ve sketched a patch that does it, and did some testing with/without
> KASAN on x86_64.
> 
> In short, it adds include/linux/atomic_compiler.h which is included
> from include/linux/atomic.h when CONFIG_COMPILER_ATOMIC is defined;
> and  is not included when CONFIG_COMPILER_ATOMIC is
> defined.
> For bitops it is similar except that only parts of asm/bitops.h are
> selectively disabled when CONFIG_COMPILER_ATOMIC, because it also
> defines other stuff.
> asm/barriers.h is left intact for now. We don't need it for KASAN. But
> for KTSAN we can do similar thing -- selectively disable some of the
> barriers in asm/barriers.h (e.g. leaving dma_rmb/wmb per arch).
> 
> Such change would allow us to support atomic ops for multiple arches
> for all of KASAN/KTSAN/KMSAN.
> 
> Thoughts?

As in my other reply, I'd prefer that we wrapped the (arch-specific)
atomic implementations such that we can instrument them explicitly in a
core header. That means that the implementation and semantics of the
atomics don't change at all.

Note that we could initially do this just for x86 and arm64), e.g. by
having those explicitly include an 
at the end of their .

For architectures which can use the compiler's atomics, we can allow
them to do so, skipping the redundant explicit instrumentation.

Other than being potentially slower (which we've established we don't
care too much about above), is there a problem with that approach?

Thanks,
Mark.

Re: [PATCH] f2fs: allocate a bio for discarding when actually issuing it

[Christoph Hellwig]

On Tue, Mar 07, 2017 at 06:33:33PM -0800, Jaegeuk Kim wrote:
> Let's allocate a bio when issuing discard commands later.

Does this solve the issue with your queue stalls?

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h|   4 +-
>  fs/f2fs/segment.c | 113 
> --
>  2 files changed, 62 insertions(+), 55 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index a58c2e43bd2a..870bb4d9bc65 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -197,10 +197,12 @@ enum {
>  struct discard_cmd {
>   struct list_head list;  /* command list */
>   struct completion wait; /* compleation */
> + struct block_device *bdev;  /* bdev */
>   block_t lstart; /* logical start address */
> + block_t start;  /* actual start address in dev */
>   block_t len;/* length */
> - struct bio *bio;/* bio */
>   int state;  /* state */
> + int error;  /* bio error */
>  };
>  
>  struct discard_cmd_control {
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 50c65cc4645a..d8f9e6c895cd 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -636,7 +636,8 @@ static void locate_dirty_segment(struct f2fs_sb_info 
> *sbi, unsigned int segno)
>  }
>  
>  static void __add_discard_cmd(struct f2fs_sb_info *sbi,
> - struct bio *bio, block_t lstart, block_t len)
> + struct block_device *bdev, block_t lstart,
> + block_t start, block_t len)
>  {
>   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
>   struct list_head *cmd_list = &(dcc->discard_cmd_list);
> @@ -644,9 +645,9 @@ static void __add_discard_cmd(struct f2fs_sb_info *sbi,
>  
>   dc = f2fs_kmem_cache_alloc(discard_cmd_slab, GFP_NOFS);
>   INIT_LIST_HEAD(>list);
> - dc->bio = bio;
> - bio->bi_private = dc;
> + dc->bdev = bdev;
>   dc->lstart = lstart;
> + dc->start = start;
>   dc->len = len;
>   dc->state = D_PREP;
>   init_completion(>wait);
> @@ -658,22 +659,66 @@ static void __add_discard_cmd(struct f2fs_sb_info *sbi,
>  
>  static void __remove_discard_cmd(struct f2fs_sb_info *sbi, struct 
> discard_cmd *dc)
>  {
> - int err = dc->bio->bi_error;
> -
>   if (dc->state == D_DONE)
>   atomic_dec(&(SM_I(sbi)->dcc_info->submit_discard));
>  
> - if (err == -EOPNOTSUPP)
> - err = 0;
> + if (dc->error == -EOPNOTSUPP)
> + dc->error = 0;
>  
> - if (err)
> + if (dc->error)
>   f2fs_msg(sbi->sb, KERN_INFO,
> - "Issue discard failed, ret: %d", err);
> - bio_put(dc->bio);
> + "Issue discard failed, ret: %d", dc->error);
>   list_del(>list);
>   kmem_cache_free(discard_cmd_slab, dc);
>  }
>  
> +static void f2fs_submit_discard_endio(struct bio *bio)
> +{
> + struct discard_cmd *dc = (struct discard_cmd *)bio->bi_private;
> +
> + complete(>wait);
> + dc->error = bio->bi_error;
> + dc->state = D_DONE;
> + bio_put(bio);
> +}
> +
> +/* this function is copied from blkdev_issue_discard from block/blk-lib.c */
> +static int __submit_discard_cmd(struct discard_cmd *dc)
> +{
> + struct bio *bio = NULL;
> + int err;
> +
> + err = __blkdev_issue_discard(dc->bdev,
> + SECTOR_FROM_BLOCK(dc->start),
> + SECTOR_FROM_BLOCK(dc->len),
> + GFP_NOFS, 0, );
> + if (!err && bio) {
> + bio->bi_private = dc;
> + bio->bi_end_io = f2fs_submit_discard_endio;
> + bio->bi_opf |= REQ_SYNC;
> + submit_bio(bio);
> + }
> + dc->state = D_SUBMIT;
> + return err;
> +}
> +
> +static int __queue_discard_cmd(struct f2fs_sb_info *sbi,
> + struct block_device *bdev, block_t blkstart, block_t blklen)
> +{
> + block_t lblkstart = blkstart;
> +
> + trace_f2fs_issue_discard(bdev, blkstart, blklen);
> +
> + if (sbi->s_ndevs) {
> + int devi = f2fs_target_device_index(sbi, blkstart);
> +
> + blkstart -= FDEV(devi).start_blk;
> + }
> + __add_discard_cmd(sbi, bdev, lblkstart, blkstart, blklen);
> + wake_up(_I(sbi)->dcc_info->discard_wait_queue);
> + return 0;
> +}
> +
>  /* This should be covered by global mutex, _i->sentry_lock */
>  void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, block_t blkaddr)
>  {
> @@ -690,8 +735,7 @@ void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, 
> block_t blkaddr)
>  
>   if (blkaddr == NULL_ADDR) {
>   if (dc->state == D_PREP) {
> - dc->state = D_SUBMIT;
> - submit_bio(dc->bio);
> + __submit_discard_cmd(dc);
>   

[PATCH] futex: move debug_rt_mutex_free_waiter() further down

[Sebastian Andrzej Siewior]

Without this, futex_requeue_pi_signal_restart will trigger

|kernel BUG at locking/rtmutex_common.h:55!
|Call Trace:
| rt_mutex_cleanup_proxy_lock+0x54/0x90
| futex_wait_requeue_pi.constprop.21+0x387/0x4d0
| do_futex+0x289/0xbf0
|RIP: remove_waiter+0x157/0x170 RSP: c9e0fbe0

with BUG  != pointer once this patch is applied.

Signed-off-by: Sebastian Andrzej Siewior 
---
 kernel/futex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 00ec4a01d3f5..73abfe0da4d0 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3046,11 +3046,11 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
WARN_ON(!q.pi_state);
pi_mutex = _state->pi_mutex;
ret = rt_mutex_wait_proxy_lock(pi_mutex, to, _waiter);
-   debug_rt_mutex_free_waiter(_waiter);
 
spin_lock(q.lock_ptr);
if (ret && !rt_mutex_cleanup_proxy_lock(pi_mutex, _waiter))
ret = 0;
+   debug_rt_mutex_free_waiter(_waiter);
 
/*
 * Fixup the pi_state owner and possibly acquire the lock if we
-- 
2.11.0

Re: [PATCH 26/26] IB/ocrdma: Adjust further ten checks for null pointers

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 7:04 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 12:50:14 +0100
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script “checkpatch.pl“ pointed information out like the following.
>
> Comparison to NULL could be written !…
>
> Thus fix affected source code places.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index bfd86fd08847..bd719e7f134e 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -267,7 +267,7 @@ static int ocrdma_add_mmap(struct ocrdma_ucontext *uctx, 
> u64 phy_addr,
> struct ocrdma_mm *mm;
>
> mm = kzalloc(sizeof(*mm), GFP_KERNEL);
> -   if (mm == NULL)
> +   if (!mm)
> return -ENOMEM;
> mm->key.phy_addr = phy_addr;
> mm->key.len = len;
> @@ -1187,7 +1187,7 @@ static int ocrdma_add_qpn_map(struct ocrdma_dev *dev, 
> struct ocrdma_qp *qp)
>  {
> int status = -EINVAL;
>
> -   if (qp->id < OCRDMA_MAX_QP && dev->qp_tbl[qp->id] == NULL) {
> +   if (qp->id < OCRDMA_MAX_QP && !dev->qp_tbl[qp->id]) {
> dev->qp_tbl[qp->id] = qp;
> status = 0;
> }
> @@ -1355,11 +1355,11 @@ static int ocrdma_alloc_wr_id_tbl(struct ocrdma_qp 
> *qp)
>  {
> qp->wqe_wr_id_tbl = kcalloc(qp->sq.max_cnt, 
> sizeof(*qp->wqe_wr_id_tbl),
> GFP_KERNEL);
> -   if (qp->wqe_wr_id_tbl == NULL)
> +   if (!qp->wqe_wr_id_tbl)
> return -ENOMEM;
> qp->rqe_wr_id_tbl = kcalloc(qp->rq.max_cnt, 
> sizeof(*qp->rqe_wr_id_tbl),
> GFP_KERNEL);
> -   if (qp->rqe_wr_id_tbl == NULL)
> +   if (!qp->rqe_wr_id_tbl)
> return -ENOMEM;
>
> return 0;
> @@ -1419,7 +1419,7 @@ struct ib_qp *ocrdma_create_qp(struct ib_pd *ibpd,
> goto gen_err;
> }
> ocrdma_set_qp_init_params(qp, pd, attrs);
> -   if (udata == NULL)
> +   if (!udata)
> qp->cap_flags |= (OCRDMA_QP_MW_BIND | OCRDMA_QP_LKEY0 |
> OCRDMA_QP_FAST_REG);
>
> @@ -1431,7 +1431,7 @@ struct ib_qp *ocrdma_create_qp(struct ib_pd *ibpd,
> goto mbx_err;
>
> /* user space QP's wr_id table are managed in library */
> -   if (udata == NULL) {
> +   if (!udata) {
> status = ocrdma_alloc_wr_id_tbl(qp);
> if (status)
> goto map_err;
> @@ -1892,11 +1892,11 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
> if (status)
> goto err;
>
> -   if (udata == NULL) {
> +   if (!udata) {
> srq->rqe_wr_id_tbl = kcalloc(srq->rq.max_cnt,
>  sizeof(*srq->rqe_wr_id_tbl),
>  GFP_KERNEL);
> -   if (srq->rqe_wr_id_tbl == NULL)
> +   if (!srq->rqe_wr_id_tbl)
> goto arm_err;
>
> srq->bit_fields_len = (srq->rq.max_cnt / 32) +
> @@ -1904,7 +1904,7 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
> srq->idx_bit_fields = kmalloc_array(srq->bit_fields_len,
> 
> sizeof(*srq->idx_bit_fields),
> GFP_KERNEL);
> -   if (srq->idx_bit_fields == NULL)
> +   if (!srq->idx_bit_fields)
> goto arm_err;
> memset(srq->idx_bit_fields, 0xff,
>srq->bit_fields_len * sizeof(*srq->idx_bit_fields));
> @@ -2878,7 +2878,7 @@ static int ocrdma_poll_hwcq(struct ocrdma_cq *cq, int 
> num_entries,
> if (qpn == 0)
> goto skip_cqe;
> qp = dev->qp_tbl[qpn];
> -   BUG_ON(qp == NULL);
> +   BUG_ON(!qp);
>
> expand = is_cqe_for_sq(cqe)
>  ? ocrdma_poll_scqe(qp, cqe, ibwc, , )
> --
> 2.12.0
>

Re: out of range LBA using sg_raw

[Christoph Hellwig]

Hi Kashyap,

for SG_IO passthrough requests we can't validate command validity
for commands as the block layer treats them as opaque.  The SCSI
device implementation needs to handle incorrect parameter to be
robust.

For your fast path bypass the megaraid driver assumes part of the
SCSI device implementation, so it will have to check for validity.

Re: [PATCH V12 10/10] arm/arm64: KVM: add guest SEA support

[James Morse]

On 07/03/17 17:58, Baicar, Tyler wrote:
> On 3/7/2017 4:48 AM, James Morse wrote:
>> On 06/03/17 20:45, Tyler Baicar wrote:
>>> Currently external aborts are unsupported by the guest abort
>>> handling. Add handling for SEAs so that the host kernel reports
>>> SEAs which occur in the guest kernel.

>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>> index a5265ed..f3608c9 100644
>>> --- a/arch/arm/kvm/mmu.c
>>> +++ b/arch/arm/kvm/mmu.c
>>> @@ -1444,8 +1463,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu,
>>> struct kvm_run *run)
>>> /* Check the stage-2 fault is trans. fault or write fault */
>>>   fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
>>> -if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
>>> -fault_status != FSC_ACCESS) {
>>> +
>>> +/* The host kernel will handle the synchronous external abort. There
>>> + * is no need to pass the error into the guest.
>>> + */
>>> +if (is_abort_synchronous(fault_status)) {
>>> +if(handle_guest_sea((unsigned long)fault_ipa,
>>> +kvm_vcpu_get_hsr(vcpu))) {
>>
>> ... Looking further up in this function:
>>> is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
>>> if (unlikely(!is_iabt && kvm_vcpu_dabt_isextabt(vcpu))) {
>>> kvm_inject_vabt(vcpu);
>>> return 1;
>>> }
>> ... so external data aborts will have already been 'claimed' by kvm and dealt
>> with, and we already have a helper for spotting external aborts. (sorry I 
>> didn't
>> spot it earlier).
>>
>> We need to do the handle_guest_sea() before this code.
>>
>> kvm_inject_vabt() makes an SError interrupt pending for the guest. This 
>> makes a
>> synchronous error asynchronous as the guest may have SError interrupts 
>> masked.
>>
>> I guess this was the best that could be done at the time of (4055710baca8
>> "arm/arm64: KVM: Inject virtual abort when guest exits on external abort"), 
>> but
>> in the light of this firmware-first handling, I'm not sure its the right 
>> thing
>> to do.
>>
>> Is it possible for handle_guest_sea() to return whether it actually found any
>> work to do? If there was none I think we should keep this kvm_inject_vabt() 
>> as
>> it is the existing behaviour.

> Yes, I'll move the handle_guest_sea() call above this. My testing didn't call
> into that if statement for some reason...it made it to the handle_guest_sea()
> call successfully.

I guess you're not using data aborts for testing then.


> If there is no work for the GHES code to do it will return and could still 
> make
> the kvm_inject_vabt() call. It will also return and do that same thing if the
> error was not fatal in GHES...would that be an issue?

We might inject a superfluous SError Interrupt in that case.

For memory errors we may do the whole unmapping and signalling thing to handle
the fault. For recoverable faults, QEMU can generate its own CPER records for
the guest and do the work to notify the guest. Everything looks fine until the
guest gets the extra SError interrupt.

If there is firmware-first RAS data, we should skip the injected SError
Interrupt as the host's RAS code should choose what to do. If this Synchronous
External Abort was nothing to do with RAS, we should inject the SError interrupt
as it's the existing behaviour, and not all platforms will have this Synchronous
External Abort mechanism.

x86's APEI NMI needs to know if the NMI was due to RAS, so we can probably
borrow the same trick. ghes_notify_nmi() calls ghes_read_estatus() for each
struct ghes. If they all return an error, there was no work to do.


(I assume firmware will only generate one of these at a time, so there is no
risk of one list-walker processing two entries, then the second finding nothing
to do?)


Thanks,

James


>>> +kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx
>>> ESR_EL2=%#lx\n",
>>> +kvm_vcpu_trap_get_class(vcpu),
>>> +(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
>>> +(unsigned long)kvm_vcpu_get_hsr(vcpu));
>>> +return -EFAULT;
>>> +}
>>> +} else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
>>> +   fault_status != FSC_ACCESS) {
>>>   kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
>>>   kvm_vcpu_trap_get_class(vcpu),
>>>   (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
>>

[PATCH v5 06/19] mlx5: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
 include/linux/mlx5/driver.h   |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c 
b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index caa837e..6eef344 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1061,7 +1061,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct 
mlx5_core_dev *dev,
if (!mailbox)
return ERR_PTR(-ENOMEM);
 
-   mailbox->buf = pci_pool_zalloc(dev->cmd.pool, flags,
+   mailbox->buf = dma_pool_zalloc(dev->cmd.pool, flags,
   >dma);
if (!mailbox->buf) {
mlx5_core_dbg(dev, "failed allocation\n");
@@ -1076,7 +1076,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct 
mlx5_core_dev *dev,
 static void free_cmd_box(struct mlx5_core_dev *dev,
 struct mlx5_cmd_mailbox *mailbox)
 {
-   pci_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
+   dma_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
kfree(mailbox);
 }
 
@@ -1696,7 +1696,8 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
return -EINVAL;
}
 
-   cmd->pool = pci_pool_create("mlx5_cmd", dev->pdev, size, align, 0);
+   cmd->pool = dma_pool_create("mlx5_cmd", >pdev->dev, size, align,
+   0);
if (!cmd->pool)
return -ENOMEM;
 
@@ -1786,7 +1787,7 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
free_cmd_page(dev, cmd);
 
 err_free_pool:
-   pci_pool_destroy(cmd->pool);
+   dma_pool_destroy(cmd->pool);
 
return err;
 }
@@ -1800,6 +1801,6 @@ void mlx5_cmd_cleanup(struct mlx5_core_dev *dev)
destroy_workqueue(cmd->wq);
destroy_msg_cache(dev);
free_cmd_page(dev, cmd);
-   pci_pool_destroy(cmd->pool);
+   dma_pool_destroy(cmd->pool);
 }
 EXPORT_SYMBOL(mlx5_cmd_cleanup);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 48d8b66..0e33e65 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -284,7 +284,7 @@ struct mlx5_cmd {
struct semaphore pages_sem;
int mode;
struct mlx5_cmd_work_ent *ent_arr[MLX5_MAX_COMMANDS];
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct mlx5_cmd_debug dbg;
struct cmd_msg_cache cache[MLX5_NUM_COMMAND_CACHES];
int checksum_disabled;
-- 
2.9.3

[PATCH v5 07/19] wireless: ipw2200: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 5ef3c5c..93dfe47 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -3211,7 +3211,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
struct fw_chunk *chunk;
int total_nr = 0;
int i;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
void **virts;
dma_addr_t *phys;
 
@@ -3228,9 +3228,10 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
kfree(virts);
return -ENOMEM;
}
-   pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
+   pool = dma_pool_create("ipw2200", >pci_dev->dev, CB_MAX_LENGTH, 0,
+  0);
if (!pool) {
-   IPW_ERROR("pci_pool_create failed\n");
+   IPW_ERROR("dma_pool_create failed\n");
kfree(phys);
kfree(virts);
return -ENOMEM;
@@ -3255,7 +3256,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
 
nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
for (i = 0; i < nr; i++) {
-   virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
+   virts[total_nr] = dma_pool_alloc(pool, GFP_KERNEL,
 [total_nr]);
if (!virts[total_nr]) {
ret = -ENOMEM;
@@ -3299,9 +3300,9 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
}
  out:
for (i = 0; i < total_nr; i++)
-   pci_pool_free(pool, virts[i], phys[i]);
+   dma_pool_free(pool, virts[i], phys[i]);
 
-   pci_pool_destroy(pool);
+   dma_pool_destroy(pool);
kfree(phys);
kfree(virts);
 
-- 
2.9.3

Re: out of range LBA using sg_raw

[Martin K. Petersen]

> "Kashyap" == Kashyap Desai  writes:

Kashyap,

Kashyap> I am just curious to know how badly we have to scrutinize each
Kashyap> packet before sending to Fast Path as we are in IO path and
Kashyap> recommend only important checks to be added.

As Christoph pointed out, when the fast path is in use you assume the
role of the SCSI device. And therefore it is your responsibility to
ensure that the VD's capacity and other relevant constraints are being
honored. Just like the MR firmware and any attached disks would.

It is a feature that there is no sanity checking in the sg interface.
The intent is to be able to pass through commands directly to a device
and have the device act upon them. Including fail them if they don't
make any sense.

PS. I'm really no fan of the fast path. It's super messy to have the VD
layout handled in two different places.

-- 
Martin K. Petersen  Oracle Linux Engineering