[PATCH] ASoC: Intel: constify snd_compr_codec_caps structures

2017-08-11 Thread Julia Lawall
These snd_compr_codec_caps structures are only copied into other
structures, so they can be const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 sound/soc/intel/atom/sst/sst_drv_interface.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/atom/sst/sst_drv_interface.c 
b/sound/soc/intel/atom/sst/sst_drv_interface.c
index ce689c5..71af544 100644
--- a/sound/soc/intel/atom/sst/sst_drv_interface.c
+++ b/sound/soc/intel/atom/sst/sst_drv_interface.c
@@ -407,7 +407,7 @@ static int sst_cdev_caps(struct snd_compr_caps *caps)
return 0;
 }
 
-static struct snd_compr_codec_caps caps_mp3 = {
+static const struct snd_compr_codec_caps caps_mp3 = {
.num_descriptors = 1,
.descriptor[0].max_ch = 2,
.descriptor[0].sample_rates[0] = 48000,
@@ -424,7 +424,7 @@ static int sst_cdev_caps(struct snd_compr_caps *caps)
.descriptor[0].formats = 0,
 };
 
-static struct snd_compr_codec_caps caps_aac = {
+static const struct snd_compr_codec_caps caps_aac = {
.num_descriptors = 2,
.descriptor[1].max_ch = 2,
.descriptor[0].sample_rates[0] = 48000,



[PATCH] omapfb: constify omap_video_timings structures

2017-08-11 Thread Julia Lawall
These omap_video_timings structures are only copied into other
structures, so they can be const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |2 +-
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
index f14691c..6cd759c 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
@@ -18,7 +18,7 @@
 
 #include 
 
-static struct omap_video_timings lb035q02_timings = {
+static const struct omap_video_timings lb035q02_timings = {
.x_res = 320,
.y_res = 240,
 
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index b529a8c..57e9e14 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -41,7 +41,7 @@ struct panel_drv_data {
struct spi_device *spi_dev;
 };
 
-static struct omap_video_timings td028ttec1_panel_timings = {
+static const struct omap_video_timings td028ttec1_panel_timings = {
.x_res  = 480,
.y_res  = 640,
.pixelclock = 22153000,



Re: [PATCH] ALSA: seq: 2nd attempt at fixing race creating a q

2017-08-11 Thread Takashi Iwai
On Fri, 11 Aug 2017 23:23:42 +0200,
Daniel Mentz wrote:
> 
> On Fri, Aug 11, 2017 at 7:42 AM, Takashi Iwai  wrote:
> >
> > On Fri, 11 Aug 2017 05:07:34 +0200,
> > Daniel Mentz wrote:
> > >
> > > commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at
> > > creating a queue") attempted to fix a race reported by syzkaller. That
> > > fix has been described as follows:
> > >
> > > "
> > > When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
> > > new queue element to the public list before referencing it.  Thus the
> > > queue might be deleted before the call of snd_seq_queue_use(), and it
> > > results in the use-after-free error, as spotted by syzkaller.
> > >
> > > The fix is to reference the queue object at the right time.
> > > "
> > >
> > > The last phrase in that commit message refers to calling queue_use(q, 
> > > client,
> > > 1) which increments queue->clients, but that does not prevent the
> > > DELETE_QUEUE ioctl() and queue_delete() from kfree()ing the queue.
> > > Hence, the commit is not effective at preventing the race.
> >
> > kfree() is performed only after snd_use_lock_sync(), thus by acquiring
> > snd_use_lock() it doesn't race.  If it were already deleted,
> > queue_use() returns NULL so it's also fine.
> 
> queue_use() is defined to return void. I am assuming you're referring
> to queueptr().
> 
> Where do you acquire the snd_use_lock i.e. where do you call
> snd_use_lock_use()? My understanding is that it's called from
> queueptr(). With that said, there is a tiny gap between the new queue
> being added to the list in queue_list_add() (from
> snd_seq_queue_alloc()) and the call to queueptr() in
> snd_seq_ioctl_create_queue(). syzkaller specifically points to the
> last instruction "return q->queue;" in snd_seq_queue_alloc(). This is
> *after* q has been added to the list (and is therefore visible to
> other threads) but *before* it has been locked through
> snd_seq_ioctl_create_queue()->queueptr()->snd_use_lock_use(). Hence,
> there is a possibility that the pointer q is no longer valid.
> You could capture the return value from queue_list_add() which is
> identical to q->queue and then return that. However, the other issue
> is that queueptr() indeed returns NULL if the queue with that index
> has been deleted, but it's theoretically possible that the queue has
> been deleted and a *different* been created that now occupies the same
> spot in the queue_list.

OK, now I understood.  It's a small race window between
queue_list_add() and queueptr().  This should be clarified better in
the description.  No too much details are needed.  The only point is 
where the race window is opened against which.

> > Or do you actually see any crash or the wild behavior?
> 
> syzkaller reported a crash:

Then it's a real bug, so need to be fixed quickly.
Could you rephrase your changelog text including the crash information 
briefly, and resubmit?  The code change itself looks good.


thanks,

Takashi


[PATCH 0/6] constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

---

 drivers/misc/genwqe/card_base.c  |2 +-
 drivers/scsi/aacraid/linit.c |2 +-
 drivers/scsi/be2iscsi/be_main.c  |2 +-
 drivers/scsi/bfa/bfad.c  |2 +-
 drivers/scsi/csiostor/csio_init.c|2 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)


[PATCH 4/6] scsi: be2iscsi: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/scsi/be2iscsi/be_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index b4542e7..511732a 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -5786,7 +5786,7 @@ static void beiscsi_remove(struct pci_dev *pcidev)
 }
 
 
-static struct pci_error_handlers beiscsi_eeh_handlers = {
+static const struct pci_error_handlers beiscsi_eeh_handlers = {
.error_detected = beiscsi_eeh_err_detected,
.slot_reset = beiscsi_eeh_reset,
.resume = beiscsi_eeh_resume,



[PATCH 3/6] scsi: aacraid: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/scsi/aacraid/linit.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index a8dedc3..2b978d8 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -2070,7 +2070,7 @@ static void aac_pci_resume(struct pci_dev *pdev)
dev_err(&pdev->dev, "aacraid: PCI error - resume\n");
 }
 
-static struct pci_error_handlers aac_pci_err_handler = {
+static const struct pci_error_handlers aac_pci_err_handler = {
.error_detected = aac_pci_error_detected,
.mmio_enabled   = aac_pci_mmio_enabled,
.slot_reset = aac_pci_slot_reset,



Re: [PATCH] [RFC] vm: add a syscall to map a process memory into a pipe

2017-08-11 Thread Andrei Vagin
On Thu, Aug 10, 2017 at 09:42:44PM +0200, Jann Horn wrote:
> On Thu, Aug 10, 2017 at 8:46 PM, Andrei Vagin  wrote:
> > It is a hybrid of process_vm_readv() and vmsplice().
> >
> > vmsplice can map memory from a current address space into a pipe.
> > process_vm_readv can read memory of another process.
> [...]
> > +/*
> > + * Map pages from a specified task into a pipe
> > + */
> > +static int remote_single_vec_to_pipe(struct task_struct *task,
> > +   struct mm_struct *mm,
> > +   const struct iovec *rvec,
> > +   struct pipe_inode_info *pipe,
> > +   unsigned int flags,
> > +   size_t *total)
> > +{
> > +   struct pipe_buffer buf = {
> > +   .ops = &user_page_pipe_buf_ops,
> > +   .flags = flags
> > +   };
> [...]
> > +   while (nr_pages) {
> [...]
> > +   /*
> > +* Get the pages we're interested in.  We must
> > +* access remotely because task/mm might not
> > +* current/current->mm
> > +*/
> > +   down_read(&mm->mmap_sem);
> > +   pages = get_user_pages_remote(task, mm, pa, pages, flags,
> > + process_pages, NULL, &locked);
> 
> This fifth "flags" argument of get_user_pages_remote() should contain
> GUP flags (FOLL_*), but it looks like you're actually passing in 0 or
> PIPE_BUF_FLAG_GIFT, which will be interpreted as FOLL_GET?
> (See the snippets quoted below.) This looks like a bug.
> 
> Maybe use a more meaningful variable name than "flags".

Good catch. I will fix and rename the variable. get_user_pages_remote
has to be called with zero flags here. Thank you.

> 
> > +static ssize_t remote_iovec_to_pipe(struct task_struct *task,
> > +   struct mm_struct *mm,
> > +   const struct iovec *rvec,
> > +   unsigned long riovcnt,
> > +   struct pipe_inode_info *pipe,
> > +   unsigned int flags)
> > +{
> [...]
> > +   ret = remote_single_vec_to_pipe(
> > +   task, mm, &rvec[i], pipe, flags, &total);
> [...]
> > +}
> > +
> > +static long process_vmsplice_to_pipe(struct task_struct *task,
> > +   struct mm_struct *mm, struct file *file,
> > +   const struct iovec __user *uiov,
> > +   unsigned long nr_segs, unsigned int flags)
> > +{
> [...]
> > +   unsigned int buf_flag = 0;
> [...]
> > +   if (flags & SPLICE_F_GIFT)
> > +   buf_flag = PIPE_BUF_FLAG_GIFT;
> [...]
> > +   if (!ret)
> > +   ret = remote_iovec_to_pipe(task, mm, iov,
> > +   nr_segs, pipe, buf_flag);
> [...]
> > +}


[PATCH 5/6] [SCSI] csiostor: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/scsi/csiostor/csio_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index 28a9c7d..ab4fbcf 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -1168,7 +1168,7 @@ static void csio_remove_one(struct pci_dev *pdev)
dev_err(&pdev->dev, "resume of device failed: %d\n", rv);
 }
 
-static struct pci_error_handlers csio_err_handler = {
+static const struct pci_error_handlers csio_err_handler = {
.error_detected = csio_pci_error_detected,
.slot_reset = csio_pci_slot_reset,
.resume = csio_pci_resume,



[PATCH 1/6] scsi: mpt3sas: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 22998cb..52c163f 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -9277,7 +9277,7 @@ bool scsih_ncq_prio_supp(struct scsi_device *sdev)
 };
 MODULE_DEVICE_TABLE(pci, mpt3sas_pci_table);
 
-static struct pci_error_handlers _mpt3sas_err_handler = {
+static const struct pci_error_handlers _mpt3sas_err_handler = {
.error_detected = scsih_pci_error_detected,
.mmio_enabled   = scsih_pci_mmio_enabled,
.slot_reset = scsih_pci_slot_reset,



[PATCH 6/6] bfa: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/scsi/bfa/bfad.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 5caf5f3..2861694 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1683,7 +1683,7 @@ struct pci_device_id bfad_id_table[] = {
 /*
  * PCI error recovery handlers.
  */
-static struct pci_error_handlers bfad_err_handler = {
+static const struct pci_error_handlers bfad_err_handler = {
.error_detected = bfad_pci_error_detected,
.slot_reset = bfad_pci_slot_reset,
.mmio_enabled = bfad_pci_mmio_enabled,



[PATCH 2/6] GenWQE: constify pci_error_handlers structures

2017-08-11 Thread Julia Lawall
These pci_error_handlers structures are only stored in the err_handler
field of a pci_driver structure, and this field is declared as const.  Thus
the pci_error_handlers structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/misc/genwqe/card_base.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/genwqe/card_base.c b/drivers/misc/genwqe/card_base.c
index 4fd21e8..8650046 100644
--- a/drivers/misc/genwqe/card_base.c
+++ b/drivers/misc/genwqe/card_base.c
@@ -1333,7 +1333,7 @@ static int genwqe_sriov_configure(struct pci_dev *dev, 
int numvfs)
return 0;
 }
 
-static struct pci_error_handlers genwqe_err_handler = {
+static const struct pci_error_handlers genwqe_err_handler = {
.error_detected = genwqe_err_error_detected,
.mmio_enabled   = genwqe_err_result_none,
.slot_reset = genwqe_err_slot_reset,



[PATCH 0/2] drivers: make regmap_irq_chip const

2017-08-11 Thread Bhumika Goyal
Make these structures const. Done using Coccinelle.

Bhumika Goyal (2):
  mfd: make regmap_irq_chip const
  gpio: make regmap_irq_chip const

 drivers/gpio/gpio-max77620.c   | 2 +-
 drivers/mfd/bd9571mwv.c| 2 +-
 drivers/mfd/intel_soc_pmic_bxtwc.c | 2 +-
 drivers/mfd/tps65086.c | 2 +-
 drivers/mfd/tps65090.c | 2 +-
 drivers/mfd/tps65218.c | 2 +-
 drivers/mfd/tps65912-core.c| 2 +-
 drivers/mfd/tps80031.c | 2 +-
 drivers/mfd/twl6040.c  | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

-- 
1.9.1



[PATCH 2/2] gpio: make regmap_irq_chip const

2017-08-11 Thread Bhumika Goyal
Make the structure const as it is only passed to the function
devm_regmap_add_irq_chip having the corresponding argument as const.
Done using Coccinelle.

Signed-off-by: Bhumika Goyal 
---
 drivers/gpio/gpio-max77620.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
index 743459d..538bce4 100644
--- a/drivers/gpio/gpio-max77620.c
+++ b/drivers/gpio/gpio-max77620.c
@@ -82,7 +82,7 @@ struct max77620_gpio {
},
 };
 
-static struct regmap_irq_chip max77620_gpio_irq_chip = {
+static const struct regmap_irq_chip max77620_gpio_irq_chip = {
.name = "max77620-gpio",
.irqs = max77620_gpio_irqs,
.num_irqs = ARRAY_SIZE(max77620_gpio_irqs),
-- 
1.9.1



[PATCH 1/2] mfd: make regmap_irq_chip const

2017-08-11 Thread Bhumika Goyal
Make these const as they are either passed to the function
devm_regmap_add_irq_chip or regmap_add_irq_chip having the corresponding
arguments as const.
Done using Coccinelle.

Signed-off-by: Bhumika Goyal 
---
 drivers/mfd/bd9571mwv.c| 2 +-
 drivers/mfd/intel_soc_pmic_bxtwc.c | 2 +-
 drivers/mfd/tps65086.c | 2 +-
 drivers/mfd/tps65090.c | 2 +-
 drivers/mfd/tps65218.c | 2 +-
 drivers/mfd/tps65912-core.c| 2 +-
 drivers/mfd/tps80031.c | 2 +-
 drivers/mfd/twl6040.c  | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 64e088d..6c1668c 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -96,7 +96,7 @@
   BD9571MWV_INT_INTREQ_BKUP_TRG_INT),
 };
 
-static struct regmap_irq_chip bd9571mwv_irq_chip = {
+static const struct regmap_irq_chip bd9571mwv_irq_chip = {
.name   = "bd9571mwv",
.status_base= BD9571MWV_INT_INTREQ,
.mask_base  = BD9571MWV_INT_INTMASK,
diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index 15bc052..7396d8a 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -138,7 +138,7 @@ enum bxtwc_irqs_crit {
REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 0, 0x03),
 };
 
-static struct regmap_irq_chip bxtwc_regmap_irq_chip = {
+static const struct regmap_irq_chip bxtwc_regmap_irq_chip = {
.name = "bxtwc_irq_chip",
.status_base = BXTWC_IRQLVL1,
.mask_base = BXTWC_MIRQLVL1,
diff --git a/drivers/mfd/tps65086.c b/drivers/mfd/tps65086.c
index 43119a6..24b5999 100644
--- a/drivers/mfd/tps65086.c
+++ b/drivers/mfd/tps65086.c
@@ -51,7 +51,7 @@
REGMAP_IRQ_REG(TPS65086_IRQ_FAULT, 0, TPS65086_IRQ_FAULT_MASK),
 };
 
-static struct regmap_irq_chip tps65086_irq_chip = {
+static const struct regmap_irq_chip tps65086_irq_chip = {
.name = "tps65086",
.status_base = TPS65086_IRQ,
.mask_base = TPS65086_IRQ_MASK,
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index d7ec318..48d93b2 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -130,7 +130,7 @@ enum tps65090_cells {
},
 };
 
-static struct regmap_irq_chip tps65090_irq_chip = {
+static const struct regmap_irq_chip tps65090_irq_chip = {
.name = "tps65090",
.irqs = tps65090_irqs,
.num_irqs = ARRAY_SIZE(tps65090_irqs),
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 13834a0..269f90ce 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -195,7 +195,7 @@ int tps65218_clear_bits(struct tps65218 *tps, unsigned int 
reg,
},
 };
 
-static struct regmap_irq_chip tps65218_irq_chip = {
+static const struct regmap_irq_chip tps65218_irq_chip = {
.name = "tps65218",
.irqs = tps65218_irqs,
.num_irqs = ARRAY_SIZE(tps65218_irqs),
diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
index f33567b..dbc71f0 100644
--- a/drivers/mfd/tps65912-core.c
+++ b/drivers/mfd/tps65912-core.c
@@ -65,7 +65,7 @@
REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_LDO10, 3, 
TPS65912_INT_STS4_PGOOD_LDO10),
 };
 
-static struct regmap_irq_chip tps65912_irq_chip = {
+static const struct regmap_irq_chip tps65912_irq_chip = {
.name = "tps65912",
.irqs = tps65912_irqs,
.num_irqs = ARRAY_SIZE(tps65912_irqs),
diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index 0812df3..7ce4bc8 100644
--- a/drivers/mfd/tps80031.c
+++ b/drivers/mfd/tps80031.c
@@ -114,7 +114,7 @@ struct tps80031_pupd_data {
[TPS80031_INT_RES2] = TPS80031_IRQ(C, 7),
 };
 
-static struct regmap_irq_chip tps80031_irq_chip = {
+static const struct regmap_irq_chip tps80031_irq_chip = {
.name = "tps80031",
.irqs = tps80031_main_irqs,
.num_irqs = ARRAY_SIZE(tps80031_main_irqs),
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index d66502d..a1b6521 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -621,7 +621,7 @@ static bool twl6040_writeable_reg(struct device *dev, 
unsigned int reg)
{ .reg_offset = 0, .mask = TWL6040_READYINT, },
 };
 
-static struct regmap_irq_chip twl6040_irq_chip = {
+static const struct regmap_irq_chip twl6040_irq_chip = {
.name = "twl6040",
.irqs = twl6040_irqs,
.num_irqs = ARRAY_SIZE(twl6040_irqs),
-- 
1.9.1



Re: [PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

2017-08-11 Thread Lokesh Vutla


On Thursday 10 August 2017 05:30 AM, Rob Herring wrote:
> On Tue, Aug 01, 2017 at 10:11:14AM +0530, Lokesh Vutla wrote:
>> Update ti,edma binding documentation to reflect 66AK2G specific
>> properties.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 95 
>> +--
>>  1 file changed, 90 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
>> b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 18090e7226b4..05fe2931d025 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -9,7 +9,12 @@ execute the actual DMA tansfer.
>>  eDMA3 Channel Controller
>>  
>>  Required properties:
>> -- compatible:   "ti,edma3-tpcc" for the channel controller(s)
>> +
>> +- compatible:   Should be:
>> +- "ti,edma3-tpcc" for the channel controller(s) on OMAP,
>> +  AM33xx and AM43xx SoCs.
>> +- "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
> 
> If power-domains is mandatory, I don't think the fallback is 
> appropriate. Or do you expect it to work if the driver ignores the power 
> domain?

power-domains is required for pm_runtime_*() apis to work on 66AK2G.
Driver doesn't handle this property separately. Driver still works with
"ti,edma3-tpcc" compatible.

Thanks and regards,
Lokesh


[PATCH 1/3] bus: kconfig: Enable SUNXI RSB for arm64

2017-08-11 Thread Jagan Teki
From: Jagan Teki 

Sunxi arm64 doesn't have separate configs for
h5 and a64 so enable SUNXI_RSB bus for ARM64.

Signed-off-by: Jagan Teki 
---
 drivers/bus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 2408ea3..ae3d8f3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -132,7 +132,7 @@ config SIMPLE_PM_BUS
 
 config SUNXI_RSB
tristate "Allwinner sunXi Reduced Serial Bus Driver"
- default MACH_SUN8I || MACH_SUN9I
+ default MACH_SUN8I || MACH_SUN9I || ARM64
  depends on ARCH_SUNXI
  select REGMAP
  help
-- 
2.7.4



[PATCH 3/3] arm64: defconfig: Enable CONFIG_REGULATOR_AXP20X

2017-08-11 Thread Jagan Teki
From: Jagan Teki 

X-POWERS AXP20X PMIC Regulators is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index a11fce7..d8f23c5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -323,6 +323,7 @@ CONFIG_MFD_MAX77620=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
+CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_FAN53555=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
-- 
2.7.4



[PATCH 2/3] arm64: defconfig: Enable CONFIG_MFD_AXP20X_RSB

2017-08-11 Thread Jagan Teki
From: Jagan Teki 

X-Powers AXP series PMICs with RSB is need for sunxi a64
so make it default in defconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 33d2d62..a11fce7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_RENESAS_WDT=y
 CONFIG_BCM2835_WDT=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_CROS_EC_SPI=y
-- 
2.7.4



[PATCH] arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

2017-08-11 Thread Jagan Teki
From: Jagan Teki 

Since current tree support AXP803 regulators, replace
fixed regulator with AXP803 dcdc1 regulator.

Tested on pine64.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 122b5d8..604cdae 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -62,13 +62,6 @@
chosen {
stdout-path = "serial0:115200n8";
};
-
-   reg_vcc3v3: vcc3v3 {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   };
 };
 
 &ehci0 {
@@ -109,7 +102,7 @@
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
-   vmmc-supply = <®_vcc3v3>;
+   vmmc-supply = <®_dcdc1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
disable-wp;
-- 
2.7.4



[PATCH v5] arm64: allwinner: a64: Add initial NanoPi A64 support

2017-08-11 Thread Jagan Teki
From: Jagan Teki 

NanoPi A64 is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner A64 SOC.

Nanopi A64 features
- Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
- 1GB DDR3 RAM
- MicroSD
- Gigabit Ethernet (RTL8211E)
- Wi-Fi 802.11b/g/n
- IR receiver
- Audio In/Out
- Video In/Out
- Serial Debug Port
- microUSB 5V 2A DC power-supply

Signed-off-by: Jagan Teki 
---
Changes for v5:
- Add AXP803 PMIC regulator support. 
Changes for v4:
- Rebased and droped wi-fi related nodes, since it require
  other changes to taken care.
Changes for v3:
- Fix to use mmc1 for SDIO instead of mmc2
- Replace buswidth by 4 instead of 8 mmc1
- Drop cap-mmc-hw-reset for mmc1
Changes for v2:
- Added ohci0, ehci0, ohic1, ehci1, usbphy.
- Tested on A64

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 205 +
 2 files changed, 206 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 108f12c..c997b5c 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
new file mode 100644
index 000..de98da1
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi A64";
+   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&ehci0 {
+   status = "okay";
+};
+
+&ehci1 {
+   status = "okay";
+};
+
+&i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins>;
+   status = "okay";
+};
+
+&i2c1_pins {
+   bias-pull-up;
+};
+
+&mmc0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins>;
+   vmmc-supply = <®_dcdc1>;
+   cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   disable-wp;
+   bus-width = <4>;
+   status = "okay";
+};
+
+&ohci0 {
+   status = "okay";
+};
+
+&ohci1 {
+   status = "okay";
+};
+
+&r_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <&r_intc>;
+   interrupts = <0 IRQ_T

[PATCH 2/3] libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs

2017-08-11 Thread Dan Williams
From: Oliver O'Halloran 

The alignment of a DAX and PFN regions dictates the page sizes that can
be used to map the region. Even if the hardware page sizes are known the
actual range of supported page sizes that can be used with DAX depends
on the kernel configuration. As a result it's best that the kernel
advertises the alignments that should be used with these region types.

This patch adds the 'supported_alignments' region attribute to expose
this information to userspace.

Signed-off-by: Oliver O'Halloran 
[djbw: integrate with nd_size_select_show() rename and other fixups]
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 2ae9a000b090..610dd17a17f6 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -111,6 +111,26 @@ static ssize_t align_show(struct device *dev,
return sprintf(buf, "%ld\n", nd_pfn->align);
 }
 
+static const unsigned long *nd_pfn_supported_alignments(void)
+{
+   /*
+* This needs to be a local variable because the *_SIZE macros
+* aren't always constants.
+*/
+   static const unsigned long supported_alignments[] = {
+   PAGE_SIZE,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   HPAGE_PMD_SIZE,
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+   HPAGE_PUD_SIZE,
+#endif
+#endif
+   0,
+   };
+
+   return supported_alignments;
+}
+
 static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
 {
unsigned long val;
@@ -260,6 +280,13 @@ static ssize_t size_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(size);
 
+static ssize_t supported_alignments_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return nd_size_select_show(0, nd_pfn_supported_alignments(), buf);
+}
+static DEVICE_ATTR_RO(supported_alignments);
+
 static struct attribute *nd_pfn_attributes[] = {
&dev_attr_mode.attr,
&dev_attr_namespace.attr,
@@ -267,6 +294,7 @@ static struct attribute *nd_pfn_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_size.attr,
+   &dev_attr_supported_alignments.attr,
NULL,
 };
 



[PATCH 3/3] libnvdimm, pfn, dax: limit namespace alignments to the supported set

2017-08-11 Thread Dan Williams
Now that we properly advertise the supported pte, pmd, and pud sizes,
restrict the supported alignments that can be set on a namespace. This
assumes that userspace was not previously relying on the ability to set
odd alignments. At least ndctl only ever supported setting the namespace
alignment to 4K, 2M, or 1G.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pfn_devs.c |   23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 610dd17a17f6..f447a1eb919d 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -131,26 +131,6 @@ static const unsigned long 
*nd_pfn_supported_alignments(void)
return supported_alignments;
 }
 
-static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)
-{
-   unsigned long val;
-   int rc;
-
-   rc = kstrtoul(buf, 0, &val);
-   if (rc)
-   return rc;
-
-   if (!is_power_of_2(val) || val < PAGE_SIZE || val > SZ_1G)
-   return -EINVAL;
-
-   if (nd_pfn->dev.driver)
-   return -EBUSY;
-   else
-   nd_pfn->align = val;
-
-   return 0;
-}
-
 static ssize_t align_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
@@ -159,7 +139,8 @@ static ssize_t align_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = __align_store(nd_pfn, buf);
+   rc = nd_size_select_store(dev, buf, &nd_pfn->align,
+   nd_pfn_supported_alignments());
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
nvdimm_bus_unlock(dev);



[PATCH 1/3] libnvdimm: rename nd_sector_size_{show, store} to nd_size_select_{show, store}

2017-08-11 Thread Dan Williams
Prepare for other another consumer of this size selection scheme that is
not a 'sector size'.

Cc: Oliver O'Halloran 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +-
 drivers/nvdimm/namespace_devs.c |6 +++---
 drivers/nvdimm/nd.h |6 +++---
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 3e359d282f8e..d58925295aa7 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -61,7 +61,7 @@ static ssize_t sector_size_show(struct device *dev,
 {
struct nd_btt *nd_btt = to_nd_btt(dev);
 
-   return nd_sector_size_show(nd_btt->lbasize, btt_lbasize_supported, buf);
+   return nd_size_select_show(nd_btt->lbasize, btt_lbasize_supported, buf);
 }
 
 static ssize_t sector_size_store(struct device *dev,
@@ -72,7 +72,7 @@ static ssize_t sector_size_store(struct device *dev,
 
device_lock(dev);
nvdimm_bus_lock(dev);
-   rc = nd_sector_size_store(dev, buf, &nd_btt->lbasize,
+   rc = nd_size_select_store(dev, buf, &nd_btt->lbasize,
btt_lbasize_supported);
dev_dbg(dev, "%s: result: %zd wrote: %s%s", __func__,
rc, buf, buf[len - 1] == '\n' ? "" : "\n");
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 75bc08c6838c..bb71f0cf8f5d 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -277,14 +277,14 @@ int nd_uuid_store(struct device *dev, u8 **uuid_out, 
const char *buf,
return 0;
 }
 
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf)
 {
ssize_t len = 0;
int i;
 
for (i = 0; supported[i]; i++)
-   if (current_lbasize == supported[i])
+   if (current_size == supported[i])
len += sprintf(buf + len, "[%ld] ", supported[i]);
else
len += sprintf(buf + len, "%ld ", supported[i]);
@@ -292,8 +292,8 @@ ssize_t nd_sector_size_show(unsigned long current_lbasize,
return len;
 }
 
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const unsigned long *supported)
+ssize_t nd_size_select_store(struct device *dev, const char *buf,
+   unsigned long *current_size, const unsigned long *supported)
 {
unsigned long lbasize;
int rc, i;
@@ -310,7 +310,7 @@ ssize_t nd_sector_size_store(struct device *dev, const char 
*buf,
break;
 
if (supported[i]) {
-   *current_lbasize = lbasize;
+   *current_size = lbasize;
return 0;
} else {
return -EINVAL;
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 5f1c6756e57c..1427a386a033 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1313,14 +1313,14 @@ static ssize_t sector_size_show(struct device *dev,
if (is_namespace_blk(dev)) {
struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
-   return nd_sector_size_show(nsblk->lbasize,
+   return nd_size_select_show(nsblk->lbasize,
blk_lbasize_supported, buf);
}
 
if (is_namespace_pmem(dev)) {
struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
-   return nd_sector_size_show(nspm->lbasize,
+   return nd_size_select_show(nspm->lbasize,
pmem_lbasize_supported, buf);
}
return -ENXIO;
@@ -1352,7 +1352,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
-   rc = nd_sector_size_store(dev, buf, lbasize, supported);
+   rc = nd_size_select_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index a08fc2e24fb3..251c7e6d2588 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -234,10 +234,10 @@ void nd_device_unregister(struct device *dev, enum 
nd_async_mode mode);
 void nd_device_notify(struct device *dev, enum nvdimm_event event);
 int nd_uuid_store(struct device *dev, u8 **uuid_out, const char *buf,
size_t len);
-ssize_t nd_sector_size_show(unsigned long current_lbasize,
+ssize_t nd_size_select_show(unsigned long current_size,
const unsigned long *supported, char *buf);
-ssize_t nd_sector_size_store(struct device *dev, const char *buf,
-   unsigned long *current_lbasize, const unsigned long *supported);
+ssize_t nd_s

[PATCH 0/3] libnvdimm: export supported page size alignments

2017-08-11 Thread Dan Williams
This series is a minor rework of Oliver's original patch:
https://patchwork.kernel.org/patch/9811257/

It allows userspace to discover the system huge and gigantic page sizes
for aligning devices to support larger than PAGE_SIZE mappings for dax.

---

Dan Williams (2):
  libnvdimm: rename nd_sector_size_{show,store} to 
nd_size_select_{show,store}
  libnvdimm, pfn, dax: limit namespace alignments to the supported set

Oliver O'Halloran (1):
  libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs


 drivers/nvdimm/btt_devs.c   |4 ++--
 drivers/nvdimm/core.c   |   10 +
 drivers/nvdimm/namespace_devs.c |6 +++--
 drivers/nvdimm/nd.h |6 +++--
 drivers/nvdimm/pfn_devs.c   |   43 ---
 5 files changed, 39 insertions(+), 30 deletions(-)


Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

2017-08-11 Thread Chen-Yu Tsai
On Sat, Aug 12, 2017 at 12:51 PM,   wrote:
> 在 2017-08-12 12:04,Chen-Yu Tsai 写道:
>>
>> On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
>>>
>>> 在 2017-05-29 15:34,Chen-Yu Tsai 写道:


 Hi,

 On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>
>>
>> [...]
>>
> +
> +/*
> + * For the special bit in gate part, please see the BSP source code at
> + *
>
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
> + */
> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
> +   "osc24M", 0x034,
> +   8, 5,   /* N */
> +   4, 2,   /* K */
> +   0, 2,   /* M */
> +   BIT(31) | BIT(14),  /* gate */
> +   BIT(28),/* lock */
> +   0);



 I think this is a somewhat simplified approach. From what I understand
 of the user manual, the SATA clock path look like:


 [ PLL-PERIPH0-SATA ] -\
   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
 [ PLL-SATA ] -/

 ... from above ... --\
  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
 [ external oscillator ] -/

 If you choose to simplify the implementation, please include a detailed
 note as to why you chose to do so, and the validity of the
 simplification.
>>>
>>>
>>>
>>> I think it can be fully implemented...
>>>
>>> But how should I call the internal clock controlled by the mux @ 0x34 bit
>>> 30?
>>
>>
>> sata-pll-mux?
>
>
> I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
> "PLL_OUTPUT_SEL".

Cool. Note that the clock names don't really matter for end users.
The only place this is visible is debugfs, or if some driver prints
it out for debug messages. So the only real requirement is that the
name makes some sense to any developers using it, in a way that they
can spot if they are using it wrong, like accidentally using a clock
for another module, and being able to roughly match it up to the
datasheet.

ChenYu


Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

2017-08-11 Thread icenowy

在 2017-08-12 12:04,Chen-Yu Tsai 写道:

On Sat, Jul 22, 2017 at 11:00 AM,   wrote:

在 2017-05-29 15:34,Chen-Yu Tsai 写道:


Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:


[...]


+
+/*
+ * For the special bit in gate part, please see the BSP source code 
at

+ *
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
+ */
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
+   "osc24M", 0x034,
+   8, 5,   /* N */
+   4, 2,   /* K */
+   0, 2,   /* M */
+   BIT(31) | BIT(14),  /* gate */
+   BIT(28),/* lock */
+   0);



I think this is a somewhat simplified approach. From what I 
understand

of the user manual, the SATA clock path look like:


[ PLL-PERIPH0-SATA ] -\
  mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- 
...

[ PLL-SATA ] -/

... from above ... --\
 mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
[ external oscillator ] -/

If you choose to simplify the implementation, please include a 
detailed
note as to why you chose to do so, and the validity of the 
simplification.



I think it can be fully implemented...

But how should I call the internal clock controlled by the mux @ 0x34 
bit

30?


sata-pll-mux?


I choose to call it pll-sata-out, as the mux @ 0x34 bit 30 is called
"PLL_OUTPUT_SEL".



ChenYu

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

2017-08-11 Thread icenowy

在 2017-08-12 12:13,Chen-Yu Tsai 写道:

On Sat, Aug 12, 2017 at 11:07 AM,   wrote:

在 2017-07-17 16:52,Maxime Ripard 写道:


On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:


SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c
b/drivers/clk/sunxi-ng/ccu_div.c
index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
ccu_mux_internal *mux,
 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(&cd->common.hw, parent,
 rate, parent_rate,
 cd->div.table, 
cd->div.width,




You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/



I think he has already did the changes suggested in the review.


Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div


Oh, got it by reading other CCU clock types that has fixed postdiv.

Thanks!



ChenYu



(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
You received this message because you are subscribed to the Google 
Groups

"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send 
an

email to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

2017-08-11 Thread Dan Williams
On Fri, Aug 11, 2017 at 8:57 PM, Andy Lutomirski  wrote:
> On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  
> wrote:
>> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>>> Please explain how this interface allows for any sort of safe userspace
>>> DMA.
>>
>> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
>> support applications that MAP_SYNC does not. Dave mentioned userspace
>> pNFS4 servers, but there's also Samba and other protocols that want to
>> negotiate a direct path to pmem outside the kernel. Xen support has
>> thus far not been able to follow in the footsteps of KVM enabling due
>> to a dependence on static M2P tables that assume a static
>> guest-physical to host-physical relationship [1]. Immutable files
>> would allow Xen to follow the same "mmap a file" semantic as KVM.
>
> One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
> degree to which things go badly if one program relies on it while
> another program clears the flag: you risk corrupting unrelated
> filesystem metadata.  I think a userspace interface to pin the extent
> mapping of a file really wants a way to reliably keep it pinned (or to
> reliably zap the userspace application if it gets unpinned).

In the current patches, mapping_mapped() pins the immutable state.


Re: [linux-sunxi] Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

2017-08-11 Thread Chen-Yu Tsai
On Sat, Aug 12, 2017 at 11:07 AM,   wrote:
> 在 2017-07-17 16:52,Maxime Ripard 写道:
>>
>> On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:
>>>
>>> SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
>>> 6 is fixed post-divider.
>>>
>>> Signed-off-by: Priit Laes 
>>> ---
>>>  drivers/clk/sunxi-ng/ccu_div.c | 15 +--
>>>  drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
>>>  2 files changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu_div.c
>>> b/drivers/clk/sunxi-ng/ccu_div.c
>>> index c0e5c10..744502a 100644
>>> --- a/drivers/clk/sunxi-ng/ccu_div.c
>>> +++ b/drivers/clk/sunxi-ng/ccu_div.c
>>> @@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct
>>> ccu_mux_internal *mux,
>>>  {
>>> struct ccu_div *cd = data;
>>>
>>> +   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>>> +   rate *= cd->fixed_post_div;
>>> +
>>> return divider_round_rate_parent(&cd->common.hw, parent,
>>>  rate, parent_rate,
>>>  cd->div.table, cd->div.width,
>>
>>
>>
>> You still haven't addressed the biggest issue with this patch, see:
>> https://patchwork.kernel.org/patch/9825565/
>
>
> I think he has already did the changes suggested in the review.

Nope. Only half of it is fixed. First you "unapply" the post-divider,
i.e. multiply the rate by the divider. Then you pass it to
divider_round_rate_parent. You still have to reapply the divider
to the result. This last part is missing. This means the clock
rate returned by ccu_div_round_rate is going to be off.

Instead the return statement should be

return divider_round_rate_parent(...) / cd->fixed_post_div

ChenYu

>
> (P.S. during developing R40 CCU driver I found that pll-periph0-sata
> also needs this patch, so I'm rechecking it)
>
>>
>> Maxime
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

2017-08-11 Thread Dave Chinner
On Fri, Aug 11, 2017 at 07:31:54PM -0700, Darrick J. Wong wrote:
> On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> > On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > > >> >From falloc.h:
> > > >>
> > > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of 
> > > >> the
> > > >> file logical-to-physical extent offset mappings in the file. The
> > > >> purpose is to allow an application to assume that there are no 
> > > >> holes
> > > >> or shared extents in the file and that the metadata needed to find
> > > >> all the physical extents of the file is stable and can never be
> > > >> dirtied.
> > > >>
> > > >> For now this patch only permits setting the in-memory state of
> > > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > > >> saved for later patches.
> > > >>
> > > >> The implementation is careful to not allow the immutable state to 
> > > >> change
> > > >> while any process might have any established mappings. It reuses the
> > > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > > >> while it validates the file is in the proper state and sets
> > > >> S_IOMAP_IMMUTABLE.
> > > >
> > > > SO I've been thinking about this - I'm thinking that we need to
> > > > separate the changes to the extent map from the action of sealing
> > > > the extent map.
> > > >
> > > > That is, I have a need to freeze an extent map without any
> > > > modification to it at all and breaking all the sharing and filling
> > > > all the holes completely screws up the file layout I need to
> > > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > > and then read out the data in the private/changed blocks in the
> > > > reflinked file. I only need a temporary seal (if we crash it goes
> > > > away), so maybe there's another command modifier flag needed here,
> > > > too.
> > > >
> > > > The DAX allocation requirements can be handled by a preallocation
> > > > call to filll holes with zeros, followed by an unshare call to break
> > > > all the COW mappings, and then the extent map can be sealed. If you
> > > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > > you need to know...
> > > >
> > > > My preference really is for each fallocate command to do just one
> > > > thing - having the seal operation also modify the extent map
> > > > means it's not useful for the use cases where we need the extent map
> > > > to remain unmodified
> > > >
> > > > Thoughts?
> > > 
> > > That does seem to better follow the principle of least surprise and
> > > make the interface more composable. However, for the DAX case do we
> > > now end up needing a SEEK_SHARED, or something similar to check that
> > > we sealed the file without shared extents?
> 
> Well, fiemap/bmap will tell you (presumably after you confirm that the
> file got sealed or whatever) if there are shared extents.

Iterating potentially hundreds of thousands of extents just to find
the one shared extent seems like crazy thing to ask people to do.

> > Don't we have an inode attribute flag for that? There's definitely a
> > flag in the on disk XFS inode to indicate that there are shared
> > extents on the file.
> > 
> > H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> > Darrick? Any reason we don't expose the "this file has shared
> > extents" flag to userspace? How are we checking that on-disk state
> > in xfstests?
> > 
> > As it is, if we're adding an immutable extent flag, we've got to be
> > able to query the immutable extent state of a file from userspace so
> > I'm thinking that we'd need to expose it via the same interface that
> > exposes the immutable flag. i.e. we could add the "shared extents
> > present" flag to FS_IOC_FSGETXATTR at the same time...
> 
> We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

Ok, got a link? Seems strange to not be able to query this state
even for testing/validation purposes...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

2017-08-11 Thread Chen-Yu Tsai
On Sat, Aug 12, 2017 at 12:04 PM,   wrote:
> 在 2017-05-29 15:34,Chen-Yu Tsai 写道:
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
>>>
>>> Allwinner R40 SoC have a clock controller module in the style of the
>>> SoCs beyond sun6i, however, it's more rich and complex.
>>>
>>> Add support for it.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v3:
>>> - Rebased on current linux-next.
>>> Changes in v2:
>>> - Fixes according to the SoC's user manual.
>>>
>>>  drivers/clk/sunxi-ng/Kconfig  |   10 +
>>>  drivers/clk/sunxi-ng/Makefile |1 +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153
>>> +
>>>  drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
>>>  include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
>>>  include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
>>>  6 files changed, 1552 insertions(+)
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
>>>  create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
>>>  create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h
>>>
>> ...
>>>
>>> +static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
>>> +  "osc24M", 0x04c,
>>> +  8, 7,/* N */
>>
>>
>> N has minimum and maximum limits.
>
>
> These constraints are never implemented in old SoCs.

Then we should implement them if we find that they are
missing.

ChenYu


Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

2017-08-11 Thread Chen-Yu Tsai
On Sat, Jul 22, 2017 at 11:00 AM,   wrote:
> 在 2017-05-29 15:34,Chen-Yu Tsai 写道:
>>
>> Hi,
>>
>> On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

[...]

>>> +
>>> +/*
>>> + * For the special bit in gate part, please see the BSP source code at
>>> + *
>>> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/clk/sunxi/clk-sun8iw11.c#L665
>>> + */
>>> +static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_sata_clk, "pll-sata",
>>> +   "osc24M", 0x034,
>>> +   8, 5,   /* N */
>>> +   4, 2,   /* K */
>>> +   0, 2,   /* M */
>>> +   BIT(31) | BIT(14),  /* gate */
>>> +   BIT(28),/* lock */
>>> +   0);
>>
>>
>> I think this is a somewhat simplified approach. From what I understand
>> of the user manual, the SATA clock path look like:
>>
>>
>> [ PLL-PERIPH0-SATA ] -\
>>   mux @ 0x34 bit 30 --- gate @ 0x34 bit 14 --- ...
>> [ PLL-SATA ] -/
>>
>> ... from above ... --\
>>  mux @ 0xc8 bit 24 --- gate @ 0xc8 bit 31
>> [ external oscillator ] -/
>>
>> If you choose to simplify the implementation, please include a detailed
>> note as to why you chose to do so, and the validity of the simplification.
>
>
> I think it can be fully implemented...
>
> But how should I call the internal clock controlled by the mux @ 0x34 bit
> 30?

sata-pll-mux?

ChenYu


Re: [PATCH v3 08/10] clk: sunxi-ng: support R40 SoC

2017-08-11 Thread icenowy

在 2017-05-29 15:34,Chen-Yu Tsai 写道:

Hi,

On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:

Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Rebased on current linux-next.
Changes in v2:
- Fixes according to the SoC's user manual.

 drivers/clk/sunxi-ng/Kconfig  |   10 +
 drivers/clk/sunxi-ng/Makefile |1 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1153 
+

 drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   68 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h |  191 +
 include/dt-bindings/reset/sun8i-r40-ccu.h |  129 
 6 files changed, 1552 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h


...

+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
+  "osc24M", 0x04c,
+  8, 7,/* N */


N has minimum and maximum limits.


These constraints are never implemented in old SoCs.


--
2.12.2



Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

2017-08-11 Thread Andy Lutomirski
On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams  wrote:
> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig  wrote:
>> Please explain how this interface allows for any sort of safe userspace
>> DMA.
>
> So this is where I continue to see S_IOMAP_IMMUTABLE being able to
> support applications that MAP_SYNC does not. Dave mentioned userspace
> pNFS4 servers, but there's also Samba and other protocols that want to
> negotiate a direct path to pmem outside the kernel. Xen support has
> thus far not been able to follow in the footsteps of KVM enabling due
> to a dependence on static M2P tables that assume a static
> guest-physical to host-physical relationship [1]. Immutable files
> would allow Xen to follow the same "mmap a file" semantic as KVM.

One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the
degree to which things go badly if one program relies on it while
another program clears the flag: you risk corrupting unrelated
filesystem metadata.  I think a userspace interface to pin the extent
mapping of a file really wants a way to reliably keep it pinned (or to
reliably zap the userspace application if it gets unpinned).


[RFC PATCH] kvm: x86: reduce rtc 0x70 access vm-exit time

2017-08-11 Thread Peng Hao
some versions of windows guest access rtc frequently because of
rtc as system tick.guest access rtc like this: write register index
to 0x70, then write or read data from 0x71. writing 0x70 port is
just as index and do nothing else. So we can use coalesced mmio to
handle this scene to reduce VM-EXIT time.
without my patch, get the vm-exit time of accessing rtc 0x70 using
perf tools: (guest OS : windows 7 64bit)
IO Port Access  Samples Samples%  Time%  Min Time  Max Time  Avg time
0x70:POUT86 30.99%74.59%   9us  29us10.75us (+- 3.41%)

with my patch
IO Port Access  Samples Samples%  Time%   Min Time  Max Time   Avg time
 0x70:POUT   10632.02%29.47%0us  10us 1.57us (+- 7.38%)

the patch is a part of optimizing rtc 0x70 port access. Another is in
qemu.

Signed-off-by: Peng Hao 
---
 virt/kvm/coalesced_mmio.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
index 571c1ce..f640c2f 100644
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -82,6 +82,7 @@ static int coalesced_mmio_write(struct kvm_vcpu *vcpu,
ring->coalesced_mmio[ring->last].phys_addr = addr;
ring->coalesced_mmio[ring->last].len = len;
memcpy(ring->coalesced_mmio[ring->last].data, val, len);
+   ring->coalesced_mmio[ring->last].pad = dev->zone.pad;
smp_wmb();
ring->last = (ring->last + 1) % KVM_COALESCED_MMIO_MAX;
spin_unlock(&dev->kvm->ring_lock);
@@ -148,8 +149,12 @@ int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm,
dev->zone = *zone;
 
mutex_lock(&kvm->slots_lock);
-   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
- zone->size, &dev->dev);
+   if (zone->pad == 0)
+   ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
+   zone->size, &dev->dev);
+   else
+   ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, zone->addr,
+   zone->size, &dev->dev);
if (ret < 0)
goto out_free_dev;
list_add_tail(&dev->list, &kvm->coalesced_zones);
@@ -173,7 +178,10 @@ int kvm_vm_ioctl_unregister_coalesced_mmio(struct kvm *kvm,
 
list_for_each_entry_safe(dev, tmp, &kvm->coalesced_zones, list)
if (coalesced_mmio_in_range(dev, zone->addr, zone->size)) {
-   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, &dev->dev);
+   if (zone->pad == 0)
+   kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS, 
&dev->dev);
+   else
+   kvm_io_bus_unregister_dev(kvm, KVM_PIO_BUS, 
&dev->dev);
kvm_iodevice_destructor(&dev->dev);
}
 
-- 
1.8.3.1




Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread David Ahern
On 8/11/17 6:25 PM, Wei Wang wrote:
> By "a patch to fix that" do you mean after your patch, for every rt6,
> rt6->rt6i_idev will be the same as rt6->dst.dev?

FIB entries should have them the same device with my patch.

The copies done (ip6_rt_cache_alloc and ip6_rt_pcpu_alloc) will have to
set dst.dev to loopback or VRF device for RTF_LOCAL routes; it's the
only way to get local traffic to work and this is similar to what IPv4 does.


Re: make clean all broken with -j? + question regarding modpost

2017-08-11 Thread Masahiro Yamada
Hi.

2017-08-11 3:28 GMT+09:00 Randy Dunlap :

>> 2.) compile modpost with debug symbols, -g
>> how do I compile the modpost helper program with debug symbols? In what
>> makefile, kbuild file do I need to add the compiler flag?
>> Any help would be appreciated!


If you want to pass extra options to the build command of host-programs,
HOST_EXTRACFLAGS is supported.

For example,  HOST_EXTRACFLAGS=-g





-- 
Best Regards
Masahiro Yamada


Re: make clean all broken with -j? + question regarding modpost

2017-08-11 Thread Masahiro Yamada
Hi.


2017-08-11 7:11 GMT+09:00 Jim Davis :
> On Thu, Aug 10, 2017 at 11:28 AM, Randy Dunlap  wrote:
>> [adding linux-kbuild]
>>
>> On 08/10/2017 08:42 AM, Thomas Meyer wrote:
>>> Hi,
>>>
>>> 1.) make with multiple targets
>>>
>>> When running
>>> $ make -j4 clean all
>>> I get error from make (probably in scripts/Makefile.modbuiltin):
>
> With 4.13-rc4 I can get a similar build failure on my Fedora 26 workstation 
> with
>
> make allnoconfig; make -j2 clean all
>
> /bin/sh: scripts/mod/empty.o: No such file or directory
> make[2]: *** [scripts/mod/Makefile:24: scripts/mod/elfconfig.h] Error 1
> make[1]: *** [scripts/Makefile.build:561: scripts/mod] Error 2
>
> Here's an ugly workaround for that test case.
>
> diff --git a/Makefile b/Makefile
> index 6eba23bcb5ad..6a1fd24dcf31 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1297,6 +1297,7 @@ MRPROPER_FILES += .config .config.old .version
> .old_version \
>
>  # clean - Delete most, but leave enough to build external modules
>  #
> +.NOTPARALLEL: clean
>  clean: rm-dirs  := $(CLEAN_DIRS)
>  clean: rm-files := $(CLEAN_FILES)
>  clean-dirs  := $(addprefix _clean_, . $(vmlinux-alldirs)
> Documentation samples)
>


If config targets and build targets are given from the command line
(for example,  "make -j8 defconfig all"
they are processed one by one.

Kbuild does not cater to the mixture of clean targets and build targets,
but I do not know why.

I wrote as follows.



--- a/Makefile
+++ b/Makefile
@@ -482,7 +482,8 @@ uapi-asm-generic:
 version_h := include/generated/uapi/linux/version.h
 old_version_h := include/linux/version.h

-no-dot-config-targets := clean mrproper distclean \
+clean-targets := %clean mrproper cleandocs
+no-dot-config-targets := $(clean-targets) \
 cscope gtags TAGS tags help% %docs check% coccicheck \
 $(version_h) headers_% archheaders archscripts \
 kernelversion %src-pkg
@@ -505,6 +506,14 @@ ifeq ($(KBUILD_EXTMOD),)
 endif
 endif
 endif
+
+# For "make -j clean all", "make mrproper defconfig all", etc.
+ifneq ($(filter $(clean-targets),$(MAKECMDGOALS)),)
+   ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
+   mixed-targets := 1
+   endif
+endif
+
 # install and module_install need also be processed one by one
 ifneq ($(filter install,$(MAKECMDGOALS)),)
 ifneq ($(filter modules_install,$(MAKECMDGOALS)),)








-- 
Best Regards
Masahiro Yamada


Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread John Stultz
On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.

Looks good so far! I've not hit the issue yet.

Thanks so much for sorting out a fix!

If its useful:
Tested-by: John Stultz 

thanks again
-john


Re: [PATCH v6 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

2017-08-11 Thread icenowy

在 2017-07-17 16:52,Maxime Ripard 写道:

On Fri, Jul 14, 2017 at 05:49:23PM +0300, Priit Laes wrote:

SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 15 +--
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c 
b/drivers/clk/sunxi-ng/ccu_div.c

index c0e5c10..744502a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,

 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate *= cd->fixed_post_div;
+
return divider_round_rate_parent(&cd->common.hw, parent,
 rate, parent_rate,
 cd->div.table, cd->div.width,



You still haven't addressed the biggest issue with this patch, see:
https://patchwork.kernel.org/patch/9825565/


I think he has already did the changes suggested in the review.

(P.S. during developing R40 CCU driver I found that pll-periph0-sata
also needs this patch, so I'm rechecking it)



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


[PATCH v2 0/2] Add i2c dt-binding and compatible for Mediatek MT7622 SoC

2017-08-11 Thread Jun Gao
This patch series based on v4.13-rc1, include MT7622 i2c dt-binding
and compatible.

changes since v1:
- Modify commit message
- Revise dt-binding documentation

Jun Gao (2):
  dt-bindings: i2c: Add MediaTek MT7622 i2c binding
  i2c: mediatek: Add i2c compatible for MediaTek MT7622

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 drivers/i2c/busses/i2c-mt65xx.c   | 18 ++
 2 files changed, 24 insertions(+), 5 deletions(-)

--
1.8.1.1



[PATCH v2 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

2017-08-11 Thread Jun Gao
From: Jun Gao 

Add MT7622 i2c binding to binding file and change the compatible
information formats of all SoCs to the same.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index bd5a7be..71fc0b3 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C 
devices.
 
 Required properties:
   - compatible: value should be either of the following.
-  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
-  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
-  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
-  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
mt7623.
-  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
+  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
+  "mediatek,mt6577-i2c": for Mediatek MT6577
+  "mediatek,mt6589-i2c": for Mediatek MT6589
+  "mediatek,mt7622-i2c": for Mediatek MT7622
+  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
+  "mediatek,mt8173-i2c": for Mediatek MT8173
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
-- 
1.8.1.1



[PATCH v2 2/2] i2c: mediatek: Add i2c compatible for MediaTek MT7622

2017-08-11 Thread Jun Gao
From: Jun Gao 

Add i2c compatible for MT7622. Compare to MT8173 i2c controller,
MT7622 limits message numbers to 255, and does not support 4GB
DMA mode.

Signed-off-by: Jun Gao 
---
 drivers/i2c/busses/i2c-mt65xx.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9bedf0b..2c7f847 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -172,6 +172,14 @@ struct mtk_i2c {
.max_comb_2nd_msg_len = 31,
 };
 
+static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
+   .max_num_msgs = 255,
+   .max_write_len = 65535,
+   .max_read_len = 65535,
+   .max_comb_1st_msg_len = 65535,
+   .max_comb_2nd_msg_len = 65535,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = &mt6577_i2c_quirks,
.pmic_i2c = 0,
@@ -190,6 +198,15 @@ struct mtk_i2c {
.support_33bits = 0,
 };
 
+static const struct mtk_i2c_compatible mt7622_compat = {
+   .quirks = &mt7622_i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 0,
+};
+
 static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
@@ -201,6 +218,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = &mt6577_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = &mt6589_compat },
+   { .compatible = "mediatek,mt7622-i2c", .data = &mt7622_compat },
{ .compatible = "mediatek,mt8173-i2c", .data = &mt8173_compat },
{}
 };
-- 
1.8.1.1



Re: [PATCH net-next V2 3/3] tap: XDP support

2017-08-11 Thread Jason Wang



On 2017年08月12日 07:12, Jakub Kicinski wrote:

On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

- fast path: small and no gso packet. We try to do XDP at page level
   before build_skb(). For XDP_TX, since creating/destroying queues
   were completely under control of userspace, it was implemented
   through generic XDP helper after skb has been built. This could be
   optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
   through generic XDP helpers.

Test were done through pktgen with small packets.

xdp1 test shows ~41.1% improvement:

Before: ~1.7Mpps
After:  ~2.3Mpps

xdp_redirect to ixgbe shows ~60% improvement:

Before: ~0.8Mpps
After:  ~1.38Mpps

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Looks OK to me now :)

Out of curiosity, you say the build_skb() is for "small packets", and it
seems you are always reserving the 256B regardless of XDP being
installed.  Does this have no performance impact on non-XDP case?


Have a test, only less than 1% were noticed which I think could be ignored.

Thanks


Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

2017-08-11 Thread Philip Prindeville

> On Aug 11, 2017, at 8:13 PM, Philip Prindeville 
>  wrote:
> 
>> 
>> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen 
>>  wrote:
>> 
>> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>>> adapter (when operating in msix mode) raises the Other interrupt to signal
>>> Receiver Overrun.
>>> 
>>> This is a double problem because 1) at the moment e1000_msix_other()
>>> assumes that it is only called in case of Link Status Change and 2) if the
>>> condition persists, the interrupt is repeatedly raised again in quick
>>> succession.
>>> 
>>> Ideally we would configure the Other interrupt to not be raised in case of
>>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>>> we handle the first part of the problem by reverting to the practice of
>>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>>> anymore. We handle the second part of the problem by not re-enabling the
>>> Other interrupt right away when there is overrun. Instead, we wait until
>>> traffic subsides, napi polling mode is exited and interrupts are
>>> re-enabled.
>>> 
>>> Reported-by: Lennart Sorensen 
>>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>>> Signed-off-by: Benjamin Poirier 
>> 
>> Any chance of this fix hitting -stable?  After all adapter reset under
>> load is not nice.
>> 
> 
> 
> I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
> utilization at softIRQ is also about 8% higher.  The previous single patch 
> that went out to fix this problem had better performance.
> 
> This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
> of interfaces with iperf3.
> 
> -Philip


Actually, after turning off MSI-X mode (and using MSI mode instead), and 
setting InterruptRateThrottle to “4” (conservative dynamic mode) across all 
interfaces, I’m actually seeing slightly better throughput than the earlier 
patch… with comparable overall CPU utilization and SoftIRQ utilization.

So setting the module parameters correctly for routing (and not end-system 
parameters) makes a big difference when routing.

-Philip



Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

2017-08-11 Thread Darrick J. Wong
On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote:
> On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> > >> >From falloc.h:
> > >>
> > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
> > >> file logical-to-physical extent offset mappings in the file. The
> > >> purpose is to allow an application to assume that there are no holes
> > >> or shared extents in the file and that the metadata needed to find
> > >> all the physical extents of the file is stable and can never be
> > >> dirtied.
> > >>
> > >> For now this patch only permits setting the in-memory state of
> > >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> > >> saved for later patches.
> > >>
> > >> The implementation is careful to not allow the immutable state to change
> > >> while any process might have any established mappings. It reuses the
> > >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> > >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> > >> while it validates the file is in the proper state and sets
> > >> S_IOMAP_IMMUTABLE.
> > >
> > > SO I've been thinking about this - I'm thinking that we need to
> > > separate the changes to the extent map from the action of sealing
> > > the extent map.
> > >
> > > That is, I have a need to freeze an extent map without any
> > > modification to it at all and breaking all the sharing and filling
> > > all the holes completely screws up the file layout I need to
> > > preserve. i.e. I want to be able to freeze the maps of a pair of
> > > reflinked files so I can use FIEMAP to query only the changed blocks
> > > and then read out the data in the private/changed blocks in the
> > > reflinked file. I only need a temporary seal (if we crash it goes
> > > away), so maybe there's another command modifier flag needed here,
> > > too.
> > >
> > > The DAX allocation requirements can be handled by a preallocation
> > > call to filll holes with zeros, followed by an unshare call to break
> > > all the COW mappings, and then the extent map can be sealed. If you
> > > need to check for holes after sealing, SEEK_HOLE will tell you what
> > > you need to know...
> > >
> > > My preference really is for each fallocate command to do just one
> > > thing - having the seal operation also modify the extent map
> > > means it's not useful for the use cases where we need the extent map
> > > to remain unmodified
> > >
> > > Thoughts?
> > 
> > That does seem to better follow the principle of least surprise and
> > make the interface more composable. However, for the DAX case do we
> > now end up needing a SEEK_SHARED, or something similar to check that
> > we sealed the file without shared extents?

Well, fiemap/bmap will tell you (presumably after you confirm that the
file got sealed or whatever) if there are shared extents.

> Don't we have an inode attribute flag for that? There's definitely a
> flag in the on disk XFS inode to indicate that there are shared
> extents on the file.
> 
> H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
> Darrick? Any reason we don't expose the "this file has shared
> extents" flag to userspace? How are we checking that on-disk state
> in xfstests?
> 
> As it is, if we're adding an immutable extent flag, we've got to be
> able to query the immutable extent state of a file from userspace so
> I'm thinking that we'd need to expose it via the same interface that
> exposes the immutable flag. i.e. we could add the "shared extents
> present" flag to FS_IOC_FSGETXATTR at the same time...

We used to have a FSGETXATTR flag; iirc hch nak'd it during the review.

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] Add /proc/pid/smaps_rollup

2017-08-11 Thread Daniel Colascione
/proc/pid/smaps_rollup is a new proc file that improves the
performance of user programs that determine aggregate memory
statistics (e.g., total PSS) of a process.

Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.

smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all
of the real-smaps VMAs. Using a common format for smaps_rollup and
smaps allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.

By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a
large process's potentially very numerous memory mappings. For
sampling system_server's PSS in Android, we measured a 12x speedup,
representing a savings of several hundred milliseconds.

One alternative to a new per-process proc file would have been
including PSS information in /proc/pid/status. We considered this
option but thought that PSS would be too expensive (by a few orders of
magnitude) to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.

The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for
each VMA.  In this way, summation happens automatically.  We let
seq_file walk over the VMAs just as it does for regular smaps and just
emit nothing to the seq_file until we hit the last VMA.

Benchmarks:

using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system

using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system

Patch changelog:

v2: Fix typo in commit message
Add ABI documentation as requested by gregkh
v3: Fix typo in ABI documentation
Add benchmarks to commit message

Signed-off-by: Daniel Colascione 
---
 Documentation/ABI/testing/procfs-smaps_rollup |  34 +
 fs/proc/base.c|   2 +
 fs/proc/internal.h|   3 +
 fs/proc/task_mmu.c| 196 ++
 4 files changed, 173 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/ABI/testing/procfs-smaps_rollup

diff --git a/Documentation/ABI/testing/procfs-smaps_rollup 
b/Documentation/ABI/testing/procfs-smaps_rollup
new file mode 100644
index ..8c24138a7279
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-smaps_rollup
@@ -0,0 +1,34 @@
+What:  /proc/pid/smaps_rollup
+Date:  August 2017
+Contact:   Daniel Colascione 
+Description:
+   This file provides pre-summed memory information for a
+   process.  The format is identical to /proc/pid/smaps,
+   except instead of an entry for each VMA in a process,
+   smaps_rollup has a single entry (tagged "[rollup]")
+   for which each field is the sum of the corresponding
+   fields from all the maps in /proc/pid/smaps.
+   For more details, see the procfs man page.
+
+   Typical output looks like this:
+
+   0010-ff709000 ---p  00:00 0  [rollup]
+   Rss: 884 kB
+   Pss: 385 kB
+   Shared_Clean:696 kB
+   Shared_Dirty:  0 kB
+   Private_Clean:   120 kB
+   Private_Dirty:68 kB
+   Referenced:  884 kB
+   Anonymous:68 kB
+   LazyFree:  0 kB
+   AnonHugePages: 0 kB
+   ShmemPmdMapped:0 kB
+   Shared_Hugetlb:0 kB
+   Private_Hugetlb:   0 kB
+   Swap:  0 kB
+   SwapPss:   0 kB
+   Locked:  385 kB
+
+
+   
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 719c2e943ea1..a9587b9cace5 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2930,6 +2930,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef CO

Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

2017-08-11 Thread Philip Prindeville

> On Jul 21, 2017, at 12:48 PM, Lennart Sorensen  
> wrote:
> 
> On Fri, Jul 21, 2017 at 11:36:27AM -0700, Benjamin Poirier wrote:
>> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
>> adapter (when operating in msix mode) raises the Other interrupt to signal
>> Receiver Overrun.
>> 
>> This is a double problem because 1) at the moment e1000_msix_other()
>> assumes that it is only called in case of Link Status Change and 2) if the
>> condition persists, the interrupt is repeatedly raised again in quick
>> succession.
>> 
>> Ideally we would configure the Other interrupt to not be raised in case of
>> receiver overrun but this doesn't seem possible on this adapter. Instead,
>> we handle the first part of the problem by reverting to the practice of
>> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
>> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
>> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
>> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
>> anymore. We handle the second part of the problem by not re-enabling the
>> Other interrupt right away when there is overrun. Instead, we wait until
>> traffic subsides, napi polling mode is exited and interrupts are
>> re-enabled.
>> 
>> Reported-by: Lennart Sorensen 
>> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
>> Signed-off-by: Benjamin Poirier 
> 
> Any chance of this fix hitting -stable?  After all adapter reset under
> load is not nice.
> 


I tried this patch sequence and I’m seeing a 2% drop in throughput.  CPU 
utilization at softIRQ is also about 8% higher.  The previous single patch that 
went out to fix this problem had better performance.

This is on an Atom D525 with an 82574L and running 2 GB streams across a pair 
of interfaces with iperf3.

-Philip




Re: [PATCH 4.4 00/15] 4.4.82-stable review

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

Compiled and booted test system. No dmesg regressions.

thanks,
-- Shuah


Re: [PATCH 4.9 00/16] 4.9.43-stable review

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

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

thanks,
-- Shuah


Re: [PATCH 4.12 00/17] 4.12.7-stable review

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

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

thanks,
-- Shuah


Re: [PATCH 3.18 0/9] 3.18.65-stable review

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

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

thanks,
-- Shuah


[PATCH] drm/gma500: fix potential NULL pointer dereference dereference

2017-08-11 Thread Gustavo A. R. Silva
NULL check at line 528: if (!sender || !data_out || !len_out) {, implies
that pointer _sender_ might be NULL.

Move pointer _sender_ dereference after NULL check in order to avoid a
potential NULL pointer dereference.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 1616af2..c50534c 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
 {
unsigned long flags;
-   struct drm_device *dev = sender->dev;
+   struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
return -EINVAL;
}
 
+   dev = sender->dev;
+
/**
 * do reading.
 * 0) send out generic read request
-- 
2.5.0



[PATCH v3 1/2] ata: mediatek: add support for MediaTek SATA controller

2017-08-11 Thread Ryder Lee
This adds support the AHCI-compliant Serial ATA controller present
on MediaTek SoCs.

Signed-off-by: Ryder Lee 
---
 drivers/ata/Kconfig|  10 +++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 3 files changed, 207 insertions(+)
 create mode 100644 drivers/ata/ahci_mtk.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 363fc53..488c937 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -153,6 +153,16 @@ config AHCI_CEVA
 
  If unsure, say N.
 
+config AHCI_MTK
+   tristate "MediaTek AHCI SATA support"
+   depends on ARCH_MEDIATEK
+   select MFD_SYSCON
+   help
+ This option enables support for the MediaTek SoC's
+ onboard AHCI SATA controller.
+
+ If unsure, say N.
+
 config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a26ef5a..ff9cd2e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_CEVA)   += ahci_ceva.o 
libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DA850)   += ahci_da850.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DM816)   += ahci_dm816.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_MTK) += ahci_mtk.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)   += ahci_mvebu.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_OCTEON)  += ahci_octeon.o
 obj-$(CONFIG_AHCI_SUNXI)   += ahci_sunxi.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
new file mode 100644
index 000..80854f7
--- /dev/null
+++ b/drivers/ata/ahci_mtk.c
@@ -0,0 +1,196 @@
+/*
+ * MeidaTek AHCI SATA driver
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ahci.h"
+
+#define DRV_NAME   "ahci"
+
+#define SYS_CFG0x14
+#define SYS_CFG_SATA_MSK   GENMASK(31, 30)
+#define SYS_CFG_SATA_ENBIT(31)
+
+struct mtk_ahci_plat {
+   struct regmap *mode;
+   struct reset_control *axi_rst;
+   struct reset_control *sw_rst;
+   struct reset_control *reg_rst;
+};
+
+static const struct ata_port_info ahci_port_info = {
+   .flags  = AHCI_FLAG_COMMON,
+   .pio_mask   = ATA_PIO4,
+   .udma_mask  = ATA_UDMA6,
+   .port_ops   = &ahci_platform_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+   AHCI_SHT(DRV_NAME),
+};
+
+static int mtk_ahci_platform_resets(struct ahci_host_priv *hpriv,
+   struct device *dev)
+{
+   struct mtk_ahci_plat *plat = hpriv->plat_data;
+   int err;
+
+   /* reset AXI bus and PHY part */
+   plat->axi_rst = devm_reset_control_get_optional_exclusive(dev, "axi");
+   if (PTR_ERR(plat->axi_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->axi_rst);
+
+   plat->sw_rst = devm_reset_control_get_optional_exclusive(dev, "sw");
+   if (PTR_ERR(plat->sw_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->sw_rst);
+
+   plat->reg_rst = devm_reset_control_get_optional_exclusive(dev, "reg");
+   if (PTR_ERR(plat->reg_rst) == -EPROBE_DEFER)
+   return PTR_ERR(plat->reg_rst);
+
+   err = reset_control_assert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, "failed to assert AXI bus\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_assert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to assert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->reg_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY register part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->sw_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert PHY digital part\n");
+   return err;
+   }
+
+   err = reset_control_deassert(plat->axi_rst);
+   if (err) {
+   dev_err(dev, "failed to deassert AXI bus\n");
+   

[PATCH v3 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

2017-08-11 Thread Ryder Lee
Add DT bindings for the onboard SATA controller present on the MediaTek
SoCs.

Signed-off-by: Ryder Lee 
---
 Documentation/devicetree/bindings/ata/ahci-mtk.txt | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt 
b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
new file mode 100644
index 000..96c8d22
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
@@ -0,0 +1,51 @@
+MediaTek Serial ATA controller
+
+Required properties:
+ - compatible : Must be "mediatek,soc-model-ahci", "mediatek,mtk-ahci".
+When using "mediatek,mtk-ahci" compatible strings, you
+need SoC specific ones in addition, one of:
+- "mediatek,mt7622-ahci"
+ - reg: Physical base addresses and length of register sets.
+ - interrupts : Interrupt associated with the SATA device.
+ - interrupt-names : Associated name must be: "hostc".
+ - clocks : A list of phandle and clock specifier pairs, one for each
+entry in clock-names.
+ - clock-names: Associated names must be: "ahb", "axi", "asic", "rbc", 
"pm".
+ - phys   : A phandle and PHY specifier pair for the PHY port.
+ - phy-names  : Associated name must be: "sata-phy".
+ - ports-implemented : See ./ahci-platform.txt for details.
+
+Optional properties:
+ - power-domains   : A phandle and power domain specifier pair to the power
+domain which is responsible for collapsing and restoring
+power to the peripheral.
+ - resets : Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Associated names must be: "axi", "sw", "reg".
+ - mediatek,phy-mode : A phandle to the system controller, used to enable
+  SATA function.
+
+Example:
+
+   sata: sata@1a20 {
+   compatible = "mediatek,mt7622-ahci",
+"mediatek,mtk-ahci";
+   reg = <0 0x1a20 0 0x1100>;
+   interrupts = ;
+   interrupt-names = "hostc";
+   clocks = <&pciesys CLK_SATA_AHB_EN>,
+<&pciesys CLK_SATA_AXI_EN>,
+<&pciesys CLK_SATA_ASIC_EN>,
+<&pciesys CLK_SATA_RBC_EN>,
+<&pciesys CLK_SATA_PM_EN>;
+   clock-names = "ahb", "axi", "asic", "rbc", "pm";
+   phys = <&u3port1 PHY_TYPE_SATA>;
+   phy-names = "sata-phy";
+   ports-implemented = <0x1>;
+   power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+   resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
+<&pciesys MT7622_SATA_PHY_SW_RST>,
+<&pciesys MT7622_SATA_PHY_REG_RST>;
+   reset-names = "axi", "sw", "reg";
+   mediatek,phy-mode = <&pciesys>;
+   };
-- 
1.9.1



[PATCH v3 0/2] Add support for MediaTek AHCI SATA

2017-08-11 Thread Ryder Lee
Hi,

This patch series add support for AHCI compatible SATA controller, and it is
compliant with the ahci 1.3 and sata 3.0 specification. This driver is slightly
different than ahci_platform.c (e.g., reset control, subsystem setting).

changes since v3:
- update binding text: fix a typo and modify compatible strings.

changes since v2:
- according to Commit a53e35db70d1 ("reset: Ensure drivers are explicit when 
requesting reset lines").
  replace devm_reset_control_get_optional() by 
devm_reset_control_get_optional_exclusive().

changes since v1:
- update binding text: add missing "specifier pairs" descriptions.
- fix kbuild test warning: fix the error handling.

Ryder Lee (2):
  ata: mediatek: add support for MediaTek SATA controller
  dt-bindings: ata: add DT bindings for MediaTek SATA controller

 Documentation/devicetree/bindings/ata/ahci-mtk.txt |  51 ++
 drivers/ata/Kconfig|  10 ++
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_mtk.c | 196 +
 4 files changed, 258 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
 create mode 100644 drivers/ata/ahci_mtk.c

-- 
1.9.1



Re: [PATCH] PCI: mediatek: add msi support for mt2712 and mt7622

2017-08-11 Thread Ryder Lee
Hi Honghui,

On Fri, 2017-08-11 at 20:27 +0800, honghui.zh...@mediatek.com wrote:
...
> +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> +{
> + u32 val;
> +
> + val = lower_32_bits((u64)(port->base + PCIE_MSI_VECTOR));
> + writel(val, port->base + PCIE_IMSI_ADDR);
> +
> + val = readl(port->base + PCIE_INT_MASK);
> + val &= ~MSI_MASK;
> + writel(val, port->base + PCIE_INT_MASK);
> +}
> +
>  static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
>irq_hw_number_t hwirq)
>  {
> @@ -460,6 +574,18 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>   return PTR_ERR(port->irq_domain);
>   }
>  
> + /* Setup MSI */
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + port->msi_domain = irq_domain_add_linear(node, MTK_MSI_IRQS_NUM,
> +  &msi_domain_ops,
> +  &mtk_pcie_msi_chip);
> + if (!port->msi_domain) {
> + dev_err(dev, "Failed to get a MSI IRQ domain\n");
> + return PTR_ERR(port->msi_domain);

Just return -ENOMEM. PTR_ERR(NULL) will cause a static checker warning.

> + }
> + mtk_pcie_enable_msi(port);
> + }
> +
>   return 0;
>  }

Ryder



Re: [PATCH] ASoC: hdmi-codec: Use different name for playback streams

2017-08-11 Thread jeffy

Hi Brian,

Thanks for noting.

On 08/12/2017 12:59 AM, Brian Norris wrote:

Hi Jeffy,

You need to be more careful about the addressee's of your patches. No
one on To/CC is a maintainer or a sufficiently-targeted mailing list. I
doubt any of the maintainers will read your patch. (I've added
alsa-devel for you, but given my understanding of at least Mark's
patchwork workflow -- and of general patch etiquette -- it's important
the patch is actually sent there in the first place.)

Probably worth resending.

Ok, will do that.

I was using patman to send it, not sure why it didn't work correctly 
that time...




[PATCH -tip v2 2/2] kprobes/x86: Remove addressof operators

2017-08-11 Thread Masami Hiramatsu
Since commit 54a7d50b9205 ("x86: mark kprobe templates as
character arrays, not single characters") changes
optprobe_template_* to arrays, we can remove addressof
operators from those symbols.

Signed-off-by: Masami Hiramatsu 
---
 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/opt.c  |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index 6cf65437b5e5..9f2e3102e0bb 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -58,8 +58,8 @@ extern __visible kprobe_opcode_t optprobe_template_call[];
 extern __visible kprobe_opcode_t optprobe_template_end[];
 #define MAX_OPTIMIZED_LENGTH (MAX_INSN_SIZE + RELATIVE_ADDR_SIZE)
 #define MAX_OPTINSN_SIZE   \
-   (((unsigned long)&optprobe_template_end -   \
- (unsigned long)&optprobe_template_entry) +\
+   (((unsigned long)optprobe_template_end -\
+ (unsigned long)optprobe_template_entry) + \
 MAX_OPTIMIZED_LENGTH + RELATIVEJUMP_SIZE)
 
 extern const int kretprobe_blacklist_size;
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 86b9a883b712..d85fac42b512 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -142,11 +142,11 @@ void optprobe_template_func(void);
 STACK_FRAME_NON_STANDARD(optprobe_template_func);
 
 #define TMPL_MOVE_IDX \
-   ((long)&optprobe_template_val - (long)&optprobe_template_entry)
+   ((long)optprobe_template_val - (long)optprobe_template_entry)
 #define TMPL_CALL_IDX \
-   ((long)&optprobe_template_call - (long)&optprobe_template_entry)
+   ((long)optprobe_template_call - (long)optprobe_template_entry)
 #define TMPL_END_IDX \
-   ((long)&optprobe_template_end - (long)&optprobe_template_entry)
+   ((long)optprobe_template_end - (long)optprobe_template_entry)
 
 #define INT3_SIZE sizeof(kprobe_opcode_t)
 
@@ -377,7 +377,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
op->optinsn.size = ret;
 
/* Copy arch-dep-instance from template */
-   memcpy(buf, &optprobe_template_entry, TMPL_END_IDX);
+   memcpy(buf, optprobe_template_entry, TMPL_END_IDX);
 
/* Set probe information */
synthesize_set_arg1(buf + TMPL_MOVE_IDX, (unsigned long)op);



Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread Wei Wang
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>

Great. Thanks.

> Do you still want feedback on the previous changes?

If this patch is good, then I don't really need the previous feedback.

Thanks.
Wei


On Fri, Aug 11, 2017 at 5:31 PM, John Stultz  wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue? It would be great to have logs for both success case and the
>>> failure case.
>>>
>>> Thanks so much for your help.
>>>
>>
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>>
>> The attached potential fix is tested by Martin and made sure it fixes his 
>> issue.
>>
>> John,
>> It will be great if you can also give it a try and see if it fixes the
>> issue on your side before I submit an official patch.
>
> So yes, sorry I haven't been able to get back quicker on the other
> patches sent, was mucking about in other work.
>
> So yea, this patch  (potential fix for unregister_netdevice()) seems
> to avoid the issue.
>
> I'm going to do some further testing, but its looking good so far.
>
> Do you still want feedback on the previous changes?
>
> thanks
> -john


[PATCH -tip v2 1/2] kprobes/x86: Don't forget to set memory back to RO on failure

2017-08-11 Thread Masami Hiramatsu
Do not forget to set kprobes insn buffer memory back
to RO on failure path. Without this fix, if there is
an unexpected error on copying instructions, kprobes
insn buffer kept RW, which can allow unexpected modifying
instruction buffer.

Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
   - Use a helper variable instead of using p->ainsn.insn directly.
---
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |1 +
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index f0153714ddac..5d8194b9a068 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -428,15 +428,18 @@ void free_insn_page(void *page)
 
 static int arch_copy_kprobe(struct kprobe *p)
 {
+   kprobe_opcode_t *buf = p->ainsn.insn;
struct insn insn;
int len;
 
-   set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
 
/* Copy an instruction with recovering if other optprobe modifies it.*/
-   len = __copy_instruction(p->ainsn.insn, p->addr, &insn);
-   if (!len)
+   len = __copy_instruction(buf, p->addr, &insn);
+   if (!len) {
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return -EINVAL;
+   }
 
/*
 * __copy_instruction can modify the displacement of the instruction,
@@ -444,13 +447,13 @@ static int arch_copy_kprobe(struct kprobe *p)
 */
prepare_boost(p, &insn);
 
-   set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
 
/* Check whether the instruction modifies Interrupt Flag or not */
-   p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
+   p->ainsn.if_modifier = is_IF_modifier(buf);
 
/* Also, displacement change doesn't affect the first byte */
-   p->opcode = p->ainsn.insn[0];
+   p->opcode = buf[0];
 
return 0;
 }
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 4f98aad38237..86b9a883b712 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -371,6 +371,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe 
*op,
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
if (ret < 0) {
__arch_remove_optimized_kprobe(op, 0);
+   set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
return ret;
}
op->optinsn.size = ret;



[PATCH -tip v2 0/2] kprobes/x86: RO text code bugfix and cleanup

2017-08-11 Thread Masami Hiramatsu
Hi,

This series fixes a kprobe-x86 bug related to RO text and
cleans up addressof operators.

The first one is an obvious bug that misses to set memory
RO when the function fails. And the second one is just a
cleanup patch to remove addressof operators ("&") since
it is meaningless anymore.

V2 has just a following update:
 - [1/2] Use a helper variable instead of using p->ainsn.insn
   directly.

Thanks,

---

Masami Hiramatsu (2):
  kprobes/x86: Don't forget to set memory back to RO on failure
  kprobes/x86: Remove addressof operators


 arch/x86/include/asm/kprobes.h |4 ++--
 arch/x86/kernel/kprobes/core.c |   15 +--
 arch/x86/kernel/kprobes/opt.c  |9 +
 3 files changed, 16 insertions(+), 12 deletions(-)

--
Masami Hiramatsu 


[RESENT PATCH] ASoC: hdmi-codec: Use different name for playback streams

2017-08-11 Thread Jeffy Chen
Currently the hdmi i2s playback stream and hdmi spdif playback stream
are using the same name. So when they are enabled at the same time,
kernel will print this warning:

[2.201835] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: Failed to
create Playback debugfs file

Assign different names to them to avoid that.

Signed-off-by: Jeffy Chen 
---

 sound/soc/codecs/hdmi-codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 509ab51..a2af440 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -696,7 +696,7 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
.name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "I2S Playback",
.channels_min = 2,
.channels_max = 8,
.rates = HDMI_RATES,
@@ -711,7 +711,7 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "SPDIF Playback",
.channels_min = 2,
.channels_max = 2,
.rates = HDMI_RATES,
-- 
2.1.4




Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread John Stultz
On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang  wrote:
>> If after Cong's fix, the issue still happens, could you help try the
>> patch attached and collect all logs when you try the reproduce the
>> issue? It would be great to have logs for both success case and the
>> failure case.
>>
>> Thanks so much for your help.
>>
>
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
> When the real device goes down, the current fib6 clean up code only
> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
> That leaves unreleased refcnt on the real device if rt6->dst.dev
> points to loopback dev.
>
> The attached potential fix is tested by Martin and made sure it fixes his 
> issue.
>
> John,
> It will be great if you can also give it a try and see if it fixes the
> issue on your side before I submit an official patch.

So yes, sorry I haven't been able to get back quicker on the other
patches sent, was mucking about in other work.

So yea, this patch  (potential fix for unregister_netdevice()) seems
to avoid the issue.

I'm going to do some further testing, but its looking good so far.

Do you still want feedback on the previous changes?

thanks
-john


Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

2017-08-11 Thread Dave Chinner
On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote:
> On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
> >> >From falloc.h:
> >>
> >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
> >> file logical-to-physical extent offset mappings in the file. The
> >> purpose is to allow an application to assume that there are no holes
> >> or shared extents in the file and that the metadata needed to find
> >> all the physical extents of the file is stable and can never be
> >> dirtied.
> >>
> >> For now this patch only permits setting the in-memory state of
> >> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
> >> saved for later patches.
> >>
> >> The implementation is careful to not allow the immutable state to change
> >> while any process might have any established mappings. It reuses the
> >> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
> >> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
> >> while it validates the file is in the proper state and sets
> >> S_IOMAP_IMMUTABLE.
> >
> > SO I've been thinking about this - I'm thinking that we need to
> > separate the changes to the extent map from the action of sealing
> > the extent map.
> >
> > That is, I have a need to freeze an extent map without any
> > modification to it at all and breaking all the sharing and filling
> > all the holes completely screws up the file layout I need to
> > preserve. i.e. I want to be able to freeze the maps of a pair of
> > reflinked files so I can use FIEMAP to query only the changed blocks
> > and then read out the data in the private/changed blocks in the
> > reflinked file. I only need a temporary seal (if we crash it goes
> > away), so maybe there's another command modifier flag needed here,
> > too.
> >
> > The DAX allocation requirements can be handled by a preallocation
> > call to filll holes with zeros, followed by an unshare call to break
> > all the COW mappings, and then the extent map can be sealed. If you
> > need to check for holes after sealing, SEEK_HOLE will tell you what
> > you need to know...
> >
> > My preference really is for each fallocate command to do just one
> > thing - having the seal operation also modify the extent map
> > means it's not useful for the use cases where we need the extent map
> > to remain unmodified
> >
> > Thoughts?
> 
> That does seem to better follow the principle of least surprise and
> make the interface more composable. However, for the DAX case do we
> now end up needing a SEEK_SHARED, or something similar to check that
> we sealed the file without shared extents?

Don't we have an inode attribute flag for that? There's definitely a
flag in the on disk XFS inode to indicate that there are shared
extents on the file.

H - for some reason it's not exposed in FS_IOC_FSGETXATTR.
Darrick? Any reason we don't expose the "this file has shared
extents" flag to userspace? How are we checking that on-disk state
in xfstests?

As it is, if we're adding an immutable extent flag, we've got to be
able to query the immutable extent state of a file from userspace so
I'm thinking that we'd need to expose it via the same interface that
exposes the immutable flag. i.e. we could add the "shared extents
present" flag to FS_IOC_FSGETXATTR at the same time...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread Wei Wang
On Fri, Aug 11, 2017 at 5:19 PM, David Ahern  wrote:
> On 8/11/17 6:10 PM, Wei Wang wrote:
>> I think we have a potential fix for this issue.
>> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
>> possible that rt6->dst.dev points to loopback device while
>> rt6->rt6i_idev->dev points to a real device.
>> When the real device goes down, the current fib6 clean up code only
>> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
>> That leaves unreleased refcnt on the real device if rt6->dst.dev
>> points to loopback dev.
>
> Yes, host routes and anycast routes.
>
> I have a patch to fix that but it is held up on a few VRF test cases
> failing. Hopefully I can get that figured out next week. These unrelated
> routes against the loopback device have been a source of a number of
> problems (e.g. take down 'lo' and all of IPv6 networking stops for that
> namespace).

Thanks David.
By "a patch to fix that" do you mean after your patch, for every rt6,
rt6->rt6i_idev will be the same as rt6->dst.dev?


Re: [PATCH v2 0/4] Update memcpy, memset etc. for M7/M8 architectures

2017-08-11 Thread Babu Moger

David,  Thanks for applying.

On 8/10/2017 4:38 PM, David Miller wrote:

From: Babu Moger 
Date: Mon,  7 Aug 2017 17:52:48 -0600


This series of patches updates the memcpy, memset, copy_to_user,
copy_from_user etc for SPARC M7/M8 architecture.

This doesn't build, you cannot assume the existence of "%ncc", it is a
recent addition.

Furthermore there is no need to ever use %ncc in v9 targetted code
anyways.

I'll fix that up, but this was a really disappointing build failure
to hit.

Thank you..


Meanwhile, two questions:

1) Is this also faster on T4 as well?  If it is, we can just get rid
of the T4 routines and use this on those chips as well.


At the time of this work, our focus was mostly on T7 and T8. We did not 
test this code on T4.
For T4 and other older configs we used NG4 versions. I would think it 
would require some

changes to make it work on T4.


2) There has been a lot of discussion and consideration put into how
a memcpy/memset routine might be really great for the local cpu
but overall pessimize performance for other cpus either locally
on the same core (contention for physical resources such as
ports to the store buffer and/or L3 cache) or on other cores.

Has any such study been done into these issues wrt. this new code?

No, we have not done this kind of study.



Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread David Ahern
On 8/11/17 6:10 PM, Wei Wang wrote:
> I think we have a potential fix for this issue.
> Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
> possible that rt6->dst.dev points to loopback device while
> rt6->rt6i_idev->dev points to a real device.
> When the real device goes down, the current fib6 clean up code only
> checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
> That leaves unreleased refcnt on the real device if rt6->dst.dev
> points to loopback dev.

Yes, host routes and anycast routes.

I have a patch to fix that but it is held up on a few VRF test cases
failing. Hopefully I can get that figured out next week. These unrelated
routes against the loopback device have been a source of a number of
problems (e.g. take down 'lo' and all of IPv6 networking stops for that
namespace).


[PATCH v3 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

2017-08-11 Thread Khuong Dinh
This patch makes pci-xgene-msi driver ACPI-aware and provides
MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.

Signed-off-by: Khuong Dinh 
[Take over from Duc Dang]
Acked-by: Marc Zyngier 
---
v3:
 - Input X-Gene MSI base address for irq_domain_alloc_fwnode
 - Add a hook to enforce X-Gene MSI be probed prior acpi_bus_scan happens
v2:
 - Verify with BIOS version 3.06.25 and 3.07.09
v1:
 - Initial version
---
 drivers/acpi/Makefile|2 +-
 drivers/acpi/acpi_msi.c  |   74 ++
 drivers/acpi/internal.h  |1 +
 drivers/acpi/scan.c  |1 +
 drivers/pci/host/pci-xgene-msi.c |   36 +--
 5 files changed, 110 insertions(+), 4 deletions(-)
 create mode 100644 drivers/acpi/acpi_msi.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc..c15f5cd 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-y+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 obj-$(CONFIG_ACPI_MCFG)+= pci_mcfg.o
-acpi-y += acpi_lpss.o acpi_apd.o
+acpi-y += acpi_lpss.o acpi_apd.o acpi_msi.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
diff --git a/drivers/acpi/acpi_msi.c b/drivers/acpi/acpi_msi.c
new file mode 100644
index 000..c2f8d26
--- /dev/null
+++ b/drivers/acpi/acpi_msi.c
@@ -0,0 +1,74 @@
+/*
+ * Enforce MSI driver loaded by PCIe controller driver
+ *
+ * Copyright (c) 2017, MACOM Technology Solutions Corporation
+ * Author: Khuong Dinh 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include "internal.h"
+
+static acpi_status acpi_create_msi_device(acpi_handle handle, u32 Level,
+   void *context, void **retval)
+{
+   struct acpi_device *device = NULL;
+   int type = ACPI_BUS_TYPE_DEVICE;
+   unsigned long long sta;
+   acpi_status status;
+   int ret = 0;
+
+   acpi_bus_get_device(handle, &device);
+   status = acpi_bus_get_status_handle(handle, &sta);
+   if (ACPI_FAILURE(status))
+   sta = 0;
+
+   device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL);
+   if (!device)
+   return -ENOMEM;
+
+   acpi_init_device_object(device, handle, type, sta);
+   ret = acpi_device_add(device, NULL);
+   if (ret)
+   return ret;
+   device->parent = kzalloc(sizeof(struct acpi_device), GFP_KERNEL);
+   INIT_LIST_HEAD(&device->parent->physical_node_list);
+
+   acpi_device_add_finalize(device);
+
+   ret = device_attach(&device->dev);
+   if (ret < 0)
+   return ret;
+
+   acpi_create_platform_device(device, NULL);
+   acpi_device_set_enumerated(device);
+
+   return ret;
+}
+
+static const struct acpi_device_id acpi_msi_device_ids[] = {
+   {"APMC0D0E", 0},
+   { }
+};
+
+int __init acpi_msi_init(void)
+{
+   acpi_status status;
+   int ret = 0;
+
+   status = acpi_get_devices(acpi_msi_device_ids[0].id,
+   acpi_create_msi_device, NULL, NULL);
+   if (ACPI_FAILURE(status))
+   ret = -ENODEV;
+
+   return ret;
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 58dd7ab..3da50d3 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -80,6 +80,7 @@ int acpi_scan_add_handler_with_hotplug(struct 
acpi_scan_handler *handler,
 void acpi_lpss_init(void);
 
 void acpi_apd_init(void);
+int acpi_msi_init(void);
 
 acpi_status acpi_hotplug_schedule(struct acpi_device *adev, u32 src);
 bool acpi_queue_hotplug_work(struct work_struct *work);
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 3389729..8ec4d39 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2029,6 +2029,7 @@ int __init acpi_scan_init(void)
acpi_status status;
struct acpi_table_stao *stao_ptr;
 
+   acpi_msi_init();
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index f1b633b..b1768a1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MSI_IR0   

[PATCH] staging/rtl8723bs: Fix some coding style issues in rtw_odm.c.

2017-08-11 Thread Tom Gardi
WARNING: line over 80 characters
WARNING: static const char * array should probably be static const char * const
CHECK: Unnecessary parentheses around hal_data->odmpriv

Signed-off-by: Tom Gardi 
---
 drivers/staging/rtl8723bs/core/rtw_odm.c | 38 ++--
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_odm.c 
b/drivers/staging/rtl8723bs/core/rtw_odm.c
index 3144e8e..edbcaeb 100644
--- a/drivers/staging/rtl8723bs/core/rtw_odm.c
+++ b/drivers/staging/rtl8723bs/core/rtw_odm.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 
-static const char *odm_comp_str[] = {
+static const char * const odm_comp_str[] = {
/* BIT0 */"ODM_COMP_DIG",
/* BIT1 */"ODM_COMP_RA_MASK",
/* BIT2 */"ODM_COMP_DYNAMIC_TXPWR",
@@ -55,7 +55,7 @@ static const char *odm_comp_str[] = {
 
 #define RTW_ODM_COMP_MAX 32
 
-static const char *odm_ability_str[] = {
+static const char * const odm_ability_str[] = {
/* BIT0 */"ODM_BB_DIG",
/* BIT1 */"ODM_BB_RA_MASK",
/* BIT2 */"ODM_BB_DYNAMIC_TXPWR",
@@ -87,7 +87,7 @@ static const char *odm_ability_str[] = {
 
 #define RTW_ODM_ABILITY_MAX 27
 
-static const char *odm_dbg_level_str[] = {
+static const char * const odm_dbg_level_str[] = {
NULL,
"ODM_DBG_OFF",
"ODM_DBG_SERIOUS",
@@ -127,7 +127,8 @@ void rtw_odm_dbg_level_msg(void *sel, struct adapter 
*adapter)
DBG_871X_SEL_NL(sel, "odm.DebugLevel = %u\n", dbg_level);
for (i = 0; i < RTW_ODM_DBG_LEVEL_NUM; i++) {
if (odm_dbg_level_str[i])
-   DBG_871X_SEL_NL(sel, "%u %s\n", i, 
odm_dbg_level_str[i]);
+   DBG_871X_SEL_NL(sel, "%u %s\n",
+   i, odm_dbg_level_str[i]);
}
 }
 
@@ -161,20 +162,23 @@ void rtw_odm_adaptivity_parm_msg(void *sel, struct 
adapter *adapter)
struct hal_com_data *pHalData = GET_HAL_DATA(adapter);
DM_ODM_T *odm = &pHalData->odmpriv;
 
-   DBG_871X_SEL_NL(sel, "%10s %16s %8s %10s %11s %14s\n"
-   , "TH_L2H_ini", "TH_EDCCA_HL_diff", "IGI_Base", "ForceEDCCA", 
"AdapEn_RSSI", "IGI_LowerBound");
-   DBG_871X_SEL_NL(sel, "0x%-8x %-16d 0x%-6x %-10d %-11u %-14u\n"
-   , (u8)odm->TH_L2H_ini
-   , odm->TH_EDCCA_HL_diff
-   , odm->IGI_Base
-   , odm->ForceEDCCA
-   , odm->AdapEn_RSSI
-   , odm->IGI_LowerBound
+   DBG_871X_SEL_NL(sel, "%10s %16s %8s %10s %11s %14s\n",
+   "TH_L2H_ini", "TH_EDCCA_HL_diff", "IGI_Base",
+   "ForceEDCCA", "AdapEn_RSSI", "IGI_LowerBound");
+   DBG_871X_SEL_NL(sel, "0x%-8x %-16d 0x%-6x %-10d %-11u %-14u\n",
+   (u8)odm->TH_L2H_ini,
+   odm->TH_EDCCA_HL_diff,
+   odm->IGI_Base,
+   odm->ForceEDCCA,
+   odm->AdapEn_RSSI,
+   odm->IGI_LowerBound
);
 }
 
-void rtw_odm_adaptivity_parm_set(struct adapter *adapter, s8 TH_L2H_ini, s8 
TH_EDCCA_HL_diff,
-   s8 IGI_Base, bool ForceEDCCA, u8 AdapEn_RSSI, u8 IGI_LowerBound)
+void rtw_odm_adaptivity_parm_set(struct adapter *adapter, s8 TH_L2H_ini,
+s8 TH_EDCCA_HL_diff, s8 IGI_Base,
+bool ForceEDCCA, u8 AdapEn_RSSI,
+u8 IGI_LowerBound)
 {
struct hal_com_data *pHalData = GET_HAL_DATA(adapter);
DM_ODM_T *odm = &pHalData->odmpriv;
@@ -190,8 +194,8 @@ void rtw_odm_adaptivity_parm_set(struct adapter *adapter, 
s8 TH_L2H_ini, s8 TH_E
 void rtw_odm_get_perpkt_rssi(void *sel, struct adapter *adapter)
 {
struct hal_com_data *hal_data = GET_HAL_DATA(adapter);
-   DM_ODM_T *odm = &(hal_data->odmpriv);
+   DM_ODM_T *odm = &hal_data->odmpriv;
 
DBG_871X_SEL_NL(sel, "RxRate = %s, RSSI_A = %d(%%), RSSI_B = %d(%%)\n",
-   HDATA_RATE(odm->RxRate), odm->RSSI_A, odm->RSSI_B);
+   HDATA_RATE(odm->RxRate), odm->RSSI_A, odm->RSSI_B);
 }
-- 
2.7.4



Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

2017-08-11 Thread Wei Wang
> If after Cong's fix, the issue still happens, could you help try the
> patch attached and collect all logs when you try the reproduce the
> issue? It would be great to have logs for both success case and the
> failure case.
>
> Thanks so much for your help.
>

I think we have a potential fix for this issue.
Martin and I found that when addrconf_dst_alloc() creates a rt6, it is
possible that rt6->dst.dev points to loopback device while
rt6->rt6i_idev->dev points to a real device.
When the real device goes down, the current fib6 clean up code only
checks for rt6->dst.dev and assumes rt6->rt6i_idev->dev is the same.
That leaves unreleased refcnt on the real device if rt6->dst.dev
points to loopback dev.

The attached potential fix is tested by Martin and made sure it fixes his issue.

John,
It will be great if you can also give it a try and see if it fixes the
issue on your side before I submit an official patch.

Thanks very much for the help from everyone.

Wei

On Fri, Aug 11, 2017 at 10:25 AM, Wei Wang  wrote:
> On Fri, Aug 11, 2017 at 9:48 AM, Cong Wang  wrote:
>> Hi,
>>
>> On Thu, Aug 10, 2017 at 11:12 AM, John Stultz  wrote:
>>> On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang  wrote:
 Hi John,

 Is it possible to try the attached patch?
>>>
>>> Thanks so much for the quick turn around!
>>>
>>> So I dropped all the reverts you suggested, and applied this one
>>> against 4.13-rc4, but I'm still seeing the problematic behavior.
>>
>> Does the following one-line fix make a difference?
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index a640fbcba15d..c145a35763a0 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -141,7 +141,7 @@ static void rt6_uncached_list_del(struct rt6_info *rt)
>> struct uncached_list *ul = rt->rt6i_uncached_list;
>>
>> spin_lock_bh(&ul->lock);
>> -   list_del(&rt->rt6i_uncached);
>> +   list_del_init(&rt->rt6i_uncached);
>> spin_unlock_bh(&ul->lock);
>> }
>>  }
>
>
> Thanks a lot Cong for proposing this fix.
>
> For the last few days, John has been helping me running debug image
> and we found out that the leaked dst is probably in addrconf.c.
> Martin and I are looking through the code and trying to put more debugs.
>
> John,
>
> If after Cong's fix, the issue still happens, could you help try the
> patch attached and collect all logs when you try the reproduce the
> issue? It would be great to have logs for both success case and the
> failure case.
>
> Thanks so much for your help.
>
> Wei
From 2d8861808c2029013f6b6e86120ba6902329145b Mon Sep 17 00:00:00 2001
From: Wei Wang 
Date: Fri, 11 Aug 2017 16:36:04 -0700
Subject: [PATCH 1/2] potential fix for unregister_netdevice()

Change-Id: I5d5f6f7a7ad0f5dd769f33487db17ff2570d52ea
---
 net/ipv6/route.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 4d30c96a819d..105922903932 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -417,14 +417,12 @@ static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
 	struct net_device *loopback_dev =
 		dev_net(dev)->loopback_dev;
 
-	if (dev != loopback_dev) {
-		if (idev && idev->dev == dev) {
-			struct inet6_dev *loopback_idev =
-in6_dev_get(loopback_dev);
-			if (loopback_idev) {
-rt->rt6i_idev = loopback_idev;
-in6_dev_put(idev);
-			}
+	if (idev && idev->dev != loopback_dev) {
+		struct inet6_dev *loopback_idev =
+			in6_dev_get(loopback_dev);
+		if (loopback_idev) {
+			rt->rt6i_idev = loopback_idev;
+			in6_dev_put(idev);
 		}
 	}
 }
@@ -2789,7 +2787,8 @@ static int fib6_ifdown(struct rt6_info *rt, void *arg)
 	const struct arg_dev_net *adn = arg;
 	const struct net_device *dev = adn->dev;
 
-	if ((rt->dst.dev == dev || !dev) &&
+	if ((rt->dst.dev == dev || !dev ||
+	 rt->rt6i_idev->dev == dev) &&
 	rt != adn->net->ipv6.ip6_null_entry &&
 	(rt->rt6i_nsiblings == 0 ||
 	 (dev && netdev_unregistering(dev)) ||
-- 
2.14.0.434.g98096fd7a8-goog



Re: [PATCH v4] arm64: allwinner: a64: Add initial NanoPi A64 support

2017-08-11 Thread icenowy

在 2017-08-12 01:42,Jagan Teki 写道:
On Fri, Aug 11, 2017 at 6:01 PM, Jagan Teki  
wrote:

From: Jagan Teki 

NanoPi A64 is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner A64 SOC.

Nanopi A64 features
- Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
- 1GB DDR3 RAM
- MicroSD
- Gigabit Ethernet (RTL8211E)
- Wi-Fi 802.11b/g/n
- IR receiver
- Audio In/Out
- Video In/Out
- Serial Debug Port
- microUSB 5V 2A DC power-supply

Signed-off-by: Jagan Teki 
---
Changes for v4:
- Rebased and droped wi-fi related nodes, since it require
  other changes to taken care.
Changes for v3:
- Fix to use mmc1 for SDIO instead of mmc2
- Replace buswidth by 4 instead of 8 mmc1
- Drop cap-mmc-hw-reset for mmc1
Changes for v2:
- Added ohci0, ehci0, ohic1, ehci1, usbphy.
- Tested on A64

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 114 
+

 2 files changed, 115 insertions(+)
 create mode 100644 
arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts


diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile

index 108f12c..c997b5c 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb 
sun50i-a64-pine64.dtb

 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts

new file mode 100644
index 000..e4c121a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -0,0 +1,114 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of 
the

+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the 
Software.

+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
WARRANTIES

+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi A64";
+   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };


Able to build the RSB with CONFIG_SUNXI_RSB and CONFIG_MFD_AXP20X_RSB
and when I replace the above regulator with axp308 dcdc1 for mmc the
SD card is not detecting and the same issue with pine64 as well.


For MFD devices, you need not only the MFD driver, but also drivers for
MFD cells.

For AXP803 currently PEK and regulator cells are supported. The PEK
driver is CONFIG_INPUT_AXP20X_PEK and the regulator driver is
CONFIG_REGULATOR_AXP20X.

I think you missed the CONFIG_REGULATOR_AXP20X driver.



[0

[PATCH 0/2] Add hugetlbfs support to memfd_create()

2017-08-11 Thread Mike Kravetz
This is a resend of the patch sent in the RFC:
http://lkml.kernel.org/r/1502149672-7759-1-git-send-email-mike.krav...@oracle.com

It addresses the issues with the commit message raised by Michal Hocko.
Only the commit message is modified, the code from the RFC patch is the
same.

In addition, a new patch is included to modify the memfd selftest.  The
modifications allow basic functionality testing of memfd_create with
hugetlbfs.

Mike Kravetz (2):
  mm/shmem: add hugetlbfs support to memfd_create()
  selftests/memfd: Add memfd_create hugetlbfs selftest

 include/uapi/linux/memfd.h |  24 ++
 mm/shmem.c |  37 ++-
 tools/testing/selftests/memfd/Makefile |   2 +-
 tools/testing/selftests/memfd/memfd_test.c | 372 ++---
 tools/testing/selftests/memfd/run_tests.sh |  69 ++
 5 files changed, 412 insertions(+), 92 deletions(-)
 create mode 100755 tools/testing/selftests/memfd/run_tests.sh

-- 
2.7.5



[PATCH 2/2] selftests/memfd: Add memfd_create hugetlbfs selftest

2017-08-11 Thread Mike Kravetz
With the addition of hugetlbfs support in memfd_create, the memfd
selftests should verify correct functionality with hugetlbfs.

Instead of writing a separate memfd hugetlbfs test, modify the
memfd_test program to take an optional argument 'hugetlbfs'.  If
the hugetlbfs argument is specified, basic memfd_create functionality
will be exercised on hugetlbfs.  If hugetlbfs is not specified, the
current functionality of the test is unchanged.

Note that many of the tests in memfd_test test file sealing operations.
hugetlbfs does not support file sealing, therefore for hugetlbfs all
sealing related tests are skipped.

In order to test on hugetlbfs, there needs to be preallocated huge pages.
A new script (run_tests) is added.  This script will first run the
existing memfd_create tests.  It will then, attempt to allocate the
required number of huge pages before running the hugetlbfs test.  At
the end of testing, it will release any huge pages allocated for testing
purposes.

Signed-off-by: Mike Kravetz 
---
 tools/testing/selftests/memfd/Makefile |   2 +-
 tools/testing/selftests/memfd/memfd_test.c | 372 ++---
 tools/testing/selftests/memfd/run_tests.sh |  69 ++
 3 files changed, 357 insertions(+), 86 deletions(-)
 create mode 100755 tools/testing/selftests/memfd/run_tests.sh

diff --git a/tools/testing/selftests/memfd/Makefile 
b/tools/testing/selftests/memfd/Makefile
index ad8a089..bc9d02d 100644
--- a/tools/testing/selftests/memfd/Makefile
+++ b/tools/testing/selftests/memfd/Makefile
@@ -3,7 +3,7 @@ CFLAGS += -I../../../../include/uapi/
 CFLAGS += -I../../../../include/
 CFLAGS += -I../../../../usr/include/
 
-TEST_PROGS := run_fuse_test.sh
+TEST_PROGS := run_tests.sh
 TEST_GEN_FILES := memfd_test fuse_mnt fuse_test
 
 fuse_mnt.o: CFLAGS += $(shell pkg-config fuse --cflags)
diff --git a/tools/testing/selftests/memfd/memfd_test.c 
b/tools/testing/selftests/memfd/memfd_test.c
index 2654689..f94c6d1 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -18,12 +18,48 @@
 #include 
 #include 
 
+#define MEMFD_STR  "memfd:"
+#define SHARED_FT_STR  "(shared file-table)"
+
 #define MFD_DEF_SIZE 8192
 #define STACK_SIZE 65536
 
+/*
+ * Default is not to test hugetlbfs
+ */
+static int hugetlbfs_test;
+static size_t mfd_def_size = MFD_DEF_SIZE;
+
+/*
+ * Copied from mlock2-tests.c
+ */
+static unsigned long default_huge_page_size(void)
+{
+   unsigned long hps = 0;
+   char *line = NULL;
+   size_t linelen = 0;
+   FILE *f = fopen("/proc/meminfo", "r");
+
+   if (!f)
+   return 0;
+   while (getline(&line, &linelen, f) > 0) {
+   if (sscanf(line, "Hugepagesize:   %lu kB", &hps) == 1) {
+   hps <<= 10;
+   break;
+   }
+   }
+
+   free(line);
+   fclose(f);
+   return hps;
+}
+
 static int sys_memfd_create(const char *name,
unsigned int flags)
 {
+   if (hugetlbfs_test)
+   flags |= MFD_HUGETLB;
+
return syscall(__NR_memfd_create, name, flags);
 }
 
@@ -150,7 +186,7 @@ static void *mfd_assert_mmap_shared(int fd)
void *p;
 
p = mmap(NULL,
-MFD_DEF_SIZE,
+mfd_def_size,
 PROT_READ | PROT_WRITE,
 MAP_SHARED,
 fd,
@@ -168,7 +204,7 @@ static void *mfd_assert_mmap_private(int fd)
void *p;
 
p = mmap(NULL,
-MFD_DEF_SIZE,
+mfd_def_size,
 PROT_READ,
 MAP_PRIVATE,
 fd,
@@ -223,7 +259,7 @@ static void mfd_assert_read(int fd)
 
/* verify PROT_READ *is* allowed */
p = mmap(NULL,
-MFD_DEF_SIZE,
+mfd_def_size,
 PROT_READ,
 MAP_PRIVATE,
 fd,
@@ -232,11 +268,11 @@ static void mfd_assert_read(int fd)
printf("mmap() failed: %m\n");
abort();
}
-   munmap(p, MFD_DEF_SIZE);
+   munmap(p, mfd_def_size);
 
/* verify MAP_PRIVATE is *always* allowed (even writable) */
p = mmap(NULL,
-MFD_DEF_SIZE,
+mfd_def_size,
 PROT_READ | PROT_WRITE,
 MAP_PRIVATE,
 fd,
@@ -245,7 +281,7 @@ static void mfd_assert_read(int fd)
printf("mmap() failed: %m\n");
abort();
}
-   munmap(p, MFD_DEF_SIZE);
+   munmap(p, mfd_def_size);
 }
 
 static void mfd_assert_write(int fd)
@@ -254,16 +290,22 @@ static void mfd_assert_write(int fd)
void *p;
int r;
 
-   /* verify write() succeeds */
-   l = write(fd, "\0\0\0\0", 4);
-   if (l != 4) {
-   printf("write() failed: %m\n");
-   abort();
+   /*
+* huegtlbfs does not support write, but we want to
+* verify everything else here.
+

[PATCH 1/2] mm/shmem: add hugetlbfs support to memfd_create()

2017-08-11 Thread Mike Kravetz
This patch came out of discussions in this e-mail thread:
http://lkml.kernel.org/r/1499357846-7481-1-git-send-email-mike.kravetz%40oracle.com

The Oracle JVM team is developing a new garbage collection model.  This
new model requires multiple mappings of the same anonymous memory.  One
straight forward way to accomplish this is with memfd_create.  They can
use the returned fd to create multiple mappings of the same memory.

The JVM today has an option to use (static hugetlb) huge pages.  If this
option is specified, they would like to use the same garbage collection
model requiring multiple mappings to the same memory.  Using hugetlbfs,
it is possible to explicitly mount a filesystem and specify file paths
in order to get an fd that can be used for multiple mappings.  However,
this introduces additional system admin work and coordination.

Ideally they would like to get a hugetlbfs fd without requiring explicit
mounting of a filesystem.   Today, mmap and shmget can make use of
hugetlbfs without explicitly mounting a filesystem.  The patch adds this
functionality to memfd_create.

Add a new flag MFD_HUGETLB to memfd_create() that will specify the
file to be created resides in the hugetlbfs filesystem.  This is
the generic hugetlbfs filesystem not associated with any specific
mount point.  As with other system calls that request hugetlbfs
backed pages, there is the ability to encode huge page size in the
flag arguments.

hugetlbfs does not support sealing operations, therefore specifying
MFD_ALLOW_SEALING with MFD_HUGETLB will result in EINVAL.

Signed-off-by: Mike Kravetz 
Acked-by: Michal Hocko 
---
 include/uapi/linux/memfd.h | 24 
 mm/shmem.c | 37 +++--
 2 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
index 534e364..7f3a722 100644
--- a/include/uapi/linux/memfd.h
+++ b/include/uapi/linux/memfd.h
@@ -1,8 +1,32 @@
 #ifndef _UAPI_LINUX_MEMFD_H
 #define _UAPI_LINUX_MEMFD_H
 
+#include 
+
 /* flags for memfd_create(2) (unsigned int) */
 #define MFD_CLOEXEC0x0001U
 #define MFD_ALLOW_SEALING  0x0002U
+#define MFD_HUGETLB0x0004U
+
+/*
+ * Huge page size encoding when MFD_HUGETLB is specified, and a huge page
+ * size other than the default is desired.  See hugetlb_encode.h.
+ * All known huge page size encodings are provided here.  It is the
+ * responsibility of the application to know which sizes are supported on
+ * the running system.  See mmap(2) man page for details.
+ */
+#define MFD_HUGE_SHIFT HUGETLB_FLAG_ENCODE_SHIFT
+#define MFD_HUGE_MASK  HUGETLB_FLAG_ENCODE_MASK
+
+#define MFD_HUGE_64KB  HUGETLB_FLAG_ENCODE_64KB
+#define MFD_HUGE_512KB HUGETLB_FLAG_ENCODE_512KB
+#define MFD_HUGE_1MB   HUGETLB_FLAG_ENCODE_1MB
+#define MFD_HUGE_2MB   HUGETLB_FLAG_ENCODE_2MB
+#define MFD_HUGE_8MB   HUGETLB_FLAG_ENCODE_8MB
+#define MFD_HUGE_16MB  HUGETLB_FLAG_ENCODE_16MB
+#define MFD_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define MFD_HUGE_1GB   HUGETLB_FLAG_ENCODE_1GB
+#define MFD_HUGE_2GB   HUGETLB_FLAG_ENCODE_2GB
+#define MFD_HUGE_16GB  HUGETLB_FLAG_ENCODE_16GB
 
 #endif /* _UAPI_LINUX_MEMFD_H */
diff --git a/mm/shmem.c b/mm/shmem.c
index b0aa607..3db79ce 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include  /* for arch/microblaze update_mmu_cache() */
 
@@ -3627,7 +3628,7 @@ static int shmem_show_options(struct seq_file *seq, 
struct dentry *root)
 #define MFD_NAME_PREFIX_LEN (sizeof(MFD_NAME_PREFIX) - 1)
 #define MFD_NAME_MAX_LEN (NAME_MAX - MFD_NAME_PREFIX_LEN)
 
-#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING)
+#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB)
 
 SYSCALL_DEFINE2(memfd_create,
const char __user *, uname,
@@ -3639,8 +3640,18 @@ SYSCALL_DEFINE2(memfd_create,
char *name;
long len;
 
-   if (flags & ~(unsigned int)MFD_ALL_FLAGS)
-   return -EINVAL;
+   if (!(flags & MFD_HUGETLB)) {
+   if (flags & ~(unsigned int)MFD_ALL_FLAGS)
+   return -EINVAL;
+   } else {
+   /* Sealing not supported in hugetlbfs (MFD_HUGETLB) */
+   if (flags & MFD_ALLOW_SEALING)
+   return -EINVAL;
+   /* Allow huge page size encoding in flags. */
+   if (flags & ~(unsigned int)(MFD_ALL_FLAGS |
+   (MFD_HUGE_MASK << MFD_HUGE_SHIFT)))
+   return -EINVAL;
+   }
 
/* length includes terminating zero */
len = strnlen_user(uname, MFD_NAME_MAX_LEN + 1);
@@ -3671,16 +3682,30 @@ SYSCALL_DEFINE2(memfd_create,
goto err_name;
}
 
-   file = shmem_file_setup(name, 0, VM_NORESERVE);
+   if (flags & MFD_HUGETLB) {
+   struct user_struct *user = NULL;
+
+   file = hugetlb_file_setup(name, 0, VM_NORESERVE, &user,
+

[PATCH v6 3/3] sparc64: Cleanup hugepage table walk functions

2017-08-11 Thread Nitin Gupta
Flatten out nested code structure in huge_pte_offset()
and huge_pte_alloc().

Signed-off-by: Nitin Gupta 
---
 arch/sparc/mm/hugetlbpage.c | 54 +
 1 file changed, 20 insertions(+), 34 deletions(-)

diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 7acb84d..bcd8cdb 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -266,27 +266,19 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
-   pte_t *pte = NULL;
 
pgd = pgd_offset(mm, addr);
pud = pud_alloc(mm, pgd, addr);
if (!pud)
return NULL;
-
if (sz >= PUD_SIZE)
-   pte = (pte_t *)pud;
-   else {
-   pmd = pmd_alloc(mm, pud, addr);
-   if (!pmd)
-   return NULL;
-
-   if (sz >= PMD_SIZE)
-   pte = (pte_t *)pmd;
-   else
-   pte = pte_alloc_map(mm, pmd, addr);
-   }
-
-   return pte;
+   return (pte_t *)pud;
+   pmd = pmd_alloc(mm, pud, addr);
+   if (!pmd)
+   return NULL;
+   if (sz >= PMD_SIZE)
+   return (pte_t *)pmd;
+   return pte_alloc_map(mm, pmd, addr);
 }
 
 pte_t *huge_pte_offset(struct mm_struct *mm,
@@ -295,27 +287,21 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
-   pte_t *pte = NULL;
 
pgd = pgd_offset(mm, addr);
-   if (!pgd_none(*pgd)) {
-   pud = pud_offset(pgd, addr);
-   if (!pud_none(*pud)) {
-   if (is_hugetlb_pud(*pud))
-   pte = (pte_t *)pud;
-   else {
-   pmd = pmd_offset(pud, addr);
-   if (!pmd_none(*pmd)) {
-   if (is_hugetlb_pmd(*pmd))
-   pte = (pte_t *)pmd;
-   else
-   pte = pte_offset_map(pmd, addr);
-   }
-   }
-   }
-   }
-
-   return pte;
+   if (pgd_none(*pgd))
+   return NULL;
+   pud = pud_offset(pgd, addr);
+   if (pud_none(*pud))
+   return NULL;
+   if (is_hugetlb_pud(*pud))
+   return (pte_t *)pud;
+   pmd = pmd_offset(pud, addr);
+   if (pmd_none(*pmd))
+   return NULL;
+   if (is_hugetlb_pmd(*pmd))
+   return (pte_t *)pmd;
+   return pte_offset_map(pmd, addr);
 }
 
 void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
-- 
2.9.2



[PATCH v6 1/3] sparc64: Support huge PUD case in get_user_pages

2017-08-11 Thread Nitin Gupta
get_user_pages() is used to do direct IO. It already
handles the case where the address range is backed
by PMD huge pages. This patch now adds the case where
the range could be backed by PUD huge pages.

Signed-off-by: Nitin Gupta 
---
 arch/sparc/include/asm/pgtable_64.h | 15 +++--
 arch/sparc/mm/gup.c | 45 -
 2 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index 6fbd931..2579f5a 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -687,6 +687,8 @@ static inline unsigned long pmd_write(pmd_t pmd)
return pte_write(pte);
 }
 
+#define pud_write(pud) pte_write(__pte(pud_val(pud)))
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static inline unsigned long pmd_dirty(pmd_t pmd)
 {
@@ -823,9 +825,18 @@ static inline unsigned long __pmd_page(pmd_t pmd)
 
return ((unsigned long) __va(pfn << PAGE_SHIFT));
 }
+
+static inline unsigned long pud_page_vaddr(pud_t pud)
+{
+   pte_t pte = __pte(pud_val(pud));
+   unsigned long pfn;
+
+   pfn = pte_pfn(pte);
+
+   return ((unsigned long) __va(pfn << PAGE_SHIFT));
+}
+
 #define pmd_page(pmd)  virt_to_page((void *)__pmd_page(pmd))
-#define pud_page_vaddr(pud)\
-   ((unsigned long) __va(pud_val(pud)))
 #define pud_page(pud)  virt_to_page((void 
*)pud_page_vaddr(pud))
 #define pmd_clear(pmdp)(pmd_val(*(pmdp)) = 0UL)
 #define pud_present(pud)   (pud_val(pud) != 0U)
diff --git a/arch/sparc/mm/gup.c b/arch/sparc/mm/gup.c
index f80cfc6..d809099 100644
--- a/arch/sparc/mm/gup.c
+++ b/arch/sparc/mm/gup.c
@@ -103,6 +103,45 @@ static int gup_huge_pmd(pmd_t *pmdp, pmd_t pmd, unsigned 
long addr,
return 1;
 }
 
+static int gup_huge_pud(pud_t *pudp, pud_t pud, unsigned long addr,
+   unsigned long end, int write, struct page **pages,
+   int *nr)
+{
+   struct page *head, *page;
+   int refs;
+
+   if (!(pud_val(pud) & _PAGE_VALID))
+   return 0;
+
+   if (write && !pud_write(pud))
+   return 0;
+
+   refs = 0;
+   page = pud_page(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+   head = compound_head(page);
+   do {
+   VM_BUG_ON(compound_head(page) != head);
+   pages[*nr] = page;
+   (*nr)++;
+   page++;
+   refs++;
+   } while (addr += PAGE_SIZE, addr != end);
+
+   if (!page_cache_add_speculative(head, refs)) {
+   *nr -= refs;
+   return 0;
+   }
+
+   if (unlikely(pud_val(pud) != pud_val(*pudp))) {
+   *nr -= refs;
+   while (refs--)
+   put_page(head);
+   return 0;
+   }
+
+   return 1;
+}
+
 static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
int write, struct page **pages, int *nr)
 {
@@ -141,7 +180,11 @@ static int gup_pud_range(pgd_t pgd, unsigned long addr, 
unsigned long end,
next = pud_addr_end(addr, end);
if (pud_none(pud))
return 0;
-   if (!gup_pmd_range(pud, addr, next, write, pages, nr))
+   if (unlikely(pud_large(pud))) {
+   if (!gup_huge_pud(pudp, pud, addr, next,
+ write, pages, nr))
+   return 0;
+   } else if (!gup_pmd_range(pud, addr, next, write, pages, nr))
return 0;
} while (pudp++, addr = next, addr != end);
 
-- 
2.9.2



[PATCH v6 2/3] sparc64: Add 16GB hugepage support

2017-08-11 Thread Nitin Gupta
Adds support for 16GB hugepage size. To use this page size
use kernel parameters as:

default_hugepagesz=16G hugepagesz=16G hugepages=10

Testing:

Tested with the stream benchmark which allocates 48G of
arrays backed by 16G hugepages and does RW operation on
them in parallel.

Orabug: 25362942

Cc: Anthony Yznaga 
Reviewed-by: Bob Picco 
Signed-off-by: Nitin Gupta 
---
 arch/sparc/include/asm/hugetlb.h|  7 
 arch/sparc/include/asm/page_64.h|  3 +-
 arch/sparc/include/asm/pgtable_64.h |  5 +++
 arch/sparc/include/asm/tsb.h| 36 ++
 arch/sparc/kernel/head_64.S |  2 +-
 arch/sparc/kernel/tsb.S |  2 +-
 arch/sparc/kernel/vmlinux.lds.S |  5 +++
 arch/sparc/mm/hugetlbpage.c | 74 ++---
 arch/sparc/mm/init_64.c | 54 +++
 9 files changed, 157 insertions(+), 31 deletions(-)

diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
index d1f837d..0ca7caa 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -4,6 +4,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_HUGETLB_PAGE
+struct pud_huge_patch_entry {
+   unsigned int addr;
+   unsigned int insn;
+};
+extern struct pud_huge_patch_entry __pud_huge_patch, __pud_huge_patch_end;
+#endif
 
 void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 pte_t *ptep, pte_t pte);
diff --git a/arch/sparc/include/asm/page_64.h b/arch/sparc/include/asm/page_64.h
index 5961b2d..8ee1f97 100644
--- a/arch/sparc/include/asm/page_64.h
+++ b/arch/sparc/include/asm/page_64.h
@@ -17,6 +17,7 @@
 
 #define HPAGE_SHIFT23
 #define REAL_HPAGE_SHIFT   22
+#define HPAGE_16GB_SHIFT   34
 #define HPAGE_2GB_SHIFT31
 #define HPAGE_256MB_SHIFT  28
 #define HPAGE_64K_SHIFT16
@@ -28,7 +29,7 @@
 #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
 #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
 #define REAL_HPAGE_PER_HPAGE   (_AC(1,UL) << (HPAGE_SHIFT - REAL_HPAGE_SHIFT))
-#define HUGE_MAX_HSTATE4
+#define HUGE_MAX_HSTATE5
 #endif
 
 #ifndef __ASSEMBLY__
diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index 2579f5a..4fefe37 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -414,6 +414,11 @@ static inline bool is_hugetlb_pmd(pmd_t pmd)
return !!(pmd_val(pmd) & _PAGE_PMD_HUGE);
 }
 
+static inline bool is_hugetlb_pud(pud_t pud)
+{
+   return !!(pud_val(pud) & _PAGE_PUD_HUGE);
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static inline pmd_t pmd_mkhuge(pmd_t pmd)
 {
diff --git a/arch/sparc/include/asm/tsb.h b/arch/sparc/include/asm/tsb.h
index 32258e0..acf5506 100644
--- a/arch/sparc/include/asm/tsb.h
+++ b/arch/sparc/include/asm/tsb.h
@@ -195,6 +195,41 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, 
__tsb_phys_patch_end;
 nop; \
 699:
 
+   /* PUD has been loaded into REG1, interpret the value, seeing
+* if it is a HUGE PUD or a normal one.  If it is not valid
+* then jump to FAIL_LABEL.  If it is a HUGE PUD, and it
+* translates to a valid PTE, branch to PTE_LABEL.
+*
+* We have to propagate bits [32:22] from the virtual address
+* to resolve at 4M granularity.
+*/
+#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
+#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, PTE_LABEL) \
+700:   ba 700f;\
+nop;   \
+   .section.pud_huge_patch, "ax";  \
+   .word   700b;   \
+   nop;\
+   .previous;  \
+   brz,pn  REG1, FAIL_LABEL;   \
+sethi  %uhi(_PAGE_PUD_HUGE), REG2; \
+   sllxREG2, 32, REG2; \
+   andcc   REG1, REG2, %g0;\
+   be,pt   %xcc, 700f; \
+sethi  %hi(0x1ffc), REG2;  \
+   sllxREG2, 1, REG2;  \
+   brgez,pnREG1, FAIL_LABEL;   \
+andn   REG1, REG2, REG1;   \
+   and VADDR, REG2, REG2;  \
+   brlz,pt REG1, PTE_LABEL;\
+or REG1, REG2, REG1;   \
+700:
+#else
+#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, PTE_LABEL) \
+   brz,pn  REG1, FAIL_LABEL; \
+nop;
+#endif
+
/* PMD has been loaded into REG1, interpret the value, seeing
 * if it is a HUGE PMD or a normal one.  If it is not valid
 * then jump to FAIL_LABEL.  If it is a HUGE PMD, and it
@@ -242,6 +277,7 @@ extern struc

Re: [PATCH] staging: typec: tcpm: Consider port_type while determining unattached_state

2017-08-11 Thread kbuild test robot
Hi Badhri,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc4 next-20170811]
[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/Badhri-Jagan-Sridharan/staging-typec-tcpm-Consider-port_type-while-determining-unattached_state/20170812-071822
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All error/warnings (new ones prefixed by >>):

   drivers/staging/typec/tcpm.c: In function 'unattached_state':
>> drivers/staging/typec/tcpm.c:2101:10: error: 'struct tcpm_port' has no 
>> member named 'port_type'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^
   drivers/staging/typec/tcpm.c:2106:17: error: 'struct tcpm_port' has no 
member named 'port_type'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^
>> drivers/staging/typec/tcpm.c:2111:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^

vim +2101 drivers/staging/typec/tcpm.c

  2098  
  2099  static inline enum tcpm_state unattached_state(struct tcpm_port *port)
  2100  {
> 2101  if (port->port_type == TYPEC_PORT_DRP) {
  2102  if (port->pwr_role == TYPEC_SOURCE)
  2103  return SRC_UNATTACHED;
  2104  else
  2105  return SNK_UNATTACHED;
  2106  } else if (port->port_type == TYPEC_PORT_DFP) {
  2107  return SRC_UNATTACHED;
  2108  } else {
  2109  return SNK_UNATTACHED;
  2110  }
> 2111  }
  2112  

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


.config.gz
Description: application/gzip


Re: [PATCH] staging: typec: tcpm: Consider port_type while determining unattached_state

2017-08-11 Thread kbuild test robot
Hi Badhri,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.13-rc4 next-20170811]
[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/Badhri-Jagan-Sridharan/staging-typec-tcpm-Consider-port_type-while-determining-unattached_state/20170812-071822
config: i386-randconfig-x019-201732 (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 >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/wait.h:6,
from include/linux/completion.h:11,
from drivers/staging/typec/tcpm.c:17:
   drivers/staging/typec/tcpm.c: In function 'unattached_state':
   drivers/staging/typec/tcpm.c:2101:10: error: 'struct tcpm_port' has no 
member named 'port_type'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/staging/typec/tcpm.c:2101:2: note: in expansion of macro 'if'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^~
   drivers/staging/typec/tcpm.c:2101:10: error: 'struct tcpm_port' has no 
member named 'port_type'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^
   include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/staging/typec/tcpm.c:2101:2: note: in expansion of macro 'if'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^~
   drivers/staging/typec/tcpm.c:2101:10: error: 'struct tcpm_port' has no 
member named 'port_type'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^
   include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> drivers/staging/typec/tcpm.c:2101:2: note: in expansion of macro 'if'
 if (port->port_type == TYPEC_PORT_DRP) {
 ^~
   drivers/staging/typec/tcpm.c:2106:17: error: 'struct tcpm_port' has no 
member named 'port_type'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   drivers/staging/typec/tcpm.c:2106:9: note: in expansion of macro 'if'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^~
   drivers/staging/typec/tcpm.c:2106:17: error: 'struct tcpm_port' has no 
member named 'port_type'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^
   include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
   drivers/staging/typec/tcpm.c:2106:9: note: in expansion of macro 'if'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^~
   drivers/staging/typec/tcpm.c:2106:17: error: 'struct tcpm_port' has no 
member named 'port_type'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^
   include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
   drivers/staging/typec/tcpm.c:2106:9: note: in expansion of macro 'if'
 } else if (port->port_type == TYPEC_PORT_DFP) {
^~
   drivers/staging/typec/tcpm.c: At top level:
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:390:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   _

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

2017-08-11 Thread Dan Williams
On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner  wrote:
> On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote:
>> >From falloc.h:
>>
>> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
>> file logical-to-physical extent offset mappings in the file. The
>> purpose is to allow an application to assume that there are no holes
>> or shared extents in the file and that the metadata needed to find
>> all the physical extents of the file is stable and can never be
>> dirtied.
>>
>> For now this patch only permits setting the in-memory state of
>> S_IOMAP_IMMMUTABLE. Support for clearing and persisting the state is
>> saved for later patches.
>>
>> The implementation is careful to not allow the immutable state to change
>> while any process might have any established mappings. It reuses the
>> existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
>> extents and fill all holes in the file. It then holds XFS_ILOCK_EXCL
>> while it validates the file is in the proper state and sets
>> S_IOMAP_IMMUTABLE.
>
> SO I've been thinking about this - I'm thinking that we need to
> separate the changes to the extent map from the action of sealing
> the extent map.
>
> That is, I have a need to freeze an extent map without any
> modification to it at all and breaking all the sharing and filling
> all the holes completely screws up the file layout I need to
> preserve. i.e. I want to be able to freeze the maps of a pair of
> reflinked files so I can use FIEMAP to query only the changed blocks
> and then read out the data in the private/changed blocks in the
> reflinked file. I only need a temporary seal (if we crash it goes
> away), so maybe there's another command modifier flag needed here,
> too.
>
> The DAX allocation requirements can be handled by a preallocation
> call to filll holes with zeros, followed by an unshare call to break
> all the COW mappings, and then the extent map can be sealed. If you
> need to check for holes after sealing, SEEK_HOLE will tell you what
> you need to know...
>
> My preference really is for each fallocate command to do just one
> thing - having the seal operation also modify the extent map
> means it's not useful for the use cases where we need the extent map
> to remain unmodified
>
> Thoughts?

That does seem to better follow the principle of least surprise and
make the interface more composable. However, for the DAX case do we
now end up needing a SEEK_SHARED, or something similar to check that
we sealed the file without shared extents?


Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

2017-08-11 Thread gengdongjiu
2017-08-11 21:19 GMT+08:00 Baicar, Tyler :
> I removed the apei_estatus_for_each_section because it was only being used
> in this one spot even though several other parts of the code do the same
> iteration (it is done several times in the CPER code). I made this iteration
> match the CPER iterations because the CPER iterations are verifying that the
> structures are all valid and lengths are correct. If those checks are being
> done this way, it makes the most sense to mimic that iteration here when
> calling into EDAC and triggering trace events.

I think the macro includes the verification for the structures and
lengths correction, it it does not correct, it will breadk the loop.
I do not see your modifcation does some special validation, it almost
smilar with the macro does.
in all the code there are three functions to do the iteration.
ghes_do_proc/cper_estatus_print/cper_estatus_check
the cper_estatus_check function is especial, because its  purpose is
to validate CPER, so it will  check every length. but not all
function's purpose is to check, for example cper_estatus_print, as
shown below, so we can use this macro to clear the code. Now we can
see there are two function use it, but in the future, if want to
iterate CPER, we can use the macro if it does not want to do special
thing.

#define apei_estatus_for_each_section(estatus, section) \
for (section = (struct acpi_hest_generic_data *)(estatus + 1); \
(void *)section - (void *)(estatus + 1) < estatus->data_length; \
--> here it will check whether length is valid, if not,  it will
break the loop
section = acpi_hest_get_next(section))


Original code:
void cper_estatus_print(const char *pfx,
   const struct acpi_hest_generic_status *estatus)
{
 struct acpi_hest_generic_data *gdata;
 unsigned int data_len;
 int sec_no = 0;
 char newpfx[64];
 __u16 severity;
 severity = estatus->error_severity;
 if (severity == CPER_SEV_CORRECTED)
  printk("%s%s\n", pfx,
 "It has been corrected by h/w "
 "and requires no further action");
 printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
 data_len = estatus->data_length;
 gdata = (struct acpi_hest_generic_data *)(estatus + 1);
 snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
 while (data_len >= acpi_hest_get_size(gdata)) {
  cper_estatus_print_section(newpfx, gdata, sec_no);
  data_len -= acpi_hest_get_record_size(gdata);
  gdata = acpi_hest_get_next(gdata);
  sec_no++;
 }
}

Can change to:
void cper_estatus_print(const char *pfx,
   const struct acpi_hest_generic_status *estatus)
{
 struct acpi_hest_generic_data *gdata;
 int sec_no = 0;
 char newpfx[64];
 __u16 severity;
 severity = estatus->error_severity;
 if (severity == CPER_SEV_CORRECTED)
  printk("%s%s\n", pfx,
 "It has been corrected by h/w "
 "and requires no further action");
 printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
 snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
 apei_estatus_for_each_section {
  cper_estatus_print_section(newpfx, gdata, sec_no);
  sec_no++;
 }
}



>
> Thanks,
>
> Tyler
>
>
> On 8/10/2017 3:37 PM, gengdongjiu wrote:
>>
>> may be directly remove the macro apei_estatus_for_each_section is not
>> better, if other place code also
>> needs to iterate through the GHES estatus blocks, it will be repeated
>> written again.
>>
>>
>> On 2017/8/11 5:31, gengdongjiu wrote:
>>>
>>> Hello,
>>>
>>> sorry, I do not see that. Just know I have reviewed your
>>> modification, may be my change can be simpleness and reserve the macro of
>>> apei_estatus_for_each_section
>>> can be used by other place to avoid duplicated code, such as prints the
>>> estatus blocks.
>>>
>>> On 2017/8/11 1:48, Baicar, Tyler wrote:

 Hello,

 I have already posted a patch fixing this. Please see:

 https://lkml.org/lkml/2017/8/3/824

 This makes the loop identical to the CPER code which prints the estatus
 blocks to the kernel logs.

 Thanks,

 Tyler


 On 8/10/2017 12:06 PM, Dongjiu Geng wrote:
>
> The revision 0x300 generic error data entry is different with the old
> version. when ghes_do_proc traverses to get the data entry, it does not
> consider this difference. so when error status block has revision 0x300
> data entry, it will have issue.
>
> Signed-off-by: Dongjiu Geng 
> ---
>drivers/acpi/apei/apei-internal.h | 4 ++--
>1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/apei/apei-internal.h
> b/drivers/acpi/apei/apei-internal.h
> index 6e9f14c0a71b..6491f1c4a96e 100644
> --- a/drivers/acpi/apei/apei-internal.h
> +++ b/drivers/acpi/apei/apei-internal.h
> @@ -122,8 +122,8 @@ struct dentry *apei_get_debugfs_dir(void);
>  #define apei_estatus_for_each_section(estatus, section)
> \
>for (section = (struct acpi_hest_generic_data *)(estatus + 1);
> \
> - (void *)se

Re: [PATCH 2/2] soc: qcom: smem: Support getting cached entries

2017-08-11 Thread Stephen Boyd
On 08/10/2017 12:37 PM, Bjorn Andersson wrote:
> @@ -252,6 +257,14 @@ phdr_to_last_uncached_entry(struct smem_partition_header 
> *phdr)
>   return p + le32_to_cpu(phdr->offset_free_uncached);
>  }
>  
> +static void *phdr_to_first_cached_entry(struct smem_partition_header *phdr,
> + size_t cacheline)
> +{
> + void *p = phdr;
> +
> + return p + phdr->size - ALIGN(sizeof(*phdr), cacheline);

le32_to_cpu(phrd->size) ?

> +}
> +
>  static void *phdr_to_last_cached_entry(struct smem_partition_header *phdr)
>  {
>   void *p = phdr;
> @@ -276,6 +289,14 @@ uncached_entry_next(struct smem_private_entry *e)
>  le32_to_cpu(e->size);
>  }
>  
> +static struct smem_private_entry *
> +cached_entry_next(struct smem_private_entry *e, size_t cacheline)
> +{
> + void *p = e;
> +
> + return p - le32_to_cpu(e->size) - ALIGN(sizeof(*e), cacheline);
> +}
> +
>  static void *uncached_entry_to_item(struct smem_private_entry *e)
>  {
>   void *p = e;
> @@ -283,6 +304,13 @@ static void *uncached_entry_to_item(struct 
> smem_private_entry *e)
>   return p + sizeof(*e) + le16_to_cpu(e->padding_hdr);
>  }
>  
> +static void *cached_entry_to_item(struct smem_private_entry *e)
> +{
> + void *p = e;
> +
> + return p - le16_to_cpu(e->size);

But it's a le32?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [kernel-hardening] [PATCH v5 00/10] Add support for eXclusive Page Frame Ownership

2017-08-11 Thread Laura Abbott
On 08/09/2017 01:07 PM, Tycho Andersen wrote:
> Hi all,
> 
> Here's a v5 of the XPFO set. Changes from v4 are:
> 
> * huge pages support actually works now on x86
> * arm64 support, which boots on several different arm64 boards
> * tests for hugepages support as well via LKDTM (thanks Kees for suggesting 
> how
>   to make this work)
> 
> Patch 2 contains some potentially controversial stuff, exposing the cpa_lock
> and lifting some other static functions out; there is probably a better way to
> do this, thoughts welcome.
> 
> Still to do are:
> 
> * get it to work with non-64k pages on ARM
> * get rid of the BUG()s, in favor or WARN or similar
> * other things people come up with in this review
> 
> Please have a look. Thoughts welcome!
> 

I gave this a quick test on my arm64 machine and I see faults once
we hit userspace:

[4.439714] Unhandled fault: TLB conflict abort (0x9630) at 
0x800391440090
[4.447357] Internal error: : 9630 [#1] SMP
[4.451875] Modules linked in:
[4.454924] CPU: 2 PID: 184 Comm: systemd Tainted: GW   
4.13.0-rc4-xpfo+ #63
[4.462989] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang 
Board, BIOS 3.06.12 Aug 12 2016
[4.472698] task: 8003e8d9fb00 task.stack: 8003f9fbc000
[4.478602] PC is at copy_page+0x48/0x110
[4.482601] LR is at __cpu_copy_user_page+0x28/0x48
 
I'll have to give this a closer look to see what's going on with the TLB 
flushing.

Thanks,
Laura


> Previously: http://www.openwall.com/lists/kernel-hardening/2017/06/07/24
> 
> Tycho
> 
> Juerg Haefliger (8):
>   mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)
>   swiotlb: Map the buffer if it was unmapped by XPFO
>   arm64: Add __flush_tlb_one()
>   arm64/mm: Add support for XPFO
>   arm64/mm: Disable section mappings if XPFO is enabled
>   arm64/mm: Don't flush the data cache if the page is unmapped by XPFO
>   arm64/mm: Add support for XPFO to swiotlb
>   lkdtm: Add test for XPFO
> 
> Tycho Andersen (2):
>   mm: add MAP_HUGETLB support to vm_mmap
>   mm: add a user_virt_to_phys symbol
> 
>  Documentation/admin-guide/kernel-parameters.txt |   2 +
>  arch/arm64/Kconfig  |   1 +
>  arch/arm64/include/asm/cacheflush.h |  11 ++
>  arch/arm64/include/asm/tlbflush.h   |   8 +
>  arch/arm64/mm/Makefile  |   2 +
>  arch/arm64/mm/dma-mapping.c |  32 ++--
>  arch/arm64/mm/flush.c   |   5 +-
>  arch/arm64/mm/mmu.c |  14 +-
>  arch/arm64/mm/xpfo.c| 160 +
>  arch/x86/Kconfig|   1 +
>  arch/x86/include/asm/pgtable.h  |  23 +++
>  arch/x86/mm/Makefile|   1 +
>  arch/x86/mm/pageattr.c  |  24 +--
>  arch/x86/mm/xpfo.c  | 153 +
>  drivers/misc/Makefile   |   1 +
>  drivers/misc/lkdtm.h|   4 +
>  drivers/misc/lkdtm_core.c   |   4 +
>  drivers/misc/lkdtm_xpfo.c   |  62 +++
>  include/linux/highmem.h |  15 +-
>  include/linux/mm.h  |   2 +
>  include/linux/xpfo.h|  47 +
>  lib/swiotlb.c   |   3 +-
>  mm/Makefile |   1 +
>  mm/mmap.c   |  19 +--
>  mm/page_alloc.c |   2 +
>  mm/page_ext.c   |   4 +
>  mm/util.c   |  32 
>  mm/xpfo.c   | 217 
> 
>  security/Kconfig|  19 +++
>  29 files changed, 810 insertions(+), 59 deletions(-)
>  create mode 100644 arch/arm64/mm/xpfo.c
>  create mode 100644 arch/x86/mm/xpfo.c
>  create mode 100644 drivers/misc/lkdtm_xpfo.c
>  create mode 100644 include/linux/xpfo.h
>  create mode 100644 mm/xpfo.c
> 



Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

2017-08-11 Thread Francois Romieu
David Miller  :
[...]
> Oops, this will need to be sent as a relative fixup as I've applied these
> two patches to net-next, sorry Francois.

No problem. It works perfectly this way.

-- 
Ueimor


Re: [PATCH v3 6/6] mm, xfs: protect swapfile contents with immutable + unwritten extents

2017-08-11 Thread Dave Chinner
On Thu, Aug 10, 2017 at 11:39:49PM -0700, Dan Williams wrote:
>   ifp = XFS_IFORK_PTR(ip, whichfork);
> diff --git a/fs/xfs/libxfs/xfs_bmap.h b/fs/xfs/libxfs/xfs_bmap.h
> index 851982a5dfbc..a0f099289520 100644
> --- a/fs/xfs/libxfs/xfs_bmap.h
> +++ b/fs/xfs/libxfs/xfs_bmap.h
> @@ -113,6 +113,15 @@ struct xfs_extent_free_item
>  /* Only convert delalloc space, don't allocate entirely new extents */
>  #define XFS_BMAPI_DELALLOC   0x400
>  
> +/*
> + * Permit extent manipulations even if S_IOMAP_IMMUTABLE is set on the
> + * inode. This is only expected to be used in the swapfile activation
> + * case where we want to mark all swap space as unwritten so that reads
> + * return zero and writes fail with ETXTBSY. Storage access in this
> + * state can only occur via swap operations.
> + */
> +#define XFS_BMAPI_FORCE  0x800

Urk. No. Immutable means immutable.

And, as a matter of policy, we should not be changing the on disk
layout of the swapfile that is provided inside the kernel.  If the
swap file is already allocated as unwritten, great. If not, we
should not force it to be unwritten to be because then if the user
downgrades their kernel the swapfile suddenly can not be used by the
older kernel.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


Re: [PATCH] fixdep: trivial: typo fix and correction

2017-08-11 Thread Masahiro Yamada
Hi.

2017-08-10 22:50 GMT+09:00 Cao jin :
> Hi Masahiro-san
>
> On 08/10/2017 12:05 AM, Masahiro Yamada wrote:
>> 2017-08-08 22:20 GMT+09:00 Cao jin :
>>> Signed-off-by: Cao jin 
>>
>> Applied to linux-kbuild/fixes.  Thanks!
>>
>
> I want to ask a question via this thread.
>
> I am tracing how each kernel source file compiled, and I met mounts-y in
> init/Makefile, I have trouble in finding the rule which compile
> $(mounts-y), but I clearly see the files in $(mounts-y) are compiled in
> the output of `make -n vmlinux`, but the files listed in mounts-y are
> not listed in obj-y. I think I must miss something, could you give some
> hint?
>


The magic is the following line:

scripts/Makefile.lib  line 55

# if $(foo-objs) exists, foo.o is a composite object
multi-used-y := $(sort $(foreach m,$(obj-y), $(if $(strip
$($(m:.o=-objs)) $($(m:.o=-y))), $(m


If foo.o is added to obj-y and foo-objs or foo-y exist,
they are also expanded.





If you see init/Makefile, mounts.o is added to obj-y.

obj-y  := main.o version.o mounts.o








-- 
Best Regards
Masahiro Yamada


[PATCH v2 03/19] perf, tools, stat: Fix saved values rbtree lookup

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

The stat shadow saved values rbtree is indexed by a pointer.
Fix the comparison function:

- We cannot return a pointer delta as an int because
that loses bits on 64bit.
- Doing pointer arithmetic on the struct pointer
only works if the objects are spaced by the multiple
of the object size, which is not guaranteed for individual
malloc'ed object

Replace it with a proper comparison.

This fixes various problems with values not being found.

Acked-by: Jiri Olsa 
Signed-off-by: Andi Kleen 
---
 tools/perf/util/stat-shadow.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 719d6cb86952..a04cf56d3517 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -70,7 +70,11 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
void *entry)
return a->ctx - b->ctx;
if (a->cpu != b->cpu)
return a->cpu - b->cpu;
-   return a->evsel - b->evsel;
+   if (a->evsel == b->evsel)
+   return 0;
+   if ((char *)a->evsel < (char *)b->evsel)
+   return -1;
+   return +1;
 }
 
 static struct rb_node *saved_value_new(struct rblist *rblist __maybe_unused,
-- 
2.9.4



[PATCH v2 06/19] perf, tools: Add missing newline to expr parser error messages

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Acked-by: Jiri Olsa 
Signed-off-by: Andi Kleen 
---
 tools/perf/util/expr.y | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index 954556bea36e..953e65ba2cc7 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -62,7 +62,7 @@ all_expr: expr{ *final_val = $1; }
 
 expr:NUMBER
| ID{ if (lookup_id(ctx, $1, &$$) < 0) {
-   pr_debug("%s not found", $1);
+   pr_debug("%s not found\n", $1);
YYABORT;
  }
}
-- 
2.9.4



[PATCH v2 02/19] perf, tools: Fix buffer overflow while freeing events

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Fix buffer overflow for

% perf stat -e msr/tsc/,cstate_core/c7-residency/ true

that causes glibc free list corruption. For some reason
it doesn't trigger in valgrind, but it is visible in AS:

=
==32681==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60303f5c at pc 0x005671ef bp 0x7ffdaaac9ac0 sp 0x7ffdaaac9ab0
READ of size 4 at 0x60303f5c thread T0
#0 0x5671ee in perf_evsel__close_fd util/evsel.c:1196
#1 0x56c57a in perf_evsel__close util/evsel.c:1717
#2 0x55ed5f in perf_evlist__close util/evlist.c:1631
#3 0x4647e1 in __run_perf_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:749
#4 0x4648e3 in run_perf_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:767
#5 0x46e1bc in cmd_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:2785
#6 0x52f83d in run_builtin /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:296
#7 0x52fd49 in handle_internal_command 
/home/ak/hle/linux-hle-2.6/tools/perf/perf.c:348
#8 0x5300de in run_argv /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:392
#9 0x5308f3 in main /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:530
#10 0x7f0672d13400 in __libc_start_main (/lib64/libc.so.6+0x20400)
#11 0x428419 in _start (/home/ak/hle/obj-perf/perf+0x428419)

0x60303f5c is located 0 bytes to the right of 28-byte region 
[0x60303f40,0x60303f5c)
allocated by thread T0 here:
#0 0x7f0675139020 in calloc (/lib64/libasan.so.3+0xc7020)
#1 0x648a2d in zalloc util/util.h:23
#2 0x648a88 in xyarray__new util/xyarray.c:9
#3 0x566419 in perf_evsel__alloc_fd util/evsel.c:1039
#4 0x56b427 in perf_evsel__open util/evsel.c:1529
#5 0x56c620 in perf_evsel__open_per_thread util/evsel.c:1730
#6 0x461dea in create_perf_stat_counter 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:263
#7 0x4637d7 in __run_perf_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:600
#8 0x4648e3 in run_perf_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:767
#9 0x46e1bc in cmd_stat 
/home/ak/hle/linux-hle-2.6/tools/perf/builtin-stat.c:2785
#10 0x52f83d in run_builtin /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:296
#11 0x52fd49 in handle_internal_command 
/home/ak/hle/linux-hle-2.6/tools/perf/perf.c:348
#12 0x5300de in run_argv /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:392
#13 0x5308f3 in main /home/ak/hle/linux-hle-2.6/tools/perf/perf.c:530
#14 0x7f0672d13400 in __libc_start_main (/lib64/libc.so.6+0x20400)

The event is allocated with cpus == 1, but freed with cpus == real number
When the evsel close function walks the file descriptors it exceeds the
fd xyarray boundaries and reads random memory.

v2:
Now that xyarrays save their original dimensions we can use these
to iterate the two dimensional fd arrays. Fix some users
(close, ioctl) in evsel.c to use these fields directly. This allows simplifying
the code and dropping quite a few function arguments. Adjust
all callers by removing the unneeded arguments.

The actual perf event reading still uses the original values from
the evsel list.

Signed-off-by: Andi Kleen 
---
 tools/perf/tests/openat-syscall-all-cpus.c |  2 +-
 tools/perf/tests/openat-syscall.c  |  2 +-
 tools/perf/util/evlist.c   | 12 +++---
 tools/perf/util/evsel.c| 37 ++
 tools/perf/util/evsel.h|  7 +++---
 5 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/tools/perf/tests/openat-syscall-all-cpus.c 
b/tools/perf/tests/openat-syscall-all-cpus.c
index 1a74dd9fd067..c7a57ba5b061 100644
--- a/tools/perf/tests/openat-syscall-all-cpus.c
+++ b/tools/perf/tests/openat-syscall-all-cpus.c
@@ -115,7 +115,7 @@ int test__openat_syscall_event_on_all_cpus(int subtest 
__maybe_unused)
 
perf_evsel__free_counts(evsel);
 out_close_fd:
-   perf_evsel__close_fd(evsel, 1, threads->nr);
+   perf_evsel__close_fd(evsel);
 out_evsel_delete:
perf_evsel__delete(evsel);
 out_thread_map_delete:
diff --git a/tools/perf/tests/openat-syscall.c 
b/tools/perf/tests/openat-syscall.c
index e44506e21ee7..121c7317bfc7 100644
--- a/tools/perf/tests/openat-syscall.c
+++ b/tools/perf/tests/openat-syscall.c
@@ -56,7 +56,7 @@ int test__openat_syscall_event(int subtest __maybe_unused)
 
err = 0;
 out_close_fd:
-   perf_evsel__close_fd(evsel, 1, threads->nr);
+   perf_evsel__close_fd(evsel);
 out_evsel_delete:
perf_evsel__delete(evsel);
 out_thread_map_delete:
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 078b58511595..6a0d7ffbeba0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1419,8 +1419,6 @@ int perf_evlist__apply_filters(struct perf_evlist 
*evlist, struct perf_evsel **e
 {
struct perf_evsel *evsel;
int err = 0;
-   const int ncpus = cpu_map__nr(evlist->cpus),
-   

Re: [GIT PULL] clockevents: fixes for 4.13-rc4

2017-08-11 Thread Ingo Molnar

* Daniel Lezcano  wrote:

> On 11/08/2017 20:43, Linus Torvalds wrote:
> > On Fri, Aug 11, 2017 at 7:16 AM, Daniel Lezcano
> >  wrote:
> >>
> >> The pull request contains the following fixes for 4.13-rc4
> > 
> > Usually these things go through Thomas, and you did say "Hi Ingo,
> > Thomas", so I'm ignoring this pull request.
> > 
> > But you *did* cc me, and it's possible that you did so on purpose,
> > expecting me to pull because everybody in Europe is on vacation.
> > 
> > So if you actually expect me to pull directly, please re-send and
> > explicitly say so, ok?
> 
> You are perfectly right, I was assuming everybody in Europe may be in
> vacation, so I let you know the pull request. However, Thomas will be
> back August, 14th, so I think you can ignore the pull request.

I'm back and my plan is to take a look and pull it tomorrow.

Thanks,

Ingo


[PATCH v2 13/19] perf, tools: Print generic metric header even for failed expressions

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Print the generic metric header even when the expression evaluation
failed. Otherwise an expression that fails on the first collections
due to division by zero may suddenly reappear later without
an header.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/stat-shadow.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index b6cbb6e67167..4ec2d8d15344 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -662,7 +662,9 @@ static void generic_metric(const char *metric_expr,
out->force_header ?  name : "",
ratio);
else
-   print_metric(ctxp, NULL, NULL, "", 0);
+   print_metric(ctxp, NULL, NULL,
+out->force_header ?
+(metric_name ? metric_name : name) : "", 
0);
} else
print_metric(ctxp, NULL, NULL, "", 0);
 }
-- 
2.9.4



[PATCH v2 10/19] perf, tools: Dedup events in expression parsing

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Avoid adding redundant events while parsing an expression.
When we add an "other" event check first if it already exists.

v2: Fix perf test failure.
Signed-off-by: Andi Kleen 
---
 tools/perf/util/expr.y | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index 5753c4f21534..432b8560cf51 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -181,6 +181,19 @@ void expr__ctx_init(struct parse_ctx *ctx)
ctx->num_ids = 0;
 }
 
+static bool already_seen(const char *val, const char *one, const char **other,
+int num_other)
+{
+   int i;
+
+   if (one && !strcasecmp(one, val))
+   return true;
+   for (i = 0; i < num_other; i++)
+   if (!strcasecmp(other[i], val))
+   return true;
+   return false;
+}
+
 int expr__find_other(const char *p, const char *one, const char ***other,
 int *num_otherp)
 {
@@ -200,7 +213,7 @@ int expr__find_other(const char *p, const char *one, const 
char ***other,
err = 0;
break;
}
-   if (tok == ID && (!one || strcasecmp(one, val.id))) {
+   if (tok == ID && !already_seen(val.id, one, *other, num_other)) 
{
if (num_other >= EXPR_MAX_OTHER - 1) {
pr_debug("Too many extra events in %s\n", orig);
break;
-- 
2.9.4



[PATCH v2 01/19] perf, tools: Save max_x, max_y in xyarray

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Save the original array dimensions in xyarrays, so that users can retrieve them
later. Add some inline functions to access these fields.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/xyarray.c |  2 ++
 tools/perf/util/xyarray.h | 12 
 2 files changed, 14 insertions(+)

diff --git a/tools/perf/util/xyarray.c b/tools/perf/util/xyarray.c
index 7251fdbabced..c8f415d9877b 100644
--- a/tools/perf/util/xyarray.c
+++ b/tools/perf/util/xyarray.c
@@ -12,6 +12,8 @@ struct xyarray *xyarray__new(int xlen, int ylen, size_t 
entry_size)
xy->entry_size = entry_size;
xy->row_size   = row_size;
xy->entries= xlen * ylen;
+   xy->max_x  = xlen;
+   xy->max_y  = ylen;
}
 
return xy;
diff --git a/tools/perf/util/xyarray.h b/tools/perf/util/xyarray.h
index 7f30af371b7e..785884158137 100644
--- a/tools/perf/util/xyarray.h
+++ b/tools/perf/util/xyarray.h
@@ -7,6 +7,8 @@ struct xyarray {
size_t row_size;
size_t entry_size;
size_t entries;
+   size_t max_x;
+   size_t max_y;
char contents[];
 };
 
@@ -19,4 +21,14 @@ static inline void *xyarray__entry(struct xyarray *xy, int 
x, int y)
return &xy->contents[x * xy->row_size + y * xy->entry_size];
 }
 
+static inline int xy_max_y(struct xyarray *xy)
+{
+   return xy->max_x;
+}
+
+static inline int xy_max_x(struct xyarray *xy)
+{
+   return xy->max_y;
+}
+
 #endif /* _PERF_XYARRAY_H_ */
-- 
2.9.4



[PATCH v2 09/19] perf, tools: Increase maximum number of events in expressions

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Some of the upcoming metrics need more than 8 events. Increase the maximum
number the parser supports.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/expr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 9c2760a1a96e..400ef9eab00a 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -1,7 +1,7 @@
 #ifndef PARSE_CTX_H
 #define PARSE_CTX_H 1
 
-#define EXPR_MAX_OTHER 8
+#define EXPR_MAX_OTHER 15
 #define MAX_PARSE_ID EXPR_MAX_OTHER
 
 struct parse_id {
-- 
2.9.4



[PATCH v2 11/19] perf, tools: Support metric_group and no event name in json parser

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Some enhancements to the JSON parser to prepare for metrics support

- Parse the new MetricGroup field
- Support JSON events with no event name, that have only MetricName.

Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c| 24 ++--
 tools/perf/pmu-events/jevents.h|  2 +-
 tools/perf/pmu-events/pmu-events.h |  1 +
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 2350f6099a46..8e7ced6a0517 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -290,7 +290,7 @@ static int print_events_table_entry(void *data, char *name, 
char *event,
char *desc, char *long_desc,
char *pmu, char *unit, char *perpkg,
char *metric_expr,
-   char *metric_name)
+   char *metric_name, char *metric_group)
 {
struct perf_entry_data *pd = data;
FILE *outfp = pd->outfp;
@@ -302,8 +302,10 @@ static int print_events_table_entry(void *data, char 
*name, char *event,
 */
fprintf(outfp, "{\n");
 
-   fprintf(outfp, "\t.name = \"%s\",\n", name);
-   fprintf(outfp, "\t.event = \"%s\",\n", event);
+   if (name)
+   fprintf(outfp, "\t.name = \"%s\",\n", name);
+   if (event)
+   fprintf(outfp, "\t.event = \"%s\",\n", event);
fprintf(outfp, "\t.desc = \"%s\",\n", desc);
fprintf(outfp, "\t.topic = \"%s\",\n", topic);
if (long_desc && long_desc[0])
@@ -318,6 +320,8 @@ static int print_events_table_entry(void *data, char *name, 
char *event,
fprintf(outfp, "\t.metric_expr = \"%s\",\n", metric_expr);
if (metric_name)
fprintf(outfp, "\t.metric_name = \"%s\",\n", metric_name);
+   if (metric_group)
+   fprintf(outfp, "\t.metric_group = \"%s\",\n", metric_group);
fprintf(outfp, "},\n");
 
return 0;
@@ -355,6 +359,9 @@ static char *real_event(const char *name, char *event)
 {
int i;
 
+   if (!name)
+   return NULL;
+
for (i = 0; fixed[i].name; i++)
if (!strcasecmp(name, fixed[i].name))
return (char *)fixed[i].event;
@@ -367,7 +374,7 @@ int json_events(const char *fn,
  char *long_desc,
  char *pmu, char *unit, char *perpkg,
  char *metric_expr,
- char *metric_name),
+ char *metric_name, char *metric_group),
  void *data)
 {
int err = -EIO;
@@ -395,6 +402,7 @@ int json_events(const char *fn,
char *unit = NULL;
char *metric_expr = NULL;
char *metric_name = NULL;
+   char *metric_group = NULL;
unsigned long long eventcode = 0;
struct msrmap *msr = NULL;
jsmntok_t *msrval = NULL;
@@ -474,6 +482,8 @@ int json_events(const char *fn,
addfield(map, &perpkg, "", "", val);
} else if (json_streq(map, field, "MetricName")) {
addfield(map, &metric_name, "", "", val);
+   } else if (json_streq(map, field, "MetricGroup")) {
+   addfield(map, &metric_group, "", "", val);
} else if (json_streq(map, field, "MetricExpr")) {
addfield(map, &metric_expr, "", "", val);
for (s = metric_expr; *s; s++)
@@ -499,10 +509,11 @@ int json_events(const char *fn,
addfield(map, &event, ",", filter, NULL);
if (msr != NULL)
addfield(map, &event, ",", msr->pname, msrval);
-   fixname(name);
+   if (name)
+   fixname(name);
 
err = func(data, name, real_event(name, event), desc, long_desc,
-   pmu, unit, perpkg, metric_expr, metric_name);
+  pmu, unit, perpkg, metric_expr, metric_name, 
metric_group);
free(event);
free(desc);
free(name);
@@ -514,6 +525,7 @@ int json_events(const char *fn,
free(unit);
free(metric_expr);
free(metric_name);
+   free(metric_group);
if (err)
break;
tok += j;
diff --git a/tools/perf/pmu-events/jevents.h b/tools/perf/pmu-events/jevents.h
index 611fac01913d..557994754410 100644
--- a/tools/perf/pmu-events/jevents.h
+++ b/tools/perf/pmu-events/jevents.h
@@ -6,7 +6,7 @@ int json_events(const char *fn,
char *long_desc,
char *pmu,
  

[PATCH v2 12/19] perf, tools, stat: Factor out generic metric printing

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

The perf stat shadow metric printing already supports generic metrics.
Factor out the code doing that into a separate function that can be re-used
in a later patch.

No behavior changes.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/stat-shadow.c | 69 ++-
 1 file changed, 42 insertions(+), 27 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index a04cf56d3517..b6cbb6e67167 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -627,6 +627,46 @@ static void print_smi_cost(int cpu, struct perf_evsel 
*evsel,
out->print_metric(out->ctx, NULL, "%4.0f", "SMI#", smi_num);
 }
 
+static void generic_metric(const char *metric_expr,
+  struct perf_evsel **metric_events,
+  char *name,
+  const char *metric_name,
+  double avg,
+  int cpu,
+  int ctx,
+  struct perf_stat_output_ctx *out)
+{
+   print_metric_t print_metric = out->print_metric;
+   struct parse_ctx pctx;
+   double ratio;
+   int i;
+   void *ctxp = out->ctx;
+
+   expr__ctx_init(&pctx);
+   expr__add_id(&pctx, name, avg);
+   for (i = 0; metric_events[i]; i++) {
+   struct saved_value *v;
+
+   v = saved_value_lookup(metric_events[i], cpu, ctx, false);
+   if (!v)
+   break;
+   expr__add_id(&pctx, metric_events[i]->name, 
avg_stats(&v->stats));
+   }
+   if (!metric_events[i]) {
+   const char *p = metric_expr;
+
+   if (expr__parse(&ratio, &pctx, &p) == 0)
+   print_metric(ctxp, NULL, "%8.1f",
+   metric_name ?
+   metric_name :
+   out->force_header ?  name : "",
+   ratio);
+   else
+   print_metric(ctxp, NULL, NULL, "", 0);
+   } else
+   print_metric(ctxp, NULL, NULL, "", 0);
+}
+
 void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
   double avg, int cpu,
   struct perf_stat_output_ctx *out)
@@ -819,33 +859,8 @@ void perf_stat__print_shadow_stats(struct perf_evsel 
*evsel,
else
print_metric(ctxp, NULL, NULL, name, 0);
} else if (evsel->metric_expr) {
-   struct parse_ctx pctx;
-   int i;
-
-   expr__ctx_init(&pctx);
-   expr__add_id(&pctx, evsel->name, avg);
-   for (i = 0; evsel->metric_events[i]; i++) {
-   struct saved_value *v;
-
-   v = saved_value_lookup(evsel->metric_events[i], cpu, 
ctx, false);
-   if (!v)
-   break;
-   expr__add_id(&pctx, evsel->metric_events[i]->name,
-avg_stats(&v->stats));
-   }
-   if (!evsel->metric_events[i]) {
-   const char *p = evsel->metric_expr;
-
-   if (expr__parse(&ratio, &pctx, &p) == 0)
-   print_metric(ctxp, NULL, "%8.1f",
-   evsel->metric_name ?
-   evsel->metric_name :
-   out->force_header ?  evsel->name : "",
-   ratio);
-   else
-   print_metric(ctxp, NULL, NULL, "", 0);
-   } else
-   print_metric(ctxp, NULL, NULL, "", 0);
+   generic_metric(evsel->metric_expr, evsel->metric_events, 
evsel->name,
+   evsel->metric_name, avg, cpu, ctx, out);
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
char unit_buf[10];
-- 
2.9.4



[PATCH v2 08/19] perf, tools: Expression parser enhancements for metrics

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Enhance the expression parser for more complex metric formulas.

- Support python style IF ELSE operators
- Add an #SMT_On magic variable for formulas that depend on the SMT
status.

Example: 4 *( CPU_CLK_UNHALTED.THREAD_ANY / 2 ) if #SMT_on else cycles

- Support MIN/MAX operations

Example: min(1 , IDQ.MITE_UOPS / ( UPI * 16 * ( ICACHE.HIT + ICACHE.MISSES ) / 
4.0 ) )

This is useful to fix up problems caused by multiplexing.

- Support | & ^ operators
- Minor cleanups and fixes
- Support an \ escape for operators. This allows to specify event names
like c2-residency
- Support @ as an alternative for / to be able to specify pmus without
conflicts with operators (like msr/tsc/ as msr@tsc@)

Example: (cstate_core@c3\\-residency@ / msr@tsc@) * 100

Signed-off-by: Andi Kleen 
---
 tools/perf/tests/expr.c |  5 
 tools/perf/util/expr.y  | 61 -
 2 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 6c6a3749aaf6..e75365098f23 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -31,6 +31,11 @@ int test__expr(int subtest __maybe_unused)
ret |= test(&ctx, "(BAR/2)%2", 1);
ret |= test(&ctx, "1 - -4",  5);
ret |= test(&ctx, "(FOO-1)*2 + (BAR/2)%2 - -4",  5);
+   ret |= test(&ctx, "1-1 | 1", 1);
+   ret |= test(&ctx, "1-1 & 1", 0);
+   ret |= test(&ctx, "min(1,2) + 1", 2);
+   ret |= test(&ctx, "max(1,2) + 1", 3);
+   ret |= test(&ctx, "1+1 if 3*4 else 0", 2);
 
if (ret)
return ret;
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index 953e65ba2cc7..5753c4f21534 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -4,6 +4,7 @@
 #include "util/debug.h"
 #define IN_EXPR_Y 1
 #include "expr.h"
+#include "smt.h"
 #include 
 
 #define MAXIDLEN 256
@@ -22,13 +23,15 @@
 
 %token  NUMBER
 %token  ID
+%token MIN MAX IF ELSE SMT_ON
+%left MIN MAX IF
 %left '|'
 %left '^'
 %left '&'
 %left '-' '+'
 %left '*' '/' '%'
 %left NEG NOT
-%type  expr
+%type  expr if_expr
 
 %{
 static int expr__lex(YYSTYPE *res, const char **pp);
@@ -57,7 +60,12 @@ static int lookup_id(struct parse_ctx *ctx, char *id, double 
*val)
 %}
 %%
 
-all_expr: expr { *final_val = $1; }
+all_expr: if_expr  { *final_val = $1; }
+   ;
+
+if_expr:
+   expr IF expr ELSE expr { $$ = $3 ? $1 : $5; }
+   | expr
;
 
 expr:NUMBER
@@ -66,13 +74,19 @@ expr: NUMBER
YYABORT;
  }
}
+   | expr '|' expr { $$ = (long)$1 | (long)$3; }
+   | expr '&' expr { $$ = (long)$1 & (long)$3; }
+   | expr '^' expr { $$ = (long)$1 ^ (long)$3; }
| expr '+' expr { $$ = $1 + $3; }
| expr '-' expr { $$ = $1 - $3; }
| expr '*' expr { $$ = $1 * $3; }
| expr '/' expr { if ($3 == 0) YYABORT; $$ = $1 / $3; }
| expr '%' expr { if ((long)$3 == 0) YYABORT; $$ = (long)$1 % 
(long)$3; }
| '-' expr %prec NEG{ $$ = -$2; }
-   | '(' expr ')'  { $$ = $2; }
+   | '(' if_expr ')'   { $$ = $2; }
+   | MIN '(' expr ',' expr ')' { $$ = $3 < $5 ? $3 : $5; }
+   | MAX '(' expr ',' expr ')' { $$ = $3 > $5 ? $3 : $5; }
+   | SMT_ON { $$ = smt_on() > 0; }
;
 
 %%
@@ -82,13 +96,47 @@ static int expr__symbol(YYSTYPE *res, const char *p, const 
char **pp)
char *dst = res->id;
const char *s = p;
 
-   while (isalnum(*p) || *p == '_' || *p == '.') {
+   if (*p == '#')
+   *dst++ = *p++;
+
+   while (isalnum(*p) || *p == '_' || *p == '.' || *p == ':' || *p == '@' 
|| *p == '\\') {
if (p - s >= MAXIDLEN)
return -1;
-   *dst++ = *p++;
+   /*
+* Allow @ instead of / to be able to specify pmu/event/ without
+* conflicts with normal division.
+*/
+   if (*p == '@')
+   *dst++ = '/';
+   else if (*p == '\\')
+   *dst++ = *++p;
+   else
+   *dst++ = *p;
+   p++;
}
*dst = 0;
*pp = p;
+   dst = res->id;
+   switch (dst[0]) {
+   case 'm':
+   if (!strcmp(dst, "min"))
+   return MIN;
+   if (!strcmp(dst, "max"))
+   return MAX;
+   break;
+   case 'i':
+   if (!strcmp(dst, "if"))
+   return IF;
+   break;
+   case 'e':
+   if (!strcmp(dst, "else"))
+   return ELSE;
+   break;
+   case '#':
+   if (!strcasecmp(dst, "#smt_on"))
+   return SMT_ON;

[PATCH v2 07/19] perf, tools: Add utility function to detect SMT status

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

Add an smt_on() function to return if SMT is enabled or disabled.
Used in the next patch.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/Build |  1 +
 tools/perf/util/smt.c | 44 
 tools/perf/util/smt.h |  6 ++
 3 files changed, 51 insertions(+)
 create mode 100644 tools/perf/util/smt.c
 create mode 100644 tools/perf/util/smt.h

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 8d49a989f193..94518c1bf8b6 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -22,6 +22,7 @@ libperf-y += rbtree.o
 libperf-y += libstring.o
 libperf-y += bitmap.o
 libperf-y += hweight.o
+libperf-y += smt.o
 libperf-y += quote.o
 libperf-y += strbuf.o
 libperf-y += string.o
diff --git a/tools/perf/util/smt.c b/tools/perf/util/smt.c
new file mode 100644
index ..453f6f6f29f3
--- /dev/null
+++ b/tools/perf/util/smt.c
@@ -0,0 +1,44 @@
+#include 
+#include 
+#include 
+#include 
+#include "api/fs/fs.h"
+#include "smt.h"
+
+int smt_on(void)
+{
+   static bool cached;
+   static int cached_result;
+   int cpu;
+   int ncpu;
+
+   if (cached)
+   return cached_result;
+
+   ncpu = sysconf(_SC_NPROCESSORS_CONF);
+   for (cpu = 0; cpu < ncpu; cpu++) {
+   unsigned long long siblings;
+   char *str;
+   size_t strlen;
+   char fn[256];
+
+   snprintf(fn, sizeof fn,
+   "devices/system/cpu/cpu%d/topology/thread_siblings",
+   cpu);
+   if (sysfs__read_str(fn, &str, &strlen) < 0)
+   continue;
+   /* Entry is hex, but does not have 0x, so need custom parser */
+   siblings = strtoull(str, NULL, 16);
+   free(str);
+   if (hweight64(siblings) > 1) {
+   cached_result = 1;
+   cached = true;
+   break;
+   }
+   }
+   if (!cached) {
+   cached_result = 0;
+   cached = true;
+   }
+   return cached_result;
+}
diff --git a/tools/perf/util/smt.h b/tools/perf/util/smt.h
new file mode 100644
index ..b8414b7bcbc8
--- /dev/null
+++ b/tools/perf/util/smt.h
@@ -0,0 +1,6 @@
+#ifndef SMT_H
+#define SMT_H 1
+
+int smt_on(void);
+
+#endif
-- 
2.9.4



[PATCH v2 16/19] perf, tools, stat: Don't use ctx for saved values lookup

2017-08-11 Thread Andi Kleen
From: Andi Kleen 

We don't need to use ctx to look up events for saved values.
The context is already part of the evsel pointer, which is the
primary key.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/stat-shadow.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 49b9931a7f63..11be64223196 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -56,7 +56,6 @@ struct saved_value {
struct rb_node rb_node;
struct perf_evsel *evsel;
int cpu;
-   int ctx;
struct stats stats;
 };
 
@@ -67,8 +66,6 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
void *entry)
 rb_node);
const struct saved_value *b = entry;
 
-   if (a->ctx != b->ctx)
-   return a->ctx - b->ctx;
if (a->cpu != b->cpu)
return a->cpu - b->cpu;
if (a->evsel == b->evsel)
@@ -90,13 +87,12 @@ static struct rb_node *saved_value_new(struct rblist 
*rblist __maybe_unused,
 }
 
 static struct saved_value *saved_value_lookup(struct perf_evsel *evsel,
- int cpu, int ctx,
+ int cpu,
  bool create)
 {
struct rb_node *nd;
struct saved_value dm = {
.cpu = cpu,
-   .ctx = ctx,
.evsel = evsel,
};
nd = rblist__find(&runtime_saved_values, &dm);
@@ -232,8 +228,7 @@ void perf_stat__update_shadow_stats(struct perf_evsel 
*counter, u64 *count,
update_stats(&runtime_aperf_stats[ctx][cpu], count[0]);
 
if (counter->collect_stat) {
-   struct saved_value *v = saved_value_lookup(counter, cpu, ctx,
-  true);
+   struct saved_value *v = saved_value_lookup(counter, cpu, true);
update_stats(&v->stats, count[0]);
}
 }
@@ -634,7 +629,6 @@ static void generic_metric(const char *metric_expr,
   const char *metric_name,
   double avg,
   int cpu,
-  int ctx,
   struct perf_stat_output_ctx *out)
 {
print_metric_t print_metric = out->print_metric;
@@ -648,7 +642,7 @@ static void generic_metric(const char *metric_expr,
for (i = 0; metric_events[i]; i++) {
struct saved_value *v;
 
-   v = saved_value_lookup(metric_events[i], cpu, ctx, false);
+   v = saved_value_lookup(metric_events[i], cpu, false);
if (!v)
break;
expr__add_id(&pctx, metric_events[i]->name, 
avg_stats(&v->stats));
@@ -866,7 +860,7 @@ void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
print_metric(ctxp, NULL, NULL, name, 0);
} else if (evsel->metric_expr) {
generic_metric(evsel->metric_expr, evsel->metric_events, 
evsel->name,
-   evsel->metric_name, avg, cpu, ctx, out);
+   evsel->metric_name, avg, cpu, out);
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
char unit_buf[10];
@@ -895,7 +889,7 @@ void perf_stat__print_shadow_stats(struct perf_evsel *evsel,
out->new_line(ctxp);
generic_metric(mexp->metric_expr, mexp->metric_events,
evsel->name, mexp->metric_name,
-   avg, cpu, ctx, out);
+   avg, cpu, out);
}
}
if (num == 0)
-- 
2.9.4



  1   2   3   4   5   6   7   8   9   >